1. EOSC Generic Application Security Framework
Daniel Fischer
European Space Agency

2. Mission Operations Infrastructure Information Security Management System
The Mission Operations Infrastructure (MOI) comprises assets and services supporting the ESA multi-mission model in all phases: development, launch and operations
The Information Security Management System (ISMS) is the implementation of the security directives resulting in requirements (SSRS) and procedures (SECOPS)

3. MOI ISMS Risk Assessment – Rationale for secure SW engineering
The MOI ISMS risk assessment has identified software engineering and applications as a critical area that requires urgent improvement The new MOI SSRS and SECOPS include requirements and procedures for secure software engineering
The SECOPS could be grouped at high level in:
Service-oriented SECOPS
ISMS Management oriented SECOPS
Systems Development oriented SECOPS: …
Procedure for defining security requirements for software developments and major maintenance activities, but…
ESA engineering standards for software development do not address security!

4. Ensuring Secure Software Engineering
HSO-G started the development of the GASF - Generic Application Security Framework
GASF Main Objectives
Ensure compliance with ISMS secure software engineering requirements
Introduce a Secure Software Development Lifecycle (SSDLC) to make newly developed software more resilient
Limit the security-related overhead for technical officers and developers
All software developments make use of ESA/ECSS software development standards with different grades of tailoring
It seemed natural to consider this asset as a baseline for implementing an approach for developing the SSDLC
ESOC has started the development of the Generic Applications Security Framework (GASF) as an answer to the risk identified during the risk assessment exercise
Thus the main objective is to be able to mitigate the ISMS risk related to software engineering and enhance the overall security of the ground systems infrastructure.
The core of the GASF is the introduction of a Secure Software Development Lifecycle (SSDLC) which is based on the traditional development lifecycle but adding, where necessary, additional steps that are required for producing secure software. These steps are applicable for technical officers and/or developers
The above mentioned extension of the traditional software development steps of course implies additional overhead in terms of effort/cost on the software development process. The intention of the GASF is to keep this overhead as small as possible by supporting the developers and technical officers with tools and providing a big level of automation
The activity will also help to amend the software engineering standards in use at ESA today. Currently they do not address security. The GASF helps to prepare a standardisation activity in this respect.

5. GASF Secure Software Development Lifecycle
Based on ECSS-E-ST-40 C/Q80 C, amended with processes from well known sources (e.g. ISO 27001, Common Criteria, NIST SP , ESA Security Directives)
Requirements Engineering
Specification of hierarchical security functional and assurance requirements
Assigning security requirements to target documentation (e.g. SRS)
Design
Use of security control design patterns
Detailed security design
Implementation & Testing
Security Code Review
Vulnerability Scanning
Security Testing
Use of off-the-shelf tools for the above
Operations & Evolution
Deploy security controls
Security Risk Assessment at every step of the SSDLC

6. GASF Requirements Engineering: Requirements Database
GASF provides a hierarchical security requirements database
Categorisation of requirements regarding target document e.g. SoW, contract, SRS, SUM, etc.
Organised according to ISO and
Using well known requirement sources e.g. ISO 27001, NIST, CWE
For each low level technical requirement, the recommended best practise to implement is referenced

7. GASF Requirements Engineering: Specific SW Requirements Selection
Not all software has the same security needs
GASF implements requirements tailoring using templates
Templates are filters that are applied to the requirements base
The CIA template selects requirements according to the confidentiality, integrity, and availability level identified by the risk assessment
The Environment Template identifies requirements applicable to well identified target deployment environments: e.g. Operational LAN, Pre Operational LANs, DMZ, etc
The Project Template identifies requirements applicable to typology of projects: e.g. Earth Observation missions, Provision of services to external users, etc
Templates are re-usable
Only the first-of-a-kind system will have to go through a detailed selection process
Follow-up systems in the same environment can re-use the templates

8. GASF Implementation: Security Best Practises
GASF requirement base links security best practises when possible
Best practises source is Common Weakness Enumeration (CWE)
CWE is built and maintained by MIT from multiple well known sources e.g OWASP
Each CWE entry explains how to mitigate the weakness  concrete help for developers
Example: Buffer Overflow
Requirement: All buffer operations shall check input sizes
CWE-120: Buffer Copy without Checking Size of Input
This helps developers implementing security requirements fast and in a standard way
No need for proprietary approach
Lends to later software verification

9. GASF Testing & Validation: Assuring correct implementation
GASF strongly supports security requirements validation & acceptance
Validation is specified in the assurance security requirements
GASF specifies validation procedures and guidelines
Static Source Code Analysis
Penetration Tests
Vulnerability Scanning
GASF supports certification
Using assurance requirements the software owner can use GASF to aid certification e.g. NIST 140-2/3 or Common Criteria

10. GASF Deliverables/ Output
Consolidated set of high-level security requirements
To be used by DSM / TO in preparation of SOW and STC
The process is assisted by an intuitive tool that automates the selection of applicable requirements based on templates
GASF formal specification
Formal specification of all processes required for execution of an SSDLC based on ECSS-E-ST-40 C /Q-80 C standards
For each process, identification of additional activities and mapping to ECSS-E-ST-40 C standard
Additional activities coming from well identified sources e.g. ISO 27001, Common Criteria, NIST SP , ESA Security Directives
GASF governance
Maintenance and evolution of GASF documentation
Maintenance and periodic review of security requirements

11. GASF Project Status (June 2013)
GASF High Level Requirements for SOW and STC – Available
Q4 2013
GASF Tool SDD
GASF specification + DSM/TO procedures (1st issue)
Complete top-down set of security requirements (1st issue)
Q1 2014
GASF Tool + complete documentation set
GASF specification (final)
Final version of the complete set of security requirements
GASF Security Governance Strategy (DSM/TO and development team procedures in applying GASF)
Result of pilot project: software security analysis of existing system based on code review and GASF tool recommendations

12. BSSC Secure SW Engineering WG: Involvement in GASF Reviews
The main GASF review will take place later this year
Contribution and participation of WG members is highly welcome
Main review items:
GASF Requirements Database (Structure & Contents)
Review starts 02/09
GASF Process Documentation (based on ECSS)
Review starts 14/10
GASF Tool and tool documentation

13. References and Sources
ISO Information security management systems — Requirements
ISO Code of practice for Information security management
ISO – Common Criteria for Information Technology Security Evaluation
NIST Recommended Security Controls for Federal Information Systems and Organizations
Common Weakness Enumeration (CWE) -
ESA Security Directives

14. THANK YOU FOR YOUR ATTENTION