Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

More documents

Recommendations

Info

6.1.3 Authentication. Authentication directly impacts the following entities: • Communications protocols should be deployed with their security turned on (see section 4.5). This means that routing protocols should be configured to use the appropriate password and HMAC for that deployment. The password needs to be unique for that system and protected via best current practices password protection mechanisms. Mutual authentication should be used whenever possible. This implies that human users and devices should both be assigned an appropriate identity by the authentication system used by the deployment (e.g., Kerberos, PKI, [82]). This, in turn, implies that the best common practice for that authentication system should be followed. • Devices (both end system and intermediate system) and software with higher safety requirements should be designed so that they cannot be misconfigured, including their naming (if any) and addressing assignments, if possible. Devices and applications with more modest safety requirements need to ensure that their administrators are authenticated and that administrative authorizations (including access control) are in accordance with the separation of duties with least privilege principals. • Applications should ensure that their users (both processes and humans) are authenticated and, if applicable, their access control limited by separation of duties with least privilege. Authentication of human users should preferentially require two factored authentication (e.g., password plus PKI identity). The ultimate goal of airborne security controls (including the authentication system) is to prevent safety failures. Physical techniques, along with policies and procedures, should be considered where practical. Remote access to safety-critical components should be minimized; however, where they are justified, authentication must be required. Authentication of airborne entities would be materially strengthened if the airborne authentication system were a constituent part of the same integrated authentication infrastructure serving both airborne and NAS systems. A number of candidate technologies could serve as the basis for such an authentication infrastructure. The requirements of such an infrastructure are that a common identity system needs to be created system-wide for humans and devices that populate the total system. These identities need to be authenticated by means of a common technology infrastructure in accordance with best IA practices. The authentication system may or may not also be associated with authorization or access control. Well-known candidates for authentication systems include PKI (see RFC 3280, RFC 4210, and RFC 3494), Kerberos (see RFC 4120); Remote Authentication Dial In User Service (see RFC 2138 and RFC 3580); and Authentication, Authorization, and Accounting (see RFC 3127 and RFC 3539) including Diameter (see RFC 3588 and RFC 4005). References 79 and 82 describe a PKI-based authentication system for the ATN. A choice of PKI to become an avionics authentication infrastructure correlates well with the extensive DoD PKI infrastructure that is currently being built by the DoD to support PKI within DoD systems. 78
6.1.4 Confidentiality. Confidentiality is generally not relevant for safety (see appendix B for a discussion to the contrary). While there are some scenarios where the real-time location of an airplane might become known to an adversary and conceivably put the plane in jeopardy, this threat has not become widely accepted within the FAA. The flight paths of commercial airplanes are already known, and the real-time information would have a short lifespan for an attacker. In this example, old data is of little value to the attacker in general. 6.1.5 Nonrepudiation. With regards to digital security, nonrepudiation means that it can be verified that the sender and the recipient were, in fact, the parties who claimed to send or receive the message, respectively. Nonrepudiation of origin proves that data has been sent, and nonrepudiation of delivery proves it has been received. Digital transactions are potentially subject to fraud, such as when computer systems are broken into or infected with Trojan horses or viruses. Participants can potentially claim such fraud to attempt to repudiate a transaction. To counteract this, the underlying processes need to be demonstrably sound so that such claims would not have credence. Logging of significant events is needed to create accountability. Log files should be protected from being modified or deleted. Nonrepudiation should be a required security attribute for all electronic parts distribution systems (e.g., software distribution). All electronic parts need to be signed in accordance with the U.S. Federal DSS [81] in accordance with an FAA-approved electronic distribution system. The source and integrity assurance of an electronic part is a critical element of verifying its authenticity prior to installation. This signature needs to be checked and verified at the deployment site before any electronic part can be deployed. The checks verify that the software has not been modified subsequent to being signed. The identity of the signer needs to be authenticated and authorized previous to deployment. In addition, whenever administrators (both device and human) interact with aviation equipment or administer devices within aircraft, a log of their activity should be kept for analysis, accountability, and administrative purposes (e.g., fault investigation). The log file needs to record the specific identity of the human responsible, the time, actions performed, as well as optionally the location from which the access occurred. This log needs to be protected from subsequent modification or deletion. If network or host intrusion detection systems (IDS) are deployed, these log files should be available for those systems to read. 6.2 EXTENDING FAA ORDERS, GUIDANCE, AND PROCESSES INTO VAST NETWORK SYSTEMS. Different communities use different terms to refer to the same or similar concepts. For example, it was previously mentioned that current FAA safety assurance processes for airborne systems are based on ARP 4754, ARP 4761, and ACs (e.g., AC 25.1309-1A and AC 23.1309-1C); software assurance is based on DO-178B; and complex electronic hardware design assurance is based on DO-254. These references reflect common FAA parlance that speaks about the laws, 79
Page 1 and 2:
DOT/FAA/AR-08/31 Air Traffic Organi
Page 3 and 4:
1. Report No. DOT/FAA/AR-08/31 4. T
Page 5 and 6:
5.4.2 Aircraft as a Node (MIP and M
Page 7 and 8:
11.1 Findings and Recommendations 1
Page 9 and 10:
22 Customer’s L3VPN Protocol Stac
Page 11 and 12:
LIST OF ACRONYMS AND ABBREVIATIONS
Page 13 and 14:
PBN PC PE PEP PFS PIB PIM-DM PIM-SM
Page 15 and 16:
This report states that the primary
Page 17 and 18:
1. INTRODUCTION. This is the final
Page 19 and 20:
protocol (IP)-based communications.
Page 21 and 22:
of linking aircraft-resident system
Page 23 and 24:
Industry and governments are extrem
Page 25 and 26:
2.1 NOTIONAL NETWORKED AIRCRAFT ARC
Page 27 and 28:
Other Control Sites Controller ATC
Page 29 and 30:
• The security viability of curre
Page 31 and 32:
alternative requires that parallel
Page 33 and 34:
Aircraft network security is a syst
Page 35 and 36:
4. NETWORK RISKS. This section spec
Page 37 and 38:
General Threat Identifiers FAILURE
Page 39 and 40:
esources so that the required real-
Page 41 and 42:
“With the rise of client-side att
Page 43 and 44: • During an 11-month period (Apri
Page 45 and 46: attempt the theft of passwords. Non
Page 47 and 48: IP networks are organized in terms
Page 49 and 50: either the user or the trusted soft
Page 51 and 52: However, the previous paragraph beg
Page 53 and 54: Table 1. Internet Engineering Task
Page 59 and 60: • Lightweight directory access pr
Page 61 and 62: mechanism to overcome the key distr
Page 63 and 64: Deployments that need to support mu
Page 65 and 66: Today’s Reality: Islands of Commu
Page 67 and 68: Simultaneously, IP addresses are al
Page 69 and 70: in-depth manner. Defense-in-depth m
Page 71 and 72: Protection Detection Reaction / Neu
Page 73 and 74: encrypted and then encapsulated wit
Page 75 and 76: Internet (grouping of autonomous sy
Page 77 and 78: via that same IP address. Specifica
Page 79 and 80: deployments. Regional flights that
Page 81 and 82: neighbor as a next hop after “Hol
Page 83 and 84: Interface Interface Customer Site S
Page 85 and 86: Interface Customer’s Application
Page 87 and 88: Although the vast majority of PBN s
Page 89 and 90: 6. RELATING SAFETY AND SECURITY FOR
Page 91 and 92: 6.1.1 Integrity. As section 4.3 ind
Page 93: As mentioned in section 4.4, the hi
Page 97 and 98: their own classification level nor
Page 99 and 100: integrity is not permitted to obser
Page 101 and 102: software has been confirmed as leve
Page 103 and 104: • Both safety and security are co
Page 105 and 106: Device at Safety level X Device at
Page 107 and 108: in a Biba Integrity Model environme
Page 109 and 110: Common Criteria Classes ACM—Confi
Page 111 and 112: (see section 9.10). A secure mechan
Page 113 and 114: employed in security-critical appli
Page 115 and 116: concept, which is needed to create
Page 117 and 118: 4. Learn from past mistakes. Poor d
Page 119 and 120: exemplar airborne network architect
Page 121 and 122: • Requirement 8: Biba Integrity M
Page 123 and 124: Figure 31 shows how the recommended
Page 125 and 126: to-live (TTL) field in the IP heade
Page 127 and 128: using the traditional dual router i
Page 129 and 130: mechanism relies upon the controlle
Page 131 and 132: HAGs are high-assurance devices tha
Page 133 and 134: 8.3.5 Firewall. The firewall needs
Page 135 and 136: (AJ) or low probability of intercep
Page 137 and 138: design decisions that need to be de
Page 139 and 140: 9.2 INTEGRATED MODULAR AVIONICS IMP
Page 141 and 142: 9.3 USING PUBLIC IPs. The model and
Page 143 and 144: alerted the pilots because the fail
Page 145 and 146:
environments. If the certification
Page 147 and 148:
DSS (FIPS 186 [81]). Code signing i
Page 149 and 150:
elationship with other equipment in
Page 151 and 152:
approach is to keep the log informa
Page 153 and 154:
11. SUMMARY. Current civilian aircr
Page 155 and 156:
environments should be extended to
Page 157 and 158:
12. COTS computer systems cannot be
Page 159 and 160:
14. NAS and airborne network archit
Page 161 and 162:
22. If SWAP considerations permit,
Page 163 and 164:
11.2 TOPICS NEEDING FURTHER STUDY.
Page 165 and 166:
9. Lee, Y., Rachlin, E., and Scandu
Page 167 and 168:
32. Loscocco, P., Smalley, S., Muck
Page 169 and 170:
59. Raisinghani, V. and Sridhar, I.
Page 171 and 172:
the following is a pointer to a rel
Page 173 and 174:
Department of Defense Instruction N
Page 175 and 176:
Information Assurance—The Departm
Page 177 and 178:
Threat source—Either (1) intent a
Page 179 and 180:
information found within these data
Page 181 and 182:
(HTTP) traffic (port 80), port scan
Page 183 and 184:
The simple network management proto
Page 185 and 186:
opportunities to crack the hosting
Page 187 and 188:
authorized to perform. 13 However,
Page 189 and 190:
sniffers, log-cleaning scripts, and
Page 191 and 192:
A.3.1 DENIAL OF SERVICE ATTACKS. Th
Page 193 and 194:
• Disclosure: Disclosure of routi
Page 195 and 196:
affected by the signal intermittenc
Page 197 and 198:
A-15. Barbir, A., Murphy, S., and Y
Page 199 and 200:
Survey Question What is the primary
Page 201 and 202:
Survey Question What is the primary
Page 203 and 204:
should be emphasized that there is
show all

Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

Create successful ePaper yourself

Delete template?

Save as template?