Incorporating DO-326A security airworthiness into software-development life cycle

Story

April 26, 2022

In 2006, EUROCAE [European Organi­sation for Civil Aviation Equipment] formed Working Group 72 (WG-72); in 2007, RTCA [a U.S. organization focused on air safety] formed Special Committee 216 (SC-216): Both were named “Aeronautical Systems Security.” Thus began the process that yielded DO-326A, which is also known as ED-202A in Europe.

The first version of DO-326 was published in 2010, called “Airworthiness Process Specification.” It contained best practices – as was best understood at the time – for addressing security, which had not been widely implemented.

The current publication of the standard, “Airworthiness Security Process Specification,” was put out in August 2014. A key important or contributing element in the latest version of DO-326A is that it includes a focus on identifying and mitigating intentional and unintentional threats. In fact, this standard is the top-level guidance for attaining Airworthiness Security Certification.

A companion document to consider is DO-356A or the European equivalent, ED-203A, which is titled “Airworthiness Security Methods and Considerations.” This document provides airworthiness security requirements throughout the stages of development and spells out details on risk assessment and objectives to be achieved.

Another complementing document is standard DO-355. Titled, “Information Security Guidance for Continuing Air­wor-thi­ness,” it’s a collection of supplement-ary requirements focused on operations and maintenance. I recommend that you obtain these companion standards.

A couple of important points to mention: First, obtaining DO-326A type certification for avionics systems is mandatory for the Federal Aviation Administration (FAA) and the European Union Aviation Safety Agency (EASA). The other point is that the approach toward cyber­security overlaps with much of what has been done for many years in ensuring safety. So those who have been building safety-focused software systems will find that incorporating software security is fairly intuitive.

The core of DO-326A is to establish the Airworthiness Security Process (AWSP) for general civil aviation, including fixed-wing and prop aircraft and rotorcraft/helicopters, including the engines and propellers. One factor to be aware of: At present, military aircraft are not addressed by DO-326A.

E-enabled avionics systems to consider

DO-326A places special consideration around internal and external communication access points, since this is where the bulk of threats and vulnerabilities will be found. DO-326A provides a list of e-enabled systems (those using TCP/IP technology for intranet and/or extranet communication) to observe. For instance, satellite communications are the main access point where information is transmitted to and from the aircraft, while Ethernet routers are used to communicate with Wi-Fi devices and onto an onboard server.

Some of these devices include cellphones, laptops, tablets, and much more. Ground communication networks also access the aircraft by way of VHF/AM, digital VHF datalinks, ACARS (Aircraft Communications Addressing and Reporting System) and wireless bridges. Security for these different devices involves distinct levels of abstraction within the entire scope. These include the access point, the data being transmitted, plus the system and subsystems, those pieces that support lower levels and the code itself. The goal is to consider and protect all access points and data at all levels.

Airworthiness security process

To ensure airworthiness security, DO-326A has defined a seven-step security and risk management framework. Figure 1 captures an overview of the airworthiness security process. Starting at the top are steps 1 and 7, which express how to manage the actual certification process.

Step 1 is putting together the Plan for Security Aspects of Certification (PSecAC) document. It contains aspects like the risk assessment for the aircraft or system, which includes the especially important activities like assurance-level assignment, security-requirements capture, security-requirements validation, and much more.

The PSecAC serves as inputs to activities further down the line. In addition, this document has to agree with the regulatory authority because other supporting documents, like the “Aircraft Security Scope Definition” – which captures the operational environment for the aircraft as it relates to security – may be required by the authority. Evidence to support the PSecAC document, including things like assigned security-assurance levels and results of the verification and validation of requirements, are to be included in the plan, which is Step 7. Therefore, they reside in the same certification-related activities box.

[Figure 1 | Shown is the RTCA DO-326A airworthiness security risk-management framework.]

Step 2 establishes the scope; in other words, this is the step to identify the assets that are to be put through the airworthiness security process. These will be the logical and/or physical assets in development. It’s important to understand that ensuring security involves applying security measures to the asset within the different software levels of abstractions.

For example, start by looking at things from the perspective of the aircraft. Consider assets like external communication systems and the interactions that happen, including with off-board personnel. At a lower level of abstraction, the system and its internal assets must also be considered: The systems, the subsystems, the interface, the data, the file transfer, and much more must be looked at, because these assets also need to ensure security.

Step 3 is the assessment of security risk, done similarly to the evaluation and assignation of the Design Assurance Level (DAL) in safety. (Figure 2.)

[Figure 2 | Pictured is the RTCA DO-326A security risk assessment workflow.]

The Security Risk Assessment figure shows the workflow defined in determining the security-risk assessment level, or the level of threat and degree of severity. Chapter 3 of the standard goes into further detail, such as providing asset security attributes and threat conditions. The security assessment level assigned affects the various verification and validation methods that must be performed to ensure that the asset is secure.

The security-risk results feed into Step 4, which is a decision gate. If there is a security risk, evidence of assessment and mitigation measures need to be produced.

Step 5 is where security protection is implemented in the design, with Step 6 measuring the effectiveness of the security protection implemented. To be more specific, in Step 5 additional security requirements are defined as part of decomposing high-level security requirements into lower-level security requirements, which drive architectural and implementation decisions. Not only do all security requirements need to be implemented, but they need to be measured for effectiveness. This equates to Step 6, the verification and validation of requirements, which means testing.

The results feed Step 7, where all evidence is captured in the PSecAC summary for certification purposes. Let’s put these steps into something more concrete – actually, something that’s more familiar: the DO 326A V-model.

DO-326A V-model

Avionics systems and software engineers are very familiar with the V-model. Associating the seven steps in the framework to the “V” should further clarify the activities in the steps within the development life cycle.

The image in Figure 3 is from the DO-326A standard, which puts things in the context of security. On the left side of the V are the system engineering phases, where requirements are captured. This is where Step 2 in the DO-326A process comes into play.

A look at Figure 3 shows that there are abstraction levels of security requirements analysis that must be considered. This is where requirements are identified. They also need to be decomposed and a system architecture produced. A preliminary security-risk assessment for the asset is performed; this is where Step 3 fits in and relates to the functional hazard assessment performed for safety. The same risk assessment also must be performed at the system level. If the security risk is unacceptable (Step 4), which is determined by the security risk level assigned, verification and validation criteria are determined.

[Figure 3 | Shown is the RTCA DO-326A security risk-assessment-related activities in the development process V-model.]

For this process, system engineers capture all the requirements in the PLM, ALM, or requirements management tool, where all the data gets decomposed, traceability is established, and test cases help verify and validate requirements.

Step 5 is where security protection is implemented in the design and code. A move over to the right side of the V to Step 6, which measures the effectiveness, which actually means that Step 6 is where verification and validation of requirements are performed. The results feed the PSecAC document and the PSecAC document fulfills Steps 1 and 7 for certification purposes.

Airworthiness security is the sister to safety airworthiness – the same processes and principles apply. Diving deeper into the core of realizing security drives home the point that security is about protecting the data, which exists in various forms and at different levels of abstraction within the scope of the aircraft.

Ricardo Camacho is director of Safety & Security Compliance at Parasoft. He has decades of experience in systems and software engineering of real-time, safety- and security-critical systems for various industries. His career has spanned multiple roles, including technical product marketing, project management, solution architect/technical sales, and embedded software and systems engineering, which he has performed at companies including IBM, Xerox, Vector, and GE Rail.

Parasoft • https://www.parasoft.com/