Software Assurance: A Strategic Initiative of the U.S. Department of Homeland Security

1. Software Assurance: A Strategic Initiative of the U.S. Department of Homeland Security to Promote Integrity, Security, and Reliability in Software Need for “Assurance” Standards in Mitigating Risks to the Enterprise March 11, 2008 Joe Jarzombek,PMP Director for Software Assurance National Cyber Security Division US Department of Homeland Security

2. "We will lead the unified national effort to secure America. We will prevent and deter terrorist attacks and protect against and respond to threats and hazards to the nation. We will ensure safe and secure borders, welcome lawful immigrants and visitors, and promote the free-flow of commerce." Key Objective I Key Objective II Key Objective III Prevent terrorist attacks within the United States Reduce America’s vulnerability to terrorism Minimize the damage and recover from attacks that do occur Authorization: Homeland Security Act of 2002 at Title 6, U.S. Code

3. Cyberspace & physical space are increasingly intertwined and software controlled/enabled • Chemical Industry • 66,000 chemical plants • Banking and Finance • 26,600 FDIC institutions • Agriculture and Food • 1.9M farms • 87,000 food processing plants • Water • 1,800 federal reservoirs • 1,600 treatment plants • Public Health • 5,800 registered hospitals • Postal and Shipping • 137M delivery sites • Transportation • 120,000 miles of railroad • 590,000 highway bridges • 2M miles of pipeline • 300 ports • Telecomm • 2B miles of cable • Energy • 2,800 power plants • 300K production sites • Key Assets • 104 nuclear power plants • 80K dams • 5,800 historic buildings • 3,000 government facilities • commercial facilities / 460 skyscrapers An Asymmetric Target-rich Environment a well-crafted cyber attack could be just as disastrous as a physical one, because it could happen at any time and could come from anywhere.

4. Cyberspace & physical space are increasingly intertwined and software controlled/enabled Need for secure software applications Agriculture and Food Energy Transportation Chemical Industry Postal and Shipping Sectors Water Public Health Telecommunications Banking and Finance Key Assets Critical Infrastructure / Key Resources Farms Food Processing Plants Power Plants Production Sites Railroad Tracks Highway Bridges Pipelines Ports Chemical Plants Delivery Sites Nuclear Power Plants Government facilities Dams Physical Assets Reservoirs Treatment Plants Cable Fiber Hospitals FDIC institutions Physical Infrastructure • Internet • Domain Name System • Web Hosting • Hardware • Database Servers • Networking Equipment • Control Systems • SCADA • PCS • DCS Cyber Assets • Services • Managed Security • Information Services • Software • Financial System • Human Resources Cyber Infrastructure “In an era riddled with asymmetric cyber attacks, claims about system reliability, integrity and safety must also include provisions for built-in security of the enabling software.”

5. Security is a Requisite Quality Attribute: Vulnerable Software Enables Exploitation • Rather than attempt to break or defeat network or system security, hackers are opting to target application software to circumvent security controls. • 75% of hacks occurred at application level • “90% of software attacks were aimed at application layer” (Gartner & Symantec, June 2006) • most exploitable software vulnerabilities are attributable to non-secure coding practices (and not identified in testing). • Functional correctness must be exhibited even when software is subjected to abnormal and hostile conditions Software applications with exploitable vulnerabilities SECURITY Software applications with exploitable vulnerabilities “In an era riddled with asymmetric cyber attacks, claims about system reliability, integrity and safety must include provisions for built-in security of the enabling software.”

6. Software Assurance Addresses Exploitable Software: Outcomes of non-secure practices and/or malicious intent Exploitation potential of vulnerability is independent of “intent” Defects Software Malware EXPLOITABLE SOFTWARE Unintentional Vulnerabilities Intentional Vulnerabilities *Intentional vulnerabilities: spyware & malicious logic deliberately imbedded (might not be considered defects) Note: Chart is not to scale – notional representation -- for discussions

7. Software & IT lifecycle processes offer opportunities to insert malicious code and to poorly design and build software which enables future exploitation. Government and businesses rely on COTS products and commercial developers using foreign and non-vetted domestic suppliers to meet majority of IT requirements. Off-shoring magnifies risks and creates new threats to security, business property and processes, and individuals’ privacy – requires more comprehensive domestic strategies to mitigate those risks. Government lacks information on suppliers’ process capabilities (business practices); cannot adequately determine security risks posed by the suppliers’ products and services to the acquisition project and to the operations enabled by the software. Needs in IT/Software Assurance Adversaries have capabilities to subvert the IT/software supply chain

