Communications
The current configuration of aircraft network domains and security measures (see figure 1) include: Aircraft Controls Domain (ACD); Aircraft Information Systems Domain (AISD); Passenger Information and Entertainment Systems (PIES); and passenger-owned devices.
Figure 1: Aircraft network domains
The ACD is central to the aircraft’s avionics and includes the flight controls, flight management, and navigation systems, which typically run on a number of high-level safety-certified Integrated Modular Avionics (IMA)-based systems. These IMA systems are isolated from other domains, but will allow selected read-only access from other domains via ARINC buses for information such as the altitude and heading data commonly shown on passenger screens. The AISD contains crew systems, such as electronic flight bags, fault monitoring systems, health management and airport ground-based communications, but also provides certain read-only data to the PIES domain, which includes the in-flight entertainment (IFE) systems, cabin management systems, credit card systems and other passenger-facing systems. The passenger-owned devices domain allows access to the Internet, media from the IFE system and services on passenger-owned devices. The ACD and AISD are isolated from the passenger information, entertainment domains, and passenger-owned devices to avoid the risk of passengers hacking the systems. Access to higher bandwidth and advanced wireless and cell (3G/4G) connectivity will increasingly be expected for the PIES domain and the AISD, although the ACD will probably remain unconnected to ensure the safety and security of vital systems.
Considerations
It is challenging to implement data services and higher bandwidth connectivity without compromising aircraft security and safety, because meeting security requirements increases development complexity and cost. Aircraft systems are generally isolated from the Internet, but with the increase in demand for value-added services and also the sophistication of security threats, this ‘air gap’ approach needs to be updated to maintain security and safety.
To handle the threat of unintentional unauthorized electronic interaction, RTCA DO-326 (EUROCAE ED-202A) provides guidance for the process of aircraft certification. A key element of the standard is the Airworthiness Security Process (AWSP), which essentially requires that the aircraft will remain in a safe operating condition when subjected to unauthorised interaction. The AWSP establishes that the security risk to the aircraft and its systems are acceptable, according to the AWSP criteria, and the airworthiness security risk assessment is complete and correct. This means that an appropriate level of security needs to be established that is relevant to e-enabled aircraft safety. Continuous effort is necessary to secure devices throughout the entire lifecycle of the aircraft – from architectural design through deployment and end-of-life – and it is necessary to plan and budget for safety and security updates, along with future threat protections.
Scope
The first security step is to define the scope of the security problem, which involves identifying the particular assets in the system, identifying the security perimeter and documenting the security environment. This essentially means a fairly straightforward review of what is in the system, where it touches the outside world, and what is the operating environment. Assets can be broken down into hardware and software, which can be further broken down into particular data assets such as navigation databases or software updates, which can be for analyzed for their value and impact.
All touch points to the outside world must be considered to identify the security perimeter, including maintenance interfaces, digital interfaces such as passenger devices, crew systems, and connections between avionics systems, as well as existing security mechanisms within systems. In addition, the environment needs to be defined and analysed, including any other systems that may come into contact with the system, such as air-traffic or passenger-booking systems. These outside systems must be identified and the security threat analysis must cover potential threats from these sources. Also, there must be provision made to update the security scope throughout the whole lifecycle of the continually evolving system, for example to respond to the introduction of new technologies such as next-generation cellular or cloud computing or new systems within the environment.
Threats and Assessment
The next step is to consider the threats to the system and identify the conditions under which they may occur: for example, allowing passengers to connect their devices to the IFE to stream information increases the risk of attacks being injected into the system. Security requirements should be documented for outside sources and RTCA DO-356 ‘trust levels’ identified such as who to trust and to what degree using safety levels in the ‘Software Considerations in Airborne Systems and Equipment Certification’ DO-178C standard.
A security risk assessment then needs to be performed to map threat scenarios on to the security system to identify potential vulnerabilities. This assessment maps vulnerabilities on to failure conditions as defined in the CFR 25.1209 and EASA CS-25 35.1309 certifications in safety analysis terms from ‘No Effect’ through to ‘Catastrophic’. This analysis also identifies the risk associated with each threat identified, so a value judgment can be made on the level of protection required.
Architecture
The security architecture can now be implemented to mitigate the risks identified and to protect the assets within the security scope. Concepts such as defence in depth and layered assurance ensure greater security, as any particular threat will need to penetrate multiple security measures. Layered protection for each system should cover system design, boot, run time and power down; and for each of these elements, systems should align the security architecture to identified threats.
As with DO-178C, design involves the process through which the code is developed. The higher the required level of safety protection, the more investment will be needed in the code development process. One way of reducing risk for code development is to use commercial off-the-shelf (COTS) components wherever it makes sense, such as the operating system (OS). As an example, Wind River’s VxWorks and Wind River Linux come with full security capabilities defined in security profiles for use in developing system security architectures.
To implement layered protection, security measures must start on power up. In IT environments, the most difficult attacks to remove are those at the boot and initialization stages. As the hardware executes its firmware, the system needs to ensure the firmware has not been compromised and that it boots into the expected secure environment. As this is tied to the hardware system, it involves customisation as well as COTS secure boot technology.
Using a COTS OS that supports safety and security mechanisms also makes sense for the run-time architecture. The security threat analysis needs to be deep enough into the system architecture to ensure that the required OS features are enabled and configured accordingly, such as password protection. In power-down mode, data protection can be either in the form of encrypted storage or more sophisticated Anti-Tamper technology implemented both in hardware and software.
Testing
Finally, security testing needs to look for specific vulnerabilities both in OS code and in middleware such as networking code as well as in the applications. Testing should cover many aspects of security vulnerabilities such as confidentiality, integrity, authentication, availability, authorization and non-repudiation. The level of testing should be identified in the security scope and threats phases, and must also include a plan for further testing across the device lifecycle, both in terms of the existing solution and for emerging threats.
Benefits
The inevitable move toward e-enabled aircraft will provide many benefits for operators, manufacturers, and passengers, but the benefits will only be realised if the additional services can be made secure, without compromising safety.
Author profile:
Alex Wilson is director of business development, Aerospace and Defence, at Wind River
