This document provides guidance to the aviation sector for the management of information security events with actual or potential aviation safety consequences. This includes unwanted or unexpected events that are an indication of an actual adverse effect on information security, as well as gaining knowledge about security vulnerabilities in information systems that could be exploited to cause such incidents. In addition to the aircraft itself, this document also addresses ground IT, maintenance equipment, ATC, aviation services and design and manufacturing supply chain that could cause a safety effect on the aircraft. Physical security attacks (e.g., sabotage, counterfeit parts, attacks with physical means) are not in scope of this document.

ED-201A / DO-391 discusses the relationship of this document to other aeronautical information security system guidance documents. This document addresses the organization and preparation, detection, analysis, response and recovery steps to information security events. This document also provides the reporting guidance necessary for an information security incident or vulnerability.

This document is not intended as a replacement for the existing occurrence reporting process. It provides guidance for the information security aspects of an event that could affect aviation safety and therefore could need to be included in those reporting chains as well. However, the guidance in this document can be used in any context of civil aviation.

Existing information security guidance (presented in ED202A / DO-326A) addresses information security concerns as Intentional Unauthorized Electronic Interaction (IUEI). IUEI is defined as a circumstance or event with the potential to affect the aircraft due to human action resulting from unauthorized access, use, disclosure, denial, disruption, modification, or destruction of information and/or aircraft system interfaces. This includes the consequences of malware and forged data and the effects of external systems on aircraft systems but does not include physical attacks or electromagnetic disturbance (reference EUROCAE ER-013 / RTCA 7-A-120-21-PMC-2151). This definition is provided for the reader to understand information security concerns but this document could be applied to any portion of the aviation ecosystem.

The security event management guidance in this document may be used to address relevant Aviation areas including:

• Aircraft development, production

• Aircraft operation (passenger and cargo) including pilots and other crew, maintenance repair and overhaul operations (MRO), continuing airworthiness management organizations (CAMO)

• Air traffic management organizations

• Airports and aviation service providers

• Design, manufacturing, operation and regular maintenance of ground ATM/ANS equipment

• Industrial equipment manufacturing or supporting the production of aircraft and supporting systems

• Aircraft decommissioning

This guidance extends as appropriate to the supply chains of these organizations.

Future Aircraft Information Security: Rationale and Needs

There are relatively few information security related capabilities for Information Security Event Management for aircraft systems (vs. safety-derived capabilities) currently deployed that are intended to work in real-time. However, nothing in this document should be interpreted as precluding deployment and use of real-time capabilities. Future revisions of this document should be expected to treat these subjects in more detail.

Aviation systems, including those onboard aircraft, continually increase in capability and interconnections with other systems. This provides more opportunities for attack but also more opportunity for detection and mitigation. Where possible, future capabilities and systems should look toward the ability to provide 1) real-time detection of attacks, 2) real-time mitigation, and 3) pilot notification and associated procedures for attacks. Having said that, human factors engineering should be considered in future capabilities. Any information provided to the pilot must be usable and actionable. Otherwise, it simply increases the pilot's workload with no added benefit.

Fundamentally, an attack on an aircraft system is a form of attempted sabotage and depending on the nature or objective of the attack, it may also be a form of virtual hijacking. ICAO Annex 2 and Annex 17 place requirements on the pilot-in-command to respond to unlawful interference. Further requirements may be imposed by national laws and aviation authorities; for example, United States law [US Code Chapter 49, Sections 1544.215 and 1544.303] designates the pilot-in-command (PIC) as the security coordinator while the aircraft is in flight and requires the PIC to be notified of threats to the aircraft. The US Federal Aviation Administration has additionally observed:

“The modus operandi of terrorist organizations is to make coordinated, simultaneous attacks designed to confuse and overwhelm defenses. Events perceived by aircrews, as isolated to one aircraft, may be part of a broader scheme or the precursor to an elaborate attack. Therefore, the rapid exchange of information is paramount to ensure the security and integrity of the NAS.” [FAA Advisory Circular AC90-103; superseded by other FAA documents and the operator’s TSA approved security program].

As an example, it is possible that an information security attack on an aircraft system may be used as a distraction for a physical attack elsewhere on the aircraft (or viceversa). External attacks on Communications, Navigation, and Surveillance (CNS) systems (e.g., “jamming” or “spoofing”) are also attacks even if they do not compromise avionics internally.

As additional rationale for these real-time capabilities, current pilot procedures and training are based on the underlying philosophy that pilots need to trust their instruments and system indications. Attacks have the potential to undermine and invalidate this trust. Historically, system failures are annunciated, or otherwise are readily apparent (for example, jammed flight controls, smoke in the cockpit or cabin, inoperative interphone, etc.). In most cases, system failures have an associated Quick Reference Handbook (QRH) procedure and checklist, intended to guide the pilot to safely handle the situation.

As of this writing, pilots receive little or no training on aircraft information security. Yet if an incident (either caused by information security or safety) occurs that degrades the state of the aircraft while in-flight, the pilot will still need to fly the aircraft for the remainder of the flight in its degraded condition or make an unscheduled landing at the nearest airfield depending on the severity of the degradation. Without detection and notification of degraded conditions, this task becomes harder as the pilot’s trust can be broken in ways that are not readily apparent. With the development of in-flight detection, mitigation, and notification, pilot trust can be bolstered by helping the pilot understand which systems can be trusted, and heightened vigilance can be applied, for example, by more frequent cross-checking of the information produced by other systems and visual confirmation of aircraft state.