8. There is a limited number of practitioners with the requisite knowledge and skills, and very few suppliers have adequately incorporated security in their development life cycle. Concern about suppliers and practitioners not exercising “minimum level of responsible practice” – no standards in place to benchmark or assess practices. Few process improvement and capability appraisal methods and models address security in business practices and process improvement; so security benchmarks are lacking in capability appraisals, and no claims are made about software/system predictable execution. Current education & training provides too few practitioners with requisite competencies in secure software engineering – enrollment down in criticalIT and software-related degree programs. Needs in IT/Software Assurance (cont.) Growing concern about inadequacies of suppliers’ capabilities to build/deliver secure IT/software

9. What if… • Government, in collaboration with industry / academia, raised expectations for product assurance with requisite levels of integrity and security: • Helped advance more comprehensive software assurance diagnostic capabilities to mitigate risks stemming from exploitable vulnerabilities and weaknesses; • Promoted use of methodologies and tools that enabled security to be part of normal business. • Acquisition managers & users factored risks posed by the supply chain as part of the trade-space in risk mitigation efforts: • Information on suppliers’ process capabilities (business practices) would be used to determine security risks posed by the suppliers’ products and services to the acquisition project and to the operations enabled by the software. • Information about evaluated products would be available, along with responsive provisions for discovering exploitable vulnerabilities, and products would be securely configured in use. • Suppliers delivered quality products with requisite integrity and made assurance claims about the IT/software safety, security and dependability: • Relevant standards would be used from which to base business practices & make claims; • Qualified tools used in software lifecycle enabled developers/testers to mitigate security risks; • Standards and qualified tools would be used to certify software by independent third parties; • IT/software workforce had requisite knowledge/skills for developing secure, quality products. Strengthen operational resiliency

10. DHS Software Assurance Program Overview • Program based upon the National Strategy to Secure Cyberspace - Action/Recommendation 2-14: “DHS will facilitate a national public-private effort to promulgate best practices and methodologies that promote integrity, security, and reliability in software code development, including processes and procedures that diminish the possibilities of erroneous code, malicious code, or trap doors that could be introduced during development.” • DHS Program goals promote the security of software across the development, acquisition and implementation life cycle • DHS Software Assurance (SwA) program is scoped to address: • Trustworthiness - No exploitable vulnerabilities exist, either maliciously or unintentionally inserted • Predictable Execution - Justifiable confidence that software, when executed, functions as intended • Conformance - Planned and systematic set of multi-disciplinary activities that ensure software processes and products conform to requirements, standards/ procedures Also See Wikipedia.org for “Software Assurance” CNSS Instruction No. 4009, "National Information Assurance Glossary," Revised 2006, defines Software Assurance as: "the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at anytime during its lifecycle, and that the software functions in the intended manner".

11. SW Assurance related to Engineering Disciplines • For a safety/security analysis to be valid … • The execution of the system must be predictable. • This requires … • Correct implementation of requirements, expectations and regulations. • Exclusion of unwanted function even in the face of attempted exploitation. System and SWEngineering and Information Systems Security Engineering Predictable Execution Traditional concern System Safety InformationAssurance Cyber Security Growing concern Predictable Execution = requisite enabling characteristic *Adopted from Jim Moore, IEEE CS S2ESC Liaison to ISO SC7

12. Disciplines Contributing to Software Assurance* Information Assurance Systems Engineering Project Mgt Software Assurance Software Acquisition Software Engineering Safety & Security *Test & Evaluation *Info Systems Security Eng • In Education and Training, Software Assurance could be addressed as: • A “knowledge area” extension within each of the contributing disciplines; • A stand-alone CBK drawing upon contributing disciplines; • A set of functional roles, drawing upon a common body of knowledge; allowing more in-depth coverage dependent upon the specific roles. • Intent is to provide framework for curriculum development and evolution of contributing BOKs * See ‘Notes Page’ view for contributing BOK URLs and relevant links • The intent is not to create a new profession of Software Assurance; rather, to provide a common body of knowledge: (1) from which to provide input for developing curriculum in related fields of study and (2) for evolving the contributing disciplines to better address the needs of software security, safety, dependability, reliability and integrity.

