delivering results that endure Delivering Results that Endure Managing Risks in the Software Acquisition Process GFIRST Conference June 2007 Stan Wisseman

1 Delivering Results that Endure Software vulnerabilities jeopardize infrastructure operations, business operations & services, intellectual property, and national security  System interdependence and software dependence has software as the weakest link  Outsourcing and use of an un- vetted software supply chain increases risk exposure  Reuse of software introduces other unintended consequences increasing the number of vulnerable targets

2 Delivering Results that Endure Must raise acquisition officials awareness of the need to exercise due diligence for software assurance  Rampant worldwide increase in exploitation of software vulnerabilities demands that software not only be checked for acceptable functionality, but also achieve acceptable software assurance  Need to convey message to acquisition officials that managing risks during acquisition increases confidence that software is trusted to perform as expected and be more resistant to attack  To that end, acquisition officials have a due diligence responsibility to factor in software assurance to reduce the risk exposure of software being passed to users

3 Delivering Results that Endure Need to go beyond features and require assured aoftware You may have built a perfectly functional car, but that doesn’t mean it’s gas tank won’t blow up.  Acquisition usually focus on functional requirements  But omit non-functional security requirements!  You can’t assume security will be addressed by the suppliers

4 Delivering Results that Endure The continual assurance of software-intensive systems in the Follow-on Phase presents some unique challenges  Many software systems are not architecturally designed for modifications  System and software engineering change control mechanisms can lack traceability, rigor, and documentation  Personnel turnover causes loss of corporate knowledge about maintaining and ensuring integrity of software  Many software support agencies are not the original software manufacturer and do not employ the same methods, tools, and processes used in development  Need to ensure that the assurance/security requirements implemented and accepted in previous contracts flow to follow-on contract efforts

5 Delivering Results that Endure Gathering data about software and supplier is critical to making smart software acquisitions  Does the supplier have an executive-level officer responsible for the security of their software products and/or processes?  Does the supplier have a vulnerability management and reporting policy? Is it available for review?  Has the software been measured/assessed for its resistance to identified, relevant attack patterns (CAPEC)?  Are static or dynamic software security analysis tools used to identify weaknesses in the software that can lead to exploitable vulnerabilities? If yes, which classes of weaknesses are covered (CWE)?  What policies and processes does the supplier use to verify that software components do not contain unintended, “dead,” or malicious code?  How can the integrity of an update/patch be verified to ensure that it is correct and unaltered?

6 Delivering Results that Endure