Department of Homeland Security SECURITY IN THE SOFTWARE LIFECYCLE Making Software Development Processes— and Software Produced by Them—More Secure DRAFT Version 1.2 - August 2006 Security in the Software Lifecycle Draft Version 1.2 | August 2006 FOREWARD Dependence on information technology makes software assurance a key element of business continuity, national security, and homeland security. Software vulnerabilities jeopardize intellectual property, consumer trust, business operations and services, and a broad spectrum of critical applications and infrastructure, including everything from process control systems to commercial application products. The integrity of key assets depends upon the reliability and security of the software that enables and controls those assets. However, informed consumers have growing concerns about the scarcity of practitioners with requisite competencies to build secure software. They have concerns with suppliers’ capabilities to build and deliver secure software with requisite levels of integrity and to exercise a minimum level of responsible practice. Because software development offers opportunities to insert malicious code and to unintentionally design and build software with exploitable weaknesses, security-enhanced processes and practices—and the skilled people to perform them—are required to build software that can be trusted not to increase risk exposure. In an era riddled with asymmetric cyber attacks, claims about system reliability, integrity and safety must also include provisions for built-in security of the enabling software. The Department of Homeland Security (DHS) Software Assurance Program is grounded in the National Strategy to Secure Cyberspace which indicates: “DHS will facilitate a national public-private effort to promulgate best practices and methodologies that promote integrity, security, and reliability in software code development, including processes and procedures that diminish the possibilities of erroneous code, malicious code, or trap doors that could be introduced during development.” Software Assurance has become critical because dramatic increases in business and mission risks are now known to be attributable to exploitable software: (1) system interdependence and software dependence has software as the weakest link; (2) software size and complexity obscures intent and precludes exhaustive test; (3) outsourcing and use of unvetted software supply chain increases risk exposure; (4) attack sophistication eases exploitation; and (5) reuse of legacy software interfaced with other applications in new environments introduces other unintended consequences increasing the number of vulnerable targets. The growing extent of the resulting risk exposure is rarely understood. The number of threats specifically targeting software is increasing, and the majority of network- and system-level attacks exploit vulnerabilities in application level software. These all contribute to the increase of risks to software-enabled capabilities and the threat of asymmetric attack. A broad range of stakeholders now need justifiable confidence that the software that enables their core business operations can be trusted to perform (even with attempted exploitation). DHS began the Software Assurance (SwA) Program as a focal point to partner with the private sector, academia, and other government agencies in order to improve software development and acquisition processes. Through public-private partnerships, the Software Assurance Program framework shapes a comprehensive strategy that addresses people, process, technology, and acquisition throughout the software life cycle. Collaborative efforts seek to shift the paradigm away from patch management and to achieve a broader ability to routinely develop and deploy software products known to be trustworthy. These efforts focus on contributing to the production of higher quality, more secure software that contributes to more resilient operations. In their Report to the President entitled Cyber Security: A Crisis of Prioritization (February 2005), the President’s Information Technology Advisory Committee (PITAC) summed up the problem of non- secure software: i Security in the Software Lifecycle Draft Version 1.2 | August 2006 Network connectivity provides “door-to-door” transportation for attackers, but vulnerabilities in the software residing in computers substantially compound the cyber security problem. As the PITAC noted in a 1999 report, the software development methods that have been the norm fail to provide the high- quality, reliable, and secure software that the Information Technology infrastructure requires. Software development is not yet a science or a rigorous discipline, and the development process by and large is not controlled to minimize the vulnerabilities that attackers exploit. Today, as with cancer, vulnerable software can be invaded and modified to cause damage to previously healthy software, and infected software can replicate itself and be carried across networks to cause damage in other systems. Like cancer, these damaging processes may be invisible to the lay person even though experts recognize that their threat is growing. And as in cancer, both preventive actions and research are critical, the former to minimize damage today and the latter to establish a foundation of knowledge and capabilities that will assist the cyber security professionals of tomorrow reduce risk and minimize damage for the long term. Vulnerabilities in software that are introduced by mistake or poor practices are a serious problem today. In the future, the Nation may face an even more challenging problem as adversaries—both foreign and domestic—become increasingly sophisticated in their ability to insert malicious code into critical software. The DHS Software Assurance (SwA) program goals promote the security of software across the development life cycle and are scoped to address: 1. Trustworthiness: No exploitable vulnerabilities exist, either maliciously or unintentionally inserted; 2. Predictable Execution: Justifiable confidence that software, when executed, functions as intended; 3. Conformance: Planned and systematic set of multi-disciplinary activities that ensure software processes and products conform to requirements and applicable standards and procedures. Initiatives such as the DHS “Build Security In” Web site at https://buildsecurityin.us-cert.gov and the Software Assurance Common Body of Knowledge (CBK) will continue to evolve and provide practical guidance and reference material to software developers, architects, and educators on how to improve the quality, reliability, and security of software – and the justification to use it with confidence. This developers’ guide, entitled Security in the Software Life Cycle: Making Software Development Processes—and Software Produced by Them—More Secure, is also being published as part of the DHS Software Assurance program, and is freely downloadable from the DHS BuildSecurityIn portal. The main goal of Security in the Software Life Cycle is to arm developers, project managers, and testers with the information they need to start improving the security of the practices and processes they use to produce software. A growing number of practitioners in the software engineering and security communities have identified tools and practices that they have found in “real world” to improve the likelihood of producing resulting software with fewer faults and other weaknesses that can be exploited as vulnerabilities. In addition, while it is not always their explicit objective, the practices and technologies described in Security in the Software Life Cycle should also help increase software’s overall dependability and quality. Unlike other works published on secure software engineering, secure programming, secure coding, application security, and similar topics, Security in the Software Life Cycle does not set out to recommend ii Security in the Software Lifecycle Draft Version 1.2 | August 2006 a specific approach to the software security problem. Instead, it offers alternative approaches for addressing specific security issues. Where it does resemble such works is in the more detailed discussion of software security principles and practices in Appendix G. However, the scope of the information provided in Appendix G is broader than that found in many other published works with similar content. Also unlike other such works, the other sections of Security in the Software Life Cycle discuss a number of life cycle process models, development methodologies, and supporting tools that have been shown in “real world” software development projects, across government, industry, and academia in the United States (U.S.) and abroad, to reduce the number of exploitable software faults that can be targeted as vulnerabilities to compromise the software, the data it processes, or the computing and networking resources on which the software depends. No single practice, process, or methodology offers a universal “silver bullet” for software security. With this in mind, this document has been compiled as a reference intended to present an overview of software security and inform software practitioners about a number of practices and methodologies which they can evaluate and selectively adopt to help reshape their own development processes to increase the security and dependability of the software produced by those processes, both during its development and its operation. Security in the Software Life Cycle is a part of