13. Software Assurance Forum and Working Groups * … encourage the production, evaluation and acquisition of better quality and more secure software through targeting People Processes Technology Acquisition Developers and users education & training Sound practices, standards, & practical guidelines for secure software development Security test criteria, diagnostic tools, common enumerations, SwA R&D, and SwA measurement Software security improvements through due-diligence questions, specs and guidelines for acquisitions/ outsourcing Products and Contributions Practical Measurement Guidance for SwA/InfoSec SwA Metrics & Tool Evaluation (with NIST) SwA Ecosystem w/ DoD, NSA, NIST, OMG & TOG NIST Special Pub 500 Series on SwA Tools Common Weakness Enumeration (CWE) dictionary Common Attack Pattern Enumeration (CAPEC) Malware Attribution & Enumeration (with ASC) SwA in Acquisition: Mitigating Risks to Enterprise Software Project Management for SwA SOAR Build Security In - https://buildsecurityin.us-cert.gov and SwA community portal – http://us-cert.gov/SwA SwA Common Body of Knowledge (CBK) & Glossary SwA Developers' Guide on Security-Enhancing SDLC Software Security Assurance State of the Art Report Systems Assurance Guide (via DoD and NDIA) SwA-related standards – ISO/IEC JTC1 SC7/27/22, IEEE CS, OMG, TOG, & CMM-based Assurance * SwA Forum is part of Cross-Sector Cyber Security Working Group (CSCSWG) established under auspices of the Critical Infrastructure Partnership Advisory Council (CIPAC) that provides legal framework for participation.

14. Software Assurance Resources • The DHS National Cyber Security Division serves as a focal point for software assurance, facilitating national public-private efforts to promulgate best practices and methodologies that promote integrity, security, and reliability in software development and acquisition.   • Collaborative efforts of the Software Assurance (SwA) community have produced several publicly available resources: • SwA Common Body of Knowledge with Guiding Security Principles (curriculum development guide, updated Oct 2007) at https://buildsecurityin.us-cert.gov/swa/people.html; • Securing the Software Lifecycle: Making Application Development Processes - and Software Produced by Them - More Secure, v2.0 (developer’s guide, update available Mar 2008); • State-of-the-Art Report on Software Security Assurance at http://iac.dtic.mil/iatac/download/security.pdf; • Practical Measurement Guidance for SwA and InfoSec, v1.0 (Measurement Guide to support information needs; draft update available Mar 2008);   • Software Assurance in Acquisition:  Mitigating Risks to the Enterprise, v1.0 (procurement guide - https://buildsecurityin.us-cert.gov/daisy/bsi/resources/dhs/908.html); • State-of-the-Art Report on Software Project Management for Software Assurance https://buildsecurityin.us-cert.gov/daisy/bsi/resources/dhs/906.html • Common Attack Pattern Enumeration and Classification (CAPEC - http://capec.mitre.org), and • Common Weakness Enumeration (CWE - http://cwe.mitre.org) with links to the National Vulnerability Database - http://nvd.nist.gov/nvd.cfm. • For more information, see Build Security In web site  https://buildsecurityin.us-cert.gov/ -- expanding to become the Software Assurance (SwA) Community of Practice portal http://www.us-cert.gov/swa to provide coverage of topics relevant to the broader stakeholder community.

15. Process Agnostic Lifecycle Launched 3 Oct 2005 Architecture & Design Architectural risk analysis Threat modeling Principles Guidelines Historical risks Modeling tools Resources Code Code analysis Assembly, integration & evolution Coding practices Coding rules Code analysis Resources Test Security testing White box testing Attack patterns Historical risks Resources Touch Points & Artifacts Requirements Requirements engineering Attack patterns Resources System Penetration testing Incident management Deployment & operations Black box testing Resources Fundamentals Risk management Project management Training & awareness Measurement SDLC process Business relevance Resources https://buildsecurityin.us-cert.gov Key Best (sound) practices Foundational knowledge Tools Resources

16. Software Security Engineering: A Guide for Project Managers • Organized for Project Managers • Derives material from DHS SwA “Build Security In” web site • https://buildsecurityin.us-cert.gov • Provides a process focus for projects delivering software-intensive products and systems • To be published in May 2008

17. Launch http://us-cert.gov/SwA for Software Assurance Community of Practice (Oct 07) • Build Security In • Will continue as a related website (on same server) • Will continue to serve as a detailed reference source for developers • Will continue to be a part of the SwA Processes & Practices WG • SwA WORKING GROUPS • SwA WGs are created to give focus to specific areas within the effort. • More description would be provided for the specific efforts. • -- A comprehensive description would provide information to the user to determine what is the purpose of WGs and what they are like. • -- It could also reference results of the working group activity here in this area as an example. • -- It will outline the different levels of participation: active & observer. • Matrix provides linkage among SwA WORKING GROUPS and SwA FOCUS AREAS -- Enables more effective navigation and access to relevant material Serving broader stakeholder community

