WG72- ED127 Part 2

Working Paper 26

Part 2 Methodology Validation- EFB

V0.3

30-Nov-2009

Daniel P. Johnson

Honeywell

1  Purpose and Scope

The purpose of this document is to validate and demonstrate the ED127 Part 2 Airworthiness Security Process (AWSP) by applying it to the Electronic Flight Bag (EFB) Use Case as developed within the ED127 Part 1 AISS Reference Model. EFB is used as a design example but not as a certification example, in that it does not honor the scope of the existing regulations and practices governing actual EFB certification and approval.

References include:

1. ED-127, "Aeronautical Information System Security", V1.0.5, Aug 2009

2. FAA AC 120-76A, "Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices", Mar 2003

3. WG72 Part 1 Working Paper 20, "EFB Use Case - Working Paper", V1.01, Jun 2009

There are three classes of EFB-

1) Purely portable devices not subject to the normal aircraft administration and maintenance control processes and not normally connected to aircraft systems;

2) Portable devices subject to the normal aircraft administration and maintenance control processes that are allowed to be connected to aircraft systems; and

3) Mounted devices subject to the normal aircraft administration and maintenance control processes that are normally connected to aircraft systems. These devices are certified under the Type Certification of the aircraft.

Scoping: This study is limited to the consideration of Classes 2 and 3 EFBs. The reason is that AWSP involves the impact on flight safety of network connectivity to onboard aircraft systems due to the possibility of harm due to network attacks. Since Class 1 EFBs are not connected to the onboard aircraft systems, their consideration is not central to the purpose of AWSP, although the AWSP methodologies can be applied to Class 1 as well.

2  AWSP Preliminary Design

Figure 1 : AWS Activities During Preliminary Design

2.1  Aircraft Security Requirements

Activity: Aircraft Security Requirement

Part of (overall Aircraft Development): Aircraft Requirements

Purpose: Identify aircraft security needs, externalities, and requirements

Actions:

• Identify the aircraft/ aircraft system(s) security environment.

• Identify external information interfaces.

• Identify assumptions about the operational environment.

• Identify security domains and trust relationships.

• Identify existing security countermeasures.

2.1.1  Aircraft Requirements

Before we can focus on the security requirements, we need to define the EFB system requirements. Normally, these are provided by the overall Aircraft Development Process, which the AWSP depends on.

A critical assumption within this analysis is that the EFB is an advisory system to the flight crew. As such, it provides supplemental information to the flight crew to aid the flight crew during the flight phases. Note that the EFB does not provide information directly to the onboard automatic aircraft control systems- it is a crew advisory system only.

An EFB provides an application platform for a variety of applications that in turn are classified into Types A, B, and C, each of which have different levels for operational approval.

Scoping: The following application functions were identified as key within the EFB Use Case Study and will be used to define the EFB functionality. This design example will only consider this level of detail in the applications. Assessment of individual applications and interference between applications will not be considered in this design example.

Identified EFB Functions:

Take-off / Provide aircraft performance during Take-off / This includes V speed limits, rotation rates, engine speed settings, pitch trim settings, wind direction and speed, runway conditions.
Landing / Provide Approach Directions during Landing / This includes approach plates, wind direction and speed, airport conditions.
Taxi Guidance / Provide taxi route and progress along route. / This includes runway exit and aircraft position.

Taxi situation awareness, covered under another AC<taxi routes come verbally from ATC, may be provided electronically as part of nexgen>

Own ship position is application on EFB>

2.1.2  Externalities

2.1.2.1  External Security Domains and Security Environment

Scoping: For this example, we are considering the EFB function within an aircraft. As a result, we are assessing the EFB system AND the aircraft security architecture within which the EFB system will operate. Hence assessment of the network architecture is within this scope, but only inasmuch as it affects the EFB function. Safety aspects of other systems are relevant only insofar as they cause an impact by having an impact on the EFB function.

Operational Context: The EFB is operated by the flight crew as part of their flight procedures. Flight crew procedures include interaction with other flight crew, aircraft control systems, ATC systems and processes, airport systems and processes, operator flight training and processes, and environmental observations.

Physical Security Context: Access to various areas of the aircraft, and to the aircraft itself, are subject to established airport security control processes and operator aircraft security control processes.

Maintenance Context: The EFB software and hardware are controlled through the aircraft maintenance control processes. This example does not include use of the ANI for software or application updating, although the criticality of the databases and charts means that many of the same security concerns will be addressed.

Administration Context: The EFB applications depend on charts and databases which are controlled through the aircraft administration control processes.

