Upload
myles-horn
View
222
Download
1
Tags:
Embed Size (px)
Citation preview
ESA UNCLASSIFIED – Releasable to the Public
Daniel FischerCCSDS Fall Meetings10/11/2014
SECURE SOFTWARE ENGINEERING FOR SPACE MISSIONS
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 2
ESA UNCLASSIFIED – Releasable to the Public
Security: A Strategic Objective
• ESA is responsible for assets of very high tangible and intangible value
• Security has emerged as a strategic objective for ESA New European Space Programmes
Stringent security requirements, mainly due to safety and/or dual aspects (Galileo, Copernicus, SSA..)
Changing Security Environment
Strong executive commitment by ESA towards security
Agency level endorsement of security best engineering practices
Enforced top level requirements in the form of security regulations and directives
Commitment to improving security practice throughout the Agency
Security certification
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 3
ESA UNCLASSIFIED – Releasable to the Public
Importance of Ground Systems Security
• At the core of any ground segment there are many software systems Large, complex, distributed
Multiple technologies, languages, generations
Different operational environments
• Ground systems are subject to various security threats Direct exploitation of implementation flaws
Viruses/ Malware
Denial-of-Service
Others
• The more complex the system, the more susceptible to attacks
• Application-level threats can never be completely eliminated however Technology and tooling addressing these risks have emerged
• Secure system and software engineering can reduce the risk and minimize the impact of attack
Increased reliability and availability
Increased robustness
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 4
ESA UNCLASSIFIED – Releasable to the Public
Physical
Network
Application
Facts and Key Principles
• Facts Security imposes extra engineering burden
Security requires specialised knowledge
Security is costly
• Key Principles Security should not be “patched” into systems
It must be considered from the outset and at each step of the Software Development Lifecycle (SDLC)
Secure software engineering should complement other security mechanisms
Part of an “onion” approach
Other layers imply the criticality of the application layer
Avoids unnecessary redundancies and reduced overhead for security
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 5
ESA UNCLASSIFIED – Releasable to the Public
Facts and Key Principles (Cont.)
• Key Principles (Cont.) Security is a system concern
Levels interdependencies
Standardised approaches to security engineering essential for
Enforcement of good security engineering practices
Security is often “the least concern”
Consistency of results at different levels e.g.
Agency Level
Missions of the same type
Systems of the same type
Reduction of burden of security engineering practices on individual projects
Application Level
Ground Segment
Level
Mission Level
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 6
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering Standardisation Initiative
at ESA
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 7
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering Standardization Initiative
• ESA and the European Space Sector applies the European Cooperation for
Space Standardisation (ECSS) system of standards
• In 2013 the ESA Standardisation Board endorsed an initiative aimed at
addressing Secure Software Engineering at Agency Level
• Main objective is to provide standardised support to effective SSE practices
in the form of: Gap Analysis: Assessment of security coverage in ECSS against
external standards and industry best practices
ESA Internal Secure SW Engineering Standard: Complements the ECSS standards for software security aspects
Companion Secure SW Engineering Handbook: Non-normative guidelines and recommendations on the implementation of the requirements in the standard
Security Requirements Repository: An exhaustive set of generic software security requirements to be tailored for specific applications
Change Requests to the ECSS Sofware Engineering and PA Standards
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 8
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis
• The gap analysis answers the following concerns: Do the ECSS standards adequately cover secure software engineering
practices and to which extent?
Can external standards and industry best practises be used to propose solutions for filling identified gaps?
• The gap analysis followed a formal, structured approach: Identification of relevant inputs
Cross mapping of identified standards
Gap Identification
Gap Analysis
Documentation and proposed way forward
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 9
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Inputs: Internal
ESA Security Directives Relevant ECSS Standards
M-Series Space Project Management E-Series Space Engineering: System and Software Q-Series Space Product Assurance
Software security
engineering
System security
engineering
Agency level security guidance
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 10
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Inputs:Industry Best Practise
ITSG-33: IT Security Risk Management, A lifecycle approach Primary source for product lifecycle (PLC) approach to system security
engineering
Includes concepts of integrated use of Threat and Risk Assessment (TRA) in the PLC, identification of relevant security activities per phase, security controls catalogue, security controls profiles, security assurance and security robustness
Common Criteria for information technology security evaluation Detailed consideration for security assurance concepts and criteria
OWASP Secure Coding Practice Quick Reference Guide Software specific practices applicable to implementation phase
Harmonized TRA Methodology, TRA-1 A basic TRA method used as a process benchmark
Clear integration of TRA processes in PLC
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 11
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Reference Inputs:Industry Best Practise
NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations
CCSDS 350.1-G-1, Report Concerning Space Data Systems Standards, Security Threats Against Space Missions
ISO-IEC 27001:2013, Information Technology – Security techniques – Information security management systems – Requirements
ISO/IEC 27005:2011, Information technology – Security techniques – Information security risk management
ENISA, Inventory of risk assessment and risk management methods
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 12
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Findings:Agency and System Level
• At Agency level the following enhancements are recommended: Establish a standard Threat and Risk Assessment (TRA) methodology
Establish corporate perspective on security by mission type security categorisation profiles for missions
• At System level the following enhancements are recommended: Include security aspects more explicitly in system engineering,
management and PA
Address Security Objectives and Requirements explicitly and systematically (provide catalogues where possible)
Integrate information Security Threat and Risk Assessment (TRA) concepts in the product lifecycle (PLC)
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 13
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Findings:Software Engineering Level
• Information Security Threat and Risk Assessment concepts are not integrated in the Software Development Lifecycle (SDLC)
• Security considerations are high-level and imlicit in all processes Security requirements concepts (e.g. controls catalogue, assurance
and strength of function concepts) are not explicitly covered
Security processes for security architecture, design and implementation are not explicit
Security processes for secure operations, maintenance and disposal are not explicit
• Software verification processes encompass security however:
Generally high-level and with gaps
Missing guidance for methods or mechanisms for security verification
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 14
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Findings:Software Engineering Level (Cont.)
• Need to complement existing Software Engineering and PA standards with
Iterative use of a cyber-security TRA in SDLC
Security requirements engineering using a security requirements catalogue
Derivation of security assurance and security strength of function requirements
Security design activities (high-level design, detailed design) and development
Security verification and validation activities
Use of penetration testing
Operational security activities
Continuous security monitoring and modifications in response to evolving threats
Secure disposal of security sensitive systems and data
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 15
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Findings:Software Engineering Level (Cont.)
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 16
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering Standard
• Delta to ECSS E40C and Q80C documents
• Provides additional information or new requirements where necessary
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 17
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering Handbook
• The equivalent to a CCSDS Green Book
• Provides additional information and guidance on specific requirements from the standard
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 18
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering Requirements Catalogue
• Will be an informal supplement to the standard
• Provides a full catalogue of security requirements applicable to software development from well known sources
• Covers different aspects of software development
• Contractual Requirements
• “Statement of Work” Requirements
• Functional Security Requirements
• Documentation Requirements
• Requirements are organised hierarchically
• For example: Requirement 133:
• The system shall be able to verify the integrity of executable code at start up and before loading it into memory.
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 19
ESA UNCLASSIFIED – Releasable to the Public
A Tool to Integrate SSE
into Daily Practice
-
Generic Application Security Framework (GASF)
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 20
ESA UNCLASSIFIED – Releasable to the Public
The GASF Tool
• Requirements Catalogue Using well known security requirement sources e.g. ISO 27001, NIST, CWE
• Assists in the selection of security requirements for software development project
Statement of Work
Contract
Security Requirements Specification
• Export to DOORS, Word, XML
• GASF Tool Technical Specs Java
Client-Server architecture
GASF catalogues stored in SQLite
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 21
ESA UNCLASSIFIED – Releasable to the Public
GASF Security Requirements Catalogue
• Security requirements catalogue Organized in requirements categories
Hierarchically organized requirements
High level: Main security categories
Low level: Refined security requirements
The lower the more refined
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 22
ESA UNCLASSIFIED – Releasable to the Public
• Not all software has the same security requirements
• GASF implements security requirements tailoring using templates
• Templates are filters that are applied to the requirements base CIA templates select requirements according to the
confidentiality, integrity, and availability level identified by the risk assessment
Environment Templates identify requirements applicable to well identified target deployment environments: e.g. Operational LAN, Pre-Operational LANs, DMZ, etc.
Project-type Templates identify requirements applicable to typologies of projects e.g. operational software, prototype etc.
Templates are re-usable Only the first-of-a-kind system will have to go through a
detailed selection process
Systems with same characteristics can re-use existing templates
GASF Requirements Tailoring Templates
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 23
ESA UNCLASSIFIED – Releasable to the Public
GASF Requirements Specification Flow
GASF Tool
Requirement Catalogue
□ .....□ .....□ .....□ .....□ .....
□ .....□ .....□ .....□ .....□ .....□ .....Template A
PP
P
□ .....□ .....□ .....□ .....□ .....□ .....Template B
P
PX
Project view
□ .....□ .....□ .....□ .....□ .....□ .....
PPP
?
X
X?
□ .....□ .....□ .....□ .....□ .....□ .....
PPP
X
Requirement engineering P
X
□ .....□ .....□ .....□ .....
Export
Project view DOORS
P
P
PP
Compute recommendations
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 24
ESA UNCLASSIFIED – Releasable to the Public
GASF Best Practices Recommendations
• GASF implements links to technology specific recommendations and the CWE (Common Weakness Enumeration) to support developers in the implementation of security requirements
• CWE is A unified, measurable set of software weaknesses
Community initiative that includes individual researchers and representatives from numerous organizations
International in scope and free for public use
• CWE catalogue linked to requirements. The tool provides Weaknesses
Applicable platform
Potential mitigations
Demonstrative examples
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 25
ESA UNCLASSIFIED – Releasable to the Public
GASF Best Practices Recommendations
GASF Tool
Access control
JavaC++
Logging
C++PHP
Project view
□ .....□ .....□ .....□ .....□ .....
HelpHelpHelp
HelpHelp
□ .....Help
PPP
X
PX
Supplier
Data Handling
Improper input validationProcess control
Technology Specific recommendations
Common Weakness Enumeration
Improper input validation
Pointer issues
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 26
ESA UNCLASSIFIED – Releasable to the Public
Way Forward
Finalisation of the Requirements Catalogue Q4 2014
ESA Internal Review of Standard and Handbook Q4 2014
Publish ESA Internal Secure SW Engineering Handbook Q1 2015
ECSS Change Requests Submission 2015
GASF Compliance with Standards and promotion at Agency level2015+
Software related system
requirements
Software requirements and
architecture engineering
process
Software design and
implementation engineering
process
Software delivery and acceptance
process
Software operation process
Software maintenance
process
Software validation process
Delta Security
ProcessesSoftware management
processSoftware verification
process
Current ECSS SW Engineering Standards
ESA UNCLASSIFIED – Releasable to the Public
THANK YOU FOR YOUR ATTENTION