1

Software Assurance:Software Assurance:Mitigating Risks Attributable to Mitigating Risks Attributable to

Software VulnerabilitiesSoftware Vulnerabilities

Joe Jarzombek, PMPDeputy Director for Software Assurance

Information Assurance DirectorateOffice of Assistant Secretary of Defense

(Networks and Information Integration)

2

Goal: Mitigate risks attributable to software exploitation in critical software by untrusted & undisciplined developers:– eliminate malicious code– reduce software vulnerabilities

Software Assurance: “The level of confidence that software is free of exploitable vulnerabilities, either intentionally designed as part of the software or accidentally inserted, and that the software functions in the manner as would be expected by a customary user.”[Source: Interim Report on “Software Assurance: Mitigating Software Risks in the DoD IT and National Security Systems,” DoD OASD(NII), Oct 2004]

Software Assurance

3

Unexploitable Defects

IntentionalVulnerabilities

UnintentionalVulnerabilities

Defect Free

Note: Chart is not to scale – notional representation -- for discussions

Exploitable Software -- Conceptual Perspective:Outcomes of non-secure practices and/or malicious intent

EXPLOITABLE SOFTWARE

• Not all defects are exploitable vulnerabilities and not all vulnerabilities are defects

• Exploitation potential of vulnerability often independent of “intent”

4

What has Caused SW Assurance Problem

• Then– US dominated market– Stand alone systems– Software small and simple– Software small part of

functionality– Custom and closed

development processes (U.S. cleared personnel)

– Adversaries known, few, and technologically less sophisticated

• Now– Global market– Globally network

environment– Software large and

complex– Software is the core of

system functionality– COTS/GOTS/Custom in

open development processes with reuse (un-cleared, foreign sourced)

– Adversaries numerous and sophisticated

5

FY04 Def Auth Conf Report 108-354, Security of Sensitive Software --

• DOD must ensure that recent emphasis on procurement of COTS software will not open vulnerabilities in sensitive DOD C3I software

• DoD must provide IA and protection for all DOD IT assets, including:– unauthorized modifications to code in mission critical software; – insertion of malicious code into mission critical software; – reverse engineering of mission critical software.

Responding to 2 Congressional Sub-Committees, GAO Review #120221resulted in May 2004 GAO-04-678 Report “Defense Acquisitions: Knowledge of Software

Suppliers Needed to Manage Risks”– Outsourcing, foreign development risks & insertion of malicious code– DoD noted domestic development subject to similar risks– Recommendations for Executive Actions to direct DoD PMs to factor in software risks

and for DoD to factor in security in risk assessments

