Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

module can be verified. Installation of OS patches to fix a reported security flaw will have a
higher potential impact on system safety.
Many commercial companies require extensive testing before deploying these types of vendor
patches. Similar procedures need to be followed on at least a fleet-wide basis. The DoD also
has policies for testing and deploying security patches (e.g., the information assurance
vulnerability alert process). Similar processes and procedures should be part of the aircraft’s
software update system that was discussed in section 7.1. Updates should only be authorized to
become available to aircraft after a level of analysis, testing, and verification commensurate with
the safety criticality of the system they are updating has been completed. Updates should only
occur within the aircraft after the integrity and authorization of the update package is established.
As discussed in section 6.1.1, the U.S. DSS [81] provides a mature foundation to enable secure
software load deliveries (new parts, security patches, software updates, etc.), including the
update of protection software. The DSS standard provides an explicit mechanism to ensure the
authenticity and integrity of signed software. The signer’s PKI identity is provided as a
constituent part of the signature. Should the signing have occurred within the auspices of
officially sanctioned and well-defined FAA processes and mechanisms, then that signed identity
can be leveraged to provide authentication and authorization within the airplane to determine
whether the received code is authorized and trustworthy. Once that determination has been
made, then the FAA-approved onboard software update system can securely distribute the
software to update the appropriate device in a safe manner. This process is discussed in section
10.6.
9.6 RESPONDING TO SECURITY BREACHES.
The aircraft’s IATF conformant defense-in-depth security design will attempt to block those
security attacks that can be prevented, detect those that cannot be prevented, respond to those
that are detected, and continue to operate through those that cannot be stopped. If the aircraft
system architecture adequately addresses these four steps (see section 5.1), then analysis of
onboard security failures that do not adversely affect safety of flight can be handled as
maintenance events.
Responding to security breaches is a policy issue, so the stakeholders (manufacturer, owner,
government agency, etc.) should determine what type of network monitoring to conduct and how
to respond to incidents. There are a wide range of policies in the commercial and DoD domains
for incident response that could be considered; however, the engineering process should focus on
eliminating any safety-related events.
The flight crew will probably not have the expertise or time to perform anything beyond a
minimal response to a security breach. The only exception would potentially be to address a
safety condition. If the issue directly impacts the operational safety of the aircraft, then the pilots
must be alerted.
In section 6.1, the impact of security controls upon airplane safety was considered. The
architecture recommended by this study explicitly has focused on safety within networked
128