Upload
dangtram
View
237
Download
6
Embed Size (px)
Citation preview
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