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 EFB1) 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
Type Certification
Airworthiness Security (AWS)
Assessment Process
AWS Requirements
Management Process
Aircraft Reqmnts
Aircraft Security
Requirements
FHA
Threat
Identification
Externalities
Concepts of
Operation
Externalities
Alloc to Systems
Aircraft Security
Architecture
Type
Certification
Preliminary
Aircraft Security
Risk
Assessment
System Security
Requirements
PSSA
Preliminary
System Security
Risk
Assessment
Syst Arch
System Security
Architecture
Item Security
Requirements
Item
Development
Item
Development
Product
Data
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
Landing
Provide Approach Directions
during Landing
Provide taxi route and progress
along route.
Taxi
Guidance
This includes V speed limits, rotation rates,
engine speed settings, pitch trim settings, wind
direction and speed, runway conditions.
This includes approach plates, wind direction and
speed, airport conditions.
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 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>
Mass Media Port
User Interface Devices
Aircraft Network
Interface
Description
A physical port for electronic loading of applications and data
Physical devices such as keyboards for use and administration of the
EFB and its applications
An active network connection between the EFB and one or more
onboard networks.
Gatelink <provide
reference to
standards><at ground
communications>
Airline <operator>
Network Connection
EFB Peer Connection
ACARS/SWIM
Peer External
Connection
Passenger Connection
Flight Crew Laptop
<note: not yet carried
thru this example>
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.
An external (to aircraft networks) virtual dataflow between the EFB and
the Airline Network used for aircraft administration control
An internal (to aircraft networks, external to EFB) virtual dataflow
between the EFB and other onboard aircraft systems used by
applications
An external (to aircraft networks) virtual dataflow between EFB and
ATC service providers used by EFB applications, but mediated by an
onboard Communications Manager
An external (to aircraft networks) virtual dataflow between an onboard
aircraft system and its external service provider
There may be connections between onboard aircraft networks and
passenger devices (e.g. IFE web services). There are no such
connections to the EFB.
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)
Application
Software
Platform Software
NOTAMs
Weather
Aircraft state
FMS Taxi Route
Load and Balance
Data
Crew Input and
Check
Taxi progress and
position
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Airline/gatelink/ through
installed dataloader
Mass Media/ through
installed dataloader
Mass Media
ACARS/SWIM/UI/Airline
ACARS/SWIM/UI/Airline
FMS
FMS
FMS/UI//Airline
X
X
X
X
X
UI
X
Traffic Sensors and
Navigation System
2.1.2.3 <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 safetyrelated 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
Physical Security
Context
Maintenance Context
Administration Context
Offboard Context
Procurement and
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 controls are assumed to be in place and can be
trusted to a level that is consistent with established guidelines.
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 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).
Level of dependence on trust for offboard control policies are to be
determined through this example.
Level of dependence on trust for procurement and development are to
Development Context
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, the lowest allowed classification of impact when there
is a non-negligible effect on the safety margin is Level III.
Impact
I
II
Allocated Safety Impact for Independent Architectural
Elements, based on analysis of security architecture
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.
Elements must include at least two independent security
countermeasures with an allocated safety impact of III or higher,
III
IV
but no element should be lower than IV.
Elements must include at least two independent security
countermeasures with an allocated safety impact of IV or higher.
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>
Take-off
Underpowered
Take-off
Catastrophic
Integrity
CoPilot observation, Pilot situation awareness,
Pilot training, Take-off abort procedures
Take-off
Underpowered
Take-off
Catastrophic
Display incorrect
V, et.al. for
conditions to pilot
Unable to display
V, et. al. to pilot
Availability
Take-off
Unstable at
Take-off
Catastrophic
Integrity
Take-off
Unstable at
Take-off
Catastrophic
Landing
Controlled
Flight Into
Terrain
Catastrophic
Display incorrect
trim for conditions
to pilot
Unable to display
unstable condition
to pilot
Display incorrect
landing approach
Landing
Controlled
Flight Into
Terrain
Catastrophic
Unable to display
landing approach
Availability
Taxi
Runway
incursion
Severe
<catastrophic>
Display incorrect
taxi guidance
Integrity
Taxi
Runway
incursion
Severe
Unable to display
taxi guidance
Availability
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Pilot training, Takeoff checklist, Manual backup
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Pilot training, Takeoff abort procedures
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Pilot training, Takeoff checklist, Manual backup
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Runway markings,
Pilot training, ATC landing procedures, ATC
monitoring, ILS systems
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Runway markings,
Pilot training, Landing checklist, ATC landing
procedures, ATC monitoring, ILS systems,
Manual backup
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Runway markings,
Pilot training, ATC ground dispatch
procedures, ATC ground monitoring
Pilot control, Pilot-In-Command observation,
Pilot situation awareness, Runway markings,
Pilot training, ATC ground dispatch
procedures, ATC ground monitoring, Manual
backup
Availability
Integrity
EFB
Safety
DAL
<allocated
impact>
C
E
C
E
C
E
C
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>
2.2.2 EFB Functional Hazard Analysis (FHA)
The resulting reductions in the safety margins for the actual EFB and its functions are
shown in the following table.
EFB
Functions
EFB Hazard
Take-off
Display incorrect V, et.al.
for conditions to pilot
Unable to display V, et.
al. to pilot
Display incorrect trim for
conditions to pilot
Unable to display
unstable condition to
pilot
Display incorrect landing
approach
Unable to display landing
approach
Display incorrect taxi
guidance
Unable to display taxi
guidance
Take-off
Take-off
Take-off
Landing
Landing
Taxi
Taxi
Safety
Impact
Major
Category
No Effect
Availability
Major
Integrity
No Effect
Availability
Major
Integrity
No Effect
Availability
Major
Integrity
No Effect
Availability
Integrity
Issue: Under current regulations, EFB and EFB applications are not evaluated through the
SAE ARP 4754/AMC 25.1309 process. In practice, at best they would have the
equivalent of a DAL D classification.
2.2.3 EFB Direct Threat Conditions
Having identified the hazards, the direct threat conditions are those conditions of the EFB
and its applications that can cause the hazards listed above. This is based on the EFB
functional dependencies and data items.
The following cross reference table matches the threat conditions of the data items to the
EFB hazards..
Threat Condition
Corrupted Database loaded
in EFB
Corrupted
Application/Platform running
in EFB
Corrupted NOTAM in EFB
Corrupted Weather in EFB
Corrupted Aircraft State in
EFB
Corrupted Taxi Route in
EFB
Corrupted Taxi Progress in
EFB
Corrupted L&B Data in EFB
Corrupted Crew Input and
Check in EFB
Portion of Databases loaded
missing from EFB
Portion of
Application/Platform missing
from EFB
Portion of NOTAM missing
from EFB
Portion of Weather missing
from EFB
Portion of Aircraft State
missing from EFB
Portion of Taxi Route
missing from EFB
Portion of Taxi Progress
missing from EFB
Portion of L&B Data missing
from EFB
Portion of Crew Input and
Check missing from EFB
Application
Take-Off
Hazard
Display
incorrect V,
et.al. for
conditions to
pilot
Unable to
display V, et.
al. to pilot
Display
incorrect trim
for conditions
to pilot
Unable to
display
unstable
condition to
pilot
Display
incorrect
landing
approach
Unable to
display
landing
approach
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Landing
X
X
X
X
X
X
Taxi
Guidance
Display
incorrect taxi
guidance
Unable to
display taxi
guidance
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
The resulting direct threat conditions of the EFB applications and data can be
summarized as below.
Note: Corrupted data is data that is available, erroneous, but has not been detected as
erroneous. It includes coherently corrupted data (data that is well-structured in terms of
expected formats and checksums).
Threat Condition
Corrupted Databases (Tables, Charts) loaded in EFB
Corrupted Application/Platform running in EFB
Corrupted NOTAM in EFB
Corrupted Weather in EFB
Corrupted Aircraft State in EFB
Corrupted Taxi Route in EFB
Corrupted Taxi Progress in EFB
Corrupted L&B Data in EFB
Corrupted Crew Input and Check in EFB
Portion of Databases (Tables, Charts) missing from EFB
Portion of Application/Platform missing from EFB
Portion of NOTAM missing from EFB
Portion of Weather missing from EFB
Portion of Aircraft State missing from EFB
Portion of Taxi Route missing from EFB
Portion of Taxi Progress missing from EFB
Portion of L&B Data missing from EFB
Portion of Crew Input and Check missing from EFB
Impact
Major
Major
Major
Major
Major
Major
Major
Major
Major
No Effect
No Effect
No Effect
No Effect
No Effect
No Effect
No Effect
No Effect
No Effect
Scoping: We will only consider those direct threat conditions which have a safety effect,
i.e. we will not further analysis those direct threat conditions with "No Effect". We will
continue to consider those direct threat conditions associated with maintenance actions
such as software and databases.
2.2.4 Threat Exposure and Source Profiles
Note: This design example is partially tutorial in nature. As a result, it will illustrate some
cases where the initial analysis should be updated as a consequence of later analysis.
Those cases will be noted below in this design example, but one should look at the
material in the appendices (to be added later) for the actual final tables.
The inherent vulnerabilities of the EFB are the means by which an attacker can cause a
threat condition by using the intended functionality of the design.
Inherent Vulnerability
Mass Media Port
User Interface
Intended Use
Software, Databases
User input and checks, NOTAMs, Load
Aircraft Network Interface
Dataflow from ACARS/SWIM
Dataflow from Aircraft
Administration Organization
Dataflow from FMS, Traffic
Sensors, and Navigation System
Offboard use of portable EFB
Other external dataflows to EFB
and Balance
Support dataflows
NOTAMs, Weather
Database/Charts, NOTAMS, Load and
Balance
Aircraft State, Load and Balance, Taxi
Route, Taxi Progress
EFB maintenance and administration, use
by offboard user
Use not forbidden
Without further countermeasures or assurances, this results in the following exposure and
potential threat sources:
Potential Exposed
Vulnerability
Access to EFB User Interface
(offboard access considered
separately)
Access to FMS
Access to Mass Media Port
Access to onboard EFB
Access to Traffic Sensors and
Navigation
Access to SWIM
Access to ACARS
Access to Aircraft Network
External
Countermeasures
Aircraft physical access
control
Exposure with external
countermeasures
Flight crew, maintenance
Aircraft physical access
control
Aircraft physical access
control
Aircraft physical access
control
Aircraft physical access
control
SWIM ground system
access control
ACARS ground system
access control
pending
Flight crew, maintenance
Flight crew, maintenance
Flight crew, maintenance
Flight crew, maintenance
Authorized SWIM users
Authorized ACARS users
Access to EFB Aircraft
Network Interface
pending
Access to NOTAM/Weather
Upload Dataflow from
ACARS/SWIM Host
Access to FMS Data Upload
Dataflow from FMS
pending
Access to Other EFB Peer
Data Upload Dataflow from
FMS
Access to Gatelink/TWLU
pending
Access to Gatelink Network
Access to Airline L&B Data
Upload Dataflow From Airline
Access to Database Upload
pending
pending
Flight crew, cabin crew,
maintenance, passengers, flight
crew laptops
Flight crew, cabin crew,
maintenance, passengers, flight
crew laptops
Flight crew, cabin crew,
maintenance, passengers, flight
crew laptops
Flight crew, cabin crew,
maintenance, passengers, flight
crew laptops
Flight crew, cabin crew,
maintenance, passengers, flight
crew laptops
Flight crew, cabin crew,
maintenance, passengers, , flight
crew laptops general airport
population
Anyone
Anyone
pending
Anyone
pending
Airport physical access
control
Dataflow From Airline
Access to NOTAM/Weather
Upload Dataflow From Airline
Access to offboard EFB
Access to unintended External
Dataflows to EFB
Access within Airline
Administration
Access within development
process
pending
Anyone
pending
pending
Anyone
Anyone
Airline Administration
access control
pending
Authorized airline administration
Anyone
2.2.4.1 Threat Source Profiles
The following threat populations can be identified from the analysis above:
Population
Flight Crew
Cabin Crew
Maintenance
Crew
Airline
Administration
ACARS/SWIM
Users
Developers
Passengers
Airport
population
Anyone
Flight Crew
Laptop
Threat Likelihood
pI
pI
pI
pIII
pIII
pIII
pV
pV
pV
pV
Supplemental information as needed for particular methodologies for threat assessment
should also be defined. <scope of insider threat>
Population
Flight Crew
(example)
Motivation
Error or Insider
Cabin Crew
Error or Insider
Maintenance
Crew
Airline
Administration
ACARS/SWIM
Users
Developers
Error or Insider
Passengers
Curious or
Malicious
Curious or
Airport
Error or Insider
Error or Insider
Error or Insider
(example) Capability
Threat Likelihood
Full knowledge, portable attack tools,
1 flight cycle
Full knowledge, portable attack tools,
1 flight cycle
Full knowledge, portable attack tools,
1 ground cycle
Full knowledge, general attack tools,
indefinite
Full knowledge, general attack tools,
indefinite
Full knowledge, general attack tools,
indefinite
General knowledge, portable attack
tools, 1 flight cycle
General knowledge, portable attack
pI
pI
pI
pIII
pIII
pIII
pV
pV
population
Anyone
Flight Crew
Laptop
Malicious
Curious or
Malicious
Inadvertent or
Malicious
tools, 1 ground cycle
General knowledge, general attack
tools, indefinite
Autonomous malware (trojan, virus,
bot), general knowledge, general
attack tools, 1 flight cycle
pV
pV
2.2.5 Preliminary Aircraft Security Risk Assessment for "Do Nothing"
Security Architecture
Purpose: Assess information security risks and generate security objectives for items
Actions:
•
Assess the system security architecture.
•
Assess vulnerabilities.
•
Categorize information assets.
•
Determine and classify threat scenarios.
•
Evaluate information security risks.
•
Determine risk treatment, including possible gaps in security architecture.
•
Identify item security levels, including those of external entities and interfaces
(trust levels).
•
Allocate item threats and impact.
•
Develop preliminary external agreements (e.g., operator requirements,
maintenance requirements).
•
Coordinate with Preliminary Safety Assessment.
•
Coordinate with System Security Architecture.
Note, ED127 Part 2, Figure 18, Determination Of Final Risk Level.
Risk Level
Threat Likelihood
Impact
V
IV
III
II
I
No Effect
Minor
Major
Hazardous
Catastrophic
pV
Frequent
Low
Medium
Medium
High
High
pIV
Probable
Low
Low
Medium
Medium
High
pIII
Remote
Low
Low
Low
Medium
Medium*
pII
Extremely
Remote
Low
Low
Low
Low
Medium*
pI
Extremely
Improbable
Low
Low
Low
Low
Medium*
* = Risk justification must include demonstrating the absence of a
single point of security weakness
In the absence of any other countermeasures or assurances, we can perform the following
risk assessment.
Threat Condition
Potential Exposed
Vulnerability
Access to EFB User
Interface
Threat Exposure
Impact
Liklihood
Risk
Flight crew,
maintenance
III
pI
Low
Access to FMS
Flight crew,
maintenance
III
pI
Low
Access to Mass
Media Port
Flight crew,
maintenance
III
pI
Low
Access to onboard
EFB
Flight crew,
maintenance
III
p
Low
Access to Traffic
Sensors and
Navigation
Access to SWIM
Flight crew,
maintenance
III
pI
Low
Authorized SWIM
users
III
pIII
Low
Access to ACARS
Authorized
ACARS users
III
pIII
Low
Corrupted
Databases/ Load
and Balance/
NOTAM/ Weather
in EFB
Corrupted
Data/Databases in
EFB
Access within Airline
Administration
Authorized airline
administration
III
pIII
Low
Access to Aircraft
Network
III
pV
Medium
Corrupted
Data/Databases in
EFB
Access to EFB
Aircraft Network
Interface
III
pV
Medium
Corrupted
NOTAMS/Weather
in EFB
Access to
NOTAM/Weather
Upload Dataflow from
ACARS/SWIM Host
Access to FMS Data
Upload Dataflow from
FMS
Flight crew, cabin
crew,
maintenance,
passengers
Flight crew, cabin
crew,
maintenance,
passengers
Flight crew, cabin
crew,
maintenance,
passengers
Flight crew, cabin
crew,
maintenance,
passengers
Flight crew, cabin
crew,
maintenance,
passengers
Flight crew, cabin
crew,
III
pV
Medium
III
pV
Medium
III
pV
Medium
III
pV
Medium
Corrupted
NOTAM/Crew
Input in EFB
Corrupted Load
and Balance/
Aircraft State/Taxi
Route in EFB
Corrupted
Software/
Databases in EFB
Corrupted
Software/
Databases in EFB
Corrupted Taxi
Progress in EFB
Corrupted
NOTAMS/Weather
in EFB
Corrupted
NOTAMS/Weather
in EFB
Corrupted Load
and Balance/
Aircraft State/Taxi
Route in EFB
Corrupted Data in
EFB
Corrupted Data in
EFB
Access to Data
Upload Dataflow from
other EFB Peer
Access to
Gatelink/TWLU
Corrupted Data in
EFB
Corrupted Load
and Balance in
EFB
Corrupted
Databases in EFB
Corrupted
NOTAMS/Weather
in EFB
Corrupted
Software/
Databases in EFB
Corrupted
Software/
Databases in EFB
Corrupted
Software/
Databases in EFB
Access to Gatelink
Network
Access to Airline L&B
Data Upload
Dataflow From Airline
Access to Database
Upload Dataflow
From Airline
Access to
NOTAM/Weather
Upload Dataflow
From Airline
Access to offboard
EFB
Access to unintended
External Dataflows to
EFB
Access to
Development
Process
maintenance,
passengers,
general airport
population
Anyone
III
pV
Medium
Anyone
III
pV
Medium
Anyone
III
pV
Medium
Anyone
III
pV
Medium
Anyone
III
pV
Medium
Anyone
III
pV
Medium
Anyone
III
pV
Medium
2.2.6 Aircraft Security Architecture
Activity: Aircraft Security Architecture
Purpose: Establish aircraft security architecture and countermeasures
Actions:
•
Determine aircraft security architecture and countermeasures.
•
Allocate security functions to systems.
•
Determine externalities (external to system) for each system.
•
Identify information assets.
•
Coordinate with Threat Identification, Preliminary Aircraft Security Risk
Assessment, and System Security Objectives.
•
Coordinate with Aircraft Safety Architecture.
From the architecture design and assessment, we can determine the security functional
requirements and security levels for efficiency and assurance.
From the security levels and requirements, we can set the software assurance and
requirements.
From the last analysis, there is a need to add security countermeasures. The following is a
discussion of possible measures:
2.2.6.1 Candidate Security Countermeasures
This section presents the set of security countermeasures to be considered in this design
example. The selection of security countermeasures is part of the design process. ED1272 does not dictate a particular choice of countermeasures, rather it defines how to analyze
whatever countermeasures the designers wish to consider, and how to determine if the
defined countermeasures are sufficient and complete.
Definition: Effectiveness is the ability of a security countermeasure to reduce the
exposure of a vulnerability to the threat population. Efficiency is the effectiveness when
the security countermeasure is operating as intended. Assurance is the evidence that the
countermeasure will operate or is operating as intended.
Scoping: This design example does not consider security architecture features based on
the internal software architecture of the EFB, such as protected memory partitions or
control of OS privileges and user rights, but is based on partitioning through use of
separate aircraft hosts.
Vulnerability/Risk
Access to Aircraft Network
Access to EFB Aircraft Network
Interface
Access to NOTAM/Weather Upload
Dataflow from ACARS/SWIM Host
Access to FMS Data Upload
Dataflow from FMS
Access to Data Upload Dataflow
from other EFB Peer
Access to Gatelink/TWLU
Access to Gatelink Network
Access to Airline L&B Data Upload
Dataflow From Airline
Access to Database Upload
Dataflow From Airline
Access to NOTAM/Weather Upload
Dataflow From Airline
Access to offboard EFB
Access to Other External Dataflows
to EFB
Access to Development Process
Note
Passengers and Fight Crew laptop
have inherent access, so this will be
broken up into finer grained access,
e.g. TWLU access, access to intended
dataflows and network interface
Subsumed by "intended EFB peer
dataflow" and external trust of
ACARS/SWIM
Subsumed by " intended EFB peer
dataflow"
Subsumed by " intended EFB peer
dataflow"
Subsumed by " intended EFB airline
dataflow"
Subsumed by " intended EFB airline
dataflow"
Subsumed by " intended EFB airline
dataflow"
<in general, review level of definitions below. WEP/WPA is too detailed, some of the
others need to be more technically oriented>
2.2.6.1.1 Access through TWLU wireless access point
countermeasure
efficiency requirement
WEP
authorization
<authentication
and encryption>
WPA2
authorization
Reduce exposure from "general airport
population" to "general airport
population possessing WEP attack tool"
Reduce exposure from "general airport
population" to "Gatelink users"
potential
vulnerabilities
failure or
defect, loss of
security data
assurance
failure or
defect, loss of
security data
implementation
implementation
Scoping: In this design case, we will judge WEP as ineffective due to lack of efficiency.
Note that overall we are hoping to reduce a "pV" to a "pIII". There may be cases where
the efficiency of WEP may be sufficient.
2.2.6.1.2 Access to Gatelink through Gatelink Network
countermeasure
efficiency requirement
Trust Gatelink
Network to
control access
Reduce exposure from "Gatelink Users"
to "Authorized Gatelink Users"
potential
vulnerabilities
failure
assurance
external
agreement
Note: Consider adding to Threat Source Profiles:
Authorized
Gatelink Users
Curious or Malicious or
Competitors or
Uncertified Organization
General knowledge, general
attack tools, indefinite
pV
Note: This represents a large business risk due to competitive interests, which would also
require a confidentiality security requirement.
<issue: sometimes airlines will use TWLU to route to off-gatelink network>
Scoping: In this design case, we will judge this as ineffective due to lack of efficinecy in
that the "Authorized Gatelink Users" remains a large and significant threat source. In
addition, this design case is going to use access to the Gatelink network as a proxy for
dataflows though uncontrolled internet networks.
2.2.6.1.3 Access to the intended EFB dataflow from airline
countermeasure
efficiency requirement
potential vulnerabilities
assurance
Integrity Check
on Intended
Airline Dataflow
Reduce exposure from
"Anyone" to "Airline
Administration"
cryptographic weakness,
bypass at source or
destination, loss of security
data
technical,
assurance for
source and
destination
2.2.6.1.4 Access to Airline administration upload tools
countermeasure
efficiency requirement
Trust Airline Organization to
control access to EFB
upload system
Reduce exposure from
"Anyone" to "Airline
Administration"
potential
vulnerabilities
failure
assurance
operational
requirements
2.2.6.1.5 Access to Unintended External Dataflows to EFB
countermeasure
efficiency requirement
Design forbids unintended
external dataflows
Security Domain to control
external flows
Reduce exposure from
"Anyone" to "No one"
Reduce exposure from
"Anyone" to "No one"
potential
vulnerabilities
unintended
external dataflow
failure,
misconfiguration
assurance
implementation
implementation
Note: The dynamic addition of functionality to EFB applications or platform is
considered to be software corruption and is allocated to that part of the assessment.
<logical dataflows are application-level dataflows>
Note: Requirement to forbid unintended external dataflows is part of standard
implementation assurance requirements.
2.2.6.1.6 Access to intended EFB Dataflow from EFB Peer
countermeasure
Integrity Check
on Intended Peer
Dataflow
efficiency requirement
Reduce exposure from
"Anyone" to "No one " (hostto-host security)
Security Domain
to prevent access
to internal flows
Reduce exposure from
"Anyone" to "Security
Domain Peer External
Service Providers"
potential vulnerabilities
cryptographic weakness,
bypass at source or
destination, loss of security
data
failure, misconfiguration
assurance
technical,
assurance for
source and
destination
implementation
Note: The process must now account for those Security Domain Peers with external
dataflows. Also note a security requirement that the EFB security domain must not
include the Passenger-accessible aircraft network host or the Flight Crew laptop.
External Service
Providers
Error or
Insider
Full knowledge, general attack tools,
indefinite
pIII
2.2.6.1.7 Access to EFB Aircraft Network Interface
countermeasure
efficiency requirement
Robustness with respect to
all network interactions
Security Domain to control
external flows
Reduce exposure from
"Anyone" to "No one"
Reduce exposure from
"Anyone" to anyone with
access to intended
dataflow to EFB or access
to security domain peer
Reduce exposure from
"Anyone" to anyone with
access to security domain
peers
Communications Manager
to manage all external
flows to EFB
potential
vulnerabilities
failure
assurance
failure,
misconfiguration
implementation
failure
implementation
implementation
Note: Remember that robustness is with respect to anyone who has some ability to
interact with the EFB Aircraft Network Interface, which includes those with access to a
EFB Dataflow (even when encrypted) such as the Authorized Gatelink Users.
Note: Communications Manager would need to be added to assessment, and would likely
inherit requirement for robustness.
2.2.6.1.8 Access to Offboard EFB
countermeasure
efficiency requirement
Trust Airline Organization to
control access to offboard
EFB
Preboard scanning and
cleaning of offboard EFB
Reduce exposure from
"Anyone" to "Authorized Crew
and Administration"
Reduce exposure from
"Anyone" to "Authorized Crew
and Administration"
potential
vulnerabilities
failure
assurance
failure
operational
requirements
operational
requirements
Note: Preboard scanning and cleaning may imply technical features for the EFB.
Discussion: Note that the previous two countermeasures control the same vulnerability,
and also involve specifying how the trusted organization should safeguard the offboard
EFB. They should be combined into a single trust relationship.
countermeasure
efficiency requirement
Trust Airline Organization to
protect offboard EFB
Reduce exposure from
"Anyone" to "Authorized Crew
and Administration"
2.2.6.1.9 Access to Development Process
potential
vulnerabilities
failure
assurance
operational
requirements
countermeasure
efficiency requirement
Trust Development
Organization to protect EFB
implementation
Reduce exposure from
"Anyone" to "Authorized
Developers"
potential
vulnerabilities
failure
assurance
implementation
Note: This is really an inherent part of the overall process and does not require explicit
considerations. The requirement to protect implementation is part of standard
implementation assurance requirements.
2.2.6.2 Trusting the FMS
The EFB has inherent vulnerabilities from the FMS, the ACARS/SWIM
Communications manager, Traffic Sensors, and Navigation, because it accepts solesource data from those systems. However, in general an attack on the FMS that could
then be used to stage an attack on the EFB already represents a direct threat condition on
the FMS, and the safety impact of the FMS is as great or greater than the safety impact of
the EFB. Thus the FMS can be trusted by the EFB- a FMS that complies with its own
safety-related security objectives will also satisfy the safety-related security objectives of
the EFB that are associated with the FMS itself.
There could be exceptions- if the FMS accepted data that is less critical to the FMS than
it is to the EFB, then an assessment of the FMS might miss the indirect threat to the EFB.
As a result, the dependence of the EFB on the FMS must be included in an overall
aircraft assessment.
<this should be included as a countermeasure to be consitent with this example>
2.2.6.3 Candidate Architecture Approaches
For this example, we will be evaluating three possible architectural approaches:
 Self-protection