Offboard Context: For Class 2 EFBs, this includes handling of portable EFBs offboard the aircraft. There are three external contexts that are potentially involved in offboard use: operational use by flight crew, maintenance use by maintenance control processes, and administrative use by administration control processes.

Procurement and Development Context: This includes the procurement and development of the EFB hardware and software.

Note on scope difference from ARP SAE 4754: All five six contexts above represent safety aspects considered by Part 2 AWSP that are not included in the ARP SAE 4754 safety assessment process. Note that the purpose of AWSP is to assess dependence of the EFB system on the security controls of those external domains, not to assess the domains themselves.

2.1.2.2  External Information Interfaces

For purposes of this example, the following electronic interfaces are assumed.

External Interface <physical and logical> / Description
Mass Media Port / A physical port for electronic loading of applications and data
User Interface Devices / Physical devices such as keyboards for use and administration of the EFB and its applications
Aircraft Network Interface / An active network connection between the EFB and one or more onboard networks.
Gatelink <provide reference to standards<at ground communications> / An active network connection between one or more onboard networks through a Terminal Wireless LAN Unit to a Gatelink network hosted through the airport. The airport network is connected logically to the operator network as a part of aircraft administration control.
Airline <operator> Network Connection / An external (to aircraft networks) virtual dataflow between the EFB and the Airline Network used for aircraft administration control
EFB Peer Connection / An internal (to aircraft networks, external to EFB) virtual dataflow between the EFB and other onboard aircraft systems used by applications
ACARS/SWIM / An external (to aircraft networks) virtual dataflow between EFB and ATC service providers used by EFB applications, but mediated by an onboard Communications Manager
Peer External Connection / An external (to aircraft networks) virtual dataflow between an onboard aircraft system and its external service provider
Passenger Connection / There may be connections between onboard aircraft networks and passenger devices (e.g. IFE web services). There are no such connections to the EFB.
Flight Crew Laptop <note: not yet carried thru this example> / The flight crew may have laptops that are either corrupted through offboard connection or have external connections to internet services, and that have connections to (limited) onboard aircraft hosts. These laptops are not the EFB laptop.
<satcom instead of acars, e.g.inmarsat<airborne communications>

More detailed data flows for the EFB itself are defined below.

Data Item / Take-off / Landing / Taxi Guidance / Maint and Admin / External Interface
Databases (Table and Charts) / X / X / X / X / Airline/gatelink/ through installed dataloader
Application Software / X / X / X / X / Mass Media/ through installed dataloader
Platform Software / X / X / X / X / Mass Media
NOTAMs / X / X / X / ACARS/SWIM/UI/Airline
Weather / X / X / ACARS/SWIM/UI/Airline
Aircraft state / X / FMS
FMS Taxi Route / X / FMS
Load and Balance Data / X / FMS/UI//Airline
Crew Input and Check / X / X / UI
Taxi progress and position / X / Traffic Sensors and Navigation System
2.1.2.3  Existing Security Controls<Assumptions about the operational environment>

This example assumes those aircraft-level controls that have been established as part of current aircraft certification practices dealing with EFBs. In current certified aircraft types, EFB applications and data have been consistently classified at DAL levels C (<?when interacting with FMS>), D, or E. The basis for this classification is the use of EFBs as advisory aids to existing systems and not as primary or secondary aircraft-level functions. Existing aircraft level functions which supersede EFB functions include:

·  ATC ground dispatch procedures

·  ATC ground monitoring

·  ATC landing procedures

·  ATC monitoring

·  ILS systems

·  Landing checklist

·  Pilot control

·  Pilot manual backup

·  Pilot situation awareness

·  Flight policies and pilot training

·  Pilot-In-Command observation

·  Crew management practices

·  Runway markings

·  Take-off abort procedures

·  Take-off checklist

This example is not tied to a particular aircraft architecture. The only technical security controls it assumes are in place are those associated with established external security domains.

2.1.2.4  External Security Domains and Trust Relationships

Definition: A trusts B with respect to A's safety-related security objectives <??> if A chooses to demonstrate those objectives by demonstrating that: if B satisfies B's safety-related security objectives then A will meet A's objectives. B is trustworthy for A if B can demonstrate that B satisfies those B objectives that A cares about.

Essentially, "A trusts B" means that A is claiming that A is secure because B is secure. Note that some would define this as "blind trust", not "trust".

