Permalink
Cannot retrieve contributors at this time
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
TracingPaper/writingNeeds
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
151 lines (131 sloc)
5.95 KB
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |