13.09.2014 Views

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

• Requirement 8: Biba Integrity Model HAGs may be strategically positioned, on an asneeded<br />

only basis, to safely jo<strong>in</strong> together entities classified at different software levels.<br />

The HAG is specifically designed to address the issues that otherwise would h<strong>in</strong>der a less<br />

trusted <strong>in</strong>tegrity entity to safely communicate with a more highly trusted one <strong>in</strong><br />

accordance with Biba Integrity Model precepts. The HAG device is a middlebox that is<br />

<strong>in</strong>serted between the communicat<strong>in</strong>g entities or networks to provide the controls (e.g.,<br />

availability and <strong>in</strong>tegrity) necessary to ensure safety between the communicat<strong>in</strong>g entities.<br />

The HAG is a highly trusted device. It, therefore, needs to be certified at both the highest<br />

software level of the specific entities it is connect<strong>in</strong>g (for safety) and also at EAL 5 or<br />

above (for security).<br />

These requirements require that a system or software entity be classified at a specific software<br />

level and only communicate with entities classified at that same level via a VPN network also<br />

certified at the same level, <strong>in</strong> general.<br />

Step 3 of the SSE process is to determ<strong>in</strong>e a security eng<strong>in</strong>eer<strong>in</strong>g plan. The security eng<strong>in</strong>eer<strong>in</strong>g<br />

plan used for networked airborne systems shall comply with the extended DO-178B and ARP<br />

4754 concepts expla<strong>in</strong>ed <strong>in</strong> section 7.<br />

The next steps (steps 4 and 5) of the SSE process are specific to a given deployment. These<br />

steps need to be followed to extend the generic architecture identified by this study <strong>in</strong>to a<br />

specific deployment environment. In step 6, a risk analysis for that deployment is performed.<br />

Section 6.1 presented the result of a risk analysis for generic networked airborne environment.<br />

With the previous steps as background, the SSE process <strong>in</strong> step 7 then creates a security<br />

architecture. This architecture applies best current IA practice (i.e., IATF) to the result<strong>in</strong>g<br />

generic system. The result<strong>in</strong>g security architecture for a generic airborne network environment<br />

is presented <strong>in</strong> section 8.3.<br />

8.3 EXEMPLAR AIRBORNE NETWORK ARCHITECTURE SOLUTION.<br />

Figure 30 shows a high-level view of a generic network design that this study recommends for<br />

airborne networked environments. This design was constructed by follow<strong>in</strong>g the SSE processes<br />

(see section 8.2) for the extended DO-1789B and ARP 4754 processes described <strong>in</strong> section 7.<br />

Specifically, this section provides the generic airborne security architecture def<strong>in</strong>ed by SSE<br />

step 7.<br />

105

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!