Integrating DO-326A Safety Airworthiness into the Software Development Lifecycle


April 26, 2022

Before jumping directly into adopting DO-326A to address cybersecurity certification, it must be placed in the context of DO-178, which is the global standard. DO-178 is a process standard that contains steps for software used in airborne systems. The DO-178C, also known as the ED-12C in Europe, is the latest version that aerospace systems and software engineers use as a guide to ensure airworthiness. Although it continues to evolve, a single document cannot encompass all development needs, and supporting or supplemental documents to DO-178 have evolved over time. DO-326A is one of them; its purpose is to provide a framework with objectives and process guidelines for dealing with intentional and unintentional security threats to aircraft systems.

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 “Aviation Systems Security”. Thus began the process that resulted in DO-326A, 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 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 published in August 2014. An important or contributing key element of the latest version of DO-326A is that it emphasizes the identification and mitigation of intentional and unintentional threats. In fact, this standard is the high-level guide to obtaining airworthiness safety certification.

A companion document to consider is DO-356A or its European equivalent, ED-203A, entitled “Airworthiness Security Methods and Considerations”. This document provides the airworthiness safety requirements throughout the development stages and details the risk assessment and the objectives to be achieved.

Another complementary document is the DO-355 standard. Titled “Information Security Guidance for Continuing Airworthiness”, it is a set of additional requirements focused on operation and maintenance. I recommend that you get these companion standards.

A few 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 to cybersecurity overlaps with much of what has been done for many years to ensure security. So, those who have built security-focused software systems will find that integrating software security is quite intuitive.

The core of DO-326A is to establish airworthiness safety process (AWSP) for general civil aviation, including fixed-wing and propeller-driven aircraft and rotorcraft/helicopters, including engines and propellers. A factor to consider: at present, military aircraft are not affected by the DO-326A.

Electronic compatible avionics systems to consider

DO-326A pays special attention to internal and external communication access points, as this is where the majority of threats and vulnerabilities will be. DO-326A provides a list of e-enabled systems (those using TCP/IP technology for intranet and/or extranet communication) to observe. For example, 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 on an on-board server.

Some of these devices include cell phones, laptops, tablets, and more. Ground communication networks also access the aircraft through VHF/AM, digital VHF data links, ACARS (Aircraft Communications Addressing and Reporting System), and wireless bridges. The security of these different devices involves distinct levels of abstraction across the perimeter. These include the access point, the data transmitted, as well as the system and subsystems, the elements that support lower levels, and the code itself. The goal is to consider and protect all access points and data at all levels.

Airworthiness Safety Process

To ensure airworthiness safety, DO-326A has defined a seven-step safety and risk management framework. Figure 1 provides an overview of the airworthiness safety process. Starting at the top, Steps 1 and 7 explain how to manage the certification process itself.

Step 1 is to prepare the Plan for Security Aspects of Certification (PSecAC) document. It contains aspects such as risk assessment for the aircraft or system, which includes particularly important activities such as assignment of level of assurance, capture of safety requirements, validation of safety requirements, And much more.

The PSecAC serves as an input to activities further downstream. Additionally, this document must be in agreement with the regulatory authority because other supporting documents, such as the “Aircraft Safety Scope Definition” – which captures the aircraft’s operating environment in with regard to safety – may be required by the authority. Evidence supporting the PSecAC document, including items such as assigned security assurance levels and results of requirements verification and validation, should be included in the plan, which is step 7 Therefore, they reside in the same certification-related activity box. .

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

Step 2 establishes the scope; in other words, it is the stage of identifying the assets that must be subjected to the airworthiness safety process. These will be the logical and/or physical assets in development. It is important to understand that ensuring security involves applying security measures to the asset in the various software levels of abstractions.

For example, start by looking at things from the plane’s point of view. Consider assets such as external communication systems and interactions that occur, including with external personnel. At a lower level of abstraction, the system and its internal assets must also be considered: Systems, subsystems, interface, data, file transfer, and much more must be considered, because these assets must also provide security. .

Step 3 is the security risk assessment, performed in the same way as the design assurance level (DAL) assessment and assignment for security. (Figure 2.)

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

The Security Risk Assessment figure shows the defined workflow for determining the security risk assessment level, or threat level and severity level. Chapter 3 of the standard gives more details, such as providing asset security attributes and threat conditions. The assigned security rating level 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 must be produced.

Stage 5 is where security protection is implemented in the design, with stage 6 measuring the effectiveness of the security protection implemented. To be more specific, in step 5, additional security requirements are defined as part of the decomposition of high-level security requirements into lower-level security requirements, which drive architecture and implementation decisions. work. Not only must all security requirements be implemented, but their effectiveness must be measured. This is equivalent to step 6, requirements verification and validation, i.e. testing.

The results feed into step 7, where all the evidence is entered into the summary of the PSecAC for certification purposes. Let’s put these steps into something more concrete – in fact, something more familiar: the V-Model DO 326A.

V-Model DO-326A

Avionics and software systems engineers are very familiar with the V-model. Mapping the seven stages of the framework to the “V” should further clarify the activities of the development lifecycle stages.

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 Stage 2 of the DO-326A process comes in.

A look at Figure 3 shows that there are levels of abstraction of security requirements analysis that need to be considered. This is where the requirements are identified. It is also necessary to break them down and produce a system architecture. A preliminary security risk assessment for the asset is performed; this is where step 3 fits in and relates to the functional risk assessment performed for security. The same risk assessment should also be performed at the system level. If the security risk is unacceptable (step 4), which is determined by the assigned security risk level, 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 requirements in the PLM, ALM or requirements management tool, where all data is broken down, traceability is established and test cases help verify and validate requirements .

Stage 5 is where security protection is implemented in the design and code. A pass from the right side of the V to Stage 6, which measures efficiency, which actually means that Stage 6 is where the verification and validation of requirements is done. The results feed into the PSecAC document and the PSecAC document completes steps 1 and 7 for certification purposes.

Airworthiness Safety is the sister of Airworthiness Safety – the same processes and principles apply. Diving deeper into the heart of realizing safety makes it clear that safety is about protecting data, which exists in various forms and at different levels of abstraction as part of the aircraft.

Ricardo Camacho is Director of Safety and 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 several roles, including technical product marketing, project management, solutions architect/technical sales, and software and embedded systems engineering, which he has held in companies. such as IBM, Xerox, Vector and GE Rail.

Parasoft •

Gordon K. Morehouse