ASTM F3532-23

This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the
Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.
Designation: F3532 − 23
Standard Practice for
Protection of Aircraft Systems from Intentional
Unauthorized Electronic Interactions
This standard is issued under the fixed designation F3532; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope is indicated. In all cases, later document revisions are accept-
able if shown to be equivalent to the listed revision, or if
1.1 This practice covers methods for addressing Aircraft
otherwise formally accepted by the governing CAA; earlier
System Information Security Protection (ASISP) risks caused
revisions are not acceptable.
by Intentional Unauthorized Electronic Interactions (IUEIs).
This practice was developed considering Level 1, Level 2, 2.2 ASTM Standards:
Level 3, and Level 4 normal category aeroplanes. The content F3060 Terminology for Aircraft
may be more broadly applicable. It is the responsibility of the F3061/F3061M Specification for Systems and Equipment in
applicant to substantiate broader applicability as a specific Aircraft
means of compliance. The topics covered within this practice F3230 Practice for Safety Assessment of Systems and
are threat identification, identifying security measures, con- Equipment in Small Aircraft
ducting a security risk assessment, and security documentation.
2.3 EASA Standard:
AMC 20-42 Airworthiness Information Security Risk As-
1.2 An applicant intending to use this practice as means of
sessment
compliance for a design approval must seek guidance from
their respective oversight authority (for example, published
2.4 EUROCAE Standards:
guidance from applicable civil aviation authority (CAA))
ED-202A Airworthiness Security Process Specification
concerning the acceptable use and application thereof. For
ED-203A Airworthiness Security Methods and Consider-
information on which oversight authorities have accepted this
ations
practice (in whole or in part) as an acceptable Means of
ED-204A Information Security Guidance for Continuing
Compliance to their regulatory requirements (hereinafter “the
Airworthiness
Rules”), refer to the ASTM Committee F44 web page
2.5 FAA Advisory Circulars:
(www.astm.org/COMMITTEE/F44.htm).
AC 20-115D Airborne Software Development Assurance
1.3 This standard does not purport to address all of the
Using EUROCAE ED-12( ) and RTCA DO-178( )
safety concerns, if any, associated with its use. It is the
AC 20-153B Acceptance of Aeronautical Data Processes
responsibility of the user of this standard to establish appro-
and Associated Databases
priate safety, health, and environmental practices and deter-
AC 119-1 Airworthiness and Operational Approval of Air-
mine the applicability of regulatory limitations prior to use.
craft Network Security Program (ANSP)
1.4 This international standard was developed in accor-
2.6 RTCA Standards:
dance with internationally recognized principles on standard-
RTCA DO-326A Airworthiness Security Process Specifica-
ization established in the Decision on Principles for the
tion
Development of International Standards, Guides and Recom-
mendations issued by the World Trade Organization Technical
Barriers to Trade (TBT) Committee.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
2. Referenced Documents
Standards volume information, refer to the standard’s Document Summary page on
2.1 Following is a list of external standards referenced the ASTM website.
Available from European Union Aviation Safety Agency (EASA), Konrad-
throughout this practice; the earliest revision acceptable for use
Adenauer-Ufer 3, D-50668 Cologne, Germany, https://www.easa.europa.eu.
Available from European Organisation for Civil Aviation Equipment
This practice is under the jurisdiction of ASTM Committee F44 on General (EUROCAE), 9-23 rue Paul Lafargue, “Le Triangle” building, 93200 Saint-Denis,
Aviation Aircraft and is the direct responsibility of Subcommittee F44.50 on France, https://www.eurocae.net/.
Systems and Equipment. Available from Federal Aviation Administration (FAA), 800 Independence
Current edition approved Nov. 1, 2023. Published January 2024. Originally Ave., SW, Washington, DC 20591, http://www.faa.gov.
approved in 2022. Last previous edition approved in 2022 as F3532 – 22. DOI: Available from RTCA, Inc., 1150 18th NW, Suite 910, Washington, D.C.
10.1520/F3532-23. 20036, https://www.rtca.org.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
F3532 − 23
RTCA DO-355A Information Security Guidance for Con- 3.2.10 data flow (physical), n—identifies “how” information
tinuing Airworthiness is conveyed between points in a system (that is, specific
RTCA DO-356A Airworthiness Security Methods and Con- physical buses and interconnections).
siderations
3.2.11 event, n—an internal or external occurrence that has
2.7 Other Industry Guidance: its origin distinct from the aeroplane. For purposes of this
practice, the event is the IUEI.
ETSI EN 303 645 Cyber Security for Consumer Internet of
Things: Baseline Requirements
3.2.12 external (aeroplane), n—reference point outside of
NIST SP 800-37 Risk Management Framework for Informa-
the aeroplane systems, not part of the aeroplane type configu-
tion Systems and Organizations
ration; may include carried on devices.
NIST SP 800-57 Recommendation for Key Management
3.2.13 external (system), n—reference point outside of the
NIST 800-131A Transitioning the Use of Cryptographic
8 system under consideration. This includes other systems on the
Algorithms and Key Lengths
aeroplane or elements meeting the definition of “external
2.8 Throughout this practice, the references to ED-202A/
(aeroplane).”
DO-326A, ED-203A/DO-356A, and ED-204A/DO355A are
3.2.14 failure, n—an occurrence that affects the operation of
used. These references are used only as an additional source of
information and are not used as pointers for additional pro- a component, part, or element such that it can no longer
function as intended (this includes both loss of a function and
cesses or activities. This practice is standalone and independent
on the above-mentioned documents and contains all required malfunction).
definitions, processes, activities, and descriptions required to
3.2.15 failure condition, n—condition on the aircraft/system
address the ASISP risks caused by IUEIs.
that is contributed by one or more failures.
3.2.16 field loadable software, n—software that can be
3. Terminology
loaded without removing the system or equipment from its
3.1 Definitions—Terminology specific to this practice is
installation. The safety-related requirements associated with
provided in 3.2. For general terminology, refer to Terminology
the software loading function are part of the system require-
F3060.
ments.
3.2 Definitions of Terms Specific to This Standard:
3.2.17 function, n—intended behavior of a product based on
3.2.1 actor(s), n—individuals, groups, or states with mali- a defined set of requirements regardless of implementation.
cious intent.
3.2.18 hazard, n—an unsafe condition resulting from
3.2.2 aircraft system information security protections failure, malfunctions, external events, error, or combination
thereof.
(ASISP), n—the process and design requirements implemented
to reduce the impact of intentional unauthorized electronic
3.2.19 integrity, n—attribute of a system or an item indicat-
interaction.
ing that it can be relied upon to work correctly on demand.
3.2.3 assessment, n—an evaluation based upon engineering
3.2.20 intentional unauthorized electronic interaction
judgment.
(IUEI), n—a circumstance or event with the potential to affect
the aircraft due to human action resulting from unauthorized
3.2.4 assets, n—resources of the aircraft and systems that
access, use, disclosure, denial, disruption, modification, or
are subject to attack or may be used as part of an attack,
destruction of information or system interfaces, or both. This
including functions, system, items, equipment, data, interfaces,
includes the consequences of malware and forged data and the
and information.
effects of external systems on aircraft systems, but does not
3.2.5 attack vector, n—the path, interface, and actions by
include physical attacks or electromagnetic disturbances.
which an attacker executes an attack.
3.2.21 mitigation, n—reduction of risk either through less-
3.2.6 availability, n—item is in a functioning state at a given
ening of impact or lessening of occurrence.
point in time.
3.2.22 requirement, n—an identifiable function specification
3.2.7 connectivity, n—capacity for the interconnect of
(Technical) that can be validated and implementation can be
platforms, systems, and applications.
verified.
3.2.8 corruption, n—the act to change something from its
3.2.23 risk, n—exposure to the possibility of harm. The risk
original function or use to one that is failed or erroneous.
of an event is a function of the severity of the adverse event and
3.2.9 data flow (logical), n—identifies “what” information is
the level of threat of that event or, conversely, the effectiveness
conveyed between points in a system (that is, applications and
of protection.
protocols).
3.2.24 security environment, n—the assumptions about the
persons, organizations, and external systems outside of the
security perimeter that interact with the asset (aeroplane,
Available from ETSI, 650, Route des Lucioles, 06560 Valbonne - Sophia systems), so that the potential threat sources may be identified.
Antipolis, France, https://www.etsi.org.
3.2.25 security event, n—an occurrence in a system that is
Available from National Institute of Standards and Technology (NIST), 100
Bureau Dr., Stop 1070, Gaithersburg, MD 20899-1070, http://www.nist.gov. relevant to the security of the system.
F3532 − 23
3.2.26 security measure, n—used to mitigate or control a 3.3.19 PSCP, n—project specific certification plan
threat condition. Security measures may be features, functions,
3.3.20 PSecAC, n—plan for security aspects of certification
or procedures. Security measures can be technical, operational,
3.3.21 PSRA, n—preliminary security risk assessment
or management.
3.3.22 SD, adj—secure digital
3.2.27 security perimeter, n—the security perimeter is the
3.3.23 SOC, n—system on a chip
boundary between an asset’s internal security context and its
security environment.
3.3.24 SRA, n—security risk assessment
3.2.28 system boundary, n—a logical element in a system 3.3.25 USB, n—universal serial bus
that designates where a change in trust occurs in the system.
3.3.26 WAN, n—wide area network
3.2.29 threat condition, n—a condition having an effect on
3.3.27 WEP, n—wired equivalent privacy
the aeroplane or its occupants, or both, either direct or
3.3.28 WPA, n—wireless protected access
consequential, which is caused or contributed to by one or
more acts of intentional unauthorized electronic interaction
4. Significance and Use
(IUEI).
4.1 The purpose of this practice is to establish methods that
3.2.30 threat scenario, n—the specification of the IUEI,
can be used to satisfy the Function and Installation
consisting of the contributing threat source (attacker and attack
requirements, and the Safety Requirements, provided in 4.1
vector), vulnerabilities, operational conditions, and resulting
and 4.2, respectively, in Specification F3061/F3061M.
threat conditions, and events by which the target was attacked.
4.2 Threat conditions that can cause Hazardous or Cata-
3.2.31 threat source, n—either (1) intent and method tar-
strophic failure conditions, including those that can propagate
geted at the intentional exploitation of a vulnerability, or (2) a
through interconnected systems causing Hazardous or Cata-
situation and method that may mistakenly trigger a vulnerabil-
strophic failure conditions, are required to be addressed using
ity. The threat source of a threat is intent and method: the
this practice.
attacker and the attack vector.
3.2.32 validation, n—the determination that the require-
5. Security Process Overview
ments for a product are correct and complete.
5.1 Modern avionics systems often include connectivity
3.2.33 verification, n—the evaluation of an implementation
between the avionics systems and external devices such as
to determine that applicable requirements are met.
portable electronic devices or ground networks. These com-
munication paths introduce the possibility of the external
3.2.34 vulnerability, n—a flaw or weakness in system secu-
device adversely affecting the avionics system. Fig. 1 shows
rity procedures, design, implementation, or internal controls
the process that is used to evaluate the possible impact of IUEI,
that could be exercised and result in a security event.
determine necessary security measures, and show that the
3.3 Abbreviations:
security architecture implemented mitigates risks to an accept-
3.3.1 ADS-B, n—automatic dependent surveillance – broad-
able level.
cast
5.2 Fig. 1 shows the process to implement system security
3.3.2 COTS, n—commercial off-the-shelf
into an existing system development process. It is assumed that
3.3.3 CVE, n—common vulnerabilities and exposures
applicants have existing system design and system safety
3.3.4 DAH, n—design approval holder
processes. These processes include the development of system
architecture, functional hazard assessments, and system safety
3.3.5 DHCP, n—dynamic host configuration protocol
assessments.
3.3.6 EFB, n—electronic flight bag
5.3 The process in Fig. 1 addresses five key questions:
3.3.7 FHA, n—functional hazard assessment
5.3.1 What are we building? See 6.1, Define Intended
3.3.8 FPGA, n—field programmable gate arrays
Function.
3.3.9 GNSS, n—global navigation satellite system
5.3.2 What can go wrong? See 6.2, Threat Identification.
5.3.3 What are we going to do to address the threats? See
3.3.10 ICA, n—instructions for continued airworthiness
6.3, Analyze Threats and Identify Security Measures.
3.3.11 IP, n—intellectual property
5.3.4 Did we do an acceptable job addressing the threats?
3.3.12 IUEI, n—intentional unauthorized electronic interac-
See 6.4, Conduct Security Assessment.
tion
5.3.5 Did we adequately and accurately document the ap-
3.3.13 LAN, n—local area network
proach to security in support of the approval process? See 6.5,
Security Documentation.
3.3.14 LRU, n—line replaceable unit
3.3.15 MFD, n—multifunctional display
6. Procedure
3.3.16 PC, n—personal computer
6.1 Define Intended Function:
3.3.17 PED, n—portable electronic device
6.1.1 The applicant shall document the intended function of
3.3.18 PLD, n—programmable logic device the system.
F3532 − 23
FIG. 1 Security Process Flow Diagram
6.1.2 In general, increased connectivity in aeroplane sys- examination shall define the security environment when ASISP
tems functionality can introduce new risks associated with
requirements apply. The examination should consider user
IUEI that typically were not assessed during the traditional
interactions with aeroplane system functionality.
safety assessment process. A systematic examination of the
aeroplane or system functionality shall be performed. The
F3532 − 23
6.1.2.1 It is recommended that applicants contact their 6.1.7 When it is determined that the project must address
certification authority to understand the applicable regulatory IUEI, then security activities and documentation shall be
security policies/requirements for their project. planned to support ASISP requirements.
6.1.3 The applicant shall determine if any elements of the 6.1.8 The final scope of the security planning activities
system design includes connectivity to an external network or
required for the project shall be determined after completing
device on the aeroplane. the process covered in 6.2 of this practice.
6.1.4 Identification of external connectivity to a network or
6.1.8.1 Planning for Security Certification—When exami-
device during operation or maintenance shall require identifi- nation of the system shows that ASISP aspects must be
cation of the information flow and the means of connectivity
addressed, formally document ASISP aspects in a Project
across the aeroplane security perimeter. Both physical (wired Specific Certification Plan (PSCP) or Plan for Security Aspects
or wireless) and logical information flows shall be considered.
of Certification (PSecAC).
Further, both new and changed information flow into the
6.1.8.2 Preliminary Security Risk Assessment (PSRA)—A
aeroplane system shall be considered. Changed data flows,
PSRA shall be completed to document the system information
whether physical or logical, may alter the existing security
flow (Physical and Logical), and threat conditions related to
measures necessary to mitigate IUEI.
these flows. If the assessment determines that the identified
6.1.5 If the assessment shows no external connectivity, then
threat condition(s) result in hazards classified as Major or
a simple statement of non-applicability in a certification plan or
lower, the assessment may be documented without further
change impact assessment is all that is required.
activities. Assessments with threat condition(s) that result in
hazards classified as Hazardous or Catastrophic shall complete
NOTE 1—A simple statement is one that provides all the information
required to conclude that ASISP aspects do not apply. For example, “All the Security Risk Assessment activities of this practice.
information flow is outbound across the aeroplane security perimeter, no
6.1.8.3 Security Verification—Provide the planning needed
information is transmitted (TX) to the aeroplane systems. Therefore
to support the security verification process. Plans and reports
ASISP requirements do not apply.”
that will be used to document the verification activities used to
6.1.5.1 System functions dealing with services provided by
assess security measures shall be listed in the certification
trusted service entities or air navigation service providers do
planning document, covered in 6.1.8.1 of this practice.
not require aeroplane specific evaluation as a part of this
6.1.8.4 Security Risk Assessment (SRA)—Provide the plan-
process. Examples of excluded functions include: Global
ning needed to support the security risk assessment process.
Navigation Satellite System (GNSS), ground-based navigation
Planned SRA activities shall be listed in the certification
aids, Automatic Dependent Surveillance – Broadcast (ADS-B).
planning document, covered in 6.1.8.1 of this practice.
These services have interoperability requirements defined in
6.1.8.5 Security Continued Airworthiness—Planning for
other regulations and guidance and are therefore outside the
installer, maintainer, and operator guidance expected to be
scope of this process.
required to ensure the integrity of the security architecture shall
6.1.6 The presence of information flow inbound across the
be listed in the certification planning document, covered in
aeroplane security perimeter shall require the applicant to
6.1.8.1 of this practice.
address IUEI. As an aid to applicants, some examples of
6.2 Threat Identification:
external connectivity requiring assessments are provided in
6.2.1 Once the system architecture under evaluation is
6.1.6.1 – 6.1.6.4. These examples are not exhaustive and are
initially defined, the applicant shall document the flow of data
not intended to be used verbatim.
across the security perimeter between components and sys-
6.1.6.1 Does the system include one or more wireless
tems. The documentation shall identify the physical and logical
connectivity methods intended for use by onboard Portable
paths, data sources, and destinations. Existing security mea-
Electronic Devices (PEDs) or external devices? This may
sures shall be identified and considered in this architecture
include Wi-Fi access points or clients, Bluetooth nodes, cellu-
evaluation.
lar nodes or devices with custom-designed radios and commu-
6.2.1.1 Data flow diagrams showing both physical and
nications protocols.
logical flows are a means to document the necessary informa-
6.1.6.2 Does the system include one or more wired connec-
tion. The data flow diagrams can aid in understanding how
tivity methods accessible without special tools or access to the
systems are interconnected, and where data is ultimately
aeroplane harness? This may include an Ethernet or USB port
consumed in the system. Reference Appendix X3 for informa-
for a PED such as a laptop, a USB port, or secure digital (SD)
tion on how to create data flow diagrams.
card slot for removable media or other accessible buses.
6.2.2 Physical data paths shall include the type of intercon-
6.1.6.3 Does the system provide a new or updated means for
nect (for example, Wi-Fi, Ethernet, RS-232) and the direction-
field-loadable data such as aeronautical databases, software, or
ality.
other information? These are considered a means of connec-
tivity. For further understanding of the corruption protections 6.2.3 Logical data paths shall include producing and con-
suming applications, and protocols used for the transfer of data.
to ensure integrity of field-loadable software and databases,
refer to AC 20-115D and AC 20-153B. Multiple logical data flow representation may be necessary to
describe information flow among different layers of a system.
6.1.6.4 Does the system include the use of any new or
changed external services or functions over an existing physi- 6.2.4 Threat conditions shall be identified by considering
cal link? This may include new applications or protocol the effect of the impacted functions on the aeroplane, system,
modifications on an existing communications bus. and occupants in correlation to the safety failure condition’s
F3532 − 23
severity identified in safety documentation (for example, Func- ment within the architecture. Such information as functional
tional Hazard Assessment (FHA)). specifications, interfaces, where the security measure is imple-
mented in the architecture, and where documented (Security,
NOTE 2—For further understanding of the development of threat
System, Software, Hardware, Organization, Operation) should
conditions, refer to ED-203A/DO-356A, Section 3.3.3.
be part of the security measure description when applicable.
6.2.5 Following the development of all the threat
6.3.2.3 When using Appendix X4, Security Risk Assess-
conditions, at least one (1) threat scenario shall be identified for
ment Scoring, the type of security measure shall be defined:
each threat condition. Threat scenarios include identification of
Technical (Cryptographic, Authentication, and Authorization)
the source of the threat, the attack vector (typically drawn from
and Non-Technical (Operator, Operational, and Organiza-
the physical or logical data flow), and where applicable the
tional). More than one type may be assigned. Reference
existing security measures implemented along the attack vec-
Appendix X4 for descriptions covering security measure types.
tor. The threat scenario also includes the impact of a successful
6.3.2.4 The security measure’s dependencies on other secu-
attack; threat condition.
rity measures, architecture features, and operational modes
NOTE 3—For further understanding of the development of threat
shall be documented.
scenarios, refer to ED-203A/DO-356A, Section 3.4.1.
6.3.2.5 If security measures are implemented in a context
6.2.6 Using the threat condition severity, decide which
using software or hardware design assurance levels, those
elements of the security process are required; either 6.2.6.1 or
measures should be developed to an appropriate design assur-
6.2.6.2.
ance level in accordance with the applicable safety assessment.
6.2.6.1 If the related safety failure conditions for each threat
If used, the software or hardware design assurance level for a
condition has a severity of Major or lower, the outcome of the
security measure should be documented.
security assessment shall be documented in a PSRA. Provided
6.3.3 Once the security measures have been identified,
that the assumptions in the PSRA are verified to remain
appropriate requirements shall be developed and identified as
applicable throughout the design process, the security activities
security requirements and fed into the technical requirements
that follow are not required to be accomplished.
(System, Security, Software, and Hardware where applicable),
6.2.6.2 If the related safety failure conditions for each threat
operation requirements (if applicable), and organization re-
condition have a severity of Hazardous or Catastrophic, then
quirements (if applicable). This results in the security measures
further security activities shall be conducted to show that the
requirements being subject to the same development require-
security risks are mitigated to an acceptable level. This is
ments and assurance actions as other safety-related mitigation
accomplished through completion of the security processes
mechanisms.
identified in 6.3 and 6.4. This will result in the complete set of
6.3.4 Subsection 6.4 assesses whether or not each threat
security documentation described in 6.5, including the final-
scenario has been mitigated to an acceptable level of risk
ization of the SRA.
following the implementation of the security measure(s). This
6.3 Analyze Threats and Identify Security Measures:
is an iterative process, therefore it should be anticipated that
6.3.1 Using the threat conditions and threat scenarios devel-
further security measure development could be required.
oped in 6.2, identify security measures that reduce the risk
6.4 Conduct Security Assessment:
from each threat to an acceptable level. A minimum of one (1)
6.4.1 The implementation of the security measures into the
security measure for each threat scenario resulting in unaccept-
security architecture to address each threat scenario shall be
able risk shall be identified; more security measures where
accomplished. The intent of the implemented security mea-
layered security architecture is required. Security measures
sures is to protect assets from the identified threat scenarios.
may take the form of existing system functions, existing
With an increase in severity of impact for a threat scenario,
security measures, additional technical or procedural security
there is a need to increase the security effectiveness of
measures, system architecture changes, or other modifications
protection. The activities in this section provide the require-
to design or operation. When identifying existing security
ments related to assess the effectiveness of protection:
measures or developing new security measures, the applicant
6.4.1.1 Moderate—Adequate to protect against a Major
shall consider the impact of the failure of the security mea-
sure(s) in conjunction with the functionality of the system. Threat Condition.
6.3.2 Security measures for which credit will be sought to
6.4.1.2 High—Adequate to protect against a Hazardous
meet security requirements shall be clearly defined. The
Threat Condition.
following information supports the documentation requirement
6.4.1.3 Very High—Required to protect against a Cata-
for each security measure:
strophic Threat Condition.
6.3.2.1 Each security measure shall be traceable to the
6.4.2 A layered security architecture shall be implemented
aeroplane or system requirement(s) that define the security
where “Very High” effectiveness of protection is required. A
measure’s functionality.
layered architecture provides the added protection that multiple
security measures are not defeated by a single attack, or attack
NOTE 4—It is recommended to utilize a unique Security Tag on any
requirement with applicability to security measures to aid in tracing of
technique. A layered protection architecture consists of mul-
security requirements.
tiple security measures that are independent, diverse, and
6.3.2.2 Security measures shall have a description that isolated. The security measure attributes are assessed during
includes its intended function and intended operating environ- the security common mode analysis.
F3532 − 23
TABLE 2 Minimum Effectiveness Level with Tailoring
6.4.3 Security Measure Common Mode Analysis shall be
performed where layered security architecture is required. For Effectiveness of Protection
Assessment Level
A
(F3230, Table 3)
high and moderate protections that have multiple security Major Hazardous Catastrophic
measures in the security architecture, it is recommended to Level I Moderate Moderate Moderate
Level II Moderate Moderate Moderate
perform a common mode analysis. This analysis evaluates the
Level III Moderate Moderate High
following common mode attributes between the security mea-
Level IV Moderate High Very High
sures mitigating a threat scenario.
A
In accordance with Table 1, addressing Major Threat Conditions is not required.
Applicants choosing to address such threat conditions in their design should use
NOTE 5—For further understanding of Security Measure Common
a measure with a minimum effectiveness of Moderate.
Mode Analysis, refer to ED-203A/DO-356A, Section 3.5.1.
6.4.3.1 Independence between security measures means that
each security measure can function without other security
6.4.7 Tailoring of Security Effectiveness by Aeroplane
measure inputs or shared assets.
6.4.3.2 Diversity between security measures evaluates the Level:
commonality of design and implementation; common 6.4.7.1 Tailoring of security effectiveness may be incorpo-
functionality, technology, and vulnerability to the same attack. rated with a reduced effectiveness protection level. This
6.4.3.3 Isolation between security measures means that reduction by aeroplane assessment level may be allowed by the
compromised or failed security measures do not propagate certification authorities and should be coordinated in advance
attacks across shared resources to other security measures. of security verification activities.
6.4.4 A verification plan shall be developed that defines how 6.4.8 The processes outlined in 6.2, 6.3, and this section are
each security measure will be shown to perform its intended typically an iterative process requiring numerous cycles
function, either by test or by analysis test. Verification tests for through the development of the data flows, and the develop-
security measures shall show functionality under normal range ment and implementation of security measures to address each
and robustness test conditions. threat scenario. When the risk assessment for each identified
threat scenario shows that the effectiveness of protection meets
NOTE 6—Non-security requirements based testing, such as Vulnerabil-
Table 1 or, when applicable Table 2, then final security
ity or Penetration “Pen” testing, may also be valuable to identify
assessment documentation activities are the next step. When
weaknesses in the security architecture. Details about this type of testing
can be found in ED-203A/DO-356A, Section 4.1.3. the assessment shows that the security architecture does not
meet the effectiveness of protection requirements for the
6.4.4.1 Intended “normal range” function test cases: normal
following reasons, return to the appropriate section of this
system inputs and operating environment.
practice to further develop the security architecture:
6.4.4.2 Robustness test cases: invalid and out of range test
6.4.8.1 When the security architecture was inadequate to
inputs and system failures that might invalidate mitigation
address the threat scenario due to missing system architecture
assumptions.
and data flow assessment, return to 6.2 to evaluate the process
6.4.5 Security measures may be verified at the system or
steps.
aeroplane level, or both, using engineering judgment.
6.4.8.2 When the security measures are shown to be inad-
6.4.6 Upon the conclusion of the security architecture veri-
equate for the effectiveness of protection level required, return
fication activity, a final risk assessment shall be performed.
to 6.3 for further development of existing or additional security
This risk assessment demonstrates that the implemented secu-
measures.
rity architecture mitigates risks from attack to an acceptable
6.4.8.3 When unable to meet the common mode analysis
level. This assessment shall show that the security effectiveness
requirement or effectiveness of protection, return to 6.3 and 6.4
of protection is adequate for each threat scenario and its threat
to re-evaluate the security architecture.
condition(s). There are numerous assessment processes pro-
vided in industry guidance/methods listed in Section 2 of this
6.5 Security Documentation:
practice. An accepted Part 23 aeroplane method when using
6.5.1 Evidence shall be provided by the applicant showing
this practice is provided in Appendix X4, Security Risk
that all required activities, based on the project scope identified
Assessment Scoring. Early agreement on the security risk
in the security planning document, have been completed.
assessment process with the applicable CAA is encouraged.
6.5.1.1 Actual documentation structure for each of the
6.4.6.1 The selected security risk assessment process shall
requirements is not prescriptive for the need of a standalone
provide an effectiveness of protection result that can be used to
document. Table 3 provides a list of possible security docu-
show the protections meet the security requirements provided
mentation as well as how security topics might be addressed
in Table 1 or Table 2.
within already required certification data. The listed data is
intended to show how the activities and tasks discussed in this
practice may be documented, but the exact packaging of the
TABLE 1 Required Minimum Effectiveness Levels
data is an applicant choice to propose as part of the planning
A
Threat Condition Severity Effectiveness of Protection
effort.
Catastrophic Very High
6.5.2 Final coverage of the security measure verification test
Hazardous High
results and analysis shall be documented. Document that each
A
Effectiveness Levels may be tailored to a reduced protection level. (Reference
security measure implemented in the security architecture
6.4.7 and Table 2.)
functions as intended.
F3532 − 23
TABLE 3 Example Security Documentation
Security Activity Example Documentation Package Content Ref.
Planning PSecAC or by means of a dedicated security section within the 6.1
Project-Specific Certification Plan (PSCP) Table X1.1
Statement when Airworthiness Security PSCP statement 6.1
Aspects are not applicable; No connectivity Table X1.1
Assessment showing Major or lower Hazard Preliminary Security Risk Assessment (PSRA). PSRA may be 6.2
classification; No further security activities included as a section in the PSCP. Table X1.2
required
Assessment showing security activities are PSRA or draft SRA; inclusion of the assessment results including 6.2
required; Hazardous or Catastrophic Threat ties to FHA as needed 6.3
Conditions 6.5
Table X1.2
Documentation of Security Requirements System Requirements Document (SysRD) 6.3
Software Requirements Document (SRD) 6.5
Hardware Requirements Document (HRD) Table X1.3
Verification Test Plan and Procedures 6.4
Test and Analysis Reports 6.5
Table X1.4
Installer and Operator Guidance Instructions for Continued Airworthiness (ICA) 6.5
Maintenance Manuals (MM) Table X1.5
Installation Manuals (IM)
Security risk assessment Security Risk Assessment (SRA) 6.5
Table X1.5
Security Summary Security Summary included in SRA 6.5
Table X1.5
6.5.3 Requirement documentation shall be finalized with 6.5.6 The SRA shall be documented to show security
any changes to the security-related requirements. architecture effectiveness. The SRA covers the activities per-
6.5.3.1 A list of known vulnerabilities for each security formed showing the data flow, threat condition and threat
measure should be maintained to help evaluate the effective- scenario development. An assessment shall be provided in the
ness of security measures. SRA that the security architecture shows no unacceptable risk
6.5.3.2 Security measures implemented with commercial in accordance with this practice.
off-the-shelf (COTS) software or hardware should consider the
NOTE 8—The operator guidance may be used by the operators for their
event where one or more vulnerabilities are identified publicly,
use in getting approval for network security by their certification authority.
and the subsequent impact of this disclosure on their continued
(Reference AC 119-1.)
effectiveness.
6.5.7 A security summary statement shall be provided,
NOTE 7—Due to the potential for changes outside the control of the
which includes a statement that all requirements within this
system manufacturer or applicant, additional mitigations may be needed
practice have been met. The summary shall address any
for security measures that rely on features within COTS software or
deviations from the security planning.
hardware.
6.5.7.1 The tables in Appendix X1 are a means, but not the
6.5.4 If the security risk assessment contains operational
only means, to show that all necessary elements of this practice
measures or other actions that are the responsibility of the
have been met.
installer or maintainer, the applicant shall provide appropriate
6.5.7.2 If the applicant uses the material in Appendix X1, it
instructions in the installation manual, operators manual, or
is recommended to include a reference with each necessary
other documents to ensure correct implementation of these
row showing where in the applicant’s documentation the
measures.
supporting data is located. This aids both the applicant and
6.5.4.1 A process shall be provided to secure delivery of
certification authority in ensuring the documentation is com-
field-loadable data from the design approval holder to the
plete.
operator. The need for the operator to validate the authenticity
and integrity of field-loadable data is covered in instructions
7. Post Certification
for maintaining the security posture of the aeroplane.
6.5.5 If the security risk assessment contains operational 7.1 System modifications shall be assessed for any changes
measures or other actions that are the responsibility of the that could impact the security assessment. The assessment of
aeroplane operator, the applicant shall provide operator guid- the proposed modifications shall be based on analysis and
ance. The guidance shall address the aspects related to ASISP follow existing system security change impact analysis guid-
to ensure system integrity and security for the lifespan of the ance. Reference Appendix X2 for one example of a security
aeroplane. change impact analysis (CIA). If the CIA shows the proposed
F3532 − 23
NOTE 10—Applicants can coordinate vulnerability management, with
alteration could impact the security risk analysis, the applicant
equipment suppliers, to ensure each component of the system has
shall assess the updated system design and its impact on the
vulnerability feedback mechanisms enabled and vulnerability manage-
aeroplane using the process described in Section 6.
ment processes applied at the appropriate point(s) in the supply chain.
7.2 The applicant shall develop and provide operators with 7.3.1 A vulnerability disclosure policy that includes public
any instructions necessary to maintain the aeroplanes security
dissemination of contact information for reporting of issues by
architecture over its lifetime. Such information should include third parties.
support for continued airworthiness of the aeroplane’s system
NOTE 11—The intent of the public aspect of the vulnerability disclosure
security measures. Information can include information secu-
policy is to help manage expectations with third parties that report
rity conditions for support for subsequent changes to the
potential security issues.
aeroplane type design performed by organizations other than
7.3.2 A policy on the reception of security issue reports,
the original applicant. Such information could also include
such as Common Vulnerabilities and Exposures (CVE) reports,
directions on retrieval of security logs if deemed necessary by
as well as the monitoring for, identification of, and treatment of
the applicant.
security vulnerabilities or changes to the security environment
NOTE 9—If the information security conditions identified by an appli-
impacting the system.
cant cannot be met by a subsequent applicant, the subsequent applicant
7.3.3 A policy on responding to security incidents, including
may need to contact the original applicant and obtain additional data.
gathering appropriate data from impacted systems.
7.3 A process for managing vulnerabilities over the entire
NOTE 12—Additional information on vulnerability management, moni-
course of a system’s service life should be developed, includ-
toring for security risk, and incident response is available in ETSI
ing the following elements: EN 303 645, NIST SP 800-37, or other security guidance.
APPENDIXES
(Nonmandatory Information)
X1. ASISP PROCESS CHECKLIST
X1.1 References in Tables X1.1-X1.5 point to sections in
LEGEND:
this practice that provide additional guidance and background.
RQD Required
Tables include:
OPT Optional
NR Not Required
X1.1.1 Description and references to the location(s) in this
N/A Not Applicable
practice that provide(s) guidance to address each checklist
CAT Catastrophic – Severity of the Treat Condition/Failure Condition
item. HAZ Hazardous – Severity of the Treat Condition/Failure Condition
MAJ Major and lower – Severity of the Treat Condition/Failure Condition
X1.1.2 Failure Condition Severity, with applicability of
X1.1.3 Table Item Numbers provided.
each requirement shown by RQD, OPT, NR, and N/A; defined
in the legend.
F3532 − 23
TABLE X1.1 Security Planning
Checklist Item Severity
Ref. Comments
No. Description CAT HAZ MAJ
Security certification planning is Plans contain an overview of aeroplane or
defined system-level architecture, or both, to be
assessed for security, and the means of
compliance to security requirements where
6.1.3 connectivity has been identified.
6.1.5
RQD
6.1.6 Planning identifies the means of compliance
6.1.7 to security requirements where connectivity
has been identified.
Planning for security aspects may be
included in a PSCP or PSecAC.
Security certification may consist of a simple
statement providing evidence that ASISP
aspects of certification do not apply.
This may be included in a PSCP or other
certification documentation provided that:
6.1.3
• No connectivity is added to the aeroplane or
6.1.4 N/A
systems
6.1.5
• Information flow is only outbound across the
aeroplane security perimeter
• All information flow inbound across the
aeroplane security perimeter is provided by
trusted services governed by aviation
interoperability standards
Security Environment is defined 6.1.1 Examine aeroplane and system functionality
2 RQD
6.1.2 to define the security environment.
Certification considerations are 6.1.2 Identify the applicable regulatory security
3 defined 6.1.4 RQD RQD OPT requirements based on aeroplane level.
6.1.6
Overview of aeroplane and 6.1.2 Provide a description of the aeroplane and
systems where ASISP is required 6.1.3 system(s) where connectivity requires ASISP
4 RQD RQD OPT
6.1.4 to be addressed.
6.1.5
Planning for PSRA activity is Identify the activities to determine and assess
5 provided 6.1.8 RQD the severity of the threat conditions related to
security vulnerabilities.
Planning for security verification Identify the planned verification activities,
6 activity is provided 6.1.8 RQD RQD OPT including test and analysis, and the means to
document them.
Planning for SRA is provided Identify the planned Security Risk
7 6.1.8 RQD RQD OPT Assessment activities, and the means to
document them.
Planning for security-related Identify the planned method for developing
8 continued airworthiness is 6.1.8 RQD RQD OPT Instructions for Continued airworthiness and
provided the means to document them.
------
...