The EFB system is to provide all protection for itself.
 Delegated protection The Aircraft will provide all protection for the EFB system.
 Layered protection Both Aircraft and EFB will provide protection to minimize
overall assurance requirements and to provide redundant layered protection. Note
that layered protection could be achieved through multiple layers by the Aircraft
alone, but this will not be pursued in this example.
Self-protection is provided through integrity checks on the dataflows, and through
robustness of the EFB ANI. Delegated protection is provided through security domains
and a communications proxy.
To simplify the analysis, we will do the following.
 Consider the Take-off application only.
 Combine application software and platform software into software, and assume it
is only being loaded from the Mass Media Port.
 Assume that Weather and NOTAMs are being loaded from the FMS.


Assume that Databases are being loaded either from the Mass Media Port, or
through a remote link to the Airline.
Assume that Load and Balance information are either being loaded from the FMS
or through a remote link to the Airline.
2.2.6.4 Security Levels
The Security Level is a classification of the effectiveness (comprising efficiency and
assurance) of a system or item (which is a component of a specified security
countermeasure) to reduce the threat likelihood of a threat population. It assumes a base
threat population representative of a broadband connection to the general uncontrolled
Internet.
Security
Level:
A
B
C
D
E
is the level of effectiveness necessary
to take an attack likelihood of:
pV (Frequent)
pV (Frequent)
pV (Frequent)
pV (Frequent)
pV (Frequent)
and reduce it to a threat
likelihood of:
pI (Extremely Improbable)
pII (Extremely Remote)
pIII (Remote)
pIV (Probable)
pV (Frequent)
In conjunction with the risk table, this implies the following association with Impact:
Security is necessary to protect a
against a threat
Level:
vulnerability with impact: likelihood of:
A
I* (Catastrophic)
pV (Frequent)
B
II (Hazardous)
pV (Frequent)
C
III (Major)
pV (Frequent)
D
IV (Minor)
pV (Frequent)
E
V (No Effect)
pV (Frequent)
* = with demonstration that there is no single point of security weakness
2.2.6.5 A Quick Look At Threat Trees
A threat tree is an event-logic tree that sorts out the combinations of attacks, failures, and
events that may result in a threat condition. The top level and the various "OR" gates
collect alternate paths of attack:
Incorrect Take-off
Info displayed to
pilot
NEWTOP
Corrupted Onboard EFB
Coherently Corrupted
Internal Peer Data in
EFB (NOTAM /Weather,
FM S L&B)
G008
G052
Page 2
Page 46
Coherently Corrupted
Database/Chart loaded
in EFB
Corrupted Airline L&B
Data in EFB
G001
G006
Page 25
Page 50
Corrupted software
running in EFB
Flight Crew enters
corrupted data into
EFB
G002
G007
Page 43
Page 51
Coherently Corrupted
Database/Chart loaded
in EFB
G001
Page 1
Page 50
8.00E-05
Corrupted
Database/Chart Upload
from M ass M edia Port
Coherently Corrupted
Database/Chart loaded
from network
interface
G085
G060
2.00E-05
8.00E-05
Page 26
Page 29
A security countermeasure is represented by its intended function and its failed function:
Access to offboard
EFB
Page 3
G089
Unauthorized access
to offboard EFB
Authorized aceess to
offboard EFB
G091
G092
Page 5
Page 7
Each leads to the threat population exposed by the intended security countermeasure:
Authorized aceess to
offboard EFB
G092
Page 4
Flight Crew
M aintenance
A015
A029
and the event that the security countermeasure fails:
Unauthorized access
to offboard EFB
Page 4
G091
Offboard EFB acccess
failure
Offboard Population
G093
G094
Page 6
and the threat population that is exposed when the security countermeasure fails:
Offboard Population
G094
Page 5
Page 33
Page 41
1.00E+00
Gatelink Network
cust omer
M aintenance
A044
A029
1.00E+00
1.00E-05
General
AN Host Service
Provider
A104
A061
1.00E+00
1.00E-03
Airline Ground
Systems user
A048
1.00E-05
As another example, consider the external integrity check:
Coherently Corrupted
Database/Chart loaded
from network
interface
G060
Page 25
8.00E-05
Database/Chart
Integrity Check
Failure
Corrupted
Database/Chart Upload
Dataflow from Airline
G068
G074
8.00E-05
1.00E+00
Page 30
Page 35
Database/Chart
Integrity Check
Failure
G068
Page 29
8.00E-05
Database/Chart
Integrity Check
Bypassed
Database/Chart
Integrity Check
Compromised (failure
or loss of security
data)
G042
G059
7.00E-05
1.00E-05
Page 31
<note that this is comporomise at the tijme of database integrity check applied>
Database/Chart
Integrity Check
Bypassed
G042
Page 30
7.00E-05
Corrupted Onboard EFB
Access to Airline
operations ground
syst em
G008
G064
5.00E-05
2.00E-05
Page 2
Page 32
Corrupted
Database/Chart Upload
Dataflow from Airline
G074
Page 29
1.00E+00
Corrupted Offboard
Database/Chart Data
Access to
Database/Chart
Dataflow or Tools
G075
G076
1.00E+00
Page 28
1.00E+00
Page 23
Corrupted Offboard
Database/Chart Data
Page 35
Page 26
G075
1.00E+00
Anyone
G026
1.00E+00
Page 19
In this case, the probabilities correspond to the threat likelihoods according to the
following table, but the probabilities are not as useful as the cutsets (see below).
pI
pII
pIII
pIV
pV
1E-9
1E-7
1E-5
1E-3
1
2.2.7 Assessment of Self-Protection Architecture
We assume the following security countermeasures have been added to the EFB Function
(see section 2.2.6.1 for additional information on each countermeasure). (Note that the
actual process of determining these countermeasure was one in which countermeasure
were introduced and exposed vulnerabilities assessed until a complete set of
countermeasures was determined. This iterative process will not be illustrated here.)
Every time a countermeasure is introduced into the security assessment, the modified
assessment must then account for the effectiveness of the security countermeasure by
accounting for the efficiency (how the countermeasure performs when operating as
intended) and the assurance (how the countermeasure performs when it fails). So we
introduce inherent and known vulnerabilities for efficiency, and potential vulnerabilities
for assurance.
Countermeasure 1:
Trust Airline Organization to protect offboard EFB
Countermeasure 2:
Integrity Check on Intended Dataflow from Airline
Countermeasure 3:
Forbid unintended external dataflows in EFB applications.
Countermeasure 4: EFB network stack is robust with respect to all network
interactions. <clarify technical meaning of this>
Countermeasure 5:
Integrity Check on Intended Dataflow from EFB Peers
A detailed Threat Tree is presented in the Appendices (see Section 3.1).
2.2.7.1 Self-Protection Security Assessment
2.2.7.1.1 An illustration of attack through Gatelink
The following is the full threat tree representing the Self-Protection architecture (details
are available in Section 3.1.
In c o re c tT a k e -o f
In fo d is
pa
l y
edo
t
p ilo t
N E WT O P
9 .00E -05
C o ru p te d O n b o a rd E F B
G 008
Co h e e
r n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
in E F B
C o ru p te d s
o ftw a re
ru n n in g in E F B
G 001
G 002
Pa g e 1
5 .00E -05
8 .00E -05
C o h e re n tly
C o ru p te d
In te rn a lP e e rDa ta in
E F B (N O T A M/We a th e r,
F MS L & B )
C o ru p te d A irln e L & B
D a ta in E F B
G 05 2
2 .00E -05
F lig h C
t re w e n te rs
c o ru p te d d a ta in to
EFB
G 006
6 .00E -05
G 007
8 .00E -05
1 .00E -09
Pa g e 1
C o ru p te d
Da a
t bas
e /C h a rtU p lo a d
fro mMa s
Me d ia P o rt
C o h e re n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
fro mn e tw o rk
in te rfa c e
G 08 5
G 06 0
2 .00E -05
C o ru p te d
A p p lic a tio n /P la tfo rm
U p lo a d F ro mMa s
Me d ia P o rt
In e
t rn a lP e e rDa ta
In te g rity
Ch e c k
F a ilu re
C o ru p te d In te rn a l
P e e rD a ta in EF B
(N O T A M/We a th e r,F MS
L &B)
Co h e e
r n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
in E F B
F lig h tC re w
G 05 8
G 005
G 001
A 01 5
G 05 4
8 .00E -05
2 .00E -05
6 .00E -05
1 .00E +00
8 .00E -05
1 .00E -09
Pa g e 1
Pa g e 1
Ac c e s
to Ma s
Me d ia
P o rt
C o ru p te d O fb o a rd
D a ta b a s
e /C h a rtD a ta
G 01 7
G 07 5
2 .00E -05
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
F a ilu re
C o ru p te d
Da a
t bas
e /C h a rtU p lo a d
D a ta flo w fro mA irln e
Ac c e s
to Ma s
Me d ia
P o rt
C o ru p te d O fb o a rd
A p p lic a tio n /P la tfo rm
D a ta
In e
t n
r a lP e e rDa ta
In te g rity
Ch e c k
By
pas
ed
In e
t n
r a lP e e rDa ta
In te g rity
Ch e c k
C o mp ro mis
e d (fa ilu re
o rlo s
o fs
e c u rity
d a ta
G 07 4
G 01 7
G 05 6
G 06 9
G 07 0
G 06 8
1 .00E +00
8 .00E -05
1 .00E +00
2 .00E -05
Pa g e 1
Ac c e s
to O n b o a rd E F B
1 .00E +00
5 .00E -05
Ac c e s
to A irc ra ft
N e tw o rk
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
C o mp ro mis
e d (fa ilu re
o rlo s
o fs
e c u rity
d a ta )
G 04 2
2 .00E -05
1 .00E -05
Pa g e 1
Ac c e s
to
Da a
t bas
e /C h a rt
D a ta lo
f w o rT o o ls
G 07 5
An y
one
G 07 6
Pa g e 1
1 .00E +00
1 .00E +00
Pa g e 1
C o ru p te d O fb o a rd
D a ta b a s
e /C h a rtD a ta
G 05 9
7 .00E -05
G1 2 3
1 .00E +00
Pa g e 1
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
By
pas
ed
G 01 0
U n in te n d e d a c c e s
to
EFBn e w
t o rk n
i te fa
r ce
G 09 6
1 .00E -05
G 008
Pa g e 1
Pa g e 1
1 .00E +00
Pa g e 1
Pa g e 1
C o ru p te d O n b o a rd E F B
G 02 6
1 .00E +00
5 .00E -05
Pa g e 1
C o ru p te d O n b o a rd E F B
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
G 008
G 06 4
Pa g e 1
Pa g e 1
5 .00E -05
2 .00E -05
An y
one
Ac c e s
to
D a ta b a s
e /C h a rtU p lo a d
D a ta flo w
G 02 6
G 07 9
1 .00E +00
Pa g e 1
U n a u th o riz
e da c c e s
to A irln e g ro u n d
te m
y
s
G 06 5
U n in te n d e d a c c e s
to
EFBn e w
t o rk n
i te fa
r ce
G 06 6
G1 2 3
1 .00E -05
Ac c e s
to A irc ra ft
N e tw o rk
G 09 6
1 .00E +00
1 .00E +00
Pa g e 1
A irln e g ro u n d s
te m
y
acces
fa ilu re
G 06 7
1 .00E -05
O fb o a rd P o p u la tio n
A irln e G ro u n d
Sy
te ms
s
us
er
G 09 4
A 04 8
1 .00E +00
C o ru p e
t d O fb o a rd
EFB
C o ru p te d O th e r
Ex
te rn a lD a ta flo w
fro mO th e rE x
te rn a l
S o u rc e
G 01 1
2 .00E -05
Ac c e s
to O n b o a rd E F B
G 01 2
2 .00E -05
E F B C o ru p te d th ro u g h
n e tw o rk in te ra c tio n s
G 01 0
Pa g e 1
1 .00E -05
G1 1 9
2 .00E -05
1 .00E -05
Pa g e 1
A u th o riz
edacc es
to
A irln e g ro u n d s
te m
y
1 .00E -05
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
G 06 4
1 .00E +00
Pa g e 1
Ac c e s
to A irln e
N e tw o rk
Ac c e s
to G a te lin k
N e tw o rk
Ac c e s
to o fb o a rd
EFB
F a ilu re to p re v e n t
unas
es
e d d a ta flo w
N o n -c re w ,
n o n -ma in te n a n c e
A u th o riz
edacc es
to
EFBp h y
ic a lmo u n tin
s
a irc ra ft
E F B n o tro b u s
to
n e tw o rk in p u ts
G 02 1
G 02 0
G 08 9
G 1 05
G 08 6
G 03 3
G1 2 0
Pa g e 1
1 .02 E -03
1 .00E +00
2 .00E -05
1 .00E -05
1 .00E +00
2 .00E -05
Ac c e s
to E F B n e tw o rk
in te fa
r ce
G1 2 1
1 .00E -05
1 .00E +00
Pa g e 1
U n a u th o riz
e da c c e s
to A irln e N e tw o rk
A u th o riz
e d Acc e s
to
A irln e N e tw o rk
G 04 5
1 .00E -05
U n a u th o riz
e da c c e s
to G a te lin k N e tw o rk
G 04 6
1 .00E -03
A u th o riz
edacc es
to
G a te lin k N e tw o rk
G 03 9
2 .00E -05
U n a u th o riz
e da c c e s
to o fb o a rd E F B
G 04 0
1 .00E +00
A u th o riz
edacees
to
o fb o a rd E F B
G 09 1
1 .00E +00
A irln e G ro u n d
Sy
te ms
s
us
er
G 09 2
1 .00E -05
Pa s
enger
A 04 8
1 .00E -05
F lig h tC re w
A 1 03
1 .00E -05
Ma in te n a n c e
A 01 5
1 .00E +00
Ac c e s
to In te rn a l
P e e rD a ta flo w
A 02 9
1 .00E -09
G 08 8
1 .00E -05
Ac c e s
to
Da a
t bas
e /C h a rt
D a ta lo
f w o rT o o ls
G 07 6
1 .00E +00
Pa g e 1
U n in te n d e d a c c e s
to
E F B n e tw o rk in te rfa c e
G1 2 3
Pa g e 1
1 .00E +00 P a g e 1
1 .00E +00
Pa g e 1
A irln e N e tw o rk
acces
fa ilu re
An y
one
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
Ga e
t lin k N e w
t o rk
acces
c o n ro
t l
fa ilu re
O fb o a rd P o p u la tio n
Ac c e s
to A irln e
N e tw o rk
G a te in
l k N e tw o rk
cus
to me r
G 08 7
G 02 6
G 06 4
G 04 1
G 09 4
G 02 1
A 04 4
1 .00E -03
1 .00E +00
Pa g e 1
2 .00E -05
Pa g e 1
1 .00E +00
1 .00E +00
Pa g e 1
1 .02 E -03
O fb o a rd E F B a c c c e s
fa ilu re
G 09 3
1 .00E +00
O fb o a rd P o p u la tio n
F lig h tC re w
Ma in te n a n c e
A N H o tS
sev
r ic e
P ro v d
i er
G 09 4
A 01 5
A 02 9
A 06 1
Pa g e 1
1 .00E -05 P a g e 1
1 .00E +00
1 .00E -09
1 .00E -05
G e n e ra l
C a b in c re w
A 1 04
1 .00E -03
Ac c e s
to A irc ra ft
N e tw o rk
A 02 7
1 .00E +00
Pa g e 1
Pa g e 1
Pa g e 1
1 .00E -05
Pa g e 1
G a te in
l k N e tw o rk
cus
to me r
Ma in te n a n c e
G a te in
l k N e tw o rk
cus
to me r
A 04 4
A 02 9
A 04 4
1 .00E +00
1 .00E -05
G e n e ra l
1 .00E +00
1 .00E +00
Pa g e 1
G 04 3
1 .00E +00
Ex
te rn a lA c c e s
to A N
Ho s
t
A 06 1
1 .00E +00
G 09 6
Ac c e s
to A N Ho s
t
1 .00E +00
A NHo s
tS e rv ic e
P ro v id e r
A 1 04
Ac c e s
to A irc ra ft
N e tw o rk
G 09 6
O n b o a rd P o p u la tio n
G 1 01
1 .00E -03
G 05 0
1 .00E +00
A irln e G ro u n d
Sy
te ms
s
us
er
1 .00E +00
U n u a th o riz
e dEx
te rn a l
Ac c e s
to A N Ho s
t
A 04 8
A u th o riz
e d Ex
te rn a l
Ac c e s
to A N Ho s
t
G 1 02
1 .00E -05
G 1 06
1 .00E +00
F lig h tC re w
A 01 5
G1 1 1
1 .00E +00
1 .01 E -03
A NHo s
tS e rv ic e
P ro v id e r
A irln e G ro u n d
Sy
te ms
s
us
er
A 06 1
A 06 1
A 04 8
1 .00E -03
1 .00E -03
1 .00E -05
A NHo s
tS e rv ic e
P ro v id e r
C a b in c re w
A 06 1
A 02 7
1 .00E -03
A NHo s
tS e rv ic e
P ro v id e r
1 .00E -09
C a b in c re w
A 02 9
1 .00E -09
Ex
te rn a lA c c e s
P o p u la tio n
G 02 6
Ma in te n a n c e
A 01 5
1 .01 E -03
An y
one
Pa g e 1
Pa g e 1
Pa g e 1
F lig h tC re w
1 .00E -05
Pa s
enger
A 1 03
1 .00E -05
1 .00E +00
G a te in
l k N e tw o rk
cus
to me r
Let us show the potential consequences of an attack by someone who has access to the
Gatelink Network. In the software used to generate this vent tree, this is done by setting
the (single) basic event to "true". The software then propagates that wherever in the tree
the it is connected.
A 02 7
A 04 4
1 .00E -05
Ma in te n a n c e
A 02 9
1 .00E +00
Pa s
enger
A 1 03
1 .00E -05
A irln e G ro u n d
Sy
te ms
s
us
er
A 04 8
1 .00E +00
G e n e ra l
A 1 04
1 .00E -05
1 .00E +00
In c o re c tT a k e -o f
In fo d is
pa
l y
edo
t
p ilo t
N E WT O P
9 .00E -05
C o ru p te d O n b o a rd E F B
G 008
Co h e e
r n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
in E F B
C o ru p te d s
o ftw a re
ru n n in g in E F B
G 001
G 002
Pa g e 1
5 .00E -05
8 .00E -05
C o h e re n tly
C o ru p te d
In te rn a lP e e rDa ta in
E F B (N O T A M/We a th e r,
F MS L & B )
C o ru p te d A irln e L & B
D a ta in E F B
G 05 2
2 .00E -05
F lig h C
t re w e n te rs
c o ru p te d d a ta in to
EFB
G 006
6 .00E -05
G 007
8 .00E -05
1 .00E -09
Pa g e 1
C o ru p te d
Da a
t bas
e /C h a rtU p lo a d
fro mMa s
Me d ia P o rt
C o h e re n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
fro mn e tw o rk
in te rfa c e
G 08 5
G 06 0
2 .00E -05
C o ru p te d
A p p lic a tio n /P la tfo rm
U p lo a d F ro mMa s
Me d ia P o rt
In e
t rn a lP e e rDa ta
In te g rity
Ch e c k
F a ilu re
C o ru p te d In te rn a l
P e e rD a ta in EF B
(N O T A M/We a th e r,F MS
L &B)
Co h e e
r n tly
C o ru p te d
D a ta b a s
e /C h a rtlo a d e d
in E F B
F lig h tC re w
G 05 8
G 005
G 001
A 01 5
G 05 4
8 .00E -05
2 .00E -05
6 .00E -05
1 .00E +00
8 .00E -05
1 .00E -09
Pa g e 1
Pa g e 1
Ac c e s
to Ma s
Me d ia
P o rt
C o ru p te d O fb o a rd
D a ta b a s
e /C h a rtD a ta
G 01 7
G 07 5
2 .00E -05
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
F a ilu re
C o ru p te d
Da a
t bas
e /C h a rtU p lo a d
D a ta flo w fro mA irln e
Ac c e s
to Ma s
Me d ia
P o rt
C o ru p te d O fb o a rd
A p p lic a tio n /P la tfo rm
D a ta
In e
t n
r a lP e e rDa ta
In te g rity
Ch e c k
By
pas
ed
In e
t n
r a lP e e rDa ta
In te g rity
Ch e c k
C o mp ro mis
e d (fa ilu re
o rlo s
o fs
e c u rity
d a ta
G 07 4
G 01 7
G 05 6
G 06 9
G 07 0
G 06 8
1 .00E +00
8 .00E -05
1 .00E +00
2 .00E -05
Pa g e 1
Ac c e s
to O n b o a rd E F B
1 .00E +00
5 .00E -05
Ac c e s
to A irc ra ft
N e tw o rk
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
C o mp ro mis
e d (fa ilu re
o rlo s
o fs
e c u rity
d a ta )
G 04 2
2 .00E -05
1 .00E -05
Pa g e 1
Ac c e s
to
D a ta b a s
e /C h a rt
Da a
t flo w o rT o o ls
G 07 5
An y
one
G 07 6
Pa g e 1
1 .00E +00
1 .00E +00
Pa g e 1
C o ru p te d O fb o a rd
D a ta b a s
e /C h a rtD a ta
G 05 9
7 .00E -05
G1 2 3
1 .00E +00
Pa g e 1
D a ta b a s
e /C h a rt
In te g rity
Ch e c k
By
pas
ed
G 01 0
U n in te n d e d a c c e s
to
EFBn e w
t o rk n
i te fa
r ce
G 09 6
1 .00E -05
G 008
Pa g e 1
Pa g e 1
1 .00E +00
Pa g e 1
Pa g e 1
C o ru p te d O n b o a rd E F B
G 02 6
1 .00E +00
5 .00E -05
Pa g e 1
C o ru p te d O n b o a rd E F B
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
G 008
G 06 4
Pa g e 1
Pa g e 1
5 .00E -05
2 .00E -05
An y
one
Ac c e s
to
D a ta b a s
e /C h a rtU p lo a d
D a ta flo w
G 02 6
G 07 9
1 .00E +00
Pa g e 1
1 .00E +00
Pa g e 1
U n a u th o riz
e da c c e s
to A irln e g ro u n d
te m
y
s
G 06 5
U n in te n d e d a c c e s
to
E F B n e tw o rk in te rfa c e
G 06 6
G1 2 3
1 .00E -05
Ac c e s
to A irc ra ft
N e tw o rk
G 09 6
1 .00E +00
1 .00E +00
Pa g e 1
A irln e g ro u n d s
te m
y
acces
fa ilu re
G 06 7
1 .00E -05
O fb o a rd P o p u la tio n
A irln e G ro u n d
Sy
te ms
s
us
er
G 09 4
A 04 8
1 .00E +00
C o ru p e
t d O fb o a rd
EFB
G 06 4
G 01 1
2 .00E -05
C o ru p te d O th e r
Ex
te rn a lD a ta flo w
fro mO th e rE x
te rn a l
S o u rc e
Ac c e s
to O n b o a rd E F B
G 01 2
2 .00E -05
E F B C o ru p te d th ro u g h
n e tw o rk in te ra c tio n s
G 01 0
Pa g e 1
1 .00E -05
G1 1 9
2 .00E -05
1 .00E -05
Pa g e 1
A u th o riz
edacc es
to
A irln e g ro u n d s
te m
y
1 .00E -05
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
Ac c e s
to A irln e
N e tw o rk
Ac c e s
to G a te lin k
N e tw o rk
Ac c e s
to o fb o a rd
EFB
F a ilu re to p re v e n t
unas
es
e d d a ta flo w
N o n -c re w ,
nonm
- a in te n a n c e
A u th o riz
edacc es
to
EFBp h y
ic a lmo u n tin
s
a irc ra ft
E F B n o tro b u s
to
n e tw o rk in p u ts
G 02 1
G 02 0
G 08 9
G 1 05
G 08 6
G 03 3
G1 2 0
Pa g e 1
1 .02 E -03
1 .00E +00
2 .00E -05
1 .00E -05
1 .00E +00
2 .00E -05
Ac c e s
to E F B n e tw o rk
in te rfa c e
G1 2 1
1 .00E -05
1 .00E +00
Pa g e 1
U n a u th o riz
e da c c e s
to A irln e N e tw o rk
A u th o riz
e d Acc e s
to
A irln e N e tw o rk
G 04 5
1 .00E -05
U n a u th o riz
e da c c e s
to G a te lin k N e tw o rk
G 04 6
1 .00E -03
A u th o riz
edacc es
to
G a te lin k N e tw o rk
G 03 9
2 .00E -05
U n a u th o riz
e da c c e s
to o fb o a rd E F B
G 04 0
1 .00E +00
A u th o riz
edacees
to
o fb o a rd E F B
A irln e G ro u n d
Sy
te ms
s
us
er
G 09 2
A 04 8
G 09 1
1 .00E +00
1 .00E -05
1 .00E -05
Pa s
enger
F lig h tC re w
Ma in te n a n c e
Ac c e s
to In te rn a l
P e e rD a ta flo w
A 01 5
A 02 9
G 08 8
A 1 03
1 .00E -05
1 .00E +00
1 .00E -09
1 .00E -05
Ac c e s
to
D a ta b a s
e /C h a rt
Da a
t flo w o rT o o ls
G 07 6
1 .00E +00
Pa g e 1
U n in te n d e d a c c e s
to
E F B n e tw o rk in te rfa c e
G1 2 3
Pa g e 1
1 .00E +00 P a g e 1
1 .00E +00
Pa g e 1
A irln e N e tw o rk
acces
fa ilu re
An y
one
Ac c e s
to A irln e
o p e ra tio n s
g ro u n d
te m
y
s
G a te lin k N e tw o rk
acces
c o n tro l
fa ilu re
O fb o a rd P o p u la tio n
Ac c e s
to A irln e
N e tw o rk
G a te in
l k N e tw o rk
cus
to me r
G 08 7
G 02 6
G 06 4
G 04 1
G 09 4
G 02 1
A 04 4
1 .00E -03
1 .00E +00
Pa g e 1
2 .00E -05
Pa g e 1
1 .00E +00
1 .00E +00
Pa g e 1
1 .02 E -03
O fb o a rd E F B a c c c e s
fa ilu re
G 09 3
1 .00E +00
O fb o a rd P o p u la tio n
F lig h tC re w
Ma in te n a n c e
A NHo s
tS e rv ic e
P ro v id e r
G 09 4
A 01 5
A 02 9
A 06 1
Pa g e 1
1 .00E -05 P a g e 1
1 .00E +00
1 .00E -09
1 .00E -05
G e n e ra l
C a b in c re w
A 1 04
1 .00E -03
Ac c e s
to A irc ra ft
N e tw o rk
A 02 7
1 .00E +00
Pa g e 1
G a te in
l k N e tw o rk
cus
to me r
Ma in te n a n c e
G a te in
l k N e tw o rk
cus
to me r
A 04 4
A 02 9
A 04 4
1 .00E +00
1 .00E -05
G e n e ra l
1 .00E +00
Pa g e 1
G 04 3
1 .00E +00
1 .00E +00
Ex
te rn a lA c c e s
to A N
Ho s
t
A 06 1
G 1 01
1 .00E +00
G 09 6
1 .00E +00
Ac c e s
to A N Ho s
t
A N H o tS
sev
r ic e
P ro v d
i er
A 1 04
G 09 6
Pa g e 1
Pa g e 1
Pa g e 1
1 .00E -05
Ac c e s
to A irc ra ft
N e tw o rk
1 .00E -03
O n b o a rd P o p u la tio n
G 05 0
1 .00E +00
A irln e G ro u n d
Sy
te ms
s
us
er
1 .00E +00
U n u a th o riz
e dEx
te rn a l
Ac c e s
to A N Ho s
t
A 04 8
A u th o riz
e d Ex
te rn a l
Ac c e s
to A N Ho s
t
G 1 02
1 .00E -05
G 1 06
1 .00E +00
G1 1 1
1 .00E +00
1 .01 E -03
A NHo s
tS e rv ic e
P ro v id e r
A NHo s
tS e rv ic e
P ro v id e r
A irln e G ro u n d
Sy
te ms
s
us
er
A 01 5
A 06 1
A 06 1
A 04 8
C a b in c re w
A 02 7
1 .00E -03
1 .00E -03
1 .00E -05
A N H o tS
sev
r ic e
P ro v d
i er
C a b in c re w
A 06 1
A 02 7
1 .00E -03
F lig h tC re w
1 .00E -09
A 02 9
1 .00E -09
Ex
te rn a lA c c e s
P o p u la tio n
G 02 6
Ma in te n a n c e
A 01 5
1 .01 E -03
An y
one
Pa g e 1
Pa g e 1
Pa g e 1
F lig h tC re w
1 .00E -05
Pa s
enger
A 1 03
1 .00E -05
1 .00E +00
G a te in
l k N e tw o rk
cus
to me r
A 04 4
1 .00E -05
Ma in te n a n c e
A 02 9
1 .00E +00
Pa s
enger
A 1 03
1 .00E -05
A irln e G ro u n d
Sy
te ms
s
us
er
A 04 8
1 .00E +00
G e n e ra l
A 1 04
1 .00E -05
1 .00E +00
In examining the tree, the vulnerabilities allowing the attack to propagate further are:
G017: Access to Mass
Media Port
G068: Database/Chart
Integrity Check
Failure
G093: Offboard EFB
access
G105: Failure to
prevent unassessed
dataflow
G058: Internal Peer
Data Integrity Check
Failure
G120: EFB not robust
to network inputs
would allow the attacker from physically uploading corrupt data
into the EFB.
would allow the attacker to use his access to Gatelink to corrupt
the upload dataflow into the EFB
would allow the attacker to directly corrupt the EFB when it is
not mounted onboard
would allow the attacker to use an undocumented and
unevaluated external dataflow to the EFB
would allow the attacker to use his access to Gatelink to access
the Aricraft Network and corrupt the internal dataflow into the
EFB
would allow the attacker to directly hack into the EFB either by
spoofing the external dataflow with malicious packets, or by
accessing the Aircraft Network through an unprotected Aircraft
Host with an external access and hacking the EFB through it.
2.2.7.1.2 Cutsets
The process above- examine the tree for each possible attack vector- can be tedious and
can lead to overlooking possible attack scenarios. However, standard event tree software
can also generate a complete set of cutsets, which are the enumeration of the sets of
possible events that would cause the top-level events. In this example, the complete
cutset report is as follows:
#
1
2
3
Event
A027
A029
A044
Description
Cabin crew
Maintenance
Gatelink Network
customer
Event
Description
G059
4
A044
G067
5
A044
Gatelink Network
customer
Gatelink Network
customer
Database/Chart Integrity Check
Compromised (failure or loss of security
data)
Airline ground system access failure
6
A044
G093
7
A044
G105
Failure to prevent unassessed dataflow
8
A044
G120
EFB not robust to network inputs
9
A048
10 A103
Gatelink Network
customer
Gatelink Network
customer
Gatelink Network
customer
Airline Ground
Systems user
Passenger
Internal Peer Data Integrity Check
Compromised (failure or loss of security
data
Offboard EFB acccess failure
G059
11 A103
Passenger
G070
12 A103
13 A103
14 A104
Passenger
Passenger
General
G105
G120
G059
15 A104
16 A104
General
General
G067
G070
17
18
19
20
A104
A104
A104
A061
General
General
General
AN Host Service
Provider
G093
G105
G120
G059
21 A061
AN Host Service
Provider
AN Host Service
G067
Database/Chart Integrity Check
Compromised (failure or loss of security
data)
Internal Peer Data Integrity Check
Compromised (failure or loss of security
data
Failure to prevent unassessed dataflow
EFB not robust to network inputs
Database/Chart Integrity Check
Compromised (failure or loss of security
data)
Airline ground system access failure
Internal Peer Data Integrity Check
Compromised (failure or loss of security
data
Offboard EFB acccess failure
Failure to prevent unassessed dataflow
EFB not robust to network inputs
Database/Chart Integrity Check
Compromised (failure or loss of security
data)
Airline ground system access failure
G070
Internal Peer Data Integrity Check
22 A061
G070
Provider
23 A061
24 A061
25 A061
26 A015
AN Host Service
Provider
AN Host Service
Provider
AN Host Service
Provider
Flight Crew
G093
Compromised (failure or loss of security
data
Offboard EFB acccess failure
G105
Failure to prevent unassessed dataflow
G120
EFB not robust to network inputs
The Self-Protection Architecture does not provide layered protection, so the
vulnerabilities are single-layered. In a layered architecture (see Section 2.2.9), the cutsets
will involve more than one vulnerability.
2.2.7.1.3 Threat Scenarios and Risk Assessment
The Cutset Report can then be used to generate the Threat Scenarios with a Risk Assessment.
Note: The Security Level is an attribute of a particular item, system, or security countermeasure. So it is a design variable and is not
determined by the risk assessment, but is an input to the risk assessment.
Threat
Populations
Someone with uncontrolled
access to the Gatelink Network
or to an Aircraft Host corrupts
the Database/Chart upload
Gatelink Network
customer, AN Host
Service Provider,
Passengers, and
General
General
Someone unauthorized corrupts
the Database/Chart within the
Airline Ground System
Someone with uncontrolled
access to the Gatelink Network
or to an Aircraft Host corrupts
the EFB data from an EFB Peer
aircraft host
Someone unauthorized corrupts
the EFB while it is offboard
Someone with undocumented
(or unassessed) remote access
to the EFB corrupts the EFB
Someone with uncontrolled
access to the Gatelink Network
or to an Aircraft Host hacks the
EFB Network Interface and
corrupts the EFB
Someone with authorized
access corrupts the EFB
Gatelink Network
customer, AN Host
Service Provider,
Passengers, and
General
General
Security
Countermsr
Database
Upload Integrity
Check
Vulnerability
Attck
Likehd
pV
S
L
C
Threat
Likehd
pIII
Impact
Risk
III
Low
Airline Ground
System Access
Control
EFB Internal
Dataflow
Integrity Check
Airline ground
system access
failure
Internal Peer
Data Integrity
Cryptographically
Compromised
pV
C
pIII
III
Low
pV
C
pIII
III
Low
Offboard EFB
Access Control
pV
C
pIII
III
Low
pV
C
pIII
III
Low
pV
C
pIII
III
Low
pIII
pIII
III
Low
Database/Chart
Integrity
Cryptographically
Compromised
General
Control of EFB
configuration
Gatelink Network
customer, AN Host
Service Provider,
Passengers, and
General
Flight Crew, Cabin
Crew, Maintenance,
Airline Administration
Robust EFB
network stack
Offboard EFB
access control
failure
Failure to prevent
unassessed
dataflow
EFB not robust to
network inputs
N/A
Inherent
2.2.8 Assessment of Delegation Architecture (incomplete)
We assume the following security countermeasures have been added to the EFB Function
(see section 2.2.6.1 for additional information on each countermeasure).
<integrity check include authentic part and unchanged>
The first two are the same as the countermeasures for the Self-Protection Architecture
because they involve threats that are external to the Aircraft.
Countermeasure 1:
Trust Airline Organization to protect offboard EFB
Countermeasure 2:
Integrity Check on Dataflow from Airline.
Countermeasure 3: Use security domain to control access to EFB Aircraft Network
Interface and to data flowing from EFB Peers
Countermeasure 4: No direct remote dataflow access to EFB, use communications
proxy to support external dataflows (e.g. a VPN server).
Countermeasure 5:
domain.
Forbid unintended external dataflows into or out of the security
2.2.8.1.1 Threat Scenarios and Risk Assessment
The Cutset Report was used to generate the Threat Scenarios with a Risk Assessment.
Threat
Populations
Someone with uncontrolled access
to the Gatelink Network corrupts the
Database/Chart upload
Gatelink Network
customer
Someone unauthorized corrupts the
Database/Chart within the Airline
Ground System
Someone with uncontrolled access
to the Gatelink Network or to an
Aircraft Host hacks a security
domain boundary host and corrupts
the EFB data from an EFB Peer
aircraft host
Someone unauthorized corrupts the
EFB while it is offboard
General
General
Offboard EFB
Access Control
Someone with unintended remote
access to the EFB compromises a
security domain boundary host and
corrupts the EFB
General
Security domain
boundary control
host
Someone with uncontrolled access
to the intended EFB remote
dataflow hacks the Communications
Manager and corrupts the EFB data
from an EFB Peer aircraft host
Gatelink Network
customer, AN Host
Service Provider,
Passengers, and
General
Com Manager for
EFB
Gatelink Network
customer, AN Host
Service Provider,
Passengers, and
General
Security
Countermsr
Database Upload
Integrity Check
Airline Ground
System Access
Control
Security domain
boundary control
host
Vulnerability
Attck
Likehd
pV
S
L
C
Threat
Likehd
pIII
Impact
Risk
III
Low
pV
C
pIII
III
Low
pV
C
pIII
III
Low
Offboard EFB
access control
failure
Security domain
access failure
pV
C
pIII
III
Low
pV
C
pIII
III
Low
Com Mgr not
robust to
network inputs
pV
C
pIII
III
Low
Database/Chart
Integrity
Cryptographicall
y Compromised
Airline ground
system access
failure
Security domain
access failure
2.2.9 Assessment of Layered Protection Architecture (incomplete)
Countermeasure 1:
Trust Airline Organization to protect offboard EFB
Countermeasure 2: In design and development, forbid all other external dataflows that
have not been assessed with an acceptable risk level.
Countermeasure 3:
Integrity Check on Dataflow from Airline.
Countermeasure 4:
EFB network stack is robust with respect to network interactions.
Countermeasure 5:
Integrity Check on Dataflow from EFB Peers
Countermeasure 6: Use security domain to control access to EFB Aircraft Network
Interface and to data flowing from EFB Peers
Countermeasure 7: No direct remote dataflow access to EFB, use communications
proxy to support external dataflows (e.g. a VPN server).
Countermeasure 5:
domain.
Countermeasure 3:
Forbid unintended external dataflows into or out of the security
Countermeasure 4:
interactions.
EFB network stack is robust with respect to all network
Countermeasure 5:
Integrity Check on Intended Dataflow from EFB Peers
Forbid unintended external dataflows in EFB applications.
2.2.9.1.1 Cutsets
3 Appendix
3.1 Self-Protection Threat Tree Detail
Threat trees serve four functions within Part 2:
 Manage of complex multi-stage attacks.
 Demonstrate completeness of security architecture (or determine gaps).


Generate threat scenarios.
Allocate risk when multiple security layers are present.
For the self-protection architecture, multiple layers are not present, so demonstration of
the fourth function will wait.
We will show the threat tree in a tops-down fashion. The top level threat can be caused
by any of six more specific threat conditions depending on the target of the attack. These
are:
 A database or chart loaded on the EFB has been coherently corrupted (in a
manner bypassing any standard CRC checks) at some point.
 A software part loaded on the EFB and being executed by the EFB has been
coherently corrupted at some point.
 Data passed to the EFB from another aircraft host (e.g. FMS, Navigation System)
and that is being used by an EFB application has been coherently corrupted at
some point.
 Load and Balance data passed to the EFB from an airline ground system has been
coherently corrupted at some point.
 The EFB has been corrupted through a direct hacking attack or by infection by
malware.
 The Flight Crew has used the EFB User Interface to enter corrupted data or
bypassed a check. Note: An implicit assumption here is that only the flight crew
has access to the user interface due to the physical security of the cockpit. This
assumption is part of the external trust relationships discussed in Sections 2.1.2.1
and 2.1.2.4.
Incorrect Take-off
Info displayed to
pilot
NEWTOP
Corrupted Onboard EFB
Coherently Corrupted
Internal Peer Data in
EFB (NOTAM /Weather,
FM S L&B)
G008
G052
Page 2
Page 46
Coherently Corrupted
Database/Chart loaded
in EFB
Corrupted Airline L&B
Data in EFB
G001
G006
Page 25
Page 50
Corrupted software
running in EFB
Flight Crew enters
corrupted data into
EFB
G002
G007
Page 43
Page 51
3.1.1 Coherently Corrupted Software
This example assumes that software can only be uploaded through the Mass Media Port
(although running software could be corrupted through the network interface, see the
threat of a "Corrupted Onboard EFB").
Corrupted software
running in EFB
G002
Page 1
2.00E-05
Corrupted
Application/Platform
Upload From M ass
M edia Port
G054
2.00E-05
Page 44
Corrupted
Application/Platform
Upload From M ass
M edia Port
G054
Page 43
2.00E-05
Access to M ass M edia
Port
Corrupted Offboard
Application/Platform
Data
G017
G056
2.00E-05
Page 27
1.00E+00
Page 45
At this point, we are not assuming any safeguards involving the software loading itselfthere are avionics boxes that do their own checking of their software before loading it
into persistent storage, but Class 2 EFBs are typically not designed for that.
Corrupted Offboard
Application/Platform
Data
Page 44
G056
1.00E+00
Anyone
G026
1.00E+00
Page 19
In the absence of any special design features, anyone with access to the onboard EFB has
access to its ports, but access to onboard EFBs is controlled (note that the threat posed
from access to an offboard EFB is covered under the top-level "corrupted onboard EFB"
threat condition).
Access to M ass M edia
Port
Page 26
Page 44
G017
2.00E-05
Access to Onboard EFB
G010
2.00E-05
Page 10
Note that unauthorized access to the onboard EFB is not included within the scope of this
security assessment, because access to the onboard EFB is limited by the cockpit physical
security context (see Section 2.1.2.1). The only exposed population is the flight crew,
cabin crew, and maintenance.
Access to Onboard EFB
G010
Page 2
Page 27
2.00E-05
Authorized access to
EFB physical mount in
aircraft
G033
2.00E-05
Page 11
Authorized access to
EFB physical mount in
aircraft
G033
Page 10
2.00E-05
Flight Crew
M aintenance
A015
A029
1.00E-09
1.00E-05
Cabin crew
A027
1.00E-05
3.1.2 Coherently Corrupted Internal Peer Data
In this example, data that is passed to the EFB from other aircraft systems are loaded
through a dataflow on the aircraft network.
The EFB peers themselves are already subject to assessment and so are not considered
part of this security assessment (but see Section 2.2.6.2). However the aircraft network
itself is allowed to include aircraft hosts that are "Level E" and may have little or no
assurance associated with them, nor are we assuming any countermeasures that would
prevent them from having external remote connections.
Hence the desire to have the EFB "self-protecting" requires the security architecture to
include some form of integrity check on the internal peer dataflow.
So we have Countermeasure 5, Integrity Check on Dataflow from EFB Peers
as defined in Section 2.2.6.4 and discussed in further detail in Section 2.2.6.1.
As a result of this countermeasure, the threat condition where a corrupted database/chart
has been accepted and loaded by the EFB requires an attack on the integrity check and
the ability to inject the corrupted data into the dataflow.
Coherently Corrupted
Internal Peer Data in
EFB (NOTAM /Weather,
FM S L&B)
G052
Page 1
6.00E-05
Internal Peer Data
Integrity Check
Failure
Corrupted Internal
Peer Data in EFB
(NOTAM /Weather, FM S
L&B)
G058
G005
6.00E-05
Page 47
1.00E+00
Page 49
As before in Section 3.1.1, failure in the integrity check is either due to
 Vulnerability to a cryptographic attack
 Vulnerability to a bypass attack directly on the source or destination
Internal Peer Data
Integrity Check
Failure
G058
Page 46
6.00E-05
Internal Peer Data
Integrity Check
Bypassed
Internal Peer Data
Integrity Check
Compromised (failure
or loss of security
data
G069
G070
5.00E-05
1.00E-05
Page 48
The source and destination are the EFB and the EFB peer. Since the EFB peer is out of
scope (see above), this leaves the possibility of an attack on the EFB itself, which is
considered in Section 3.1.6 on "Corrupted Onboard EFB".
Internal Peer Data
Integrity Check
Bypassed
Page 47
G069
5.00E-05
Corrupted Onboard EFB
G008
5.00E-05
Page 2
Access to the internal dataflow itself means that the attack can either affect the dataflow
across the Aircraft Network, or can directly access the EFB Network Interface (which is
the same thing, in the absence of any aircraft network security countermeasures as are
discussed in the Delegated Protection Architecture.).
Corrupted Internal
Peer Data in EFB
(NOTAM /Weather, FM S
L&B)
G005
Page 46
1.00E+00
Access to Aircraft
Network
Unintended access to
EFB network interface
G096
G123
1.00E+00
1.00E+00
Page 15
Page 24
Because this is the "Self-Protection" architecture, we are not assuming there are any
internal protections preventing any host on the Aircraft Network from sending packets to
the EFB Network interface (this assumption is changed in the "Delegated Protection"
architecture defined in Section 2.2.6.3). Since we are also not forbidding unprotected
hosts from accessing the Aircraft Network (another countermeasure added to the
"Delegated Protection" architecture), this means that access to the Aircraft Network
allows access to the EFB Network Interface.
Unintended access to
EFB network interface
Page 13
Page 49
Page 36
G123
1.00E+00
Access to Aircraft
Network
G096
1.00E+00
Page 15
For the same reason, we assume that access to any host allows access to the Aircraft
Network.
Access to Aircraft
Network
G096
Page 14
Page 24
Page 49
... see x-ref
1.00E+00
Access to AN Host
G043
1.00E+00
Page 16
Finally, access to hosts comes either because someone is onboard the aircraft who has a
legitimate right to access a host, or because they have external access to an aircraft host.
Access to AN Host
G043
Page 15
1.00E+00
Ext ernal Access to AN
Host
Onboard Population
G101
G050
1.00E+00
Page 17
1.00E+00
Page 22
One of the assumptions of this design example is that Passengers have some form of
access to an onboard system, even if only the IFE. Again, since the "Self-Protection"
architecture does not assume any non-EFB assurances, the passengers are included as a
threat source population.
Onboard Population
G050
Page 16
1.00E+00
Flight Crew
M aintenance
A015
A029
1.00E-09
1.00E-05
AN Host Service
Provider
Cabin crew
A061
A027
1.00E-03
1.00E-05
Passenger
A103
1.00E+00
As before, External Access is either Authorized or Unauthorized.
Ext ernal Access to AN
Host
G101
Page 16
1.00E+00
Unuathorized Ext ernal
Access to AN Host
Authorized Ext ernal
Access to AN Host
G102
G106
1.00E+00
1.01E-03
Page 18
Page 20
Authorized includes the usual populations.
Authorized External
Access to AN Host
Page 17
G106
1.01E-03
External Access
Population
G111
1.01E-03
Page 21
Ext ernal Access
Population
G111
Page 20
1.01E-03
AN Host Service
Provider
Airline Ground
Systems user
A061
A048
1.00E-03
1.00E-05
However, since we are not assuming any controls on external access to the other hosts,
we are forced to admit Anyone as a potential attacker without any additional
countermeasures.
Unuathorized External
Access to AN Host
Page 17
G102
1.00E+00
Anyone
G026
1.00E+00
Page 19
3.1.3 Coherently Corrupted Database/Chart
In this example, the databases and charts can be loaded through two main dataflows
 Directly loaded through the mass media port of the EFB

Remotely loaded through the EFB network interface from Airlines Operations
through the Gatelink interface to the Aircraft Network
Coherently Corrupted
Database/Chart loaded
in EFB
G001
Page 1
Page 50
8.00E-05
Corrupted
Database/Chart Upload
from M ass M edia Port
Coherently Corrupted
Database/Chart loaded
from network
interface
G085
G060
2.00E-05
Page 26
8.00E-05
Page 29
Because the remote dataflow includes non-proprietary network hosts and the desire to
have the EFB "self-protecting", the security architecture includes some form of integrity
check on the database/charts. This could be a digital signature integrity-only check, or
integrity/encryption, or a VPN link hosted on the EFB itself- at this stage we are only
concerned in determining how critical the strength of that integrity check is to the overall
EFB safety-related security risk.
So we have Countermeasure 4, Integrity Check on Dataflow from Airline, as defined in
Section 2.2.6.4 and discussed in further detail in Section 2.2.6.1.
As a result of this countermeasure, the threat condition where a corrupted database/chart
has been accepted and loaded by the EFB is caused by a weakness in the integrity check
and corruption in the database/chart itself. (Suppose for example a weak key sequence
algorithm was used that could be predicted. That is a defect in the integrity check
countermeasure. In addition, the attacker needs access to the dataflow itself to insert a
false database using the guessed integrity keys.)
Coherently Corrupted
Database/Chart loaded
from network
interface
G060
Page 25
8.00E-05
Database/Chart
Integrity Check
Failure
Corrupted
Database/Chart Upload
Dataflow from Airline
G068
G074
8.00E-05
1.00E+00
Page 30
Page 35
In general, integrity checks on dataflows can fail for one of two causes. Either
 the integrity protection on the dataflow packets is vulnerable to a cryptographic
attack, Or
 the integrity check was bypassed through compromise of the source or the
destination of the dataflow.
Database/Chart
Integrity Check
Failure
G068
Page 29
8.00E-05
Database/Chart
Integrity Check
Bypassed
Database/Chart
Integrity Check
Compromised (failure
or loss of security
data)
G042
G059
7.00E-05
1.00E-05
Page 31
Bypassing can either happen by an attacker attacking the EFB itself, or by attacking the
ground systems where the remote dataflow originated. (There are more complicated
ground architectures involving proxy VPN connections and so on. For this example, we
look at the criticality at the point where the dataflow leaves the responsibility of the
ground system.)
Database/Chart
Integrity Check
Bypassed
G042
Page 30
7.00E-05
Corrupted Onboard EFB
Access to Airline
operations ground
syst em
G008
G064
5.00E-05
Page 2
2.00E-05
Page 32
Note that the corrupted onboard EFB has already been noted as an important threat
condition in and of itself. Such interdependence between threat conditions is endemic in
analyzing complex attack scenarios and handling it is one of the advantages of the threat
tree method. At any rate, we will defer further analysis of that threat until later in Section
3.1.6.
Consideration of access to the Airline Ground System shows a very common motif in
access control security countermeasures- one needs to consider authorized access and the
possibility of unauthorized access.
Access to Airline
operations ground
syst em
G064
Page 31
Page 23
Page 39
2.00E-05
Unauthorized access
to Airline ground
syst em
Authorized access to
Airline ground syst em
G065
G066
1.00E-05
1.00E-05
Page 33
Page 34
Authorized access is defined through the threat source population with access (see
Section 2.2.4.1.
Authorized access to
Airline ground system
Page 32
G066
1.00E-05
Airline Ground
Systems user
A048
1.00E-05
Unauthorized access occurs when access control fails and results in exposure to a larger
set of threat source populations.
Unauthorized access
to Airline ground
syst em
G065
Page 32
1.00E-05
Airline ground syst em
access failure
Offboard Population
G067
G094
1.00E-05
1.00E+00
Page 6
Offboard Population
G094
Page 5
Page 33
Page 41
1.00E+00
Gatelink Network
cust omer
M aintenance
A044
A029
1.00E+00
1.00E-05
General
AN Host Service
Provider
A104
A061
1.00E+00
1.00E-03
Airline Ground
Systems user
A048
1.00E-05
Note that a more detailed analysis could attempt to discriminate between the types of
population that failure of the on-ground access control would expose the EFB to, but that
unless there is a specific assurance that a particular population is excluded, it is important
to cast a wide net.
Now we go back to the threat that someone is able to corrupt the database/chart dataflow
in the first place. Formally, this requires both electronic access to the dataflow path (so as
to be able to inject the corrupted data), and the ability to maliciously manipulate a
database--
Corrupted
Database/Chart Upload
Dataflow from Airline
G074
Page 29
1.00E+00
Corrupted Offboard
Database/Chart Data
Access to
Database/Chart
Dataflow or Tools
G075
G076
1.00E+00
1.00E+00
Page 28
Page 23
However, we do not intend to take any assurance credit for "security through obscurity",
so we will be assuming that most any attacker will be able to maliciously manipulate a
database in such a way that the EFB will try to run it in the absence of the additional
integrity checks we've already considered.
Corrupted Offboard
Database/Chart Data
Page 35
Page 26
G075
1.00E+00
Anyone
G026
1.00E+00
Page 19
Anyone
Page 18
Page 38
Page 28
... see x-ref
G026
1.00E+00
Flight Crew
AN Host Service
Provider
A015
A061
1.00E-09
1.00E-03
Cabin crew
Gatelink Network
customer
A027
A044
1.00E-05
1.00E+00
M aintenance
Passenger
A029
A103
1.00E-05
1.00E+00
Airline Ground
Systems user
General
A048
A104
1.00E-05
Electronic access to the dataflow itself is more interesting.
1.00E+00
Access to
Database/Chart
Dataflow or Tools
Page 35
Page 13
G076
1.00E+00
Access to
Database/Chart Upload
Dataflow
Access to Airline
operations ground
syst em
G079
G064
1.00E+00
Page 36
2.00E-05
Page 32
Note that we've already considered "Access to Airline operations" above- this is yet
another example of the complexity of threat scenarios, and that is managed correctly by
standard Event Tree tools.
Electronic access to the dataflow is dependent on the network topology, but we classify it
into the dataflow path from the ground system tool through the Airline network to the
Gatelink network to the onboard Aircraft network to the EFB network interface itself.
Access to
Database/Chart Upload
Dataflow
G079
Page 23
1.00E+00
Unintended access to
EFB network interface
Access to Airline
Network
G123
G021
1.00E+00
1.02E-03
Page 24
Page 37
Access to Aircraft
Network
Access to Gatelink
Network
G096
G020
1.00E+00
Page 15
1.00E+00
Page 40
Note that there might be public links to go from the Airline network to the Gatelink
network, but since we are considering the Gatelink Network itself as being essentially
uncontrolled (see the entry in Section 2.2.4.1), there is no additional benefit in modeling
that as well.
The resulting internal threat to the dataflows is included within the " Coherently
Corrupted Internal Peer Data" top-level threat in Section 3.1.2.
Unintended access to
EFB network interface
G123
Page 13
Page 49
Page 36
1.00E+00
Access to Aircraft
Network
G096
1.00E+00
Page 15
Now having covered the on-board attacks on the Database Upload Dataflow, there still
remain the off-board attacks, through the Gatelink Network, and the Airline Network.
The Gatelink Network has the usual access threats
Access to Gatelink
Network
G020
Page 36
1.00E+00
Unauthorized access
to Gatelink Network
Authorized access to
Gatelink Network
G039
G040
1.00E+00
Page 41
1.00E+00
Page 42
The authorized population consists of the Airline customer itself, and all the other
potential Gatelink customers. The Airline Network appears in two roles in this subtree- as
a direct threat to the dataflow (since the dataflow passes through the Airline Network)
and as an indirect threat to access the Gatelink Network and then pose a direct threat to
the dataflow.
Authorized access to
Gatelink Network
G040
Page 40
1.00E+00
Access to Airline
Network
Gatelink Network
cust omer
G021
A044
1.02E-03
1.00E+00
Page 37
The unauthorized population consists of anyone who is not on-board the aircraft itself.
(already discussed above). Note that some form of Gatelink Access Control is included
here.
Unauthorized access
to Gatelink Network
G039
Page 40
1.00E+00
Gatelink Network
access control
failure
Offboard Population
G041
G094
1.00E+00
1.00E+00
Page 6
The Airline Network has a similar threat tree- authorized and unauthorized access.
Access to Airline
Network
G021
Page 36
Page 42
1.02E-03
Unauthorized access
to Airline Network
Authorized Access to
Airline Network
G045
G046
1.00E-03
2.00E-05
Page 38
Page 39
In this example, authorized access is only for the Airline Operation Ground System.
More complex analysis can be done if additional detail into the internal security
architecture of the Airline Organization is found to be needed. The Airline Operations
Ground System has already been analyzed above since they also own the source of the
dataflow itself.
Authorized Access to
Airline Network
Page 37
G046
2.00E-05
Access to Airline
operations ground
system
G064
2.00E-05
Page 32
Unauthorized access has the usual structure, and we assume here that if the access
controls fails, anyone might get access.
Unauthorized access
to Airline Network
Page 37
G045
1.00E-03
Airline Network
access failure
Anyone
G087
G026
1.00E-03
1.00E+00
Page 19
The last top-level threat involving the Database/Chart was the threat that a corrupted
database is loaded directly into the EFB through the Mass Media Port. This threat is
identical to the threat of corrupted software being loaded directly into the EFB through
the Mass Media Port and will be considered in the next section.
3.1.4 Corrupted Airline Load and Balance Data
The assumption in this design example is that Load and Balance data from the Airline
Organization is subject to the same basic threats as the Database/Charts, and while it is
certainly possible to require different channels and tools in practice, duplicating the
security assessment of the Database/Charts channels and tools is not informative unless
the security architecture intends to protect the L&B data in a manner significantly
different from the Database/Chart data.
Corrupted Airline L&B
Data in EFB
Page 1
G006
8.00E-05
Coherently Corrupted
Database/Chart loaded
in EFB
G001
8.00E-05
Page 25
3.1.5 Flight Crew Enters Corrupted Data
Examination of this threat serves little purpose except to point out an obvious point- that
the authorized population is not subject to any security countermeasures other than those
that resulted in the selection of that population itself. Otherwise, access to the onboard
EFB itself is subject to the Physical Security Context that is part of the external trust
relationships discussed in Sections 2.1.2.1 and 2.1.2.4.
Flight Crew enters
corrupted data into
EFB
Page 1
G007
1.00E-09
Flight Crew
A015
1.00E-09
3.1.6 Corrupted Onboard EFB
The threat condition of a corrupted onboard EFB in turn can be due to four threat
conditions:
 The EFB was corrupted while it was offboard.
 The EFB was corrupted through some external dataflow for an application not
already included in the list above (e.g. something other than software parts,
database/charts, load and balance, NOTAMS, or weather data).
 The EFB was corrupted by someone with direct physical access to the EFB
onboard.
 The EFB was corrupted through its network interface (e.g. through IP stack
overflow or other network-based attacks.)
Corrupted Onboard EFB
Page 1
Page 27
Page 48
G008
Corrupted Offboard
EFB
Access to Onboard EFB
G011
G010
Page 3
Page 10
Corrupted Other
Ext ernal Dataflow
from Other Ext ernal
Source
EFB Corrupted through
network interact ions
G012
G119
Page 8
Page 12
We will not assume any self-protection by the off-board EFB, so that access to the offboard EFB is the basic threat.
Corrupted Offboard
EFB
G011
Page 2
Access to offboard
EFB
G089
Page 4
Access to the offboard EFB can be authorized or unauthorized.
Access to offboard
EFB
Page 3
G089
Unauthorized access
to offboard EFB
Authorized aceess to
offboard EFB
G091
G092
Page 5
Page 7
Authorized access to the offboard EFB is only allowed by Maintenance (to administer the
EFB) and the Flight Crew (to use the applications as part of preflight).
Authorized aceess to
offboard EFB
G092
Page 4
Flight Crew
M aintenance
A015
A029
Unauthorized access involves Security Countermeasure 1 added as part of the selfprotection security architecture: Trust Airline Organization to protect offboard EFB. Our
goal here is to determine our dependence on the Airline Organization by including the
consequences of a potential failure of that countermeasure within our assessment.
Potential failure of that countermeasure would result in the offboard EFB being exposed
to the general offboard population, which is made up of several populations as
documented in Section 2.2.4.1.
Unauthorized access
to offboard EFB
Page 4
G091
Offboard EFB acccess
failure
Offboard Population
G093
G094
Page 6
We have now dealt with the off-board threat to the EFB itself and so we will proceed to
look at the on-board threat. There are three sources mentioned above (see the picture for
G012).



Corruption due to access to the onboard EFB itself
Corruption due to someone attacking the network interfaces of the EFB (the
onboard hacking threat).
Corruption due to some external dataflow to the EFB that hasn't already been
explicitly included.
Access to the onboard EFB is limited by the cockpit physical security context (see
Section 2.1.2.1) so the only exposed population is the flight crew, cabin crew, and
maintenance.
Corruption of the EFB through its network interface is probably the most complex threat
condition, because it involves understanding the circumstance under which anyone might
be in a position to touch network packets that are able to touch the EFB network stack.
In the Self-Protection Architecture, there are no guarantees external to the EFB that might
prevent an attacker from trying to corrupt the EFB through its network interface through
buffer overflow attacks, or malicious packets intended to exploit vulnerabilities in the
EFB IP stack. So the EFB itself must be robust against such attacks, requiring
Countermeasure 3: EFB network stack is robust with respect to network interactions,
specified in Section 2.2.6.3 and discussed further in Section 2.2.6.1.
EFB Corrupted through
network interact ions
G119
Page 2
1.00E-05
EFB not robust to
network inputs
Access to EFB network
interface
G120
G121
1.00E-05
1.00E+00
Page 13
This countermeasure would not be necessary if access to the EFB network interface were
sufficiently safe-guarded, but that is not true for the Self-Protection Architecture, as will
be seen in the threat tree. In particular, access to the EFB network interface is available
for three classes of access:
 Intended dataflows from other aircraft hosts to the EFB
 Intended dataflows from external hosts to the EFB (exemplified here by the
Database/Chart Upload Dataflow)

Unintended dataflows from any host (including routers and switches) on the same
network as the EFB.
Access to EFB network
interface
G121
Page 12
1.00E+00
Access to Internal
Peer Dataflow
Unintended access to
EFB network interface
G088
G123
1.00E+00
1.00E+00
Page 14
Page 24
Access to
Database/Chart
Dataflow or Tools
G076
1.00E+00
Page 23
In the absence of aircraft network protections, any host on the aircraft network can
potentially touch the internal peer dataflows or the EFB network interface. Access to the
Aircraft Network has been discussed under Section 3.1.2, "Coherently Corrupted Internal
Peer Data". Access to the external dataflows has been discussed under Section 3.1.3,
"Coherently Corrupted Database/Chart".
Access to Internal
Peer Dataflow
Page 13
G088
1.00E+00
Access to Aircraft
Network
G096
1.00E+00
Page 15
Unintended access to
EFB network interface
Page 13
Page 49
Page 36
G123
1.00E+00
Access to Aircraft
Network
G096
1.00E+00
Page 15
Finally, we consider the possibility that the EFB was corrupted through some external
dataflow for an application not already included in the list above (e.g. something other
than software parts, database/charts, load and balance, NOTAMS, or weather data).
This is a general point- the system is potentially vulnerable to any external dataflow
including standard network interactions such as DNS service. However, many of these
are installation specific and not amenable to a generic analysis such as this design
example. What we can do in this example is note that all external dataflows should be
included in the Final Assessment and determine the potential vulnerability that an
unaccessed dataflow could pose to the EFB.
Corrupted Other
Ext ernal Dataflow
from Other Ext ernal
Source
G012
Page 2
1.00E+00
Failure to prevent
unassessed dataflow
Non-crew,
non-maintenance
G105
G086
1.00E+00
1.00E+00
Page 12
Non-crew,
non-maintenance
G086
Page 11
1.00E+00
Airline Ground
Systems user
Gatelink Network
cust omer
A048
A044
1.00E-05
1.00E+00
EFB Peer Service
Provider
Passenger
A038
A103
1.00E-03
1.00E+00
AN Host Service
Provider
General
A061
A104
1.00E-03
1.00E+00