In addition, the QRH procedures may not have been designed to consider possible information security causes. As an example, there is no requirement to include in current flight manuals a description of how to identify and handle jamming or spoofing of Global Navigation Satellite System (GNSS) signals - these manuals implicitly treat GNSS to be “truth”. Pilot manuals also vary in how much information they provide on how the Flight Management System manages and cross-checks various navigation sources.

Finally, as information security specific capabilities (for example, domain guard or data diode function) are deployed, the detection and alerting of failures in these systems should be considered. If in fact no safety effect is determined, then such failures could be communicated as maintenance actions required.

The first capability to be developed is real-time detection of an attack. Aircraft and system health monitoring capabilities could be extended to provide this function. Declaring an anomaly to be an attack is a difficult problem but may be possible in some cases (for example, jamming or spoofing on CNS systems.) This capability becomes more important as aircraft designs move toward more integration and connectivity with external entities. For example, functions that are separate systems in legacy aircraft are now running as applications on a more generalized computing architecture. Other examples are the use of commercially derived communications links that are much more complex than legacy capabilities like ARINC 429 data busses.

The second capability to be developed is real-time mitigation of attack. These capabilities are analogous to fault detection and isolation capabilities. Ideally aircraft architectures will allow fall back to a Fail-Operational state if a system becomes compromised by an attack. Beyond Fail-Operational are Fail-Safe and Fail-Secure in order of priority.

Finally, notification of pilots and development of associated pilot actions are needed to work with ICAO requirements and national laws and regulation for aircraft security. The intent here is not to have pilots become troubleshooters of their systems or overwhelmed by nuisance alerts, but rather to ensure there is a standard and vetted response to information security related failures. It is a difficult problem to develop alerts and guidance to avoid nuisance alerts or undermine trust in the remaining uncompromised aircraft systems.

Even if an anomaly cannot be deemed an attack in real-time, the QRH procedure for systems should consider and mitigate possible information security causes. Human factors issues are significant, and regulatory and certification guidance may need to be revised as part of this.

For all of the above, existing frameworks for mitigating safety effects should be extended to include security effects. For example, 14 CFR 25.1309 and AC 25.1322-1 / AMC 25.1322 (or equivalent for other regulatory bodies) on crew alerting should be followed. The QRH model for handling failures should be used. Proper human factors engineering needs to be applied. If necessary, the aircraft Functional Hazard Assessment may need to be updated.

Finally, for attacks on CNS systems, post-event processes for communicating and handling these events should be developed.

In closing, the capabilities described above are needed as aircraft become more sophisticated and complex, and connectivity in real-time with external data becomes more prevalent. Future versions of this and other information security documents should treat these subjects in more detail.

Treatment of Legacy Aircraft and Systems

Newer aircraft systems will often have security assessments performed against them and detection methods in concert with their level of interconnectivity which can be used in the effective management of events. However, legacy aircraft and systems will not have these supporting assessments from which to work from, they also may not have the level of interconnectivity of newer systems. Legacy aircraft are defined as those aircraft without information security requirements as part of their applicable certification basis (TC or if modified later it will be identified in the Supplemental Type Certificate (STC) or Amended Type Certificate (ATC)). That said, event management is still a vital task necessary to ensure the safety of air traffic. This section addresses considerations for those aircraft and systems and the operator of such systems are encouraged to review this section as well as the overall document and determine the appropriate processes and regulatory interaction to manage events for legacy aircraft and systems.

This document discusses security events. In a general sense, for legacy aircraft and systems, these should be handled in the same manner as those for e-enabled aircraft and systems in that an event which is determined to be an incident or a vulnerability (with potential exploitation) that has a safety effect need to be reported. This is no different than if the event were discovered by some means other than in a security sense. To discover this, the operator monitors and performs an analysis of events in line with the guidance of this document but also considering that previous security assessments do not exist, and that detection and interconnectivity is not the same as e-enabled aircraft and systems. The guiding principle is that a legacy aircraft or system needs to account for and report incidents just like an e-enabled aircraft or system with the objective of performing due diligence for on a case-by-case basis.

A significant difference for legacy aircraft or systems from the e-enabled counterparts, is the lack of event detection methods specific to security related events. These include security logs, third party supplier monitoring, security functions detecting suspicious events, Design Approval Holder (DAH) analysis for events, etc. So although the reporting of safety effects is always required, the sources of these events on legacy aircraft and systems is reduced. However, this is offset by the lack of connectivity necessary to produce many of the same events. It is necessary that when such events are detected that they be analyzed sufficiently to determine if a safety effect exists. This includes voluntary monitoring by Operator and support from DAH when required, of material such as general vulnerability reports, or third-party supplier reports, as well as information from Information Sharing and Analysis Center (ISAC) bodies or other available sources.

Finally, if the event has a safety effect, it needs to be reported in line with regulatory requirements and the guidance in this document. The legacy aircraft or system will need to be returned to the Type Certification state if not already in that state. Vulnerabilities that have a safety effect and are deemed exploitable need to be reported and the appropriate process for mitigation determined with the regulator.

In summary, it is important to note that legacy aircraft and systems are not exempted from this guidance but it is recognized that these systems do not have the detection methods and assessments that e-enabled aircraft and systems possess so that this guidance considers those aspects when treating events for these aircraft and systems.