18. Software Security Assurance: A State of the Art Report, 31 July 2007IATAC, an Information Analysis Center in Defense Technical Information Center • Publicly available resource provides a comprehensive look at efforts to improve the state of Software Security Assurance: • describes the threats and common vulnerabilities to which software is subject; • presents the many ways in which the S/W Security Assurance problem is being framed and understood across government, industry, and academia; • describes numerous methodologies, best practices, technologies, and tools currently being used to specify, design, and implement software that will be less vulnerable to attack, and to verify its attack-resistance, attack-tolerance, and attack-resilience; • offers a large number of available print and online resources from which readers can learn more about the principles and practices that constitute Software Security Assurance; • provides observations about potentials for success, remaining shortcomings, and emerging trends across the S/W Security Assurance landscape. • Free via http://iac.dtic.mil/iatac/download/security.pdf • The SOAR reflects output of efforts in the DoD-DHS Software Assurance Forum and Working Groups that provide collaborative venues for stakeholders to share and advance techniques and technologies relevant to software security.

19. DHS SwA – Process Focus • Provide Software Assurance (SwA) Developers’ Guidance • Provided practical guidance via “Build Security In” on US-CERT web site with regular updates based on feedback from stakeholders • Provided developers guide, “Securing the Software Lifecycle: Making Application Development Processes – and Software Produced by Them – More Secure” v1.2 – primary input to Software Security Assurance State of the Art Report • Collaborate with DoD “Systems Assurance” Guidebook • Work with IEEE CS S2ESC, ISO/IEC JTC1 SC7/SC27/SC22, OMG, TOG, CNSS, & NIST to recommend changes to national/ international standards related to SwA • Plans: • Continue to provide periodic updates to https://buildsecurityin.us-cert.gov • Evolve developers’ guide, draft v2 in Sep 2007 reflecting new organization and references to related work • In collaboration with federal agencies, standards bodies, industry and academia: • provide draft guidance for specifying ‘assurance case/arguments’ from which to base claims about the safety, security and dependability of software • provide recommended changes to national and international standards on programming languages, software testing and software assurance • provide recommendations to Capability Maturity Models (CMMs) for Assurance 7 Aug 07 Workshop on “Assurance” with CMMI focused efforts

20. Process Improvement Should Link to Security:SEPG 2007 Security Track Recaphttp://www.sei.cmu.edu/publications/documents/07.reports/07tn025.html 1 Process Improvement Should Link to Security • Panel Questions, Presentations and Resources • Getting Credit for Effective Security Processes • Processes for Determining Security Requirements • Measuring Security Processes & Improvement Efforts • Development Processes Contributing to Operational Resiliency • Leveraging Process Improvement for Security in the SDLC • Audience Feedback To Panelists 2 Security Track Presenters Connect Security to Process 2.1 Security Track Speakers Covered A Range of Security Issues 2.2 Software Security— Setting the Stage 2.3 Insider Threats in the SDLC 2.4 Engineering Safety- and Security-Related Requirements for Software-Intensive Systems 2.5 Focus on Resiliency: A Process Improvement Approach to Security 2.6 Getting Started with Measuring Your Security 3 Strengthening Ties between Process and Security 3.1 Security Birds of a Feather (BOF) at SEPG07 3.2 NDIA Systems Assurance Guidebook 3.3 DHS Software Assurance Program 3.4 ISSEA Systems Security Engineering CMM 3.5 ISO/IEC 15026 “Systems and Software Assurance”

21. Enhance “Assurance” Considerations:Leveraging CMM-based Process Improvement Determine how “assurance” has been factored into suppliers’ process capabilities • An infrastructure for safety & security is established and maintained. • Ensures Safety and Security Competency within the Workforce; • Establishes a Qualified Work Environment (including the use of qualified tools); • Ensures Integrity of Safety and Security Information; • Monitors Operations and Report Incidents (relative to the deployed environment); • Ensures Business Continuity. • Safety & security risks are identified and managed. • Identifies Safety and Security Risks; • Analyzes and Prioritizes Risks relative to Safety and Security; • Determines, Implements, and Monitors the associated Risk Mitigation Plan. • Safety & security requirements are satisfied. • Determines Regulatory Requirements, Laws, and Standards; • Develops and Deploys Safe and Secure Products and Services; • Objectively Evaluates Products (using safety and security criteria); • Establish Safety and Security Assurance Arguments (with supporting evidence). • Activities/products are managed to achieve safety & security requirements/objectives. • Establishes Independent Safety and Security Reporting; • Establishes a Safety and Security Plan; • Selects and Manages Suppliers, Products, and Services using safety and security criteria; • Monitors and Controls Activities and Products relative to safety and security requirements. Many suppliers use CMMs to guide process improvement & assess capabilities; yet many CMMs do not explicitly address safety and security. Source for “Assurance” enhanced processes: U.S. DoD and FAA joint project on Safety and Security Extensions for Integrated Capability Maturity Models, September 2004, at http://www.faa.gov/about/office_org/headquarters_offices/aio/documents/media/SafetyandSecurityExt-FINAL-web.pdf