Addressing software issues for all Critical Infrastructure relied upon by Federal Agencies (addressed by several Congressional sub-committees, the GAO has initiated a new consolidated review in Nov 2004.

Congressional Research Study Report, “Creating a National Framework for Cybersecurity: An Analysis of Issues and Options, February 22, 2005

– Addressed vulnerabilities attributable to exploitable software

Congressional Interest

6

Government Perspective of Software Assurance

• Significant government/industry interest in SW assurance• Continue to leverage all sources of software, but reduce risk

– Raise level of trust for all software– Minimize vulnerabilities and understand threat

• DoD in conjunction with DHS is identifying and specifying SW Assurance processes/practices and SW-enabled technologies to mitigate risks

• Software Assurance body of knowledge should be delineated to support education and training, and lifecycle management

• Continue collaboration with industry / academic institutions

8

Software Assurance Initiative

• Used Working Groups coordinated by Steering Group– Prioritization of Protected Assets – Supply Chain Awareness

• Supplier Threats• Supplier Security Process Capabilities

– Acquisition/Procurement & Industrial Security Policies– Software Product Evaluation (product focused)– Workforce Education and Training– Research & Development

• Held Forum to gather additional data and vet findings• Produced interim report Oct 2004• Established DoD SW Assurance Tiger Team Dec 2004

• Next DoD-DHS SW Assurance Forum 11-12 April, 2005– Alexandria, VA– https//enstg.com/Signup/default.cfm– Conference code: SOF60973

(includes Outsourcing)

9

Software Assurance Comes From: *

Building and/or acquiring what we wantThreat analysisRequirements engineeringFailsafe design and defect-free code

Understanding what we built / acquiredProduction assurance evidenceComprehensive testingFormal methods & static analysis

Using what we understandPolicy & practices for use & acquisitionComposition of trustHardware support

Knowing what it takes to “get” what we wantDevelopment/acquisition practices and process capabilitiesCriteria for assuring integrity & mitigating risks

*(Source: Interim Report on Software Assurance, Appendix A, Oct 2004)

10

Software Assurance Lifecycle Considerations

• Define Lifecycle Threats, Vulnerabilities & Risks• Identify Risks attributable to software• Determine Threats• Understand key aspects of Vulnerabilities• Consider Implications in Lifecycle Phases:

– Threats to: System, Production process, Using system, – Vulnerabilities attributable to: Ineptness, Malicious intent,

Incorrect or incomplete artifacts, Inflexibility– Risks in Current Efforts: Polices & practices, Constraints

* See “Primer” in Appendix A to Interim Report on “Software Assurance: Mitigating Software Risks in the DoD IT and National Security Systems,” Oct 2004

11

12

Software Assurance Education & Training

• Scope workforce needs for SW assurance– Knowledge Areas– Core Competencies

• Leverage related “best practices” work from universities and standards bodies

• Develop SW Assurance Common Body of Knowledge

• Support development of related curriculum

13

Interrelationship Among Disciplines Contributing to Software Assurance Body of Knowledge*

Safety & Security

Project Mgt

Software Acquisition

Software Engineering

Software Assurance

* Note: Initial input (subject to update) for the contributing bodies of knowledge (BOK) comes from:

a) IEEE CS SW Eng Body of Knowledge (SWEBOK) for Software Engineering, www.swebok.orgb) PMI Project Management Body of Knowledge (PMBOK) for Project Management, www.pmi.orgc) DAU SW Acquisition Management (SAM) Core Competencies for SW Acquisition, http://acc.dau.mil d) Safety and Security extension for integrated CMMs from 8 S&S standards & ISSE, www.faa.gov/ipg e) DoD Information Assurance Training, Certification and Workforce Management, DoD 8570.1-M f) DoD Systems Engineering, http://www.acq.osd.mil/ds/se/index.html

Systems Engineering

Information Assurance

14

Interrelationship Among Disciplines

• From an Education and Training perspective, Software Assurance could be addressed as:– A “knowledge area” extension within each of the

contributing disciplines;– A stand-alone Body of Knowledge drawing upon

subsets of the contributing disciplines;– A set of functional roles, drawing upon a common

body of knowledge; allowing more in-depth coverage dependent upon the specific roles.

• Curriculum could be developed based on the common body of knowledge or functional roles

15

Product Diagnostic Capabilities

• Process must have:– Meaningful results (trusted)– Criteria– Multiple Options for assurance levels

• Software Evaluation– Assumes a prioritized list of critical assets– Important to look at all critical software– Need lifetime evaluation/monitoring of software– Resource constrained– Need to influence R&D

16

R&D – Research and Development

• Top Priorities– Cost-effective, improved source scanning, correct by construction– Composability of secure systems – Improved binary scanning tools– Trustworthy computing base– Minimize/control functionality– Metrics and measurements of exploitability– Detect/counter run-time vulnerabilities

• Groupings– Development processes– Scanning/detection of vulnerabilities– Countermeasures– Development tools– Application Environment– Requirement/Design/Validation– Education and Training– Secure Kernel

All

High Assurance

Less than High Assurance

17

President’s Information Technology Advisory Committee (PITAC)

Subcommittee on Cyber Security

Areas in Need of Increased Support (as of 12 Jan 2005)

• Computer Authentication Methodologies• Securing Fundamental Protocols• Secure Software Engineering and Software Assurance• Holistic System Security• Monitoring and Detection• Mitigation and Recovery Methodologies• Cyber Forensics and Technology to Enable Prosecution of

Criminals• Modeling and Testbeds for New Technologies• Metrics, Benchmarks, and Best Practices• Societal and Governance Issues

18

19

Executive Agent Responsibilities

• Executive Agent for Software Mitigation and Discovery would be responsible for specific aspects of software assurance

– Identifying requirements for, leading and conducting R&D– The DoD portfolio of technologies, processes, tools and techniques

– Leading DoD efforts to coordinate test, evaluation, certification and accreditation requirements

– Providing oversight of National Information Assurance Partnership (NIAP)

– Identifying and promoting software assurance standards

– Promoting education and awareness of software assurance risks

– Supporting security-aware process improvement

– Supporting the evaluation of security capabilities in suppliers’ software development processes

– Establishing and sustaining a federated national Center for Assured Software (CAS) to provide the capabilities as described above