esa unclassified – releasable to the public daniel fischer ccsds fall meetings 10/11/2014 secure...

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


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



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



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



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

• 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



• 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



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



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

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



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


THANK YOU FOR YOUR ATTENTION

esa unclassified – releasable to the public daniel fischer ccsds fall meetings 10/11/2014 secure...

Documents

security slide

public security

esa slide

security practice

security mechanisms

security engineering

esa unclassified releasable

key principles facts