22. System, Software, or Work Product Make the case for adequate quality/ assurance of the Quality / Assurance Case justify belief in supports Claims Arguments is developed for Evidence Quality / Assurance Factor Quality / Assurance Subfactor Assurance Case -- ISO/IEC 15026 System & Software Assurance What constitutes sufficient Evidence to support Arguments that justify Claims? How might “scaling” be structured to enable and encourage more suppliers and acquirers to make use of assurance cases? Adopted from US TAG ISO/IEC 15026 proposal May 2007 and CMU SEI QUASAR tutorial by Donald Firesmith, March 2007

23. Leveraging Related Standards, Models and Schemes • Overarching framework for evaluating suppliers and products leverages standards and CMMs to understand and mitigate risk exposures • Assurance Cases enable “scaling” that allows provisions for using: • Formal methods; • Internationally recognized product evaluation schemes, eg. Common Criteria and others; • Qualified tool-based evaluations (with test results independently verifiable) * • Harmonize use of standards and CMMs enabled suppliers and acquirers to better leverage investments in process improvement to support needs for “assurance” in products and systems • Measurement needs being addressed to adequately support information needs to facilitate the use of assurance cases * Requires certification of tools

24. OWASP & WASC

25. 11 21 CWE Compatibility & Effectiveness Program ( launched Feb 2007) 625 common root causes of ~25,000 CVEs Most CWEs can now be detected with tools prior to use of software cwe.mitre.org/compatible/

26. For More Information[makingsecuritymeasurable.mitre.org]

27. Value of Standards • Software Assurance needs standards to assign names to practices or collections of practices. • This enables communication between: • Buyer and seller • Government and industry • Insurer and insured Standards represent the “minimum level of responsible practice” and “sound practices” that are consensus-based methods

28. SwA Concerns of Int’l Standards Organizations TMB Advisory Group on Security ISO IEC Risk Mgmt Vocabulary TC176 JTC1 Information Technology TC56 TC65 Quality Mgmt Dependability Safety SC22 SC7 SC27 Programming Languages SW & System Engineering IT Security * DHS NCSD has membership on SC7, SC27 & IEEE S2ESC leveraging Liaisons in place or requested with other committees

29. Scope of ISO/IEC JTC1 SC7 Software and Systems Engineering: ISO/IEC 15026 “Systems and Software Assurance” “System and software assurance focuses on the management of risk and assurance of safety, security, and dependability within the context of system and software life cycles.” Terms of Reference changed: ISO/IEC JTC1/SC7 WG7, previously “System and Software Integrity” SC7 WG9 • More focused efforts applied as of May 2007 • Appointment of IEEE CS reps as Project Editor / Co-Editor for • CD ISO/IEC 15026 “Systems and Software Assurance” • Liaison to JTC1/SC27/WG4 collaborative work on Application Security • Balloting of draft documents enables stakeholder reivew/comment • (N3714) US federal government & suppliers working to ensure consistency with related, evolving Systems and Software Assurance guidelines

30. ISO/IEC JTC1 SC7 – System and Software AssuranceInterface with ISO/IEC Standards – Assurance Case/Argument • Describes interfaces/ amplifications to the Technical & Management processes of ISO/IEC 15288 System Lifecycle & 12207 Software Lifecycle • Describes interfaces/ amplifications to ISO/IEC 16085 Risk Management Process and 15939 Measurement Process and ISO/IEC 27004 Security Measures • Establishes centrality of Assurance Case/Argument • Leverages safety and IT security concepts and terminology in relevant standards Assurance Case - Argument Source: ISO/IEC 15026-D4, JTC1, SC7, WG9 (currently in the process of modifying the context interrelationships)

31. Role of Assurance Case

32. General Requirements on Assurance Cases • The project shall establish and maintain an assurance case. • The project shall ensure that: • Goals and objectives for safety, security, dependability and any other designated critical properties are formulated. • Product assurance-related objectives, properties, or characteristics are explicitly selected for special attention and application of this standard to address the goals and objectives. • Requirements for the achievement of these objectives, properties, or characteristics are defined. • Measures for the requirements are selected and related to the desired characteristics. • Criteria for the achievement or degree or achievement of these objectives, properties, or characteristics are selected and traced to requirements. • Approaches for achieving the objectives, properties, or characteristics are planned, designed, and implemented, as well as demonstrating and documenting that achievement. • The extent of achievement is continuously monitored, documented, and communicated to stakeholders and managers. • An assurance case documenting and communicating the extent of achievement is specified, developed, and maintained as an element of the system. • The artifacts for documenting, analyzing, and communicating the required or claimed properties and characteristics and the extent of achievement are specified, developed, and maintained. • Requirements of the approval authority are satisfied and necessary licenses or certifications are received.

