Synergies of the Common Criteria with Other Standards

Transcription

1 Synergies of the Common Criteria with Other Standards Mark Gauvreau EWA-Canada 26 September 2007 Presenter: Mark Gauvreau

2 Overview Purpose Acknowledgements Security Standards & References Common Criteria Body Of Knowledge (CCBoK) Background Material 2

3 Purpose The purpose of this presentation is to: Discuss the application of synergies in standards-based best practices pertaining to security for supporting the implementation of departmental/ divisional and enterprise-wide security process improvements, management and appraisal; Assist developers, who have implemented CC security processes/ procedures for their organization and wish to further extend these processes/procedures to include other related and synergistic standards and standards-based best practices pertaining to Information Technology security. Spread awareness of other essential security practices defined by other national and international standards within the CC community and to encourage their use by means of the development of a Common Criteria Body of Knowledge (CCBoK) (How to Do Guide). 3

4 Acknowledgements An important reference upon which this presentation is based is the State-of-the-Art Report (SOAR) on Software Security Assurance, 31 July 2007 Information Assurance Technology Analysis Center (IATAC) & Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS. provides an overview of the current state of the environment in which software must operate and surveys current and emerging activities and organizations involved in promoting various aspects of software security assurance. presents observations about noteworthy trends in software security assurance as a discipline. represents an output of collaborative efforts of organizations and individuals in the Software Assurance Forum and Working Groups. ( 4

5 Acknowledgements (cont d) Other important references: Software Assurance Series, Software Assurance, A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software, September Version 1, DRAFT, Software Assurance, Workforce Education and Training Working Group, US Departments of Homeland Security and Defense Safety and Security Extensions For Integrated Capability Maturity Models, September

6 Security Standards & References There are already polices, standards and processes in place to review practices and evaluate products or processes for security: Common Criteria, Carnegie Mellon Software Institute s Capability Maturity Model (CMM), ISO 9000 series, ISO 17799, SAS 70, FISMA NSTISSP 11 6

7 Security Standards & References Some of the other security guides,reports and standards examined for synergies with the CC v3.1 include: ISO/IEC 21827:2002 Systems Security Engineering Capability Model NIST SP Risk Management Guide for Information Technology Systems FIPS 140-2, Security Requirements for Cryptographic Modules general national and international Systems Engineering standards (ISO, IEEE, EIA) 7

8 Security Standards & References National Cyber Security Partnership Taskforce Report on Processes to Produce Secure Software [Redwine 2004] National Cyber Security Partnership, Technical Standards and Common Criteria Task Force, Recommendations Report, April Safety and Security Extensions for Integrated Capability Maturity Models [Ibrahim et al, 2004] IEEE Software and Systems Engineering Standards Committee (S2ESC) collection of IEEE standards ISO/IEC JTC1/SC7 WG9 Redefined its terms of reference to software and system assurance (part of Systems Engineering System Life Cycle Processes) 8

9 Security Standards & References ISO/IEC to address management of risk and assurance of safety, security, & dependability within context of system and software life cycles [ISO 15026] National Institute of Standards and Technology (NIST) FISMA Implementation Project The Common Criteria for evaluating the security of software including the new version 3.0 issued in July 2005 [CC 2005] The SafSec effort in the UK7 combining concern for safety and security [SafSec Introduction], [SafSec Standard], and [SafSec Guidance] 9

10 Security Standards & References International Standard ISO/IEC 17799:2005 Code of Practice for Information Security Management As a code of practice, it offers guidelines and voluntary directions for information security management. It does not provide enough information to support an in-depth organizational information security review, or to support a certification program like the ISO 9000 process quality certification program. [International Standard ISO/IEC 17799:2000 Code of Practice for Information Security Management, Frequently Asked Questions] 10

11 Security Standards & References How does ISO/IEC 17799:2005 relate to the Common Criteria for IT Security Evaluation? ISO/IEC 17799: 2005 is a management standard The Common Criteria for Information Technology Security Evaluation v3.1 is an evaluation standard, and in addition to providing a taxonomy of security functional requirements, specifies 7 predefined assurance packages (EALs). 11

12 Security Standards & References NIST Information Security Documents: Guide to National Institute of Standards and Technology (NIST) Information Security Documents The Federal Information Processing Standards (FIPS) Publication Series. FIPS 140-2, Security Requirements for Cryptographic Modules NVLAP accredited Cryptographic Modules Testing (CMT) laboratories perform validation testing of cryptographic modules against requirements found in FIPS PUB The Special Publication 800-series NIST SP (Risk Management Guide for Information Technology Systems) This guide describes the risk management methodology, how it fits into each phase of the System Development Life Cycle, and how the risk management process is tied to the process of system authorization (or accreditation). 12

13 Common Criteria Body of Knowledge (CCBoK) CCRA, AC CCRA, CC/CEM v3.1, scheme oversight documents, etc. CEM Annex A (General Evaluation Guidance), Site Visits: Example Checklist Supplement the above (the What) with a CCBoK (the How to Do), based on SwA CBK, Software Security Assurance SOAR, etc: [Software Assurance, A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software September Version 1.1 DRAFT] [Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance State-of-the-Art Report (SOAR), July 31, 2007] DHS Build Security In Website The motivation for the CCBoK is to improve consistency in evaluations under the CCRA and participating nations schemes through the issuance of more evaluation guidance. 13

14 CCBoK DHS Build Security In Website 14

15 CCBoK SwA Common Body of Knowledge 15

16 CCBoK SwA Common Body of Knowledge 16

17 CCBoK SwA Common Body of Knowledge PART 1: Introduction Section 1 Introduction PART 2 Security Foundation Section 2 Dangers & Damage Section 3 Fundamental Concepts & Principles Section 4 Ethics, Law & Governance PART 3: Application to Secure Software Section 5 Secure Software Requirements Section 6 Secure Software Design Section 7 Secure Software Construction Section 8 Secure Software Verification, Validation & Evaluation Section 9 Secure Software Tools & Methods Section 10 Secure Software Processes Section 11 Secure Software PM Section 12 Secure Software Sustainment PART 4: Using the SwA CBK 17

18 CCBoK SwA Common Body of Knowledge 5 SECURE SOFTWARE REQUIREMENTS 5.1 SCOPE 5.2 REQUIREMENTS FOR A SOLUTION Traceability Identify Stakeholder Security-related Needs Asset Protection Needs Threat Analysis Interface and Environment Requirements Usability Needs Reliability Needs Availability, Tolerance, and Survivability Needs Sustainability (Maintainability) Needs Deception Needs Validatability, Verifiability, and Evaluatability Needs Certification Needs System Accreditation and Auditing Needs 18

19 CCBoK SwA Common Body of Knowledge 5 SECURE SOFTWARE REQUIREMENTS REQUIREMENTS ANALYSES Risk Analysis Feasibility Analysis Tradeoff Analysis Analysis of Conflicts among Security Needs 5.4 SPECIFICATION Document Assumptions Specify Software-related Security Policy Security Functionality Requirements High-Level Specification 5.5 REQUIREMENTS VALIDATION 5.6 ASSURANCE CASE 19

20 CCBoK SwA Common Body of Knowledge 7 SECURE SOFTWARE CONSTRUCTION 7.1 SCOPE 7.2 COMMON VULNERABILITIES Buffer Overrun Resource Exhaustion Operating Environment Race Conditions Canonical Form Violations of Trust 7.3 CONSTRUCTION OF CODE Language Selection Annotations and Add-ons Using Security Principles in Secure Coding Coding Standards for Secure Software Secure Coding Practices Sound Practices 7.4 CONSTRUCTION OF USER AIDS 7.5 SECURE RELEASE 7.6 CONCLUSION 7.7 APPENDIX A. TAXONOMY OF CODING ERRORS 20

21 CCBoK SwA Common Body of Knowledge 8 SECURE SOFTWARE VERIFICATION, VALIDATION, AND EVALUATION 8.1 SCOPE 8.2 ASSURANCE CASE 8.3 ENSURE PROPER VERSION 8.4 TESTING Test Process Test Techniques 8.5 DYNAMIC ANALYSIS Simulations Prototypes Mental Executions Dynamic Identification of Assertions and Slices 21

22 CCBoK SwA Common Body of Knowledge 8 SECURE SOFTWARE VERIFICATION, VALIDATION, AND EVALUATION STATIC ANALYSIS Formal Analysis and Verification Informal Analysis, Verification, and Validation 8.7 USABILITY ANALYSIS 8.8 VERIFICATION AND VALIDATION OF USER AIDS 8.9 SECURE SOFTWARE MEASUREMENT 8.10 THIRD-PARTY VERIFICATION AND VALIDATION AND EVALUATION Independent Verification and Validation Software Certification System Accreditation 8.11 ASSURANCE FOR TOOLS 8.12 SELECTING AMONG VV&E TECHNIQUES 8.13 FURTHER READING 22

23 CCBoK SwA Common Body of Knowledge 9 SECURE SOFTWARE TOOLS AND METHODS 9.1 SCOPE 9.2 FORMAL METHODS 9.3 SEMI-FORMAL METHODS 9.4 COMPILERS 9.5 STATIC ANALYSIS 9.6 DYNAMIC ANALYSIS 9.7 DEVELOPMENT TOOL SUITES 9.8 SELECTING TOOLS 23

24 CCBoK Software Security Assurance SOAR Section 1 Introduction Section 2 Definitions Section 3 - Why is Software at Risk? Section 4 Secure Systems Engineering Section 5 SDLC Processes and Methods and the Security of Software Section 6 Software Assurance Initiatives, Activities, and Organizations Section 7 Resources Section 8 Observations Appendices 24

25 CCBoK Safety and Security Standards Goal 1. An infrastructure for safety and security is established and maintained. Practice 1. Ensure Safety and Security Competency Practice 2. Establish Qualified Work Environment Practice 3. Ensure Integrity of Safety and Security Information Practice 4. Monitor Operations and Report Incidents Practice 5. Ensure Business Continuity INCOSE INSIGHT, April 2007 Special Feature Standards in Systems Engineering: Harmonization of Safety and Security Standards, Linda Ibrahim, The final report by this author and others, Safety and Security Extensions for Integrated Capability Maturity Models (Federal Aviation Administration, 2004), provides full details about this work. 25

26 Summary Purpose Acknowledgements Security Standards & References Common Criteria Body Of Knowledge (CCBoK) Background Material 26

27 Questions? For further information: 27

28 Background Material Build Security In (BSI) is a project of the Software Assurance program of the Strategic Initiatives Branch of the National Cyber Security Division (NCSD) of the U.S. Department of Homeland Security. The Software Engineering Institute (SEI) was engaged by the NCSD to provide support in the Process and Technology focus areas of this initiative. 28

29 Background Material Software Assurance Common Body of Knowledge The Department of Homeland Security (DHS) Software Assurance Program is seeking review and comment on the Common Body of Knowledge for this version (v.1.1). Software Assurance Series Software Assurance A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software September Version 1.1, DRAFT. The IEEE International Symposium on Secure Software Engineering and the Software Assurance Forum provide opportunities for additional information in this area. 29

30 Background Material (SSE-CMM) The Systems Security Engineering Capability Maturity Model (SSE-CMM) was developed to advance security engineering as a defined, mature, and measurable discipline. Its acceptance as ISO/IEC 21827, makes it the first formal standard of this scale dedicated to security engineering practices. 30

31 Background Material (SSE-CMM) The SSE-CMM addresses security engineering activities that span the entire trusted product or secure system life cycle, including concept definition, requirements analysis, design, development, integration, installation, operations, maintenance, and decommissioning. The SSE-CMM applies secure product developers, secure system developers and integrators, and organizations that provide security services and security engineering. For more information, download the SSE-CMM Model Document: 31

32 Background Material (Safety and Security Extensions for Integrated Capability Maturity Models) FAA integrated Capability Maturity Model (FAAiCMM or icmm) version 2.0 (available at Capability Maturity Model Integration for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI -SE/SW/IPPD/SS or CMMI) version 1.1 (available at 32

33 Background Material (Safety and Security Extensions for Integrated Capability Maturity Models) Today the need for safe and secure products and services is widely recognized. To be relevant in the global environment, capability maturity models that support process improvement need to include standards-based safety and security practices. Both the CMMI and icmm provide process improvement frameworks in which safety and security activities can take place. However, some practices specific to safety and security are not addressed in these models, nor is there sufficient guidance for interpreting the models practices in a safety and security context. 33

34 Background Material (Safety and Security Extensions for Integrated Capability Maturity Models) The FAA approved a project to address both safety and security in the icmm, and the CMMI Steering Group and CMMI user community have discussed addressing safety and security. Safety and Security Extensions for Integrated Capability Maturity Models, September

35 Background Material (Safety and Security Extensions for Integrated Capability Maturity Models) They also selected these four security standards: ISO/IEC 17799:2000(E (Information technology Code of practice for information security management), International Organization for Standardization, first edition ISO/IEC (Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements), version 2.1, Common Criteria Project Sponsoring Organizations, 1999 ISO/IEC 21827:2002 (Systems Security Engineering Capability Maturity Model), International Organization for Standardization NIST SP (Risk Management Guide for Information Technology Systems), National Institute of Standards and Technology, Special Publication ,

36 Background Material (Safety and Security Extensions for Integrated Capability Maturity Models) Goal 1. An infrastructure for safety and security is established and maintained. Goal 2. Safety and security risks are identified and managed. Goal 3. Safety and security requirements are satisfied. Goal 4. Activities and products are managed to achieve safety and security requirements and objectives. 36