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

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

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

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

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

Secure Software Engineering Standardisation Initiative at ESA

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

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

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

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

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

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)

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

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

Gap Analysis Findings: Software Engineering Level (Cont.)

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

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

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.

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

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

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

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

GASF Requirements Specification Flow

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

GASF Best Practices Recommendations

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 level 2015+

THANK YOU FOR YOUR ATTENTION