33. Measurement in ISO/IEC 15026 • Assurance claim must use measures and be measurable • Assurance claims must be characterized in terms of critical performance parameters • Ability to compromise the system • Management of tolerance thresholds  • Characterize appropriate balance between assurance and functionality – it’s a trade off • Two types of measures are required • Reflecting the achievement of assurance objectives • Binary (y/n) • Extent of achievement • Completeness of processes • Reflecting the effectiveness of assurance processes and procedures • Degree of residual risk (probability) • Efficiency and effectiveness of processes • Link to higher levels of CMMI (Level 4/5) and predicative models 

34. Measurement Guidance: Purpose • To provide a practical framework for measuring software assurance achievement of SwA goals and objectives within the context of individual projects, programs, or enterprises. • Making informed decisions in the software development lifecycle related to information security compliance, performance, and functional requirements/controls • Facilitate adoption of secure software design practices • Respond to identified threats throughout the System Development Lifecycle (SDLC) and ultimately reduce the numbers of vulnerabilities introduced into software code during development • Determining if security/performance/trade-offs have been defined and accepted • Assessing the trustworthiness of a system. • Can be applied beyond SwA to a variety of security-related measurement efforts to help facilitate risk-based decision making through providing quantitative information on a variety of aspects of organization’s security related performance.

35. Measurement Guidance: Scope & Resources • Common measurement framework and measurement process leverage established measurement methodologies or emerging measurement methodologies that enjoy broad industry support: • NIST SP 800-55, Security Metrics Guide for Information Technology Systems • Draft ISO/IEC 27004, Information Security Management Measurement • ISO/IEC 15939, Software Engineering - Software Measurement Process, also known as Practical Software and System Measurement (PSM) • Capability Maturity Model Integration (CMMI) • CMMI Goal Question Indicator Measure (GQ(I)M) • A listing of resources is being prepared to be published on the SwA web site targeting primary stakeholder groups: Executive, Developer/Vendor/Supplier, Buyer/Acquirer • Sample SwA goals and questions lists to be used to define measures • Sources of measurable requirements, such as NIST documents • Articles on related subjects, including SwA measurement, security measurement, and software security measurement • Useful links • Measures library

36. Delivering Software Assurance:Delivering System Predictability and Reducing Uncertainty • Software Assurance (SwA) includes processes & practices that: • Specify Assurance Case • Enable supplier to make assurance claims about safety, security and/or dependability of systems, product or services • Obtain Evidence for Assurance Case • perform software assurance assessment to justify claims of meeting a set of requirements through a structure of sub-claims, arguments, and supporting evidence • Collecting evidence and verifying claims’ compliance is complex and costly process • Use Assurance Case to calculate and mitigate risk • Exam non-compliant claims and their evidence to calculate risk and identify course of actions to mitigate it • Each stakeholder will have own risk assessment – e.g. security, liability, performance, compliance Currently, SwA processes & practices are informal, subjective & manual due to lack of comprehensive tooling and formalized specifications

37. Software Assurance Ecosystem: Turning Challenges into Solutions • SwA Ecosystem is a formal framework for analysis and exchange of information related to software security and trustworthiness • Provides a technical environment where formalized claims, arguments and evidence can be brought together with formalized and abstracted software system representations to support high automation and high fidelity analysis. • Based entirely on ISO/OMG Open Standards • Semantics of Business Vocabulary and Rules (SBVR) • Knowledge Discovery Meta-model (KDM) • Software Assurance Meta-model (SAM) – work in progress for Assurance Case • Software Assurance Evidence Metamodel submissions received • Software Assurance Claims & Arguments Metamodel RFP in progress • Architected with a focus on providing fundamental improvements in analysis

38. Leveraging what we already have through SwA Ecosystem • Software Assurance Ecosystem enables industry and government to leverage and connect existing standards, policies, practices, processes and tools, in an affordable and efficient manner • The key enabler is the Software Assurance (SwA) Ecosystem Infrastructure • an open standard-based integrated tooling environment thatdramatically reduces the cost of software assurance activities • Integrates 3+1 different communities: Formal Methods, Reverse Engineering and Static Analysis, and Dynamic Analysis for a SwA solution • Enables different tool types to interoperate • Introduces many new vendors to ecosystem because they each leverage parts of the tool chain

