Software AssuranceSoftware AssuranceSoftware Acquisition Working Group

Chairs:

Stan WissemanBooz Allen Hamilton

Mary L. PolydysNational Defense UniversityInformation Resources Management College

Software vulnerabilities jeopardize infrastructure operations, business operations & services, intellectual property, and national security

Adversaries have capabilities to subvert the IT/software supply chain: Government and businesses rely on COTS products and commercial developers

using foreign and non-vetted domestic suppliers to meet majority of IT requirements

Software & IT lifecycle processes offer opportunities to insert malicious code and to poorly design and build software which enables future exploitation

Off-shoring magnifies risks and creates new threats to security, business property and processes, and individuals’ privacy – requires domestic strategies to mitigate those risks

Needs for Software Assurance

Strengthen operational resiliency

Today’s risk factors impact software assurance

System interdependence and software dependence has software as the weakest link

Software size and complexity obscures intent and precludes exhaustive test

Outsourcing and use of an un-vetted software supply chain increases risk exposure

Attack sophistication eases exploitation

Reuse of software introduces other unintended consequences increasing the number of vulnerable targets

The number of threats targeting software, coupled with the number of vulnerabilities and incidents, all contribute to the increased risk of asymmetric attacks and threats to software-enabled capabilities

Acquisition Program

Supplier

“Supply chain introduces risks to American society that relies on Federal Government for essential information and services.”

“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”

*

DHS Software Assurance: AcquisitionCollaborate with stakeholders to enhance software supply chain management through improved risk mitigation and contracting for secure software **

Collaborate with stakeholder organizations to support acquisition community to develop and disseminate:

– Acquisition Managers handbook on software assurance for acquisition/procurement of software-intensive systems and services

– Due-diligence questionnaire for RFI/RFP and source selection decision-making

– Templates and sample statement of work / procurement language for acquisition and evaluation based on successful models

Collaborate with government and industry working groups to:

– Identify needs for reducing risks associated with software supply chain

– Provide acquisition training and education to develop applicable curriculum

Chair IEEE CS S2ESC WG to update of IEEE 1062, “Software Acquisition”

Collaborate with agencies implementing changes responsive to changes in the FAR that incorporated IT security provisions of FISMA when buying goods and services

**NCSD Objective/Action 1.4.4

Most acquisition officials are unaware of the need to exercise due diligence for software assurance

Want to convey message that managing risks during acquisition increases confidence that software is trusted to perform as expected and be more resistant to attack

Target roles in the acquisition process include

Software Acquirers/Buyers (industry and government)

IA personnel supporting acquisition managers (if available)

Decision Makers for software acquisitions

Prime contractors and the subs in their supply chain

Software suppliers

Program/Project Managers

Requirements Personnel

During the Planning Phase, identification of software risk considerations is essential

Determining Need and Risk Categorization

Solution Alternatives, including types of software Commercial-off-the-Shelf (COTS)

Government-off-the-Shelf (GOTS)

Freeware, shareware, open source software

Custom software

Web services

High level software assurance requirements should be identified

Acquisition Strategy/Procurement Plan

Software Due Diligence Questionnaires are a tool that provide a means for gathering information to evaluate quantitative, qualitative, and/or

“go/no-go” Software Assurance criteria

Many questions have been defined as examples acquisition

officials can use to gather information about software What threat modeling process is used when designing the software?

Is the software able to detect, recognize, and respond to attack patterns in input it receives from human users and external processes?

Has the software been measured/assessed for its resistance to identified, relevant attack patterns?

Does your company have established policies and procedures for dealing with the contractual obligations of third party developers that go out of business?

During the Contracting Phase, software risks must be addressed and mitigated through terms and conditions, evaluation factors for awarded, and risk mitigation requirements in the SOW

Issuance of the solicitation or RFP Definitions related to trustworthy software that provides a common

understanding

An Assurance Case that addresses the required security requirements (functions and properties) and the arguments and evidence needed to prove the requirements are met

Terms and Conditions depend on software type and should be worded in such a way to ensure that they flow down to all levels of subcontracts

Evaluation of proposals submitted in response to the solicitation or RFP should include IA specialists

During the Implementation and Acceptance Phase, software risk management deliverables must be evaluated to determine compliance in accepted risk mitigation strategies as stated in the requirements of the contract

Phase includes project management, assurance case management, software risk management, and acceptance of the software product or service

Acquisition officials must ensure that all the Software Assurance requirements are adequately implemented Due diligence questionnaire may be used as a tool or checklist in

determining if security requirements are being met

Evaluators must ensure that software risk mitigation has been implemented and can be sustained before acceptance

During the Follow-on Phase, software risks must be managed through continued analysis of risk and readjustment of risk mitigation strategies

Ensure that the assurance/security requirements implemented and accepted in previous contracts flow to follow-on contract efforts

Weak change control procedures can corrupt software and introduce new security vulnerabilities

Suppliers should provide updates in a secure fashion

Current StatusDraft 1.0 of guide out for comment

16 May Working Group to review comments

Targeting summer for broader review

Positioning guide to be NIST SP

Quick Reference guide to be released earlier

Use of guidance can begin today

ConclusionLarge numbers of vulnerable software-based systems exist today, in many cases due to acquisition of vulnerable software

Rampant worldwide increase in exploitation of software vulnerabilities demands that acquisition officials not only check for acceptable functionality, but also achieve acceptable SwA

Security cannot be “bolted on” after the services and products are delivered

To that end, acquisition officials must become educated consumers relative to SwA needs, and each phase of the acquisition process