1 / 14

EOSC Generic Application Security Framework

EOSC Generic Application Security Framework. Daniel Fischer European Space Agency. Mission Operations Infrastructure Information Security Management System.

charis
Download Presentation

EOSC Generic Application Security Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Mission Operations InfrastructureInformation 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

  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 800-53, 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 27001 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 • TheProject 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 800-53, 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 • Review starts 14/10

  13. References and Sources • ISO 27001 - Information security management systems — Requirements • ISO 27002 - Code of practice for Information security management • ISO 15408 – Common Criteria for Information Technology Security Evaluation • NIST 800-53 - Recommended Security Controls for Federal Information Systems and Organizations • Common Weakness Enumeration (CWE) - http://cwe.mitre.org/ • ESA Security Directives

  14. THANK YOU FOR YOUR ATTENTION

More Related