Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Threats / Hazards<br />
Ops Environment<br />
Technology<br />
Vulnerability<br />
Analysis<br />
Design<br />
Concepts<br />
<strong>FAA</strong> safety<br />
Security<br />
requirements<br />
Work<strong>in</strong>g<br />
Group<br />
IA<br />
Security<br />
Criteria<br />
Criteria<br />
Analysis<br />
Security<br />
Specification<br />
Requirements<br />
Countermeasures<br />
Adversary<br />
Analysis<br />
Basel<strong>in</strong>e<br />
Design<br />
Concept<br />
Lessons<br />
Learned<br />
Trade-Off<br />
Studies<br />
System Security<br />
Security<br />
Specification<br />
Development<br />
Entry <strong>in</strong>to<br />
Development<br />
Figure 29. Security Eng<strong>in</strong>eer<strong>in</strong>g Process<br />
The Systems and Software Consortium 31 has developed well-accepted SSE processes. Their<br />
generic approach can be summarized by the follow<strong>in</strong>g steps.<br />
1. Determ<strong>in</strong>e the security policies. This is a high-level def<strong>in</strong>ition of what is allowed and<br />
what is forbidden with<strong>in</strong> the system. The policies provide the basis for determ<strong>in</strong><strong>in</strong>g the<br />
security requirements that will be developed and implemented. Without good security<br />
policies, one cannot determ<strong>in</strong>e the high-value assets and data that must be protected.<br />
2. Determ<strong>in</strong>e and specify the security requirements. In this step, requirements for the<br />
protection of assets and data are determ<strong>in</strong>ed us<strong>in</strong>g the security policies as a guide. It is<br />
essential that only requirements be specified, not solutions or constra<strong>in</strong>ts. Therefore, the<br />
requirements must be stated <strong>in</strong> technology neutral terms. In addition, the requirements<br />
must be practical and testable to permit eventual verification that the requirements have<br />
been satisfied by the f<strong>in</strong>al system. F<strong>in</strong>ally, the security requirements should not be open<br />
to <strong>in</strong>terpretation. This is accomplished <strong>in</strong> high-assurance systems by specify<strong>in</strong>g the<br />
security design via mathematical formalisms. However, this is rare. In most cases,<br />
English is used to specify the requirements. Care must be taken to avoid ambiguity of<br />
mean<strong>in</strong>g.<br />
3. Establish a security eng<strong>in</strong>eer<strong>in</strong>g plan. This plan should <strong>in</strong>clude items critical to the<br />
design and implementation of the security protection mechanisms. Such items <strong>in</strong>clude<br />
the security requirements, constra<strong>in</strong>ts, and decisions already made. It should be used to<br />
help allocate the resources needed to properly complete the project while simultaneously<br />
establish<strong>in</strong>g realistic expectations.<br />
31 See http://www.software.org<br />
100