Transcript Presentation SecSWEngineering

SECURE SOFTWARE ENGINEERING
FOR SPACE MISSIONS
Daniel Fischer
CCSDS Fall Meetings
10/11/2014
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 2
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 3
ESA UNCLASSIFIED – Releasable to the Public
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


Application
Network
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
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 4
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
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 5
ESA UNCLASSIFIED – Releasable to the Public
Secure Software Engineering
Standardisation Initiative
at ESA
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 6
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 7
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 8
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
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 9
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 10
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 11
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 12
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 13
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


Operational security activities


Use of penetration testing
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 14
ESA UNCLASSIFIED – Releasable to the Public
Gap Analysis Findings:
Software Engineering Level (Cont.)
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 15
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 16
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 17
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 18
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 19
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 20
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 21
ESA UNCLASSIFIED – Releasable to the Public
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
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 22
ESA UNCLASSIFIED – Releasable to the Public
GASF Requirements Specification Flow
□ .....
□ .....
□ .....
□ .....
□ .....
□
P .....
□
P .....
□ .....
□ .....
□
P .....
□ .....
□
P .....
□ .....
□
P .....
□ .....
□ .....
X
□ .....
X
Template A
Template B
Compute
recommendations
GASF Tool
Requirement Catalogue
□
P .....
□
P .....
□
P .....
□? .....
□? .....
□
X .....
Project view
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 23
ESA UNCLASSIFIED – Releasable to the Public
Requirement
engineering
□
P .....
□
P .....
□
P .....
□
P .....
□
X .....
□
X .....
Project view
Export
□
P .....
□
P .....
□
P .....
□
P .....
DOORS
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 24
ESA UNCLASSIFIED – Releasable to the Public
GASF Best Practices Recommendations
GASF Tool
Access control
Java
C++
Supplier
Logging
C++
PHP
□
P .....Help
□
P ..... Help
□
P ..... Help
□
P .....Help
□ .....Help
X
□ .....Help
X
Project view
Technology Specific recommendations
Data Handling
Improper input validation
Process control
Improper input validation
Pointer issues
Common Weakness Enumeration
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 25
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 level
Current ECSS SW
Engineering Standards
Delta
Security
Processes
Software validation
process
Software related
system
requirements
Software
requirements and
architecture
engineering
process
Software verification
process
Software design
and
implementation
engineering
process
Daniel Fischer |CCSDS Fall Meetings | 11/11/2014 | Slide 26
ESA UNCLASSIFIED – Releasable to the Public
Software delivery
and acceptance
process
Software management
process
Software
operation
process
Software
maintenance
process
2015+
THANK YOU FOR YOUR ATTENTION
ESA UNCLASSIFIED – Releasable to the Public