1 / 6

Managing Risks in the Software Acquisition Process GFIRST Conference June 2007

Software vulnerabilities jeopardize infrastructure operations, business operations

selia
Download Presentation

Managing Risks in the Software Acquisition Process GFIRST Conference June 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Managing Risks in the Software Acquisition Process GFIRST Conference June 2007

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

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

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

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

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

More Related