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
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
As mentioned <strong>in</strong> section 4.4, the higher assurance <strong>in</strong>tegrity entities (e.g., higher software levels)<br />
should not rely upon (human) adm<strong>in</strong>istrative activity. Specifically, it should not be possible to<br />
misconfigure or mismanage high-assurance devices (<strong>in</strong>clud<strong>in</strong>g software) or systems.<br />
6.1.2 Availability.<br />
Availability issues directly impact the same three entities that were previously described for<br />
<strong>in</strong>tegrity:<br />
• Adequate availability (or spare capacity) is needed for the physical network media that<br />
conveys data communications packets. Network availability can be attacked by caus<strong>in</strong>g<br />
the <strong>in</strong>termediate systems that forward packets to not function correctly or else by<br />
saturat<strong>in</strong>g the network so that entities that need to use it cannot do so. The latter is called<br />
a DoS attack, which leverages the fact that network capacity is a f<strong>in</strong>ite resource. The first<br />
threat can be reduced by deploy<strong>in</strong>g <strong>in</strong>termediate systems that cannot be misconfigured<br />
(i.e., are high assurance). DoS exploits can be reduced by ensur<strong>in</strong>g that the capacity of<br />
the network exceeds the cumulative network use, either by rate limit<strong>in</strong>g the devices that<br />
connect to the network or else by implement<strong>in</strong>g other QoS techniques. If QoS is used,<br />
higher software levels applications (e.g., Level A and Level B) should preferentially<br />
leverage technology that is implemented so that it cannot be misconfigured.<br />
• Availability of the security controls should be assured for a device that is used with<strong>in</strong> a<br />
distributed system’s defense-<strong>in</strong>-depth security protections. This requirement can be met<br />
by ensur<strong>in</strong>g that defense-<strong>in</strong>-depth and control life cycle pr<strong>in</strong>cipals mentioned <strong>in</strong> section<br />
5.1 are followed. Key system resources should also either have redundancies or else<br />
have fail-safe protections.<br />
• Availability should be assured for the applications that support airborne operations.<br />
These devices need to be designed to be impervious to bad data. They also need to be<br />
designed to withstand repeated and prolonged attempted accesses by rogue processes or<br />
systems (e.g., DoS attacks).<br />
Availability is traditionally addressed by us<strong>in</strong>g either real-time systems where <strong>in</strong>formation flows<br />
are predeterm<strong>in</strong>ed and systems are preconfigured to guarantee delivery of critical <strong>in</strong>formation, or<br />
by QoS network capabilities. For safety systems, this property must be designed <strong>in</strong> mechanisms<br />
that must be provided to segregate non-real-time systems from real-time systems and techniques<br />
to assess <strong>in</strong>teractions between systems that must be employed, <strong>in</strong> accordance with the rules that<br />
are articulated <strong>in</strong> section 8.2.<br />
77