39. Software Assurance Ecosystem: The Formal Framework The value of formalization extends beyond software systems to include related software system process, people and documentation Reports Risk Analysis, etc) Process Docs & Artifacts Requirements/Design Docs & Artifacts Process, People & Documentation Evaluation Environment • Some point tools to assist evaluators but mainly manual work • Claims in Formal SBVR vocabulary • Evidence in Formal SBVR vocabulary • Large scope requires large effort Process, People, documentation Evidence Claims, Arguments and Evidence Repository Formalized Specifications - Formalized in SBVR vocabulary - Automated verification of claims against evidence - Highly automated and sophisticated risk assessments using transitive inter-evidence point relationships Software System / Architecture Evaluation • Many integrated & highly automated tools to assist evaluators • Claims and Evidence in Formal vocabulary • Combination of tools and ISO/OMG standards • Standardized SW System Representation In KDM • Large scope capable (system of systems) • Iterative extraction and analysis for rules Software system Technical Evidence Executable Specifications Protection Profiles Hardware Environment Software System Artifacts CWE IA Controls

40. Recommendations Addressing Globalization of SoftwareDefense Science Board Task Force September 2007 Report on “Mission Impact of Foreign Influence on DoD Software” Eliminate excess functionality in mission-critical components Improve effectiveness of Common Criteria Improve usefulness of assurance metrics Promote use of automated tools in development Increase transparency and knowledge of suppliers’ processes Components should be supplied by suppliers of commensurate trustworthiness Custom code for critical systems should be developed by cleared US citizens Provide incentives to industry to produce higher quality code; improve assuredness of COTS SW Use risk-based acquisition Research programs to advance vulnerability detection and mitigation Advance the issue of software assurance and globalization on national agenda as part of effort to reduce national cyber risk Findings relate to: -The Industry Situation -Dependence on Software- -Software Vulnerabilities -Threat of the Nation-State Adversary -Awareness of Software Assurance Threat and Risk -Status of Software Assurance -Ongoing Efforts in Software Assurance -Supplier Trustworthiness Considerations -Finding Malicious Code -Government Access to Source Code Recommendations relate to: -Procurement of COTS and Off-Shore Software -Increase US Insight into Capabilities and Intentions -Offensive Strategies can complicate Defensive Strategies -System Engineering and Architecture for Assurance -Improve the Quality of Software -Improve Tools and Technology for Assurance -More Knowledgeable Acquisition of Software -Research and Development in Software Assurance

41. Executive Summary 1.Introduction 1.1 Background 1.2 Purpose and Scope 1.3 Audience—Acquisition Official Defined 1.4 Document Structure 1.5 Risk-Managed Software Acquisition Process 2.Planning Phase 2.1 Needs Determination, Initial Risk Categorization, and Solution Alternatives 2.2 SwA Requirements 2.3 Acquisition Plan and/or Acquisition Strategy 2.4 Evaluation Plan and Criteria 2.5 SwA Due Diligence Questionnaires 3. Contracting Phase 3.1 Request for Proposals 3.1.1 Work Statement 3.1.2 Terms and Conditions 3.1.3 Instructions to Suppliers 3.1.4 Certifications 3.1.5 Prequalification 3.2 Proposal Evaluation 3.3 Contract Negotiation 3.4 Contract Award 4. Implementation and Acceptance Phase 4.1 Contract Work Schedule 4.2 Change Control 4.3 Risk Management Plan 4.4 Assurance Case Management 4.5 Independent Software Testing 4.6 Software Acceptance 5. Follow-on Phase 5.1 Support and Maintenance 5.1.1 Risk Management 5.1.2 Assurance Case Management—Transition to Ops 5.1.3 Other Change Management Considerations 5.2 Disposal or Decomissioning Software Assurance (SwA) Acquisition Handbook “Software Assurance in Acquisition: Mitigating Risks to the Enterprise“ Draft Version 0.95 Sep 2007

42. Appendix A— Acronyms Appendix B— Glossary Appendix C— An Imperative for SwA in Acquisition Appendix D— Software Due Diligence Questionnaires (Examples) Table D-1. COTS Software Questionnaire Table D-2. Open-Source Software Questionnaire Table D-3. Custom Software Questionnaire Table D-4. GOTS Software Questionnaire Table D-5. Software Services Appendix E— Other Examples of Due Diligence Questionnaires Appendix F— Sample Language for the RFP and/or Contract F.1 Security Controls and Standards F.2 Securely Configuring Commercial Software F.3 Acceptance Criteria F.4 Certifications F.5 Sample Instructions to Offerors Sections F.6 Sample Work Statement Sections F.7 Open Web Application Security Project F.8 Certification of Originality Appendix G— US Government Executive Branch IA Acquisition Policy & Source Code Requirements (removed) Appendix H— References Software Assurance (SwA) Acquisition Handbook See https://buildsecurityin.us-cert.gov/swa/acqgde.html