Operational Context / Passengers are not trusted. Flight crew, cabin crew, and maintenance crew are trusted to a level that is consistent with the impact of their authorized activities (see Section 2.2.4 for more details). Flight crew laptops are not trusted.
Physical Security Context / Physical security controls are assumed to be in place and can be trusted to a level that is consistent with established guidelines.
Maintenance Context / Maintenance crew and maintenance control policies (including independent contracted entities) are trusted to a level that is consistent with the impact of their authorized activities (see Section 2.2.4 for more details).
Administration Context / Administration personnel and administration control policies (including independent contracted entities) are trusted to a level that is consistent with the impact of their authorized activities (see Section 2.2.4 for more details).
Offboard Context / Level of dependence on trust for offboard control policies are to be determined through this example.
Procurement and Development Context / Level of dependence on trust for procurement and development are to be determined through this example.

2.2  Threat Identification

Activity: Threat Identification

Purpose: Identify the information security threats to flight safety

Actions:

• Determine threat source profile(s).

• Identify the threat conditions associated with the aircraft level functions.

• Identify functional security dependencies between threat conditions and threats.

• Categorize information asset classes.

• Coordinate with FHA.

• Assess safety impact of threat conditions.

• Identify additional verification studies to validate assumptions involving issues that need to be resolved by data from later stages.

Scoping: Since this example does not assume a particular aircraft architecture, we will not be including an assessment of the indirect threat that a compromised EFB might pose to other onboard aircraft systems. An actual aircraft assessment will include the consideration of indirect threats, which may or may not be allocated to the EFB system itself. Some of the issues involved will be discussed in this example as part of the consideration of the possible threat to the EFB of an attack on an EFB peer system.

2.2.1  Functional Hazard Analysis (FHA), Aircraft-level Considerations

Before we look at the threat conditions, we need to extract the required safety hazard information from the aircraft-level FHA for the EFB. The table below extracts those aircraft-level hazards which can be attributed in part to an EFB failure condition. In addition, the table shows the aircraft-level controls which are considered the primary and secondary controls within this example.

In aeronautical systems, no serious incident is the result of a single event or action but is the result of multiple failures and events. Hence "Safety Impact" is determined through the magnitude of the reduction in the safety margins and functional capabilities.

Table from ED127 Part 2, Table 12, Allocated Safety Impact shows that since EFB is not a primary or secondary element, it can be classified as the lowest allowed classification of impact when there is a non-negligible effect on the safety margin is Level III.

Impact / Allocated Safety Impact for Independent Architectural Elements, based on analysis of security architecture
I / Elements must include at least two independent security countermeasures with an allocated safety impact of II or higher, but no element should be lower than III.
II / Elements must include at least two independent security countermeasures with an allocated safety impact of III or higher, but no element should be lower than IV.
III / Elements must include at least two independent security countermeasures with an allocated safety impact of IV or higher.
IV / Elements must include at least one security countermeasures with an allocated safety impact of IV or higher.
EFB Function / Aircraft level hazard / Aircraft level Safety Impact / EFB High-level Failure Condition / Category / EFB Externalities- Aircraft-level controls <reasons why> / EFB Safety DAL
<allocated impact>
Take-off / Underpowered Take-off / Catastrophic / Display incorrect V, et.al. for conditions to pilot / Integrity / Pilot control, CoPilot-In-Command observation, Pilot situation awareness, Pilot training, Take-off abort procedures / C
Take-off / Underpowered Take-off / Catastrophic / Unable to display V, et. al. to pilot / Availability / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Pilot training, Take-off checklist, Manual backup / E
Take-off / Unstable at Take-off / Catastrophic / Display incorrect trim for conditions to pilot / Integrity / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Pilot training, Take-off abort procedures / C
Take-off / Unstable at Take-off / Catastrophic / Unable to display unstable condition to pilot / Availability / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Pilot training, Take-off checklist, Manual backup / E
Landing / Controlled Flight Into Terrain / Catastrophic / Display incorrect landing approach / Integrity / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Runway markings, Pilot training, ATC landing procedures, ATC monitoring, ILS systems / C
Landing / Controlled Flight Into Terrain / Catastrophic / Unable to display landing approach / Availability / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Runway markings, Pilot training, Landing checklist, ATC landing procedures, ATC monitoring, ILS systems, Manual backup / E
Taxi / Runway incursion / Severe <catastrophic> / Display incorrect taxi guidance / Integrity / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Runway markings, Pilot training, ATC ground dispatch procedures, ATC ground monitoring / C
Taxi / Runway incursion / Severe / Unable to display taxi guidance / Availability / Pilot control, Pilot-In-Command observation, Pilot situation awareness, Runway markings, Pilot training, ATC ground dispatch procedures, ATC ground monitoring, Manual backup / E

<clarify-- this is from FHA, this is use of FHA to generate EFB situation, better show how EFB hazard effect is related to aircraft level effect