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 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-YY3/ED-203 AIrworthiness Security Methods and Considerations DO-YY4/ED-204 AIrworthiness Security Instructions for Continued Airworthiness Expected end of 2013 or early 2014
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 Catastrop hic / Hazardous III Major IV Minor 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 V No Effect
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) Part of ARP 4754A Allocation of Aircraft Functions to System Functions New/ Modified Aircraft and System Functions Aircraft and System Functional Hazard Analysis Part of ARP 4761 What can be used as part of an attack? Attack Vector 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 What can be attacked? Assess the Risk and Design out the Unacceptable Risks What happens if this is attacked? New/ Modified Safety Impact Part of AWSP 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 predetermined 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
Future integration (>2014) Standards will overlap for projects ED- 202A/204 DO-178 DO-254
Design & Manufacture Seminar SOFTWARE SECURITY & DESIGN ASSURANCE Thank you for your time