Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE JAYSON ROWE – SENIOR ENGINEER AVIONICS

Aircraft Network Security

Development was required for B787 B787 over 1400 Loadable Software Parts FAA imposed Special Condition on B787 Type certificate

Legacy Software Distribution compared to Electronic

ARINC Report 827

Boeing - ANSOG

To meet special conditions, Boeing has published Airplane Network Security Operator Guidance (ANSOG), FAA approved

Contains requirements to comply with (eg keeping of security logs) and recommendations

Airbus - Airworthiness Limitations

EASA has approved Airbus Instructions for Continued Airworthiness and Airworthiness Limitations for A380

ALS Part 6 – Aircraft Information System Security

ANSOG

Contains requirements: eg keeping of security logs

Contains security recommendations eg controlling access to wireless networks

Will be detailed in further standards

CAAP 232A

CASA has released generic guidance on aircraft network security covering detail in ANSOG

Further development of Aircraft Network Security guidance material will be evolving

CAAP 232A

CAAP deals with assessing security assessments which could adversely affect flight safety via risk based assessment

CAAP 232A

Application of security countermeasures at various levels eg Aircraft, system or item

CAAP 232A

Recognising key patterns in security logs to determine attacks are taking place

Eg. Unusual amount of network traffic or CPU

CAAP 232A

Appointment of network security administrator Similar dedicated role to that of EFB admin

Standards Development

RTCA SC-216 Aeronautical Systems Security

EUROCAE WG72 SG-2 Process & Methods for Airworthiness/certification SG-4 Continuing Airworthiness

Airworthiness Security

Expected end of 2013 or early 2014

Airworthiness of Aircraft

(ICAO Annex 8)

Aviation Security

(ICAO Annex 17)

Aircraft Operation

(ICAO Annex 6)

Personnel Licensing

(ICAO Annex 1)

Facilitation (ICAO

Annex 9)

Air Services (ICAO Annex

4/5/11/15)

Type Certification

Continuing Airworthiness

Operational Approvals

Safety Assessment

Particular Risks

IT Security Risk to Airworthiness

DO-326A/ED-202A

AIrworthiness Security Process

DO-YY4/ED-204AIrworthiness

Security Instructions for

Continued Airworthiness

DO-YY3/ED-203AIrworthiness

Security Methods and

Considerations

Airworthiness Security Process ED-202A

Similar layout & terms to RTCA/DO-178 & DO-254

Addresses system security as part of type certification basis (TC,STC and ATC) Information on development of operators guidance for security

AWSP Activity Section Severity of system asset threat conditions

I & II Catastrophic / Hazardous

III Major

IV Minor

V No Effect

Plan for Security Aspects of Certification (PSecAC) 8.1 Yes Yes Yes Yes

Aircraft Security Context (ASC) 8.2.1 Yes Yes Yes Yes

Aircraft Threat Identification (ATI) 8.2.2 Yes Yes Yes Yes

Preliminary Aircraft Security Risk Assessment (PASRA)

8.2.3 Yes(I) Yes Yes No

Aircraft Security Risk Assessment (ASRA) 8.2.4 Yes Yes Yes No System Security Context (SSC) 8.2.5 Yes Yes AsNeg No

System Threat Identification (STI) 8.2.6 Yes Yes AsNeg No

Preliminary System Security Risk Assessment (PSSRA)

8.2.7 Yes(I) Yes AsNeg No

System Security Risk Assessment (SSRA) 8.2.8 Yes(I) Yes Yes No

Airworthiness Security Methods and Considerations ED-203

Gives methods of security prior to certification Integration with ARP 4754 and 4761 process Provides information for retrofitting aircraft systems (STCs)

Aircraft and

System Functional Hazard Analysis

Allocation of Aircraft Functions

to System Functions

Assess the Risk and Design out the

Unacceptable Risks

What can be

attacked?

What happens if

this is attacked?

What can be used

as part of an attack?

New/Modified

Aircraft and System

Functions

Attack Vector

Part of ARP

4754A

Part of ARP 4761

Part of AWSP

New/Modified Safety Impact

A system can:(1) have a safety criticality associated to one its functions, making it a target; or(2) have a function or a vulnerability which makes it useful as part of an attack on another system

If there is a function or a vulnerability which makes a system useful as part of an attack on another system, then the SFHA needs to be modified with the addition of this new scenario

Continuing Airworthiness Guidance ED-204

Provides information to designers on: Security of FLS Copying Storage & Distribution Disposal of hardware Network access points Training Access control methods Digital certificates Incident response

What is Software?

Software part may be: type-certified aircraft part

application

database

document or list

What is Software?

Usually capable of loading on-aircraft

Part number is electronically verifiable on aircraft

Target LRU part number may not change

Software has unique part number

Copying of software Software supplier must make it clear what is allowed to be copied

Copying of software part of software configuration management

Operators are responsible for making unaltered copies using

specified processes

Check of integrity and bit image comparisons

History Aircraft Software Approval

CAO 103.5 requires use of RTCA/DO-178A

Version A was released in 1985

Version C released 2011

CASA draft AC currently in development to recognise version C

DGTA also looking to introduce version C for software approval

EASA/FAA are in process of finalising guidance

User-modifiable software Provision exists for user-modifiable software that can be varied

without consultation with CASA, TC or STC holder

UMS must be documented during certification of core software

Core software designed to be UMS must be agreed by CASA before being varied by the operator

Does not need ARC but needs to be documented by operators policy and procedures

Still requires configuration management for UMS

DO-178C Does not address software development standard

DO-178 provides for design assurance of software

Intent is to recognise software as a part

Approvals have already been given under 21.305A

DO-178C Software is part of the design process

Software level is pre-determined by System Safety

Assessment!

Determination of software level

Level must line up with system criticality

Software cannot exist in isolation. Part of system

CASA to agree on appropriateness of level

Software life cycle process

Each part of the process is a section in DO-178C

Engage CASA early in the process

DO-178C supplements

DO-178C traceability

Compatibility with DO-178B

Version C is backwards compatible

Applicants to supply life cycle data against version C

FAA has draft AC 20-115C with flow chart for conversion of 178B to 178C

Supplied data

Applicants contact CASA and supply necessary life cycle data as detailed in standard

If applying for level E then no DO-178C process is required, provide

justification to CASA to proceed

DO-178C details what type of life cycle data needs to be submitted

Further information FAA CAST papers example: Replacement of obsolete electronic parts with software Use of C++ programming language Approving source code to object code traceability Reverse engineering Use of COTS for graphics processors

Method for approval

Approval for software is granted initially under 21.305A of CASR

Modification to software is approved under 21.435 of CASR

If on AP instrument, approval under 21.437 of CASR

Method for approval

Changes to software configuration

Instructions need to be included to control aircraft software configuration

Authorised changes to software must match authorised software configuration list

See ARINC 667-1 for further information

ED-202A/204

DO-254 DO-178

Standards will overlap for projects

Future integration (>2014)

Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE

Thank you for your time