43. Acquisition Program Supplier * “Supply chain introduces risks to American society that relies on Federal Government for essential information and services.” 30 Sep 2005 changes to Federal Acquisition Regulation (FAR) focus on IT Security Focuses on the role of contractors in security as Federal agencies outsource various IT functions. “Scope of Supplier Expansion and Foreign Involvement” graphic in DACS www.softwaretechnews.com Secure Software Engineering, July 2005 article “Software Development Security: A Risk Management Perspective” synopsis of May 2004 GAO-04-678 report “Defense Acquisition: Knowledge of Software Suppliers Needed to Manage Risks”

44. There are two sides to software acquisition There are buyers and sellers… Buyers issue RFPs to acquire software and systems. Their point of reference is the acquisition lifecycle. These are typically government agencies and prime contractors. Their point of reference is the acquisition lifecycle. Sellers are suppliers/vendors, software developers, and integrators who develop software and build systems for sale to the based on a contract. Their point of reference is the software development lifecycle. Modified Walker, E. (2005, July). Software Development Security: A Risk Management Perspective. In The DoD Software Tech News—Secure Software Engineering. Vol(8)No(2). Acquisition is the first step to security. If security is not integrated during acquisition, unplanned costs could jeopardize the project

45. Software Assurance (SwA) Acquisition Handbook • SwA Acquisition guide is recommended in Sep 2007 Report of the Defense Science Board (DSB) Task Force on “Mission Impact of Foreign Influence on DoD Software” -- Under the Recommendations on Risk-Based Acquisition (starting on page 64): • “…the mere fact of asking what vendors do to engineer security and quality into their lifecycle puts the vendor community on notice that it is important to DoD.”   • The DoD/DHS software assurance forum has been working on a procurement guide focused on software assurance, which helps procurement officers glean (through a series of questions) what vendors have done (and not done) as part of their secure development process, how they handle vulnerabilities, and so on.”   • “Such a document, when reviewed by a larger audience and finalized, could be used as part of IT procurement cycles to help DoD better evaluate risk.”   • “As long as this is sensible, the questions are phrased to allow expository answers, and the benefit derived is commensurate with the cost of vendors completing it, this is one way for DoD both to know what they are getting and to put vendors on notice that quality and security-worthiness has become a purchasing criteria for DoD.”   • “There also needs to be some way for vendors to complete these questions so they are not repeating the same questionnaire for the same product (or subsequent releases of it) needlessly.”

46. Target audience are the industry and government acquisition officials involved in the acquisition/purchase of software by contract • The generic term “acquisition official” is used to mean the members of the purchasing team. • Guidance may also be used by suppliers (e.g., prime contractors, integrators, subcontractors, and vendors in the supply chain) to facilitate an understanding of what acquisition officials may request regarding SwA. • Due-diligence questionnaires could be used by developers using third party software in evaluating “fit for use”

47. The objective is for acquirers to buy software that is more resistant to attack, has fewer vulnerabilities, and minimizes operational risks to the greatest extent possible Acquisition officials should be able to: Understand the importance of integrating SwA practices within the software acquisition life cycle. Contractually capture SwA factors critical to the success of the acquisition and deployment of the application. Recognize risks that can be avoided or minimized. Implement security practices to be adopted by acquisition personnel.

48. Including security in the initial requirements analysis is critical Cannot assume security will be addressed by the developers by default. Based on security categories, determine minimum level of security controls. Augment with application-level functional and non-functional security requirements. Require an Assurance Case: “a body of evidence organized into an argument demonstrating that some claim about a system holds, i.e., is assured. An assurance case is needed when it is important that a system exhibits some complex property such as safety, security, or reliability.” Software Engineering Institute and DHS National Cyber Security Division Assurance Case

49. SwA considerations may impact contractual requirements SwA-related definitions to provide a common understanding. The arguments/evidence needed to prove the SwA requirements are met. SwA acceptance criteria (associated with the assurance case). Risk management that specifically addresses the mitigation of SwA risks. Software Architecture that includes SwA or other descriptions to provide a structure for the SwA case. Qualifications and required SwA training of software personnel and identification of key security personnel. Required information relative to foreign ownership, control, or influence and how this information relates to SwA risk management. Organization or agency specific requirements or mandates.

50. Acquisition strategies and plans provide a description of roles and responsibilities, a roadmap for completing milestones, and a discussion for including special considerations Examples of SwA considerations that acquisition decision makers should include in strategies and plans include: SwA Expertise - personnel who possess significant SwA expertise should be part of the acquisition process Initial Security Category SwA Requirements - statements of critical, high-level SwA considerations. SwA Considerations in Contractor Selection - high-level statements on how SwA will be considered in the selection of contractors. SwA Considerations in Contract Administration and Project Management – statements on how the SwA requirements will be monitored during contract performance Plans for Independent Testing – how independent testing of the software can be used to ensure its construction, safety, and functionality.