Software Assurance

1. Software Assurance Software Acquisition Working Group Chairs: Stan Wisseman Booz Allen Hamilton Mary L. Polydys National Defense University Information Resources Management College

2. Needs for Software Assurance • 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 Strengthen operational resiliency

3. 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

4. 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”

5. DHS Software Assurance: Acquisition • Collaborate 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

6. 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

7. 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

8. 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?

9. 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

10. 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

11. 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

12. Current Status • Draft 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

13. Conclusion • Large 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