1. SECURE SOFTWARE ENGINEERING FOR SPACE MISSIONS
Daniel Fischer CCSDS Fall Meetings 10/11/2014

2. 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

3. 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

4. Facts and Key Principles
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
Physical
Network
Application

5. Facts and Key Principles (Cont.)
Application Level
Ground Segment Level
Mission Level
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

6. Secure Software Engineering Standardisation Initiative at ESA

7. 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

8. 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

9. 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

10. 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

11. Gap Analysis Reference Inputs: Industry Best Practise
NIST SP , Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
NIST SP , Security and Privacy Controls for Federal Information Systems and Organizations
CCSDS 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

12. 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)

13. 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

14. 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

15. Gap Analysis Findings: Software Engineering Level (Cont.)

16. Secure Software Engineering Standard
Delta to ECSS E40C and Q80C documents
Provides additional information or new requirements where necessary

17. Secure Software Engineering Handbook
The equivalent to a CCSDS Green Book
Provides additional information and guidance on specific requirements from the standard

18. 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.

19. A Tool to Integrate SSE into Daily Practice - Generic Application Security Framework (GASF)

20. 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

21. GASF 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

22. GASF Requirements Tailoring Templates
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

23. GASF Requirements Specification Flow

24. 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

25. GASF Best Practices Recommendations

26. 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
GASF Compliance with Standards and promotion at Agency level 2015+

27. THANK YOU FOR YOUR ATTENTION