Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
151 lines (131 sloc) 5.95 KB
Needs for Pre-Evaluation Writing:
What are the things can be done to set-up the problem
- Matching requirements (AADL) to components (properties, etc.)
- Then go into optimization
- What do the requirements look like
- What how do you set-up the language of the problem
- What are properties of components
- Novelty: use of AADL as language for requirements side, but also componentn properties (component security)
- Then set-up problem in scope of PBD hourglass
- Can pick a system to use as a model for this (e.g. car)
Position paper for the end of March
- How it should be done
- Set-up framework
Get idea onto paper for components/security properties/etc.
- Define everything!
- Look deeper into how AADL represents things
- AADL makes sense from requirements side (and from implementation level)
- SystemC makes sense in implementation level
- How to translate/map from one or the other
- Model production is mainly done by handle
- Lack of auto generation from a list of requirements
Come up with framework (more imporatnt)
- Then work to fit to an existing framework
Would good to have not only framework but also examples with what the language would look like
- Show why you chose AADL
- Why using the language chosen
See if displaying types in tables is a better format than bullet points
What is not clear:
- What is already in the AADL security specification
- What is not already in the specification?
1) What is the problem?
2) Talk about PBD
- Requirements, architecture, mapping
3) What is AADL
- Can give requirement specifications
- Can give element specifications
- Need both for PBD
- Could be used fro PBD
- New AADL additions to security
- AccessGroup
- AccessMode
- Not complete
- What needs to be added from requirements side
- What needs to be added from component side
4) What is the new security specification encompass
i) Models
ii) Requirements
iii) Not so much levels of encryption, as levels of privacy
- Kind of the opposite of access control
- Privacy = data/information/services (is there information that leaks out when someone does not even have access)
- If protection is circumvented, does the information still remain secure?
- What is leaked of the information?
- What can be found out?
- Is the information simply in the clear now?
- Protection = data/information/services access control through mechanisms (control who does or does not have access)
- Integrity = is what was written what is returned
- Has the data been modified?
- Has the service been modified?
5) How does this fit into the PBD model?
i) AADL examines systems from a requirements specification
ii) How to map to components that have (A,B,C) security features
Need to add examples and figures (can not be all text)
- Need something more than just writing
Expand on security design problem writing
10 pages, two column, ACM format (CODES Conference)
- Will let me see what pages we have and what we can play with
Things to Ask Chandy:
- Should I add a bunch of examples of element properties?
Add in section highlighting all previous work similar to proposed PBD security model
- Show how easily adooptable the new model can be along with evidence of other already attempting to implement similar concepts/ideas into the existing AADL lexicon
New Outline Concepts:
Cut down Section 7
- Takes up a lot of room
Point does not entirly come across
New Outline Concept:
Introduction
- Keep basics of security
- Points:
- Security is tough
- Design is a problem
- Do not know how to do properly
- Start laying out ideas on how to design secure embedded systems
PBD
- Point that really needs to come out:
- Illustrate the phases of PBD
- Requirements are important!
- Requirements of design perspective
- Need component specifications
- Without these, one can NOT do platform-based design
- Can not do design mapping without component specs
- Could keep the language of PBD as 'contracts' [Make 'contracts' terminology more fluid, be able to switch without issues]
Requirement Specifications for Security
- AADL (as a modeling language)
- AADL with security properties (what already exists)
- What tools already exist?
- Mainly used for verification
Design/Mapping (What is new being introducted by the paper) [Core of the paper - new stuff being brought to the table]
- What are the problems
- What is missing
- Want to add:
- Cost based requirements
- Component specifications of security
- What expansions needs to be added to allow for AADL to model security
- AADL extensions
- Mapping problem
- How does one do the mapping
- Note: solution to mapping problem is not easy
- Don't claim to have a solution
- Presenting model one can use to produce a solution
- Make point: This is a problem that NEEDS TO BE SOLVED!!!
- There are previous steps that need to be tackled before doing the mapping problem
- THIS IS WHAT NEEDS TO BE BROUGHT OUT IN DETAIL!!!
- Could use this paper to do the mapping problem
Move security extension work expected for AADL into the AADL section instead of the 'Future Work' section
Image to add:
- Draw own figure: what would the design flow be and how does AADL (& others) come together
- Can be simple, just needs to show where this work would insert into development
- Draw embedded system: to show components and where security could be incorporated
- Larger system to show where additional security properties help
- Draw smaller system example to illustrate need/aid of incorporating security
Chandy to send emails from CPS security mailing list
- See about joining the working group
- Have weekly calls
- Chandy to send information about how to join the mailing list
Meld 'Related Work' section into the larger PBD part
Mention work done on 'Secure Software Design' in the introduction
- To show that research does exist
Introduction should highlight security failures
- Plane hacks
- Car hacks
- High profile embedded system attacks
You can’t perform that action at this time.