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

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
Acquisition officials have a due-diligence
responsibility to factor in Software Assurance to
reduce the risk exposure of exploitable software
being passed to users of delivered
software-intensive systems

• Knowing what it takes to get what we want
• Development/acquisition practices/process
  capabilities
• Criteria for assuring integrity mitigating risks

• Acquiring what we want
• Threat modeling and analysis
• Requirements engineering
• Failsafe design and defect-free code
• Supply Chain Management

• Understanding what we acquired
• Production assurance evidence
• Comprehensive testing and diagnostics
• Formal methods static analysis

Multiple Sources DHS/NCSD, OASD(NII)IA, NSA,
NASA, JHU/APL

• Using what we understand
• Policy/practices for use acquisition
• Composition of trust
• Hardware support

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

8
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

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

10
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

11
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

12
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

13
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

14
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