Secure Software Common Body of Knowledge

Working Draft Comments Due by August 20, 2006 Send suggested changes, comments, and rationales to: Cindy Gagliano – Cindy.Gagliano@associates.dhs.gov with a copy to Mary Polydys – polydysm@ndu.edu For review within Working Group Only Acquisition Management Guide For Software Assurance Version 0.7 July 20, 2006 Software Assurance Acquisition Working Group Mary Linda Polydys, Editor DRAFT v. 0.7 – July 20, 2006 Prior to official release to public in non-draft form, permission is not granted for excerpting or reuse of all or portions of this document.1 Please always ensure proper acknowledgement is given. The Software Assurance Acquisition Working Group is seeking additional participation in developing the Software Security--Acquisition Guide. Representatives from government, academia, and the private industry have identified key information needed to provide information to acquisition managers to leverage the acquisition process to ensure the safety, security, reliability and dependability of software. This document is offered for informative use; it is not intended as a policy or standard. Additional inputs on this draft are being sought before it is released as a final product next spring. This draft is for review only with suggested changes due by 20 July 2006. NO WARRANTY THIS DRAFT MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. THE EDITORS, AUTHORS, CONTRIBUTORS, MEMBERS OF THE WORKING GROUP ON WORKFORCE EDUCATION AND TRAINING, THEIR EMPLOYERS, THE UNITED STATES GOVERNMENT AND OTHER SPONSORING ORGANIZATIONS, ALL OTHER ENTITIES ASSOCIATED WITH THIS REPORT, AND ENTITIES AND PRODUCTS MENTIONED WITHIN THE REPORT MAKE NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. NO WARRANTY OF ANY KIND IS MADE WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. No warranty is made that use of the guidance on this site will result in software that is secure or more secure. Examples are for illustrative purposes and are not intended to be used as is or without undergoing analysis. 1 This in no way reduces the authors‘ rights to reuse their own material at any time. iii Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Authorship and Acknowledgements Authorship and Acknowledgements Department of Homeland Security (DHS) and Department of Defense Software Assurance efforts encompass software safety, security, reliability and dependability. The Software Assurance (SwA) Acquisition Working Group, composed of government, industry, and academic members, is currently taking a first step towards leveraging the acquisition process to influence the safety, security, reliability and dependability of software. This draft is for review and comments by working group members and by those stakeholders interested in participating in evolving a guide to leverage the acquisition process to improve software safety, security, reliability and dependability. It was developed by: Editor: Mary Linda Polydys Authors: Mary Linda Polydys Stan Wisseman (others to be named) Working Group Chairs Mary Linda Polydys, Information Resources Management College, National Defense University Stan Wisseman, Booz Allen Hamilton Additional contributors included: Reviews of all or parts of document drafts were provided by: Special thanks go to: Joe Jarzombek, Director of Software Assurance, Department of Homeland Security National Cyber Security Division, without whose leadership and support this guide would not exist. The Working Group members are: Larry Baker, Defense Acquisition University Ed Barger, Boeing Sean Barnum, Cigital, Inc. Joe Bergmann, The Open Group Andy Bochman, Ounce Labs Peter Cybuck, Sharp Electronics Lauren Eisenberg Davis, The Johns Hopkins University Applied Physics Laboratory Bob Dix, Citadel Security Software, Inc. Sally Dixon, U.S. Army, Chief Information Office, G-6 Bob Ellison, Software Engineering Institute Karen Goertzel, Booz Allen Hamilton Becky Grant, U.S. Department of Defense Contract Management Agency Fred Hall, Assurance Engineering, Inc. Deanne Harwood, DHS CSIRC v Software Security Acquisition Guide 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 Authorship and Acknowledgements Dede Haskins, Cigital, Inc. Frank Herman, Fraunhofer Center Maryland George Huber, SRI International Steven Lavenhar, Booz Allen Hamilton Glen Logan, Open Systems Joint Task Force Sandra Ludwig, Booz Allen Hamilton Ernest R. Lucier James Moore, The MITRE Corporation Tom O‘Flaherty, INPUT Sam Redwine, James Madison University Phil Reitinger, Microsoft Bob Reynolds, IDA Skip Romero, Booz Allen Hamilton Warren Russell, DoD USDI Thomas Santaniello, CompTIA Jan Morgan Vargas, Software Engineering Institute, Carnegie Mellon University John Weiler, Interoperability Clearinghouse (ICH) Joe Jarzombek, DHS NCSD vi Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Preface Preface Introduction In 2003 the US Department of Defense (DoD) launched a Software Assurance Initiative led by Joe Jarzombek,3 and this was joined in 2004 by the Department of Homeland Security (DHS) to address concerns of poor-quality, unreliable, and non-secure software. In March 2005, Mr. Jarzombek moved to become Director for Software Assurance, National Cyber Security Division within DHS and retains his leadership role in the collaborative interagency Software Assurance efforts. Several working groups (with members from government, industry, and academia) were established. The initial working groups for DHS include: Software Software Software Software Technology, Tools and Product Evaluation Acquisition Processes and Practices Workforce Educational and Training Additional working groups have been formed to address the measurement and business case areas. Initial Creation of a Software Security--Acquisition Guide The goal of the Software Acquisition Working Group is to look at how to ―enhance software supply chain management through improved risk mitigation and contracting for secure software.‖ [NCSD Goal Action 2.3.4] The Group is addressing how to leverage the procurement process to ensure the safety, security, reliability and dependability of software. The Working Group‘s kickoff meeting was on 3 October 2005. The attendees were from government, industry, and academia. The overwhelming recommendation of the group was a need for sample templates and language that could be used in statements of work, request for proposal, and contracts. To accomplish the foregoing, the Acquisition Working Group was formalized and met on 28/29 November 2005 to begin its work on a Software Assurance--Acquisition Guide. The guide will provide good practices and materials that can be used in acquisition and training and education. The guide will include critical tools for participants to use in software acquisition programs: Templates for acquisition language and evaluation based on successful models Common or sample statement of work/procurement language that includes provisions on liability for federal acquisition managements Due Diligence Questionnaires designed to support risk mitigation efforts by eliciting information about the software supply chain These tools are intended to assist acquisition participants in setting standards, operating with sound practices, and managing software acquisition with an eye towards meeting security requirements. 3 Then Deputy Director for Software Assurance, Information Assurance Directorate, Office of Assistant Secretary of Defense (Networks and Information Integration) vii Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 Foreword Foreword by Joe Jarzombek Dependency on information technology makes software assurance a key element of national security and homeland security. Software vulnerabilities jeopardize intellectual property, consumer trust, business operations and services, and a broad spectrum of critical infrastructure, including everything from process control systems to commercial application products. Software enables and controls the nation‘s critical infrastructure, and in order to ensure the integrity of key assets within that infrastructure, the software must be reliable and secure. 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 exploitable software, security-enhanced processes and practices – and the skilled people to perform them – are required to build trust into 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: 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 un-vetted software supply chain increases risk exposure; attack sophistication eases exploitation; reuse of software introduces other unintended consequences increasing number of vulnerable targets; and the number of threats targeting software, coupled with the number of vulnerabilities and incidents, all contribute to the increase risk of asymmetric attack and threats to software-enabled capabilities. A broad range of stakeholders now need justifiable confidence that the software which enables their core business operations can be trusted to perform (even with attempted exploitation) and contribute to more resilient operations. 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 lifecycle. 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. The DHS Software Assurance (SwA) program goals promote the security of software across the development life cycle, and are scoped to address: Trustworthiness (no exploitable vulnerabilities exist, either maliciously or unintentionally inserted), Predictable Execution (justifiable confidence that software, when executed, functions in a manner in which it is intended), and Conformance (planned and systematic set of multi-disciplinary activities that ensure software processes and products conform to requirements, and applicable standards or procedures). viii Software Security Acquisition Guide 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 1 Foreword Initiatives such as this –Acquisition Management Guide for Software Assurance and the ―Build Security In‖ web site http://buildsecurityin.us-cert.gov will continue to evolve and provide practical guidance and reference material to acquisition managers who identify the need, establish requirements, and buy systems and products that include software. Two companion guides are also being published: Securing the Software Lifecycle: Making Application Development Processes – and Software Produced by Them – More Secure. Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software (contains a section on the Acquisition of Secure Software). The Acquisition Management Guide for Software Assurance is a part of the Software Assurance Series, and it is expected to contribute by providing practical advice and sample acquisition language to leverage the procurement process to ensure delivery of safe, secure, reliable, dependable software. In an era riddled with asymmetric cyber attacks, claims about system reliability, integrity and safety must include provisions for built-in security for the enabling software. Acquisition Managers have a due-diligence responsibility to factor in software assurance in procurements to reduce the risk exposure being passed to users of the delivered systems. A major part of that due-diligence is understanding the risks posed by the entire software supply chain, not just the seller. Joe Jarzombek, PMP Director for Software Assurance National Cyber Security Division Department of Homeland Security ix Software Security Acquisition Guide Table of Contents 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 Table of Contents 1. 2. 3. 4. 5. 6. 7. Acquisition of Trustworthy Software ....................................................................... 1 Software Assurance—An Imperative for Acquisition Managers .................................. 3 Organization of the Guide ..................................................................................... 6 Initiation and Planning ......................................................................................... 8 Contracting ....................................................................................................... 11 Implementation and Acceptance .......................................................................... 17 Sustainment ..................................................................................................... 18 Appendix A. Sample Language ................................................................................... 19 Appendix B. Source Code Review ............................................................................... 35 Appendix C. Generic Software Assurance Questionnaire ................................................ 41 C.1 INTRODUCTION ................................................................................................. 42 C.2 USING THE DUE DILIGENCE QUESTIONNAIRE ....................................................... 44 C.2.1 ORGANIZATION BACKGROUND ............................................................................................................ 46 C.2.1.1 Objective ......................................................................................................................................... 46 C.2.1.2 Assumptions .................................................................................................................................... 46 C.2.1.3 Approach ......................................................................................................................................... 46 C.2.1.4 Value ............................................................................................................................................... 47 C.2.1.5 Questions to Consider Asking the Suppliers ................................................................................... 47 C.2.1.6 Response Interpretation................................................................................................................... 49 C.2.1.7 References ....................................................................................................................................... 50 C.2.2 SOFTWARE PRODUCTION POLICIES .................................................................................................... 51 C.2.2.1 Objective ......................................................................................................................................... 51 C.2.2.2 Assumptions .................................................................................................................................... 51 C.2.2.3 Approach ......................................................................................................................................... 51 C.2.2.4 Value ............................................................................................................................................... 53 C.2.2.5 Questions to Consider Asking the Suppliers ................................................................................... 53 C.2.2.6 Response Interpretation................................................................................................................... 55 C.2.2.7 References ....................................................................................................................................... 55 C.2.3 SOFTWARE PEDIGREE ............................................................................................................................. 56 C.2.3.1 Objective ......................................................................................................................................... 56 C.2.3.2 Assumptions .................................................................................................................................... 56 C.2.3.3 Approach ......................................................................................................................................... 56 C.2.3.4 Value ............................................................................................................................................... 57 C.2.3.5 Questions to Consider Asking the Suppliers ................................................................................... 57 C.2.3.6 Response Interpretation................................................................................................................... 59 C.2.3.7 References ....................................................................................................................................... 59 C.2.4 ASSURANCE ............................................................................................................................................... 60 C.2.4.1 Objective ......................................................................................................................................... 60 C.2.4.2 Assumptions .................................................................................................................................... 60 C.2.4.3 Approach ......................................................................................................................................... 60 C.2.4.4 Value ............................................................................................................................................... 61 C.2.4.5 Questions to Consider Asking the Suppliers ................................................................................... 61 C.2.4.6 Response Interpretation................................................................................................................... 64 C.2.4.7 References ....................................................................................................................................... 64 C.2.5 PREVENTIVE MEASURES........................................................................................................................ 66 C.2.5.1 Objective ......................................................................................................................................... 66 x Software Security Acquisition Guide 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 Table of Contents C.2.5.2 Assumptions .................................................................................................................................... 66 C.2.5.3 Approach ......................................................................................................................................... 66 C.2.5.4 Value ............................................................................................................................................... 68 C.2.5.5 Questions to Consider Asking the Suppliers ................................................................................... 68 C.2.5.6 Response Interpretation................................................................................................................... 71 C.2.5.7 References ....................................................................................................................................... 72 C.2.6 QUALITY CONTROL ................................................................................................................................. 73 C.2.6.1 Objective ......................................................................................................................................... 73 C.2.6.2 Assumptions .................................................................................................................................... 73 C.2.6.3 Approach ......................................................................................................................................... 74 C.2.6.4 Value ............................................................................................................................................... 75 C.2.6.5 Questions to Consider Asking the Suppliers ................................................................................... 75 C.2.6.6 Response Interpretation................................................................................................................... 77 C.2.6.7 References ....................................................................................................................................... 78 C.2.7 OPERATIONS AND SUPPORT .................................................................................................................. 79 C.2.7.1 Objective ......................................................................................................................................... 79 C.2.7.2 Assumptions .................................................................................................................................... 79 C.2.7.3 Approach ......................................................................................................................................... 79 C.2.7.4 Value ............................................................................................................................................... 81 C.2.7.5 Questions to Consider Asking the Suppliers ................................................................................... 81 C.2.7.6 Response Interpretation................................................................................................................... 83 C.2.7.7 References ....................................................................................................................................... 84 C.2.8 SERVICE GOVERNANCE ......................................................................................................................... 85 C.2.8.1 Objective ......................................................................................................................................... 85 C.2.8.2 Assumptions .................................................................................................................................... 85 C.2.8.3 Approach ......................................................................................................................................... 85 C.2.8.4 Value ............................................................................................................................................... 86 C.2.8.5 Questions to Consider Asking the Suppliers ................................................................................... 86 C.2.8.6 Response Interpretation................................................................................................................... 90 C.2.8.7 References ....................................................................................................................................... 90 Appendix D. Due Diligence Questionnaire Specific ........................................................ 92 Appendix E. Bibliography ........................................................................................... 97 Appendix F. Acronyms List ...................................................................................... 100 xi Software Security Acquisition Guide Section 1. Acquisition of Trustworthy Software 1 1. Acquisition of Trustworthy Software Purpose. With the increasing exploitable vulnerability risks inherent in software, software assurance communities are pursuing various means and methods to improve the safety and security of software. One such means is the exploitation of the software acquisition process with the goal of obtaining software that is trustworthy. Trustworthiness is a holistic property, encompassing security, safety and reliability. Trustworthy software is stable, sufficiently fault-tolerant so that it does not crash from minor flaws and will shut down in an orderly manner in the face of major exception errors. Trustworthy software also functions consistently, always producing the same kind of output from the same kind of input. The National Institute of Standards and Technology (NIST) defines trustworthiness as ―software that can and must be trusted to work dependably in some critical function, and failure to do so may have catastrophic results, such as serious injury, loss of life or property, business failure or breach of security.‖ The primary purpose of this guide is to provide assistance to acquisition personnel on what to include in Request for Proposals (RFPs) contracts and what to request from suppliers when incorporating security in software acquisitions. The guide contains sample language, templates, certifications, and due-diligence questionnaires for use in the acquisition process and suggestions on how to use these tools. Software Assurance—The Objective. The objective is to enhance the process for acquiring trustworthy software, thereby, enhancing the IT security and safety posture. This can be achieved by supporting the security of software across the Software Development Life Cycle (SDLC) to address Trustworthiness (no exploitable vulnerabilities), Predictable Execution (when executed, functions in a manner in which it is intended) and Conformance (software processes and products conform to identified requirements in RFPs and contracts and applicable standards or procedures). Bottom line: ―Build security in‖ and maintain software assurance throughout the software life cycle. Meaning of Acquisition. For purposes of this document, ―acquisition‖ means the acquiring of software development services or software products whether by contract or by other means, e.g., downloading open source software from the Internet. For the U.S. Federal government, also see the Federal Acquisition Regulation (FAR) Subpart 2.101(b)(2) definition of acquisition. In addition, for purposes of this document, ―acquisition‖ applies to functions across the entire acquisition framework and the software development life cycle, including development, integration, testing, operations, maintenance and disposition, as well as the contracting/solicitation process itself. The contents are applicable to any type of software acquisition including commercial off-the-shelf (COTS) software purchases, custom developed software, system integration, services and outsourcing. Guide Usage. This guide is designed for both government and industry and may be used by a wide variety of personnel involved in an acquisition that includes software components. Guide’s Target Audience      Program/Project Managers Buyers (industry and government) Decision Makers for Buys Integrators Requirements Personnel 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 The Open Web Application Security Project Foundation (OWASP) states, ―Ultimately, we believe that there is no alternative to making security a part of the software contracting. Currently, we believe that there are serious misunderstandings about the security of code being delivered under many software development contracts. This can only lead to expensive litigation and a decision made by individuals with little software experience or understanding. See 1 Software Security Acquisition Guide 48 49 Section 1. Acquisition of Trustworthy Software http://www.owasp.org/columns/jwilliams/jwilliams4.html for a full discussion of this problem.‖ 2 Software Security Acquisition Guide Section 2. Software Assurance—An Imperative for Acquisition Managers 1 2. Software Assurance—The Business Case Current Practice. Common current practice in acquisition is to accept software that satisfies functionality with little regard for achieving and assuring security properties. Acquisition managers continue to accept software riddled with errors and other security vulnerabilities. This, in part, may be due to acquisition policies and procedures that do not ensure that security is a main concern of software. In addition, acquisition managers may not be aware of the costs and dangers of insecure software. Purchasing secure software does entail moderate up-front costs to the acquisition manager, however the price paid in lost time and resources to continually maintain (patch) a vulnerable software component can run as much as 3 times the initial purchase of secure software. (Secure Coding: Principles and Practices, Graff and Van Wyk, 2003) Coupled with the realization that many organizations fall behind in properly patching vulnerable software due to those exponential costs, and they are left in an extremely volatile position ripe for attack. Dangers may be attributable to software errors or other vulnerabilities to include the unknowing acceptance of software that contains malicious code. Vulnerable software may permit: Unintentional errors leading to faulty operations resulting in destruction of information, or major disruption of operations. Intentional insertion of malicious code intent on loss of life, destruction of information, major disruption of operations, or even destruction of critical infrastructures. Theft of classified information. Theft of personal information. Attackers to change the product, insert agents, or corrupt information. The Imperative. Rampant worldwide increase in exploitation of software vulnerabilities, demands that acquisition managers not only check for acceptable functionality, but also achieve acceptable Software Assurance (SwA). Although the prevailing practices of software suppliers have failed to produce the safe, secure, reliable, and dependable software, some segments of the software industry are moving toward rigorous software development practices to minimize software errors and other vulnerabilities that give our adversaries an open door to exfiltrate data and to deny or degrade services. The acquisition process can be leveraged to promote good software development practices and to facilitate the delivery of safe, security, reliable and dependable software. All the final software security requirements decisions are made during the acquisition process. In addition, acceptance and implementation decisions are all made during the acquisition process. Therefore, the acquisition manager is the last line of defense to ensure that safe, secure, reliable, and dependable software is delivered. Information Assurance vis-à-vis Software Assurance. Information Assurance (IA) relates to measures that protect and defend information and information systems by ensuring their availability4, integrity5, authentication6, confidentiality7, and nonrepudiation8. 4 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Timely, reliable access to data and information services for authorized users [CNSSI No. 4009]. 3 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Section 2. Software Assurance—An Imperative for Acquisition Managers These measures include providing for restorations of information systems by incorporating protection, detection, and reaction capabilities. Information systems include the software that controls the system and processes data and information. Therefore, measures must be employed to protect the systems from software vulnerabilities and unintended software processing that expose a system to compromises in availability, integrity, and other security properties. SwA provides those measures. United States National Concerns. A report to the President of the United States in February 2005 identified the vulnerability of software as a cyber security issue of national importance. This report states that software development practices lack the scientific underpinnings and rigorous controls needed to produce high-quality, secure products at acceptable cost. Commonly used software engineering practices permit dangerous error, which enable hundreds of attack programs to compromise millions of computers every year. ―Vulnerabilities in software that are introduced by mistake or poor practices are a serious problem today. In the future, the Nation may face even more challenging problems as adversaries—both foreign and domestic—become increasingly sophisticated in their ability to insert malicious code into critical software.‖ [US PITAC 2005, p. 9] The report also recognizes that software is an underpinning of all critical infrastructures. Software is an essential element of systems that comprise critical infrastructure sectors: public health, banking and finance, agriculture and food, water, emergency services, telecommunications, energy, transportation, chemicals and hazardous materials, postal services and defense industrial base. The vulnerabilities that permit adversaries to insert malicious code into these critical systems must be minimized. The US General Accounting Office issued a defense report to the US Congress in May 2004 on the vulnerability of defense software in the acquisition process. [GAO-04-678] In particular, the report found that ―malicious code is a threat that is not adequately addressed in current acquisition policies and security procedures.‖ The main thrust of the review revolved around risks inherent in the development of weapons system software by foreign sources. However, the findings and recommendations covered all purchased products or systems that are software intensive. Two recommendations are quoted below: ―Require program managers, working with software assurance experts, acquisition personnel, and other organizations as necessary to specifically define software security requirements, including those for identifying and managing software suppliers. These requirements should then be communicated as part of the prime development contract, to be used as part of the criteria to select software suppliers.‖ ―Based on defined software security requirements, require program managers to collect and maintain information on software suppliers, including software from foreign suppliers. This information should be evaluated periodically to assess changes in the status of suppliers and adjustments to program security requirements.‖ 5 6 7 8 Quality of an information system reflecting the logical correctness and reliability of the operating system; the logical completeness of the hardware and software implementing the protection mechanisms; and the consistency of the data structures and occurrence of the stored data. Note that, in a formal security mode, integrity is interpreted more narrowly to mean protection against unauthorized modification or destruction of information [CNSSI No. 4009]. Security measure designed to establish the validity of a transmission, message, or originator, or means of verifying an individual‘s authorization to receive specific categories of information [CNSSI No. 4009]. Assurance that information is not disclosed to unauthorized individuals, processes, or devices [CNSSI No. 4009]. Assurance that the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender‘s identity, so neither can later deny having processed the data [CNSSI No. 4009]. 4 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 Section 2. Software Assurance—An Imperative for Acquisition Managers A report to the President of the United States in February 1999 [US PITAC 1999, pp. 2731] identified software development practices failing to produce high-quality, reliable and secure software. Since that time an increasing number of software intensive systems fail because of errors imposed into the software. In September 2005, the Federal Acquisition Regulation was updated to include the IT Security provisions of the Federal Information Systems Management Act (FISMA) specifically noting, ―supply chain introduces risks to American society that relies on the Federal Government for essential information and services.‖ Because the majority of network and system exploits target software applications, it is important that acquisitions and procurements factor in risks posed by the entire supply chain, not just the seller. 13 5 Software Security Acquisition Guide Section 3. Organization of the Guide 1 3. Organization of the Guide9 Introduction. This guide includes a body that addresses software assurance efforts that are suggested during several major phases of the acquisition process. The guide also includes appendices that contain sample solicitation and contract language for software assurance and questionnaires that acquisition managers can use to help them craft statements of work or use in the evaluation process. The body of the guide contains three major sections addressing phases of a general acquisition process: Initiation and Planning; Contracting; Implementation and Acceptance; and Sustainment. Each section addresses software assurance considerations that are recommended for each phase. Since Software Assurance (SwA) may be approached differently based on type of buy, differences are addressed for custom software development, commercial-off-the-shelf software (COTS), system integration services, and IT services and business process outsourcing10. References to phases of the Department of Defense acquisition process are provided within each of the broad general phases as a point of reference. Lastly, use of the appendices is addressed where appropriate in the body. Risk-Managed Acquisition (see Figure 1). Decisions in the acquisition process are based on risk assessment and mitigation. These well understood and established processes must now factor in software assurance risk assessment and mitigation. Reasonable risk taking may be appropriate as long as a risk assessment results in the determination that certain risks under certain conditions are acceptable. Acquisition of trustworthy software must begin with a SwA risk analysis. Risks must also be controlled and mitigated and residual risks understood. Therefore, risk management is essential throughout the process of acquiring trustworthy software. Risk activities are allocated among the following phases: the Initiation and Planning phase incorporates an initial identification of risk considerations, the Contracting phase requires the supplier to provide a risk management process, the Implementation phase requires risk management by both the acquirer and supplier, and the Sustainment phase requires the continuation of risk management. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Appendices. Include:    Sample Request for Proposals (RFP) and contract language, US Government position on source code reviews, Generic Due Diligence Questionnaire that provides a set of questions relative to software security that acquisition personnel can ask during the acquisition process to ascertain risk. These questions are organized into eight major sections: o o Organization Background Software Production Policies 9 10 The organization corresponds to a degree to the organization of the acquisition section in [SwA CBK] The types of buys were derived from [INPUT, 2005]. 6 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 Section 3. Organization of the Guide o o o o o o  Software Pedigree Assurance Preventive Measures Quality Control Operations and Support Service and Governance An example of a specific questionnaire used by the healthcare community when purchasing medical devices Risk-Managed Software Acquisition Process Need Initial Software Risk Considerations Solution Alternatives (incl contracting) SwA Responsibilities Initial SwA Requirements Contract Type Acquisition Strategy and/or Plan Initiation and Planning COTS Custom Systems Integration Services & Outsourcing Contracting •Request for Proposal Work Statement Terms and Conditions Instructions to Suppliers Certifications Questionnaire(s) •Preparation of Response—supplier •Source Selection •Contract Negotiation and Finalization COTS Custom Systems Integration Services & Outsourcing Implementation and Acceptance •Project/Contract Management •SwA Plan •Software Risk Management •Assurance Case Management •SwA Acceptance Criteria COTS Custom Systems Integration Services & Outsourcing Sustainment •Change Control •SwA Risk Management •Assurance Case Management COTS Custom Systems Integration Services & Outsourcing Figure 1. Risk-Managed Software Acquisition Process 7 Software Security Acquisition Guide Section 4. Initiation and Planning 1 4. Initiation and Planning [I have not completed the changes to this section. Need to: add a graphic, focus on vulnerabilities (vice malicious behavior), include DoD mission assurance cats, redo the bullets in the ―initial SwA Risk considerations, define some terms, clarify section on SwA responsibilities and contract type, need words in context of enterprise architecture, need words on assurance case.—to name a few—wording suggestions are welcome] Introduction. The acquisition manager should consider Software Assurance (SwA) as part of determining the need for a software solution and whether to contract or accomplish the task ―in-house‖. In addition, an initial risk assessment should be performed. The results should be the foundation for the solution alternatives, software and SwA requirements, SwA responsibilities, contract type, and acquisition strategy and/or plan. Need Determination. This activity involves the definition of required capabilities to satisfy a need. In today‘s information age, most capabilities involve the processing of information by software solutions. Therefore, at the very onset of defining desired capabilities, the threat of untrustworthy software should be recognized. Initial SwA Risk11 Considerations. The initial software assurance risk assessment should be performed concurrent with the discussion of solution alternatives. If a solution alternative includes open source or COTS, risks are different than developing software internally or acquiring the development of software by contract. Heads of U.S. Federal agencies are required by FAR Subpart 7.103 (u) to comply with NIST guidance and standards. The guidance and standards include NIST special publications and Federal Information Processing Standards (FIPS). The U.S. Department of Commerce, National Institute of Standards and Technology, Special Publication (NIST SP 800-30), Risk Management Guide for Information Technology Systems, provides guidance on performing risk management throughout the systems [software] development life cycle, The risk management guide provides a risk assessment method that is intended to be an essential management function of an organization. The risk management process starts with system characterization (e.g., defining the scope of the effort, identifying system-related information, describing the processing environment). System characterization should clearly describe the software aspects of the systems and the software processing environment. The next steps include threat12 identification and vulnerability13 identification. Very specific software threats and software vulnerabilities should be identified at this point. To facilitate the threat and vulnerability identification, Appendix C of this document includes a Due Diligence Questionnaire that can be used. Although these questions are intended to be asked of potential suppliers, the acquisition manager can use a subset of these questions to think through threats and vulnerabilities. The questions that are used may only be 11 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 12 13 Risk is a function of the likelihood of a given threat-source‘s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization (NIST SP 800-30, page 8) Threat is defined as the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability (NIST SP 800-30, para 3.2). Vulnerability is defined as a flaw or weakness in system security procedures that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system‘s security policy (NIST SP 800-30, para 3.3). 8 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Section 4. Initiation and Planning answered in general terms, but such answers should provide a sense of the threat and vulnerability environment. The questionnaire is divided into eight sections: Organization Background; Software Production Policies; Software Pedigree; Assurance; Preventive Measures; Quality Control; Operations and Support; and Service Governance. Each of these eight sections includes an ―Approach‖ paragraph that discusses areas of potential risks. In addition, each section includes a Risk Factor Worksheet to facilitate the documentation of potential risks. An initial software assurance risk assessment can be done by selecting the appropriate areas of potential risk for each viable solution alternative and documenting the risks using the Risk Factor Worksheet. The following are examples: If the acquisition includes COTS, foreign interests might be a concern. Section 2.1 addresses the organization background of the supplier. Paragraph 2.1.3 contains the areas of risks regarding foreign ownership and interests, organization history, software security ―track history,‖ and financial viability and stability. Paragraph 2.1.5 contains a set of questions and paragraph 2.1.6 provides a Risk Factor Worksheet to facilitate the documentation of potential risks. If the processing environment requires a medium or higher level of software assurance, questions regarding the software environment may be important. Section 2.4 addresses software assurance approach of the supplier. The next step is control analysis. This includes an analysis of the management, operational and technical safeguards or countermeasures necessary to protect the confidentiality, integrity and availability of a system and its data that have been implemented or are planned to minimize the likelihood (or probability) of a threat‘s exercising a system vulnerability14. These include preventive and detective security controls. This is followed by a likelihood rating that indicates the ―probability that a potential vulnerability may be exercised within the construct of the associated threat environment.‖ [NIST SP 800-30] The NIST SP 800-30 provides three levels: high, medium, and low likelihoods. The next step is an impact analysis to determine the adverse impact resulting from a successful threat exercise. The impact of a security event is described in terms of three security goals: integrity, availability, and confidentiality. The FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, provides the standard for categorizing information and information systems in terms of integrity, availability, and confidentiality15. The FIPS Publication provides examples expressed in terms on impact on organizations and individuals. The Department of Defense‘s (DoD) method defines three mission assurance categories that reflect the importance of information relative to the achievement of mission goals and objectives [DoD Instruction 8500.2,para E2.1.38 and Enclosure 4]. Integrity and availability levels are determined by these categories. The DoD also has several levels of sensitivity classifications for information including – unclassified, confidential, secret, top secret, and SCI [DoDI S3600.2]. Confidentiality levels are determined by these classifications [DoDI 8500.2, para E4.1.1]. 14 15 NIST SP 800-30, section 3.4. Title III of the E-Government Act, entitled the Federal Information Security Management Act of 2002 (FISMA) required NIST to set such a standard to be applicable for all Federal information and information systems (some exceptions apply). 9 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Section 4. Initiation and Planning Solution Alternatives. These include acquisition of open source software; purchase COTS software; develop the software internally; acquire the development of software by contract; enhance existing software; modify legacy software; or any combination of these options. After examination of the risks identified and assessed in the initial software assurance risk assessment, the acquisition manager can select the alternative(s) that support the level of risk acceptable to the acquiring organization. Initial Software and SwA Requirements. The initial SwA risk considerations provides the foundation for the software assurance requirements. The FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems, is a mandatory security standard required by FISMA legislation specified minimum security requirements associated with security categorization completed during impact analysis. The standard requires the implementation of security controls identified in NIST SP 800-53, Recommended Security Controls for Federal Information Systems. Although the NIST SP 800-53 falls a bit short in identifying software assurance requirements, the standard (in conjunction with Appendix C, Due Diligence Questionnaire) can be used to derive such requirements. Responsibilities for SwA. This is the time to obtain management buy-in on software assurance as an acceptable expense in the acquisition of software. Although exact cost of software assurance is difficult to estimate and depends on the extent of trustworthiness that the organization needs, the acquisition manager can present the conceptual costs by laying out the dangers of ignoring the need for trustworthy software. At the very least and at the very beginning of any project, an individual or individuals in the organization should be trained to oversee and execute SwA responsibilities throughout the life cycle. Additional Note: In the operational realm where software vulnerabilities are exploited, software vulnerabilities derive from two primary but distinctly different sources: (1) software defects, and (2) improper or inadequate use of the security technical (configuration) controls built into the software—at the operating system, middleware, and application software layers. This is important from a management and accountability perspective as to by whom and how software defect patches and updates are managed, and by whom and how configuration control settings are managed, from the initial default state through the entire operational life of the software. Contract Type. Contract types are selected based on the level of financial and performance risk associated with the type and complexity of requirements. Also see FAR 16.104 for additional factors in determining contract type. The initial software assurance risk assessment can facilitate the decision on contract type. As an example, let us say that the risk assessment concluded that the capability must include only ―high assurance‖ software. The financial risk of providing this capability under a fixed price contract might motive a supplier to propose a price that is unaffordable. Selecting a cost reimbursement contract would reduce the supplier‘s financial risk and increase the acquirer‘s financial risk. However, the predicted final cost would be affordable. Acquisition Strategy and/or Plan. The US Federal government requires an acquisition strategy and/or plan for all acquisitions. See FAR Part 7: Acquisition Planning. In particular, FAR 7.105(b)(17) requires that plans discuss how agency information security requirements are to be met. This would include the software assurance strategies resulting from the initial software assurance risk assessment and requirements definition. 10 Software Security Acquisition Guide Section 5. Contracting 1 5. Contracting16 Introduction. Assuming that a decision to contract was made, the acquisition manager should use the outputs of the Initiation and Planning process as inputs into the Contracting process. This process includes the Preparation of the Request for Proposals that contains the Work Statement and Terms and Conditions. The Work Statement should include the initial software and SwA requirements. In addition, this is the time in which the supplier will prepare a response to the Request for Proposals. It is important that instructions to suppliers are clear and unambiguous regarding what they are to submit in their proposals. The acquisition manager should not only ask for documentation that provides evidence of their ability to delivery on SwA requirements but also provide evidence about their affiliations with foreign interests. The acquisition manager can use a questionnaire to elicit the appropriate evidence. Appendix C includes a Due Diligence Questionnaire with instructions on when and how to use each question. This should be supplemented with requests for addition evidence as appropriate. Lastly, during this stage Source Selection and Contract Negotiation and Finalization is accomplished as well. The acquisition manager and team of experts evaluate the evidence that is submitted by the supplier to determine the supplier that can best provide the services. This section includes SwA considerations when: Request for Proposals Work Statements Terms and Conditions Instructions to Suppliers Certifications 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Preparation of Response—supplier Source Selection Contract Negotiation and Finalization Request for Proposals. Acquisition managers should include appropriate SwA requirements in the work statement, appropriate SwA language in terms and conditions, and clear instructions to suppliers on what to submit that provides clear evidence that the SwA requirements will be met. Work Statements. Appendix A contains sample software assurance language for a work statement. The Due Diligence Questionnaire at Appendix C also contains ideas for expressing requirements. In addition, The areas under the ―Approach‖ paragraphs may be used to formulate requirements, or alternatively, security terms and conditions. The acquisition manager should consider including the following software assurance requirements in a work statement: Definitions related to trustworthy software that provides a common understanding. A description of the security category [see FIPS PUB 199 and DoDI 8500.2] that provides a common framework and understanding of security needs. This security category can be derived from the initial software assurance risk assessment. Based on the security category, the minimum security objective and requirements [see FIPS PUB 200 and NIST SP 800-53]. Some of the following should be considered: 16 Examples and/or references to SCADA will be included in subsequent drafts. 11 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Section 5. Contracting - Input validation and encoding Authentication and session management Access control Error handling Logging Connections to external systems Encryption Availability Secure configuration Specific vulnerabilities Software Assurance Case that addresses the required security requirements (functions and properties) and the arguments and evidence that the requirements are met. This includes compliance in all relevant laws, regulations, standards, and other legal or societal requirements; adherence to the organizational and system security policies; and satisfaction of all security objectives. An assurance case should present a convincing argument that the software will operate in an acceptably secure manner. The case should present definitive evidence, supported by process, procedure, and analysis, that a system and its software will be acceptably secure throughout its life cycle, including termination. The case should demonstrate that within the totality of the environment in which the software will operate, any problems created by the software itself failing to operate as required, have been identified and assessed and that any necessary amelioration has been made. The case should be modified as development progresses, and knowledge of the system and its software increases. All the lifecycle activities, resources, and products, which contribute to or are affected by the security of the software, also need to be covered by the case. [SwA CBK] Software Assurance Plan may include the following [SwA CBK]: - Plan Purpose and Scope. - Software Systems Identification and Description. - Software Assurance Manager: Name of person responsible for software assurance. - Software Staff Qualifications: Names, education, experience related to software development and software security. - Development Environment Description that enables the development of trustworthy software. - Software Security Risks and Mitigation: Identification of vulnerabilities and risks associated with the development and deployment of software and the steps that will be taken to mitigate those risks. These include risks across the entire life cycle of the software. The initial software risk assessment provides the foundation for this section. - Software Assurance Case Management: Include a discussion on the contents of the case, how the case will evolve and be managed throughout the software development life cycle, configuration management of the case, verification, validation, and evaluation of software security. - Software Assurance Life Cycle: Include software assurance tasks, products, and documentation/records by phase. - Security Reviews. - Security Issue Management. - Software Requirements and Traceability: Include a discussion on traceability management to include protection of the software. 12 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Section 5. Contracting - Tool Support (special or unique software assurance modeling and simulation). - Subcontract Management (special or unique software assurance requirements). - Process and Product Certification. Software Assurance Risk Management Plan that includes a formal program for risk management. Risk management would include case management. Consideration for auditing the code by an independent body to determine the security posture of the code. Software Description that includes a Software Architecture and such other description as needed to provide a structure for the assurance case. The Software Architecture includes an initial description of the software components and connector including software security related aspects. A security test plan that defines the approach for testing each of the security requirements. Configuration guidelines for all security configuration options.  COTS software  Infrastructure software  Applications software  Custom-written software  Systems integration/customized software  Outsourcing (software components)  Platform outsourcing/hosting  Business process outsourcing [INPUT 2006] Terms and Conditions. Some items described in the work statement above may be more appropriate as terms and conditions. Whether to include an item in the work statement or as a term or condition is dependent on the policies and structure of the acquisition organization. Selection of terms and conditions would depend on the type of software acquired. Because prime suppliers often subcontract software services, terms and conditions should be worded in such a way to ensure that they flow down to all levels of subcontracts. Terms and conditions include, but are not exclusive to: Legal responsibilities of supplier and acquirer relative to software assurance. Quality of software development processes. Software assurance acceptance criteria. Qualifications and training of software personnel and identification of key security personnel. Software assurance training program. Required information relative to foreign ownership, control or influence. Required preset security features. The Due Diligence Questionnaire in Appendix C also contains ideas for appropriate terms and conditions. The areas under the ―Approach‖ paragraphs may be used to formulate terms and conditions, or alternatively, security requirements that might be included in a work statement. In addition to the sample language found in Appendix A, the following are a few more examples: The following is sample language regarding implementing security controls and standards for U. S. Federal Information and National Security Systems. 13 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Section 5. Contracting Security Controls and Standards (a) When mitigating or remediating risks to confidentiality, integrity, and availability of Federal Information, National Security Systems, and Contractor assets that enable possession, control, or otherwise enable access to Federal Information or National Security Systems, the Contractor shall implement controls and standards as effective or more effective than those implemented by the Agency for the same or substantially similar risks with the same or substantially similar potential measure of harm. (b) When selecting appropriate controls and standards for protecting confidentiality, integrity, and availability of Federal Information and National Security Systems, the Contractor shall use the analyses, processes and standards established for Federal Government systems established by the [current agency and other applicable standards] publications. The following is an example of a particular term/condition regarding the security of commercial software. [This is work that is currently in progress by the US Chief Information Officer‘s Council to be incorporated into the US Federal Acquisition Regulation.] Securely configuring commercial software (c) In the performance of this contract, any commercial off the shelf (COTS) software delivered by [contractor] shall be configured in conformance with applicable system configuration requirements established by [acquirer] pursuant to [44 USC 3544 (b) (2) (D)] (iii) as enumerated in Exhibit [X]. (d) [Supplier] shall maintain such COTS software so as to assure that it conforms to the most current version of all applicable [acquirer] system configuration requirements throughout its operational life cycle. (e) For both custom and COTS software, with initial delivery and each subsequent release, [supplier] shall provide written assurance that the software operates satisfactorily on systems configured in accordance with section (a) above (f) Prior to acceptance of the software by [acquirer] [supplier] shall deliver a complete vulnerability test report of both system and application vulnerability of the application running on the operating system and platform proposed to be used in production prior to initial acceptance and for each subsequent software release. (g) Any exceptions to conformance with the [acquirer‘s] system configuration requirements must be approved in advance and in writing. The following are suggested as generic software security acceptance criteria to be tailored as appropriate. This is similar to the terms and conditions in paragraph B above. These would apply at delivery and throughout the software life cycle: (h) All operating system, middleware, and application software provided to Buyer shall be security configured by Supplier in accordance with the FAR requirement based on 44 USC 3544 (b) (2) (D) (iii), in order to ensure that available software security features are properly activated. (i) All application software shall be demonstrated by Supplier to be fully functional when residing on the operating system and middleware platforms used by Buyer in its production environment, configured as noted above. 14 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Section 5. Contracting (j) Software updates provided by Supplier will not change any configuration settings without specific permission of Buyer. (k) Supplier will provide Buyer with software tools with which Buyer can monitor software update and configuration status on a continuing basis. (l) At specified intervals, Supplier will provide Buyer with a comprehensive vulnerability test report for the suite of applications and associated operating system and middleware platforms used by Buyer in its production environment, configured as noted above. Instructions to Suppliers. The supplier should be required to submit information to provide evidence of their ability to perform the software assurance aspects of the statement of work and terms and conditions during the proposal process. This information is evaluated within the overall proposal evaluation process. The acquisition manager should provide instructions to the supplier on the kinds of information that needs to be submitted and how that information will be evaluated. Appendix A contains a sample of instructions of suppliers. Instructions to suppliers may include the following: Due Diligence Questionnaire. Explain fully the kinds of answers expected and the type of evidence that provides proof of the answers. An initial Software Assurance Case. An initial Software Assurance Plan. An initial Software Description. Certifications. The use of certifications provides an assertion by the supplier of existing conditions or compliance in certain requirements. The use of certifications shifts the burden of compliance to the supplier. See Appendix A for a sample certification or originality. The Due Diligence Questionnaires at Appendix C may also be used in identifying appropriate certifications. The following are other examples: The following may be considered for use in US Department of Defense contracts and may be appropriately modified for other uses. (m) Contractors must warrant that their products have been satisfactorily validated under common criteria or that products will be satisfactorily validated with the period of time specified in the contract and that such product validation will be maintained for updated versions or modifications by subsequent evaluation as required. (n) Contractors must also warrant that proposed product specifications and security and data access architectures have either been addressed in ongoing System Security Authorization Agreements (SSAA) and/or are ready for evaluation in applicable phases of the DITSCAP process, i.e., definition, verification, validation or post-accreditation, as required. Contractors must also address willingness to provide proposed equipment and engineering assistance as required, at no cost to the government, to the DOD specified testing facility to obtain required certification of functionality or ISS scans.‖ Another take with similar wording is as follows. (a) Contractors must warrant that their products have been satisfactorily validated under common criteria pursuant to DOD Directive 8500.1 and National Security Telecommunications and Information Systems Security Policy (NSTISSP) Number 11. Such product validation will be maintained for updated versions or modifications by subsequent evaluation as required. All information assurance 15 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Section 5. Contracting (IA) or IA-enabled information technology hardware, firmware, and software components/products will be seen as an essential enhancement in the area of security for purposes of evaluation and source selection. (b) If an approved U.S. Government protection profile exists for the MFD‘s represented by this RFQ, the contractor will be required to provide certification of common criteria validation specifying compliance at a minimum EAL level of 2. ―The United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria for Information Security Technology Evaluation Recognition Agreement (CCRA) for EAL 1-4 only.‖ (DoDI 8500.2) (c) In the absence of an approved U.S. Government protection profile for the MFD‘s represented by this RFQ, certification of common criteria validation is solely a validation of the contractor‘s security claims about its product. It is the contractor‘s responsibility to submit their products for evaluation and validation at a minimum EAL level of 2. (d) Should a DOD service site receive additional requirements or should a government-defined set of security functions be developed, contractors will be advised and appropriate action must be initiated within 90 days. The following provides reference to System Security Authorization Agreements (SSAA). (o) Contractors must warrant that proposed product specifications and security and data access architecture have either been addressed in ongoing System Security Authorization Agreements (SSAA) and/or are ready for evaluation in applicable phases of the DITSCAP process, i.e. definition, verification, validation or postaccreditation, as required. (p) At the discretion of the customer/end user, all components/products must be satisfactorily certified and fully accredited or have interim approval to operate by the DAA (Designated Approval Authority) under DITSCAP within 90 days of the contract award. If the products/components cannot obtain the full certification/accreditation within the 90-day period, the contractor will remove the equipment at no cost to the government and the contractor agrees to waive any early termination/cancellation fees. Evaluation Factors for Award. Acquisition managers should consider one or more factors addressing software assurance. The factor can be either a quantitative or qualitative factor. In addition, a ―go/no-go‖ factor should be considered. Appendix C, Due Diligence Questionnaire can be used in establishing a ―go/no-go‖ factor. To do this, key questions must be carefully selected and modified to suit the particular acquisition. Acquisition managers must be very careful not to select and modify the questions that can easily be answered by suppliers and provide value to the acquisition decision. The primary objective is to determine whether the supplier‘s software environment is acceptable from the standpoint of security risks. 16 Software Security Acquisition Guide Section 6. Implementation and Acceptance 1 6. Implementation and Acceptance Introduction. Acquisition managers must ensure that all the software assurance requirements are adequately implemented. The Implementation phase includes project management, software assurance planning, software risk management, assurance case management, and acceptance of the software product or service. Project/Contract Management. Project and contract managers must rely on software assurance experts to ensure that the software assurance requirements are implemented appropriately. See the discussion in the Initiation and Planning, SwA Responsibilities section. Software Assurance Plan. Software assurance experts ensure that the implementation is in accordance with the Software Assurance Plan. See the discussion in the Contracting, Work Statement section. Software Risk Management. Software risks are monitored in accordance with the Software Risk Management Plan. Assurance Case Management. A Software Assurance Case is a reasoned, auditable argument created to support the contention that the defined software will satisfy software security requirements and objectives. See the discussion in the Contracting, Work Statement section. Software Assurance Acceptance Criteria. Acceptance criteria may be included in a term or condition or as part of the assurance case. See the Contracting section, Terms and Conditions. Also see Appendix C, Due Diligence Checklist (Generic), Quality Control section. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 17 Software Assurance Acquisition Guide Section 7. Sustainment 1 7. Sustainment Introduction. Sustainment is the logistics tail in the acquisition of software. Most software endures years of sustainment. Therefore, it is important not to compromise software assurance during this phase and appropriately manage the change in security requirements. Therefore, change control, software risk management, and assurance case management must continue. Care should be taken to enforce terms and conditions in the contract that apply to the life of the product of service, such as the example in the Contracting section (―Securely configuring commercial software. Also see Appendix C, Due Diligence Checklist (Generic), Operations and Support section. Change Control. Change must be managed to ensure that the software security functions are maintained at the appropriate level of acceptable risk. Software Risk Management. Implementation does not end the need to continue to manage software risk. The Software Risk Management Plan used to manage risk during the Contracting phase should continue to be used and updated. Assurance Case Management. Just as software risk management continues during Sustainment, the software assurance case must be maintained and updated. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 18 Software Security Acquisition Guide 1 Appendix A. Sample Language Appendix A. Sample Language Introduction This appendix contains four examples of language that can be tailored to include in a work statement, instructions to supplier, a commercial contract annex, and a certification of originality. 2 3 4 5 6 7 8 9 10 11 12 13 Using the Sample Language This language is guidance only. Each sample is self-contained. The user should use parts from one or more of the samples and add additional language to tailor a work statement, terms and conditions, and/or certifications that fit their particular acquisition and contract. If language is changed, the changes and overall context should be reviewed by contracting officers and legal counsel. All things being equal, agencies are encouraged to use the standard language. This will enable responding vendors to reuse their responses, reducing the administrative burden on them and producing higher quality information. 19 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix A. Sample Language Sample Work Statement 1.0 Trustworthy Software 1.1 Key definitions: 1.1.1 ―Trustworthy software‖ means ―highly secure software realizing – with justifiably high confidence but not guaranteeing absolutely – a substantial set of explicit security properties and functionality including all those required for its intended usage.‖ [Redwine 2004, p. 2] One can also state this in a negative way as ―justifiably high confidence that no software-based vulnerabilities exist that the system is not designed to tolerate.‖ that incorporates the appropriate software security controls for a software intensive system‘s security category in order to meet software security objectives. 1.1.2 ―Software security controls‖ mean the management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for a software information system to protect the confidentiality, integrity, and availability of the system and its information. 1.1.3 ―Security category‖ means the characterization of information or an information system based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability of such information or information system would have on organizational operations, organizational assets, or individuals. 1.1.4 ―Software security objectives‖ confidentiality, integrity, availability, authenticity, accountability, and non-repudiation. 1.1.5 ―Software assurance case‖ means a reasoned, auditable argument created to support the contention that the defined software intensive system will satisfy software security requirements and objectives. 1.1.6 Include other appropriate definitions--1.2 Security Category [NOTE: This is an example, also see FIPS Publication 199 and DoD Instr 8500.2, Enclosure 4.]: 1.1.7 This software system is used for large procurements in a contracting organization and contains both sensitive and proprietary supplier information and routine administrative information. For the sensitive supplier information the potential impact from a loss of confidentiality is moderate (e.g., the loss may result in a significant financial loss), the potential impact from a loss of integrity is moderate (e.g., the loss may result in the effectiveness of the contracting mission is significantly reduced and there is significant damage to the information asset), the potential impact from a loss of availability is low (e.g., the loss may result in downtime, but there is backup). For the routine administrative information, the potential impact from a loss of confidentiality is low, the impact from a loss of integrity is low, and the impact from a loss of availability is low. 1.1.8 Based on 2.1, the resulting security category of the software system is {(confidentiality, moderate), (integrity, moderate), (availability, low)} 1.3 Software Security Requirements. Based on the security category for the software system, the minimum security requirements specified in [NOTE: Reference the external document(s)] are required.] (NOTE: Minimum security controls may be specified in this paragraph or in an external document similar to FIPS Pub 200; NIST SP 800-53; and DoDI 8500.2, Enclosure 4] 20 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Appendix A. Sample Language 1.4 Software Assurance Case. The contractor shall refine the Software Assurance Case throughout the development process. This assurance case should be based on the software security requirements. The contractor shall submit the Case for review ----[NOTE: Specify when the Case should be reviewed, such as with the submission of the software design, etc.] Lastly the successful execution of the Software Assurance Case shall be a condition for final acceptance of the software. 1.5 Auditing the Code. The supplier shall have an independent verification and validate (V&V) performed on the code to determine the security posture of the code. This verification and validation shall be performed by a qualified [NOTE: specify what ―qualify‖ means] software assurance V&V entity. 1.6 Software Assurance Practices. The supplier shall use software assurance practices in accordance with [NOTE: either explain those practices or provide a reference document]. 1.7 Software Assurance Plan. The supplier shall refine, throughout the life cycle of this software development work, the Software Assurance Plan that was submitted with the supplier‘s proposal. The Software Assurance Plan shall be submitted to the acquirer [XX] days after each development milestone for review. [NOTE: Include how often this should be delivered. As a suggestion, the revisions to this plan should be submitted at key milestones. Such milestones might be: after requirements analysis, after software architectural design, after detailed software design, after coding and testing. [See ISO/IEC 12207, 5.3.] This plan shall include but not be limited to: [State what is to be included] 1.8 Software Assurance Risk Management. The supplier shall maintain a formal software assurance risk management program. Within [XX ] days of the award of the contract, the supplier shall deliver a Software Assurance Risk Management Plan to the acquirer for review. [NOTE: This could be a section in the Software Assurance Plan.]‖ [SwA CBK] 21 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix A. Sample Language Sample Instructions to Suppliers ―Instructions to Suppliers on Software Assurance 1.0 Foreign ownership, control or influence (FOCI) is a concern. For any software product that the supplier intends to acquire or develop, the supplier shall answer the following questions: 2.0 Due Diligence Questionnaire (words TBD) 3.0 Software Assurance Case 3.1 In order for the acquirer to evaluate the proposed software assurance capabilities, the offeror must submit an initial System Description and Software Assurance Case that address the required security properties and functionality and the arguments and evidence (existing or proposed) that the properties are preserved and all relevant laws, regulations, standards and other legal or societal requirements are met, the organizational and system security policies are adhered to, and security objectives are met for the software intensive system as specified in the statement of work and other characteristics as specified in paragraph 3.2 below. This initial Software Assurance Case will subsequently become a part of the contract and be used by the acquirer as an acceptance condition. 3.2 A software assurance case should present a convincing argument that the software intensive system will operate in an acceptably secure manner. The case should present definitive evidence, supported by process, procedure, and analysis, that a system and its software will be acceptably secure throughout its life cycle, including termination. [see Fundamentals section‘s subsection on Assurance Case for a list of kinds of evidence might explicitly call for here.]The case should demonstrate that within the totality of the environment in which the software will operate, any problems created by the software itself failing to operate as required, have been identified and assessed and that any necessary amelioration has been made. Subsequent to contract award, the contractor shall modify the case as development progresses, and knowledge of the system and its software increases. All the lifecycle activities, resources, and products, which contribute to or are affected by the security of the software, also need to be covered by the case. Similar to a risk analysis, the following questions are examples of what should be of interest, be examined, and be analyzed through the use of the software assurance case: a) How can a software security violations or failure occur? b) What might the causes and conditions of the security violation or failure be? c) What are the consequences of security violations or failure? d) What is the level of criticality of the consequences? e) How often is it likely that the security violation or failure will occur? Software assurance cases are likely to contain significant numbers of complex interdependencies that typically result from a wide range of related analyses. They often rest upon a number of explicit, as well as implicit, assumptions and can have a long history, going through multiple versions in the course of their production. Both product, process, and resource issues need to be addressed in the case; it must be shown both that the system meets its software assurance requirements and that the processes for deriving the requirements, constructing the system, and assessing the system are of appropriate depth, breadth, and integrity. The analyses crucially 22 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Appendix A. Sample Language depend upon the formulation of suitable models of the system, at various levels of abstraction, produced during the development process. Given these characteristics, it should be noted that software assurance cases are resource intensive to create and support. 4.0 Initial Software Assurance Plan. 4.1 The supplier shall submit an initial Software Assurance Plan. 4.2 The Plan shall include [NOTE: See the Contracting, Work Statement section for items to include in the plan/] 5.0 Initial Software Description 5.1 The supplier shall submit an initial Software Architecture and such other description as needed to provide a structure for the assurance case. The Software Architecture shall include an initial description of the software components and connector including software security related aspects. [NOTE: Include additional explanation.]‖ [SwA CBK] 23 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Appendix A. Sample Language Sample Contract Annex The following contract annex is a product of the Open Web Application Security Project (OWASP) Foundation. For the entire document go to: http://www.owasp.org/documentation/legal.html. ―CONTRACT ANNEX‖ This Annex is made to _____________________ ("Agreement") between Client and Developer. Client and Developer agree to maximize the security of the software according to the following terms. 1. PHILOSOPHY This Annex is intended to clarify the security-related rights and obligations of all the parties to a software development relationship. At the highest level, the parties agree that: (a) Security Decisions Will Be Based on Risk. Decisions about security will be made jointly by both Client and Developer based on a firm understanding of the risks involved. (b) Security Activities Will Be Balanced. Security effort will be roughly evenly distributed across the entire software development lifecycle. (c) Security Activities Will Be Integrated. All the activities and documentation discussed herein can and should be integrated into the Developer's software development lifecycle and not kept separate from the rest of the project. Nothing in this Annex implies any particular software development process. (d) Vulnerabilities Are Expected. All software has bugs, and some of those will create security issues. Both Client and Developer will strive to identify vulnerabilities as early as possible in the lifecycle. (e) Security Information Will Be Fully Disclosed. All security-relevant information will be shared between Client and Developer immediately and completely. (f) Only Useful Security Documentation Is Required. Security documentation does not need to be extensive in order to clearly describe security design, risk analysis, or issues. 2. LIFECYCLE ACTIVITIES (a) Risk Understanding. Developer and Client agree to work together to understand and document the risks facing the application. This effort should identify the key risks to the important assets and functions provided by the application. Each of the topics listed in the requirements section should be considered. (b) Requirements. Based on the risks, Developer and Client agree to work together to create detailed security requirements as a part of the specification of the software to be developed. Each of the topics listed in the requirements section of this Annex should be discussed and evaluated by both Developer and Client. These requirements may be satisfied by custom software, third party software, or the platform. (c) Design. Developer agrees to provide documentation that clearly explains the design for achieving each of the security requirements. In most cases, this documentation will describe security mechanisms, where the mechanisms fit into the architecture, and all relevant design patterns to ensure their proper use. The design should clearly specify whether the support comes from custom software, third party software, or the platform. 24 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix A. Sample Language (d) Implementation. Developer agrees to provide and follow a set of secure coding guidelines. These guidelines will indicate how code should be formatted, structured, and commented. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for unit test. (e) Security Analysis and Testing. Developer agrees to provide and follow a security test plan that defines an approach for testing or otherwise establishing that each of the security requirements has been met. The level of rigor of this activity should be considered and detailed in the plan. Developer will execute the security test plan and provide the test results to Client. (f) Secure Deployment. Developer agrees to provide secure configuration guidelines that fully describe all security relevant configuration options and their implications for the overall security of the software. The guideline shall include a full description of dependencies on the supporting platform, including operating system, web server, and application server, and how they should be configured for security. The default configuration of the software shall be secure. 3. SECURITY REQUIREMENT AREAS The following topic areas must be considered during the risk understanding and requirements definition activities. This effort should produce a set of specific, tailored, and testable requirements Both Developer and Client should be involved in this process and must agree on the final set of requirements. (a) Input Validation and Encoding. The requirements shall specify the rules for canonicalizing, validating, and encoding each input to the application, whether from users, file systems, databases, directories, or external systems. The default rule shall be that all input is invalid unless it matches a detailed specification of what is allowed. In addition, the requirements shall specify the action to be taken when invalid input is received. Specifically, the application shall not be susceptible to injection, overflow, tampering, or other corrupt input attacks. (b) Authentication and Session Management. The requirements shall specify how authentication credentials and session identifiers will be protected throughout their lifecycle. Requirements for all related functions, including forgotten passwords, changing passwords, remembering passwords, logout, and multiple logins, shall be included. (c) Access Control. The requirements shall include a detailed description of all roles (groups, privileges, authorizations) used in the application. The requirements shall also indicate all the assets and functions provided by the application. The requirements shall fully specify the exact access rights to each asset and function for each role. An access control matrix is the suggested format for these rules. (d) Error Handling. The requirements shall detail how errors occurring during processing will be handled. Some applications should provide best effort results in the event of an error, whereas others should terminate processing immediately. (e) Logging. The requirements shall specify what events are security-relevant and need to be logged, such as detected attacks, failed login attempts, and attempts to exceed authorization. The requirements shall also specify what information to log with each event, including time and date, event description, application details, and other information useful in forensic efforts. 25 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Appendix A. Sample Language (f) Connections to External Systems. The requirements shall specify how authentication and encryption will be handled for all external systems, such as databases, directories, and web services. All credentials required for communication with external systems shall be stored outside the code in a configuration file in encrypted form. (g) Encryption. The requirements shall specify what data must be encrypted, how it is to be encrypted, and how all certificates and other credentials must be handled. The application shall use a standard algorithm implemented in a widely used and tested encryption library. (h) Availability. The requirements shall specify how it will protect against denial of service attacks. All likely attacks on the application should be considered, including authentication lockout, connection exhaustion, and other resource exhaustion attacks. (i) Secure Configuration. The requirements shall specify that the default values for all security relevant configuration options shall be secure. For audit purposes, the software should be able to produce an easily readable report showing all the security relevant configuration details. (j) Specific Vulnerabilities. The requirements shall include a set of specific vulnerabilities that shall not be found in the software. If not otherwise specified, then the software shall not include any of the flaws described in the current "OWASP Top Ten Most Critical Web Application Vulnerabilities." 4. PERSONNEL AND ORGANIZATION (a) Security Architect. Developer will assign responsibility for security to a single senior technical resource, to be known as the project Security Architect. The Security Architect will certify the security of each deliverable. (b) Security Training. Developer will be responsible for verifying that all members of the developer team have been trained in secure programming techniques. (c) Trustworthy Developers. Developer agrees to perform appropriate background investigation of all development team members. 5. DEVELOPMENT ENVIRONMENT (a) Configuration Management. Developer shall use a source code control system that authenticates and logs the team member associated with all changes to the software baseline and all related configuration and build files. (b) Distribution. Developer shall use a build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the software delivered to Client. 6. LIBRARIES, FRAMEWORKS, AND PRODUCTS (a) Disclosure. The Developer shall disclose all third party software used in the software, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source. (b) Evaluation. The Developer shall make reasonable efforts to ensure that third party software meets all the terms of this agreement and is as secure as custom developed code developed under this agreement. 26 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Appendix A. Sample Language 7. SECURITY REVIEWS (a) Right to Review. Client has the right to have the software reviewed for security flaws at their expense at any time within 60 days of delivery. Developer agrees to provide reasonable support to the review team by providing source code and access to test environments. (b) Review Coverage. Security reviews shall cover all aspects of the software delivered, including custom code, components, products, and system configuration. (c) Scope of Review. At a minimum, the review shall cover all of the security requirements and should search for other common vulnerabilities. The review may include a combination of vulnerability scanning, penetration testing, static analysis of the source code, and expert code review. (d) Issues Discovered. Security issues uncovered will be reported to both Client and Developer. All issues will be tracked and remediated as specified in the Security Issue Tracking section of this Annex. 8. SECURITY ISSUE MANAGEMENT (a) Identification. Developer will track all security issues uncovered during the entire lifecycle, whether a requirements, design, implementation, testing, deployment, or operational issue. The risk associated with each security issue will be evaluated, documented, and reported to Client as soon as possible after discovery. (b) Protection. Developer will appropriately protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in operational Client software are exposed. (c) Remediation. Security issues that are identified before delivery shall be fixed by Developer. Security issues discovered after delivery shall be handled in the same manner as other bugs and issues as specified in this Agreement. 9. ASSURANCE (a) Assurance. Developer will provide a "certification package" consisting of the security documentation created throughout the development process. The package should establish that the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately. (b) Self-Certification. The Security Architect will certify that the software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery. (c) No Malicious Code. Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code. 10. SECURITY ACCEPTANCE AND MAINTENANCE (a) Acceptance. The software shall not be considered accepted until the certification package is complete and all security issues have been resolved. 27 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 Appendix A. Sample Language (b) Investigating Security Issues. After acceptance, if security issues are discovered or reasonably suspected, Developer shall assist Client in performing an investigation to determine the nature of the issue. The issue shall be considered "novel" if it is not covered by the security requirements and is outside the reasonable scope of security testing. (c) Novel Security Issues. Developer and Client agree to scope the effort required to resolve novel security issues, and to negotiate in good faith to achieve an agreement to perform the required work to address them. (d) Other Security Issues. Developer shall use all commercially reasonable efforts consistent with sound software development practices, taking into account the severity of the risk, to resolve all security issues not considered novel as quickly as possible.‖ [OWASPSSDC] 28 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Appendix A. Sample Language Sample Certification of Originality The following is an IBM example on how certifications can be used [IBM CO]. ―Certificate of Originality This questionnaire must be completed by a vendor (―You‖) furnishing copyrightable material, such as software, audio/visual works, written materials, etc. (―Material‖) to IBM. The acceptance of this questionnaire by IBM is a prerequisite for the IBM final payment for the furnished Material. Depending on Your agreement with IBM, You may have an obligation to communicate additional information to IBM that IBM may require for copyright registration and/or enforcement of legal rights relating to the furnished material. Please leave no questions blank. Write "not applicable" or "N/A" if a question is not relevant to the furnished material. Summary Information Your name and address: Name of the Material: IBM Contract No: IBM Contract Administrator: A -Material Identification 1. Category of the material (Please check only one): a) Software (including its related documentation) b) Audiovisual Works c) Mask Works d) Written Materials excluding related documentation of a)-c) e) Other (if other please identify) If You selected either "Software" or "Audio/Visual Works", please provide the names of any software tools (e.g. compiler, software development tool, etc.) that were used to create such Material: 2. General description of the Material (including the description of any new function that You contributed): 3. What was the date that the creation of Material was completed? (except for minor error corrections, etc.): B - Newly Created Material The questions in this section are targeted at any newly created portion of the Material (―Newly Created Material‖). If the Material includes any pre-existing material, please provide detailed information for such pre-existing material in section C (Pre-existing Material). All developers or creators of the Newly Created Material must be specified in one of the following Categories I, II or III. Unless otherwise indicated, Your employees include 29 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Appendix A. Sample Language temporary and supplemental employees who created or contributed to the creation of the Material under contract or other agreement with You. I. Was any portion of the Newly Created Material created by Your employee(s) within the scope of their work assignment or job function ("Category I") assignment? Yes No If You checked Yes please provide a copy of any relevant employee agreement governing the creation of intellectual property for Your company by the employee and provide below the requested information for each employee. It is not necessary to provide copies of the agreements actually signed by each employee as long as you provide the terms of each agreement. For example, it would be sufficient to provide blank employee agreement forms of the type actually completed by the employee. Name of employee: Title: Name of employee: Title: Name of employee: Title: (If there is insufficient space to list all contributors, please attach an additional page with the required information). II. Was any portion of the Newly Created Material created by Your employee(s) outside the scope of their work assignment or job function ("Category II")? Yes No If You checked Yes please provide a copy of any relevant employee agreement governing the creation of intellectual property for Your company by the employee and provide below the requested information for each employee. It is not necessary to provide copies of the agreements actually signed by each employee as long as you provide the terms of each agreement. For example, it would be sufficient to provide blank employee agreement forms of the type actually completed by the employee. Name of employee: Title: Name of employee: Title: Name of employee: Title: (If there is insufficient space to list all contributors, please attach an additional page with the required information). III. Was any portion of the Newly Created Material created for You by anyone other than Your employees, including another vendor company, an independent contractor, a subcontractor, a consortium or university ("Category III")? Yes No If You checked Yes please provide a copy of any relevant agreement that you may have governing the creation and/or license of the intellectual property for this Material and the names and title of the individuals who contributed the material. If the third party was a company, please provide the name and address for the company. 30 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Appendix A. Sample Language Name of employee: Title: Name of employee: Title: Name of employee: Title: (If there is insufficient space to list all contributors, please attach an additional page with the required information). 1. Does any portion of the Newly Created Material link to any libraries or other software that is characterized as freeware, shareware or open source software (―OSS Material‖). For the purposes of this Certificate of Originality, open source software is computer software programs whose source code is available for inspection and use by anyone and is made available under a license that permits recipients to copy, modify and distribute the program‘s source code without payment of royalty. Common examples of such licenses, include, but are not limited to, the GNU GPL and LGPL licenses, the Mozilla Public License, Apache license, BSD License, MIT License, Common Public License, etc.? Yes No If you checked No, please go to section C. If you checked Yes please, provide the following OSS Material information. Is the linking static or dynamic? OSS Material Name: Source of the OSS Material (e.g. a URL, company address, etc.): License Information (please attach a copy of the license): Any information that would be helpful to identify the ownership of the OSS Material (e.g., Copyright notice, author‘s name, contact information, etc.): C -Pre-existing Material The target of this section is any material that had been created by You or others, before you entered into an agreement with IBM to create the Material ("Pre-existing Material"). Preexisting Material includes, but is not limited to, software, software libraries, textbooks, and publications that were used in the creation of the Material provided by You to IBM. 1. Was any portion of the Material composed of or derived from Pre-existing Material? Yes No static dynamic If you checked No go to section D. 2. Is any portion of the Pre-existing Material owned by You? Yes No If you checked Yes please provide the name of the Pre-existing Material 31 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Appendix A. Sample Language 3. Is any portion of the Pre-existing Material owned by a third party (excluding OSS Material)? Yes No If you checked Yes please provide the following information: Name of Pre-existing Material: Source of the Pre-existing Material (e.g. a URL, company address, etc): License Information (please attach a copy of the license): Any information that would be helpful to identify the source and ownership of the material (e.g. Copyright notice, author‘s name, contact information, etc.): Have You modified the third party Pre-existing Material? Yes No If you checked Yes, please briefly describe the nature of the modifications 4. Is any portion of the Pre-existing Material OSS Material? If you checked Yes please provide the following information: Name of Pre-existing Material: Source of the Pre-existing Material (e.g. a URL, company address, etc): License Information (please attach a copy of the license): Any information that would be helpful to identify the source and ownership of the material (e.g. Copyright notice, author‘s name, contact information, etc.): Have You modified the third party OSS Material? Yes No Yes No If you checked Yes, please briefly describe the nature of the modifications 5. Does any portion of the Pre-existing Material link to any OSS Material, including, for example, by using an OSS Material source software development kit? Yes No If you checked Yes please, provide the following OSS Material information. Is the linking static or dynamic? OSS Material Name: Source of the OSS Material (e.g. a URL, company address, etc): License Information (please attach a copy of the license): Any information that would be helpful to identify the source and ownership of the material (e.g. Copyright notice, author‘s name, contact information, etc.): D -External Characteristics including Icons (―External Characteristics‖ include display screens, data formats, instruction or command formats, operator messages, interfaces, images video, sound recordings, icons, etc.) static dynamic 32 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Appendix A. Sample Language Were the "External Characteristics" of the Material or any portion thereof copied or derived from the pre-existing "external characteristics" of other software or copyrightable material ("Pre-existing Externals")? Yes No If You checked No go to section E. If You checked Yes please provide the following information: a) Type of External Characteristic: b) Name of the External Characteristic: c) Source of the External Characteristic: d) Author (if known): e) Owner: f) License information (if applicable): g) Please identify or describe any pre-existing External Characteristics are known to you that are similar in appearance to the External Characteristic(s) that you are providing in the Material. E -Miscellaneous 1. Does the Material conform to any particular technology standards? Yes No If You checked yes please identify the name of such standard and standard body. Name of Standard: Standards body: 2. Identify below, or in an attachment, any other circumstance which might affect IBM's ability to reproduce and market this material, including: a) Confidentiality or trade secrecy of Pre-existing Materials included in the Material: b) Known or possible royalty obligations to others arising out of the Material: c) Other circumstances: Certification By submitting this form, You acknowledge that you have responsibility for and direct knowledge of, development or creation of this Material and hereby certify that: a) All statements made in this form are true; b) This Material does not contain any materials copied or derived from other code, designs, document or other materials, except as listed herein; and c) All newly written parts of this material are original work of Your employees and/or third party under contract as specified herein. 33 Software Security Acquisition Guide 1 2 3 4 5 6 7 Appendix A. Sample Language Yes, I certify to the above statements Signature Name: Title: Date: [IBM CO] 34 Software Security Acquisition Guide 1 Appendix B. Source Code Review Appendix B. Source Code Review General Overview: U.S. Government Executive Branch Information Assurance (IA) Acquisition Policies and Source Code Requirements February 21, 2006 Generally speaking, U.S. Government (USG) executive branch agencies (see Attachment A for list of these agencies) require source code review in government information security and information assurance (IA) procurement only in certain select cases. Please see below. Non-national security versus national security computer systems: USG executive branch agency computer systems are categorized by a legal definition (see Attachment B) as either national security or non-national security systems. This categorization is not by agency, but by computer system. Even a ―national security‖-related agency, such as the U.S. Department of Defense (DOD) or the Department of Homeland Security (DHS), will have both national security and non-national security computer systems. The level of security for each type of system is distinct. NON-NATIONAL SECURITY COMPUTER SYSTEMS: The vast majority of USG computer systems fall into this category. NIST standards and guidelines: The Federal Information Security Management Act (FISMA) of 2002 mandates that executive branch agencies that handle sensitive but nonclassified materials must use computer security standards and guidelines developed by the National Institute of Standards and Technology (NIST). NIST‘s Computer Security Division creates and disseminates these standards and guidelines, using extensive private-sector input, such as via public comment procedures. NIST‘s standards for federal computer systems are called Federal Information Processing Standards Publications (FIPS PUBS), and the guidelines are the Special Publication 800 (SP-800) series. NIST‘s standards and guidelines for federal government computer security are found here: http://csrc.nist.gov/publications/index.html Source code is almost never required to meet these NIST standards and guidelines, with one specific exception for cryptographic modules, FIPS-140-2. NIST‘s FIPS 140-2, ―Security Requirements for Cryptographic Modules,‖ is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. Cryptographic commercial-off-the-shelf (COTS) products used by the USG must be validated to FIPS 140-2 by the NIST Cryptographic Module Validation Program (CMVP). All of the tests under the CMVP are handled by third-party laboratories that are accredited as Cryptographic Module Testing (CMT) laboratories by the National Voluntary Laboratory Accreditation Program (NVLAP). All FIPS 140-2 testing that is performed by a testing laboratory includes review of any and all source code that is part of the cryptographic module. However, the code is provided only to the laboratory (not to NIST) under a non-disclosure agreement. NIST would only have access to see source code if the CMVP specifically requested such code during the validation review of the test results provided by the laboratory (during a validation review, the CMVP may request more details). NIST‘s access to source code in such an instance would also be bound by the same 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 35 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Appendix B. Source Code Review non-disclosure through the NVLAP. Further, the modules are generally small enough to make code examination feasible. CMVP assumes that once a module has been validated, that very same moduleunchanged/not tampered with) is in every product the vendor sells, and therefore there is no need to test specific purchases (i.e., the vendor is trusted to put the approved/tested module in every product without modification). Information on the CMVP is found here: http://csrc.nist.gov/cryptval/ Federal Acquisition Regulation (FAR): The FAR, which complements FISMA, governs USG non-national security procurement contracts. With a few exceptions, the majority of USG executive branch agencies are bound by, and must purchase in accordance with, the FAR. FAR section 12.212 applies to purchases of COTS computer software, and mandates that USG agencies, when purchasing such software, must accept the commercial license or enduser-licensing agreement. This section is copied below: 12.212 Computer software. (a) Commercial computer software or commercial computer software documentation shall be acquired under licenses customarily provided to the public to the extent such licenses are consistent with Federal law and otherwise satisfy the Government’s needs. Generally, offerors and contractors shall not be required to— (1) Furnish technical information related to commercial computer software or commercial computer software documentation that is not customarily provided to the public; or (2) Relinquish to, or otherwise provide, the Government rights to use, modify, reproduce, release, perform, display, or disclose commercial computer software or commercial computer software documentation except as mutually agreed to by the parties. (b) With regard to commercial computer software and commercial computer software documentation, the Government shall have only those rights specified in the license contained in any addendum to the contract. In item (1) above, source code is considered to be an example of ―technical information‖ that offerors and contractors are not required to furnish. General information on the FAR is found at: http://205.130.237.11/far/ NATIONAL SECURITY COMPUTER SYSTEMS: NIST‘s standards and guidelines and the FAR do not apply to national security agencies or national security computer systems. For information assurance procurement by national security agencies or national security computer systems, agencies must follow ―NSTISSP #11.‖ NSTISSP 11 is a national security community policy governing the acquisition of information assurance (IA) and IA-enabled information technology products. The policy mandates, effective 1 July 2002, that departments and agencies within the Executive Branch shall acquire, for use on national security systems, only those COTS products or cryptographic modules that have been validated with the International Common Criteria for Information Technology Security Evaluation, the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS), or by the National 36 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Appendix B. Source Code Review Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Cryptographic Module Validation Program. The objective of NSTISSP #11 is to ensure that COTS IA and IA-enabled IT products acquired by the U.S. Government for use in national security systems perform as advertised by their respective manufacturers, or satisfy the security requirements of the intended user. Information on NSTISSP 11 is found at: http://niap.nist.gov/cc-scheme/nstissp-faqs.html Source code review: Even when following NSTISSP 11, only in certain procurement cases is source code review or submission required. These instances would be: Department of Defense: Department of Defense Directive (DoDD) 8500.1 and Department of Defense Instruction (DoDI) 8500.2 define the protection requirements and the implementation of NSTISSP#11. These documents call for the acquisition of products that have been evaluated against a CC Protection Profile based on 3 levels of robustness (basic, medium, and high). Protection Profiles at the medium and high robustness levels include vulnerability analysis requirements, and require the vendor to provide source code for review (i.e., AVA-VLA.3 at EAL5 requires source code). If the cryptographic module is tested under FIPS 140-2 and validated by the CMVP, as explained above. The only other occasion where the USG may ask for source code is when the USG pays for the code to be written so that it becomes the government‘s intellectual property (IP), as opposed to IP of the vendor. 37 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Appendix B. Source Code Review Attachment A: U.S. Executive Branch Executive Office of the President (EOP) White House Office of Management and Budget (OMB) United States Trade Representative (USTR) Executive Agencies Department of Agriculture (USDA) Department of Commerce (DOC) Department of Defense (DOD) Department of Education Department of Energy Department of Health and Human Services (HHS) Department Homeland Security (DHS) Department of Housing and Urban Development (HUD) Department of the Interior (DOI) Department of Justice (DOJ) Department of Labor (DOL) Department of State (DOS) Department of Transportation (DOT) Department of the Treasury Department of Veterans Affairs INDEPENDENT AGENCIES Advisory Council on Historic Preservation (ACHP) American Battle Monuments Commission Central Intelligence Agency (CIA) Commodity Futures Trading Commission (CFTC) Consumer Product Safety Commission (CPSC) Corporation for National Service Environmental Protection Agency (EPA) Equal Employment Opportunity Commission (EEOC) Farm Credit Administration (FCA) Federal Communications Commission (FCC) Federal Deposit Insurance Corporation (FDIC) Federal Election Commission (FEC) Federal Energy Regulatory Commission (FERC) Federal Labor Relations Authority (FLRA) Federal Maritime Commission Federal Reserve System, Board of Governors of the Federal Reserve System Federal Retirement Thrift Investment Board (FRTIB) Federal Trade Commission (FTC) General Services Administration (GSA) Federal Consumer Information Center (Pueblo, CO) Institute of Museum and Library Services (IMLS) International Boundary and Water Commission International Broadcasting Bureau (IBB) Merit Systems Protection Board (MSPB) National Aeronautics and Space Administration (NASA) National Archives and Records Administration (NARA) National Capital Planning Commission (NCPC) 38 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Appendix B. Source Code Review National Commission on Libraries and Information Science (NCLIS) National Council on Disability National Credit Union Administration (NCUA) National Endowment for the Arts (NEA) National Endowment for the Humanities (NEH) National Indian Gaming Commission (NIGC) National Labor Relations Board (NLRB) National Mediation Board (NMB) National Railroad Passenger Corporation (AMTRAK) National Science Foundation (NSF) Board National Transportation Safety Board (NTSB) Nuclear Regulatory Commission (NRC) US Nuclear Waste Technical Review Board (NWTRB) Occupational Safety and Health Administration (OSHA) Office of Federal Housing Enterprise Oversight (OFHEO) Office of Personnel Management (OPM) Overseas Private Investment Corporation (OPIC) Peace Corps Pension Benefit Guaranty Corporation Postal Rate Commission Railroad Retirement Board (RRB) Securities and Exchange Commission (SEC) Selective Service System (SSS) Small Business Administration (SBA) Social Security Administration (SSA) Tennessee Valley Authority (TVA) Thrift Savings Plan (TSP) United States Agency for International Development (USAID) United States Arms Control and Disarmament Agency (ACDA) United States International Trade Commission (USITC) United States Office of Government Ethics (OGE) United States Postal Service (USPS) United States Trade and Development Agency Voice of America (VOA) 39 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 Appendix B. Source Code Review Attachment B: Identification of USG National Security Systems Computer Security Act of 1987: This Act clarified the definition of ―national securityrelated information,‖ and assigned the National Institute of Standards and Technology (NIST) the responsibility and authority of developing all Federal standards for safeguarding unclassified systems. The National Security Agency (NSA) was assigned responsibility for security of information that is classified for national security purposes. This definition was most recently included in the U.S. Federal Information System Management Act (FISMA) of 2002 (please see http://csrc.nist.gov/policies/FISMAfinal.pdf), excerpted below: 2.0 Basis for Identification of National Security Systems ―(2)(A) The term ‗national security system‘ means any information system (including any telecommunications system) used or operated by an agency or by a contractor of an agency, or other organization on behalf of an agency— (iii) the function, operation, or use of which(VI) involves intelligence activities; (VII) involves cryptologic activities related to national security; (VIII) involves command and control of military forces; (IX) involves equipment that is an integral part of a weapon or weapons system; or (X) subject to subparagraph (B), is critical to the direct fulfillment of military or intelligence missions; or (iv) is protected at all times by procedures established for information that have been specifically authorized under criteria established by an Executive order or an Act of Congress to be kept classified in the interest of national defense or foreign policy. (B) Subparagraph (A)(i)(V) does not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).‖ Systems not meeting any of these criteria are not national security systems. 40 Software Security Acquisition Guide 1 Appendix C. Generic Questionnaire Appendix C. Generic Software Assurance Questionnaire Introduction This section includes questionnaires for use by acquisition managers. The questionnaires provide a set of questions from which acquisition managers may choose depending on the circumstances surrounding a particular acquisition. Acquisition managers should seek the advice of information assurance, software assurance, and/or software managers/engineers when determining which questions to use. The set of questions that are chosen for a particular acquisition can be incorporated into the RFP as part of the evaluation of a supplier. This section will contain both a generic questionnaire that has applicability to any acquisition and specific questionnaires that have applicability to specialized products (such as medical equipment) that incorporate software as its underpinnings. In later editions of this guide, there will be an accompanying instruction on when each question might be used in an acquisition. 2 3 4 5 6 7 8 9 10 11 12 13 14 41 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Appendix C. Generic Questionnaire C.1 INTRODUCTION This Software Assurance Acquisition Due Diligence Questionnaire (―Due Diligence Questionnaire‖ or ―Questionnaire‖) is part of the Software Assurance Series sponsored by the Department of Homeland Security (DHS) Software Assurance Acquisition Working Group. The Questionnaire specifically supports the software acquisition manager in implementing due diligence in the acquisition of software and will evolve as threats and technology evolve. The questions within this document assist the acquirer (or buyer) in assessing assurance, trustworthiness, and reliability of software prior to its acquisition (or purchase/procurement) from a supplier (or seller or developer). Elements of the Questionnaire are applicable throughout the Software Development Life Cycle (SDLC) and the corresponding acquisition life cycle. The questions can be used informally or incorporated into a formal process such as a Request for Proposal (RFP). For example, the acquirer of commercial off-the-shelf (COTS) software may apply the questions to independent research into COTS products to assist in the assessment of a COTS software product prior to purchase. Or, correspondingly, the acquirer may incorporate questions into a Request for Information (RFI) or an RFP as part of major software acquisition or planned software development. C.1.1 OBJECTIVE The objective is to enhance the process for acquiring trustworthy software, thereby, enhancing the IT security posture. This can be achieved by supporting the security of software across the SDLC to address Trustworthiness (no exploitable vulnerabilities), Predictable Execution (when executed, functions in a manner in which it is intended) and Conformance (software processes and products conform to requirements and applicable standards or procedures). Bottom line: ―Build security in‖ and maintain software assurance throughout its life cycle. C.1.2 PURPOSE The purpose of the Due Diligence Questionnaire is to assist the acquisition manager in achieving the above goal. A reality today is that, at a time of increasing and changing software security risks, software assurance is inadequately considered during the acquisition process. This Software Assurance Acquisition Due Diligence Questionnaire is designed to address that challenge. The intent is to inform the acquirer of potential risks associated with the software they are considering for acquisition. The Questionnaire provides the acquirer a means to gather, in advance, some of the information needed to make a decision about the trustworthiness of the software. C.1.3 BACKGROUND AND SCOPE With the increasing and emerging risks inherent in software and the use of software, software assurance communities are pursuing various means and methods to enhance the software acquisition process with the goal of executing and obtaining software that is trustworthy. This Software Assurance Acquisition Due Diligence Questionnaire (hereafter called the ―Due Diligence Questionnaire‖ or ―Questionnaire‖) addresses software assurance concerns of the acquisition manager or software acquirer. Broader questions pertaining to software functionality are addressed in the "Software Security--Acquisition Guide" and numerous other documents available through the Government and commercially (see 42 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Appendix C. Generic Questionnaire References in Section 3). Questions are derived from Lessons Learned and Best Practices of experts in the field. The Due Diligence Questionnaire is an iterative work that reflects the fact that the acquisition of trustworthy and quality software is evolving within the acquisition framework with emerging standards, policies and Best Practices. The value of the Questionnaire is in the Community of Interest (COI) contributions it represents. The participants of the DHS Software Assurance Acquisition Working Group consist of representatives from government, academia, and private industry. They have identified key concerns and challenges that acquisition managers face in acquiring assured software that is guaranteed to be safe, secure, interoperable and reliable. For purposes of this document, ―acquisition‖ means the acquiring of software development services or software products whether by contract or by other means, e.g., downloading open source software from the Internet. For the U.S. federal government, also see the FAR Subpart 2.101(b)(2) definition of acquisition. (Derived from the Software Assurance Acquisition Companion Guide’s definition and use of ―acquisition.‖) In addition, for purpose of this document, ―acquisition‖ applies to functions across the entire acquisition framework and the software development life cycle, including development, integration, testing, operations, maintenance and disposition, as well as the contracting/solicitation process itself. The Questionnaire is applicable to any type of software acquisition ranging from a commercial off-the-shelf (COTS) GSA Schedule procurement to an Indefinite Delivery/Indefinite Quantity (ID/IQ) contract vehicle, to a major developmental acquisition. 43 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Appendix C. Generic Questionnaire C.2 USING THE DUE DILIGENCE QUESTIONNAIRE The Questionnaire is categorized into eight different sections, including: 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Organization Background Software Production Policies Software Pedigree Assurance Preventive Measures Quality Control Operations and Support Service Governance Each represents a category of questions and related guidance: Objective, Assumptions, Approach, Value, Response Interpretation, and References. The questions within each can be used by an acquisition manager (optimally with the assistance of an IA subject matter expert familiar with software assurance) to apply the questions and interpret the responses. Whether buying a single copy of a single software application or a multi-million dollar software information system, the Questionnaire is a useful tool. It can be used in whole or in-part. Some questions may apply, some may not; some may be added, others may be tailored. Several examples of when the Questionnaire may be effectively applied include: Developing an RFI to gather information for a major software development program; Developing an RFP -- Statement of Work and contractual language such as Terms and Conditions -- for the development of software for a major information system or weapon system platform; Developing vendor surveys; and Gathering information on given software products or suppliers to determine which COTS software application to procure under the GSA Schedule or ID/IQ. The responses to the questions posed are factored into the acquisition decision process. For example, if the supplier has a poor track record, are there mitigating factors? If a response from a supplier is incomplete, inconsistent, unclear, or raises concerns, the buyer may sometimes be able to return to the supplier with follow-on questions for clarification (unless, for example, limited by the FAR) to better understand the possible impact and its effect on confidence in the software. If the response from the supplier is clear and complete but results in concerns regarding the quality of a supplier‘s software product, this information becomes critical to the software acquisition decision process. In some circumstances it may be helpful to call upon appropriate Subject Matter Experts (SME) in a functional area such as contracting, finance, legal, software testing, or information assurance, etc, to assist in the review or assessment of responses to the Questionnaire. A Risk Factor Worksheet is provided in to assist in interpreting responses to the Questionnaire. The ratings used in the worksheets are explained below: Low Medium High Not Applicable Need Info This acquisition exhibits the low risk cue, or appears to have no risk in this area. This acquisition exhibits the medium risk cue, or something similar in threat. This acquisition exhibits the high risk cue, or something similar in threat. This factor is not applicable to this acquisition. We need information from someone else (perhaps an expert) to make a judgment. 44 Software Security Acquisition Guide TBD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Appendix C. Generic Questionnaire The acquisition is not far enough along to make a rating; we need to review this later. The Questionnaire is a means for gathering relevant information to support decisionmaking vs. being a decision-making tool. Expertise in software, acquisition and information assurance -- as well as common sense -- is critical to making smart decisions on the acquisition of assured software. Questions should be posed by, and responses assessed by, knowledgeable software security experts or other appropriate functional experts. The Questionnaire provides the acquirer the opportunity to share in and apply the Best Practices and Lessons Learned of software assurance acquisition experts across the software assurance community. By supporting the implementation of due diligence in the acquisition of software, the Questionnaire supports the process for acquiring trustworthy and quality software and supports an enhanced IT security posture. Due diligence entails taking all the "reasonable steps" necessary to ensure that a software system meets business and technical goals and requirements, determining required skills sets to support the software, training costs, and life-cycle costs, including the purchase price, and the maintenance and upgrade costs. In addition, it helps to identify potential risks and red flags. The Questionnaire is a tool. It is not a checklist or a complete listing of all possible software security concerns. 45 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Appendix C. Generic Questionnaire C.2.1 ORGANIZATION BACKGROUND C.2.1.1 Objective One of the many factors to consider when acquiring software is the company background of the supplier. As a result of increased globalization and outsourcing of software development, new risks have been introduced to the development process. Stakes are high as a result of evolving Cyber Threats. Understanding who your suppliers are and who they partner with is critical. The primary objective of this section is to identify risks to secure software development and support that may derive from a supplier‘s company or financial conditions. Also, to provide a means, through suggested questions and guidance, to identify such risks in advance in support of the acquisition of trustworthy software. The primary objective of this section is to provide a set of questions that would help the acquisition manager in identifying specific supplier company risks that should be considered. C.2.1.2   Assumptions The following assumptions have been made in preparing this section: The acquirer has an understanding of software development standards and IA or has Subject Matter Experts (SME) to provide assistance. The acquirer has an understanding of outsourcing of software development, countries of concern, and known threats to software in development, or has SME to provide assistance. The acquirer follows its security policies or other security policies set forth by other companies such as NIST or ISO. There is buy-in from top management for acquiring secure software.   C.2.1.3 Approach Ideally, this kind of company information would be collected once and maintained at a central point. This would be more efficient and specialists could do a much better job at company analysis. The considerations for this category are divided into four areas: (1) Foreign Interests and Influences. A company‘s security culture will in large part determine the security of the software it supplies or develops. The ability of an company to build secure software starts from the top down – the Chairman of the Board, the Board, President and the ―three-letters‖ i.e., the CXO‘s It is helpful to know if there are any controlling foreign interests among the officers or ―Cs‖ of the company/company, from what country(ies) and to what extent control is exercised. For a publicly held company, limited information of this nature is available. If FOCI is an area of particular interest, use the questions in OMB Standard Form 32817. (2) Organizational History. With the extent of mergers and acquisitions in Information Technology (IT), it can be a challenge to keep up with even the major IT companies. Asking for a corporate history provides the acquirer the opportunity to understand and decipher the background, role, relationships, and culture of the company. The acquirer can review the history, learn what other software is developed by the supplier, and use that information to assess the company‘s ―track record‖ (see below) and determine if there are 17 http://www.dtic.mil/whs/directives/infomgt/forms/eforms/sf0328.pdf 46 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Appendix C. Generic Questionnaire conflicting circumstances or competing interests within the company that may lead to increased risk in the software development. (3) Financial History and Status. The questions in this section inquire into the supplier‘s financial viability and stability. If the company is publicly held, some of the answers are a matter of public record. The intent of the questions is to identify documented financial conditions or actions of the supplier that may impact its viability and stability, such as mergers, sell-offs, lawsuits, and financial losses. It is a best practice to run a financial report (e.g. three brokerage reports or a Dunn and Bradstreet report) to gain better insight into the company‘s financial standing. Such conditions or actions should be identified to determine if and what risk they may pose to the supplier‘s software development security environment or to the supplier‘s ability to provide security support services to its customers. (4) Security ―Track Record‖. To increase their confidence in the security of the software they are acquiring, acquirers can ask about the performance history or track record of a supplier. Though past performance is not a guarantee of future performance, the established record of a supplier can provide factual information regarding the supplier‘s financial stability, innovation, support services, and reliability. It can also provide insight into whether the supplier places a high priority on security throughout its company and throughout the life cycle of its products. A supplier‘s response to a known software defect or threat may be indicative of the seriousness with which it treats software security. The acquirer can look into the supplier‘s performance in going after software threats and determine whether the supplier consistently has demonstrated an effective response to known or anticipated risks to its software. In addition to raising questions such as those below, the acquirer can also search the public record and media for such information. See also ―Defect Management‖ in paragraph 2.5.3(4) for additional Best Practices in this area. C.2.1.4    Value Background information collected on the supplier‘s company will: Provide a structured view of the supplier‘s company and performance as it pertains to a secure software development/ops/and support environment. Address documented and relevant security information about the supplier‘s working environment, chain of control, and the priority it gives to software security. Help identify supplier company‘s that have a malicious intent to the acquirer. C.2.1.5 Questions to Consider Asking the Suppliers COTS Custom System Integration Service & Outsourcing Criticality Role Number/Question 1 1a Foreign Interests and Influences Is the controlling share (51+%) of your company owned by a nonU.S. entity? If so, please complete Standard Form 328, Certificate Pertaining to Foreign Interests. If your company is an entity of a larger “parent” company. If “yes”, does that “parent” company include any subsidiaries or other sub-entities that are 51+% foreign owned? If so, please identify those subsidiaries/sub-entities. x x 1b x x 47 Software Security Acquisition Guide Number/Question 1c Please provide company names of all third-party entities with whom your firm contracts software development, maintenance, or support services. Organizational History Please summarize your company’s history of ownership, acquisitions, and mergers (both those performed by your company and those to which your company was subjected). Please provide a list of the names and dates of service of the following executive officers starting with the present and going back to the establishment of your company in its original form (before any mergers or acquisitions):  Chairman of the Board (COB)  Chief Executive Officer (CEO)  President (if different from CEO)  Vice President(s)  Chief Financial Officer (CFO) How many employees does your company have:  In the U.S.?  Worldwide? Financial History and Status Has your company ever filed for Recompany under U.S. Code Chapter 11? If so, please provide dates for each incident, and describe the outcome. Does your company have policies and procedures for periodically reviewing the financial health of the third-party entities with which it contracts for software development, maintenance, or support services? Does your company have established policies and procedures for dealing with the contractual obligations of third party developers that go out of business? x x x x x COTS x Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x Criticality Role 2 2a x x 2b x x 2c x x 3 3a x x 3b x x x 3c x x x 4 Security “Track Record” (refer also to Section 2-5, Preventive Measures, Section 3) 48 Software Security Acquisition Guide Number/Question 4a Does your company have an executive-level officer responsible for the security your company’s software products and/or processes? Has your company ever produced software products that were successfully evaluated under the Common Criteria, ITSEC, or TCSEC? If so, what products(s) and at what evaluation level(s)? What are your policies and procedures regarding patches and Service Packs? DO you disclose vulnerabilities are part of your policies and procedures? Has civil legal action ever been filed against your company for delivering or failing to correct defective software? x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x x x Criticality Role 4c x 4d x x x x 4e x x x x 1 2 3 4 C.2.1.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be refined in a future version. Rating (check one) Facto r ID Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues NA NI TB D Notes M H L  Organizational Background 1 Controlling Foreign interest by CXO’s No controlling interest by anyone Some controlling interest by maintaining partnership of foreign-owned company Some non-US citizens are upper management CXO may be on board of directors or own large sum of stock in foreign-owned company. Some non-US citizens are on board of directors or CXO level Company has no documented corporate history Significant turnover of officers and/or corporation has been or will be purchased recently. 2 Non-US citizen included in company structure Company employs many non-us citizens but most are lower in company structure Company’s history is fully documented and can provide to acquirer. little or no change corporate officers 3 The “corporate” history summary Company has some documented corporate history will change some or have small affect on software that is being acquired 4 Turn-over rate of corporate officers 49 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 Appendix C. Generic Questionnaire C.2.1.7  References NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html DoDI 8500.2, Information Assurance Implementation, 6 February 2003. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v 08%2001092006.pdf OMB Standard Form 328. http://www.dtic.mil/whs/directives/infomgt/forms/eforms/sf0328.pdf    50 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 C.2.2 SOFTWARE PRODUCTION POLICIES C.2.2.1 Objective Existence, implementation and enforcement of software assurance-related general policies and controls provide assurance that software assurance has been incorporated into the management and development processes and not just added. In addition, software assurance-related policies and controls are important indicators of supplier attention to safety, security, reliability and dependability of software. General polices need to address a number of software development risks associated with security. For example,    Personnel inappropriately accessing or changing sensitive development information (security of the development facility) A developer purposely inserting malicious code (monitoring and control of individual behavior) Design and coding development activities introducing software vulnerabilities (reduced by the software development process) Testing of security functionality with standard functional testing techniques and riskbased security testing based on attack patterns, risk analysis results and abuse cases.  The primary objective of this section is to provide a set of questions that would help the acquisition manager in identifying specific risks that should be considered by the developer, the adequacies of the policies proposed to mitigate those risks, and the evidence that those policies are enforced and effective. C.2.2.2   Assumptions The following assumptions have been made in preparing this section: General knowledge of security risks associated with the development Management buy-in on software assurance as criteria for selection C.2.2.3 Approach The discussion has three components: 1) security of the software development facility, 2) monitoring and controlling individual malicious behavior, and 3) policies associated with software development practices. (1) Software Development Facility. The purpose of the questions in this component is to ascertain that the supplier has and enforces policies that support a secure development facility. The policies that support a secure development facility depend on a number of factors: one or multiple and physically separated sites; use of out-sourced development, and incorporation of open source development. As a minimum, there should be policies on and enforcement of access controls and auditing of software to prevent unauthorized access to software and to ascertain whether unauthorized access has occurred. In addition, there should be policies related to actions that are taken when violations of the access controls and unauthorized access has occurred. The access controls should support separation of roles so that a developer cannot by-pass the controls. The check-in of critical software 51 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix C. Generic Questionnaire might require the concurrence of two or more individuals. Often the access and auditing is enforced by a configuration management system. (2) Individual Malicious Behavior. The purpose of the questions in this component is to determine if the supplier has and enforces policies that minimize individual malicious behavior. Identifying malicious personnel behavior is a very difficult problem. There are multiple controls that can reduce but not eliminate this risk. Access control and change auditing are one mechanism. Independent design and code reviews provide some protection. Tool-based code analysis may identify purposely-introduced coding vulnerabilities. It is harder to identify malicious behavior with out-sourced development. However, suppliers who out-source all or part of software development should have policies in place and enforcement mechanisms that minimize the impact of malicious behavior of their out-sourced developer. This could include, but not limited to, testing policies for malicious code prior to acceptance of the code from an out-sourced developer. (3) Software Development. The purpose of the questions in this component is to determine whether the supplier has and enforces good software assurance practices in the development of software. The answers to these questions depend on what is being developed: a general-purpose product, computing infrastructure services, a closed system, or a system or application that must be integrated into an existing collection of systems. The policies should reflect differences in scale and scope among these kinds of development contexts. Software development activities are sources of a significant number of vulnerabilities. While a developer may claim that their software development process incorporates security, critical questions involve the choice of development practices, whether the developer effectively and consistently uses those practices, whether the software risks that are essential for the proposed usage of the software are addressed by the developer‘s software process, and whether the people involved in the software development life cycle are trained in good software security practices. The following are supporting indicators. The developer can provide a rationale for how their chosen development practices reduce the likelihood of a class of software vulnerabilities. That rationale should be consistent with existing knowledge on best practices. The developer has identified metrics that guide their own selection and application of software development processes. The metric can be as simple as a historical reduction in software errors. The personnel policies include training on best practices for all aspects of development: requirements, architecture, design, coding, testing, and deployment. Personnel policies related to training may includes the requirement for certifications including security certifications. One area to examine for evidence regarding the enforcement of software assurancerelated software development policies is the project management policies and guidance. Those policies and guidance should incorporate software assurance requirements and practices and should be reflected in: project requirements and scope, the technical plan in terms of the scheduling of deliverables and enforcement activities such as risk analysis, design reviews, tool-based analysis of the source code, and testing that reflects the identified risks, resources required such as security expertise for a specific domain or technology, 52 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 Appendix C. Generic Questionnaire coordination of security risk analysis and the associated development guidance across all development teams, and specific attention given to out-sourced development and use of open-source software. C.2.2.4 Value General polices and controls provide assurance that software assurance has been incorporated into the management and development processes and not just added on. The primary objective is to avoid surprises, i.e. a mismatch between the advertised and delivered product quality. Software Production Policies should reflect where the developer has put their resources and hence may better specify their objectives. A purchase where the developer‘s (supplier‘s) objectives support the acquirer‘s (buyer‘s) objective should be more cost effective. C.2.2.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Roles 1. 1a Software Development Facility Does your company have formal software security polices and procedures in place for change management, configuration management, and build management? If yes, how are they enforced? What tools are used to perform these tasks? Do these tools provide audit logs? If yes, is auditing enabled and how frequently are the audit logs reviewed? What actions are taken if a violation of a security policy is observed in the logs? Is the level of security where the software was developed the same as where the software will operate? Individual Malicious Behavior What kind of management controls and auditing policies do you have to prevent the intentional introduction of malicious code into your products? How are these controls and policies enforced? Does your company perform background checks on members of the software development team? If so, are there any additional “vetting” checks done on people who work on critical application components, such as security? Explain Does your company have formally defined security policies associated with clearly defined roles and responsibilities for personnel working within the software development life cycle, along with management oversight and enforcement? Explain x x x x x x x x x x x 1b x x x x 2 2a 2b x x x x 2c x x x x 53 Software Security Acquisition Guide 2d Does your company provide training to development staff to help them identify malicious behavior? Does it have formal policies for reporting malicious behavior? Software Development Does your company having formal coding standards including secure coding practices for each language in use during the software development life cycle? If yes, how are they enforced? How often are these standards and practices reviewed and updated? Does your company offer training related to defining security requirements, secure architecture and design, secure coding practices, and security testing? This may include traditional classroom training, eclasses (scheduled, instructor-led classroom experience delivered over the Web), workshops, and seminars. Is this training optional or mandatory? Does your company offer continuing education and training programs related to application security? Are continuing education and training programs optional or mandatory? Does your company have corporate policies and management controls in place to ensure that only corporate approved software components, such as licensed, vetted, and FIPS-140 certified encryption routines, are used during the development process? If yes, how are these policies and management controls enforced? Does your company require developers to have professional certifications such as Sun’s Java Programmer, Developer, or Architect certifications or Microsoft’s Certified Professional Developer (MCPD), Application Developers (MCAD) or Solution Developers (MCSD) certification? Is certification a requirement for being hired? Are employees vetted to ensure that certifications are valid and up-to-date? Is the development staff required to have other security related certifications, such as a CISSP? Operational Dependencies Does your company have a matrix of dependencies by platform? Does your company have a standard practice of what this does or does not work with? Does your company perform architectural maintenance to allow your product to continue operations with other vendors? Are your products designed to be maintained together? x x x x x x x x x Appendix C. Generic Questionnaire x 3 3a x x x 3b x x x x 3c x x x x 3d x x x x 4 4a x x 4b x x x x 54 Software Security Acquisition Guide 1 2 3 4 5 6 Appendix C. Generic Questionnaire C.2.2.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Rating (check one) Factor ID NA Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues TBD Notes NI M H L Software Production Policies 1 2 3 4  7 8 9 10 11 12 13 14 15 16 17 C.2.2.7  References NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html DODD 8500.1, Information Assurance, 24 October 2002. http://www.dtic.mil/whs/directives/corres/html2/d85001x.htm DoDI 8500.2, Information Assurance Implementation, 6 February 2003. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v 08%2001092006.pdf    55 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 C.2.3 SOFTWARE PEDIGREE C.2.3.1 Objective Software pedigree, or the background and lineage so to speak of software being acquired, continues to be a critical element in determining the trustworthiness and quality of software. The challenge has been how to attest to the quality and security of software that may contain millions of lines of code. Gradually, with advances in technology and testing tools as well as a more educated software acquisition community, higher standards and greater developmental and environmental discipline are being imposed and there is a greater ability to determine the software lineage of a given product. As discussed in Section 2.1, new risks have been introduced to the development process as a result of increased globalization and outsourcing of software development. Stakes are high as a result of the evolving Cyber Threat evidenced by subversive and malicious/non-malicious activities. The primary objective of this section is to identify specific risks pertaining to the background and ―pedigree‖ of the software during any and all phases of its lifecycle that should have been considered by the supplier. The questions and guidance in this section provide a means by which an acquirer can identify potential pedigree risks before source selection, in order to increase the likelihood of acquiring trustworthy software. C.2.3.2   Assumptions The following assumptions have been made in preparing this section: The acquirer has an understanding of software development standards and IA or has Subject Matter Experts (SME) to provide assistance. The acquirer acknowledges that the less is known about the pedigree of a component, the more information must be obtained on the architecture of said component. The acquirer has an understanding of outsourcing of software development, countries of concern, and known threats to software in development, or has SME to provide assistance. The acquirer follows its security policies or other security policies set forth by other organizations such as NIST or ISO. There is buy-in from top management for acquiring secure software.    C.2.3.3 Approach The software pedigree discussion has three components: 1) Software Configuration, 2) Software Change Management, and 3) Software Support Lifecycle Policy (1) Software Configuration. The supplier‘s configuration files and policies will determine if the application is using development standards and new technologies to produce a trustworthy product. These files and/or policies should identify any risks or malicious code that have been left in or injected into the software. Asking about this assists the acquirer in determining what level of development standards have been used in the software and acknowledge where the software was created. (2) Software Change Management. The acquirer should ask if there is a change management procedure or document that will identify the type and extent of changes 56 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Appendix C. Generic Questionnaire conducted on the software throughout the lifecycle. These changes lead to new version releases of an application. The primary objective is to determine if the changes were adequately assessed by management. (3) Software Support Lifecycle Policy. The acquirer should ask if there is a Support Lifecycle Policy within the organization18. This policy should determine how long the support of a software application will be in effect and if there are any additional costs for service. This policy should outline and establish a consistent and predictable support timeline for a product or application to assist management with requirements and planning. C.2.3.4   Value The value for addressing Software Pedigree includes the following: Is a critical element in determining the trustworthiness and quality of software Identify specific risks pertaining to the background and ―pedigree‖ during the software lifecycle C.2.3.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration x Service & Outsourcing x Criticality Role1 1. 1a Software Configuration Does the software contain third-party components? If “yes”, does the third-party developer deliver those components to the organization in source code or binary executable form? Are open source components used in the software? If “yes”, what are the policies and procedures for verifying the quality and security of those components. x x Technical 1b x x x x Technical 2. 2a Software Change Management What are your policies and procedures for maintaining SDLC artifacts, including requirements, design and architecture documents, source code, binaries, and user documentation? Does the organization have policies and procedures in place to monitor and audit the transmission of its technology-related intellectual property to third parties, and to prevent unauthorized transmission of that intellectual property? What are your policies and procedures for version control and configuration management? What tools are used for these activities? Are your version control and configuration management policy’s and procedures the same throughout your entire organization? How are they enforced? Are third-party developers contractually required to follow these policies and procedures? x x x x Technical 2b x x x x Legal 2c x x x x Technical 2d x x x x Business 18 http://support.microsoft.com/gp/lifepolicy 57 Software Security Acquisition Guide 2e Does the organization have a policy and process to prevent the illegal transmission to foreign entities of any export-restricted technical content in its software, such as encryption algorithms? Is any mechanism in place that establishes a persistent, auditable linkage between the identity of the developer who produces a software artifact and the artifact itself? (EXAMPLES: digital signatures applied to artifacts; audit records traceable to individual developer identity for all file accesses in the configuration management system) Does the organization perform any personnel background checks on its developers and software project managers? If “yes”, please describe the nature of the information collected, and any investigation performed to verify that information. How often, if ever, is an individual’s background check process repeated? Are third parties contractually obligated by the organization to perform comparable background checks processes on those of their developers who are producing software for the organization? What are your policies and procedures for dealing with any developer it may suspect of malicious or subversive behaviors (such as embedding of malicious logic in the software, or unauthorized release of the organization’s technology/intellectual property to entities hostile to the U.S. government or to criminal elements)? Are third-party developers contractually required to follow these policies and procedures.. What , if any, requirements for configuration management, quality assurance, and secure development practices does the organization contractually obligate its thirdparty developers to satisfy? What policy’s and processes does your organization use to verify that software components do not contain malicious code? What tools are used? Are there contractual recourses that the organization can take if a third-party developer delivers software that contains malicious code? Does the organization ever perform site inspections/policy compliance audits of its U.S. development facilities? Of its non-U.S. facilities? Of the facilities of its third-party developers? If yes, how often do these inspections/audits occur? Are they periodic or triggered by events (or both)? If triggered by events, provide examples of “trigger” events. x x x x x x Appendix C. Generic Questionnaire x x Legal 2f x x x x Legal 2g x x x x Legal 2h x x x x Legal 2i x x Legal Technical 2j x x Technical 2k x x Legal 2l x x Legal Business 58 Software Security Acquisition Guide 2m Does your organization establish contractually-binding agreements with their own developers and/or with their third-party developers regarding the ownership and/or licensing of intellectual property? Appendix C. Generic Questionnaire x x Legal 3. 3a Software Support Lifecycle Policy Are digital intellectual property controls of any type embedded in the software before it is distributed (e.g., digital rights management controls, digital watermarks, code signatures, etc.)? If “yes”, identify the types of controls used. x x x x Legal Technical 1 2 3 4 5 6 7 8 9 C.2.3.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Additional Note: http://www.ICHnet.org provides a pre-application self assessment template that is required for a vendor to clearly articulate how it meets a particular need through third-party products. It also provides an example of what to ask in order to validate and stand behind a claim. Rating (check one) Facto r ID Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues NA NI TB D Notes M H L Software Pedigree 1 2 3 4  10 11 12 13 14 15 16 17 18 19 20 21 22 23 C.2.3.7  References NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html DoDI 8500.2, Information Assurance Implementation, 6 February 2003. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v 08%2001092006.pdf OWASP, Guide to Building Secure Web Applications and Web Services, July 27, 2005. http://www.owasp.org/documentation/guide.html Fred Cohen, Enterprise Patch Management: Strategies, Tools, and Limitations, 9 January 2004. http://www.burtongroup.com     59 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 C.2.4 ASSURANCE C.2.4.1 Objective There are many elements of contextual information about a supplier and how they build software (described in the other sections of this Questionnaire) that can be of value in deriving some idea of the assurance level present in software being considered for acquisition. Beyond these indirect indicators, it is important to understand in a more explicit sense exactly how a supplier communicates their claims of assurance, against what these claims have been measured and to what levels they have verified these claims. This set of questions is intended to assist the acquisition manager in determining what levels of description exist for the claimed assurance of the software in question, to what levels it has been assessed against standard measures of assurance and to what levels of verification activities, both internal and external, it has been subjected. The primary objective of this section is to provide a set of questions that would help the acquisition manager better understand the assurance case being made by the supplier, the adequacies of the steps to build-in assurance, and how the assurance case has been validated. C.2.4.2 Assumptions The following assumptions have been made in preparing this section: The acquirer has an understanding of software development standards and IA or has Subject Matter Experts (SME) to provide assistance. The acquirer follows its security policies or other security policies set forth by other organizations such as NIST or ISO. There is buy-in from top management for acquiring secure software. C.2.4.3 Approach The considerations for this phase are divided into three sections: (1) Assurance Description. The supplier‘s description of the software assurance approach is at the heart of the section. Asking about this assists the acquirer in determining what level of description exists for the claimed assurance of the software, i.e., is there a description documented for modifications? For access by different levels of users (roles and permissions)? (2) Assurance Measurement. The acquirer asks the supplier to identify the types and extent of measurements and assessments conducted on the software. The primary objective is to determine if weaknesses and flaws were adequately assessed. (3) Assurance Verification. The acquirer asks the supplier to identify to what levels of verification activities the software has been subjected. This can include a complete range of validation/verifications – internal to external, penetration testing to regression testing to a complete Certification and Accreditation in accordance with the applicable authority (e.g., NIST, DoD, DCID 6/3). 60 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 Appendix C. Generic Questionnaire C.2.4.4 Value Information Assurance is not a feature, it must be part of the overall system design and technology selection process. The value of addressing Assurance considerations includes: Information collected enables the acquirer to procure software with an increased likelihood that it will be safe, secure, interoperable and reliable. Software security is addressed in advance of a software acquisition regarding the software‘s built in security or vulnerabilities. Support for more structured, measurable and secure software processes and products through implicit support of software metrics as a viable assurance tool. Increased level of secure software standardization and interoperability. Assurance that there is conformance to the architecture and design specification throughout the software development lifecycle. C.2.4.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Role 1. 1a Assurance Description What software development life cycle (SDLC) process is used in your company? Does your company have a set of formal security best practices that are designed to address security concerns in the SDLC? How are security best practices mapped to the SDLC process in use? What security design and security architecture artifacts are prepared as part of the SDLC process? What security best practices have been implemented in your company. Does your company’s requirements analysis process explicitly address quality requirements, security requirements, other non-functional requirements, and architecture, design, implementation, and testing constraints? What review processes are implemented to ensure that security requirements are unambiguous, traceable and testable throughout the entire SDLC? Are security requirements developed independently of the rest of the requirements engineering activities, or are they integrated into the mainstream requirements activities? x x x x 1b x x x x 1c x x x 1d 1e x x x x x x x 1f x x x 1g x x x 61 Software Security Acquisition Guide Number/Question 1h Are misuse/abuse cases derived from the application requirements? Are.relevant attack patterns used to identify and document potential threats? Is a process utilized by your company that provides a means for categorizing, and prioritizing security requirements? What tool(s) does your company use for requirements management? Does your company perform audits to assess compliance with security best practices by your development organization? Does your company have formal security policies applicable to the SDLC (roles, procedures, responsibilities. management, coding rules, acceptance/release criteria, etc.)? Is a process utilized by your company that can be used for documenting and analyzing the security aspects of fielded systems and for steering future improvements and modifications to those systems? Assurance Measurement What measurement practices and data does your company utilize to enable realistic project planning, timely monitoring of project progress and status, identification of risks to the project, and effective process improvement. What management and technical controls has your company implemented to produce highquality, secure products at acceptable cost? Has the software been measured/assessed for its resistance to identified, relevant attack patterns and related abuse/misuse cases? Has the software been measured/assessed against the Common Criteria scheme? If so, what evaluation assurance level (EAL)? Was the software developed in accordance with a Protection Profile and does the security target meet the acquirer’s requirements? x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing Criticality Role 1i x x x 1j 1k x x x x x x x x 1l x x x 1m x x x 2 2a x 2b x x x 2c x x x 2d x 62 Software Security Acquisition Guide Number/Question 2e Does your company develop security measurement objectives throughout the SDLC? Are there agreed-to measurement objectives with the Stakeholders for which attainment can be measured? Has your company identified specific statistical and/or qualitative analytical techniques for measuring attainment of security objectives? Assurance Verification What verification and validation technologies does your company use to ensure that documented requirements and design specifications have been implemented? Are static or dynamic software security analysis tools used to identify vulnerabilities in the software? If yes, what tools are used? How broad is the analysis? How are false positives addressed in the analysis process? How frequently are such analysis performed? Are security-specific regression tests performed during the development process? If yes, what securityspecific issues do they cover? How broad is the test coverage? How frequently are security-specific regression tests performed? Are application penetration tests performed? If yes, what securityspecific issues do they cover? How broad is the test coverage? How frequently are security-specific regression tests performed? Has security testing been performed on the software? What types (attack testing, code review, fault injection)? When does testing occur during the SDLC? How frequently are tests performed? How broad is the test coverage? During testing what proportion of identified defects relate to security concerns and requirements? Does your company’s defect classification schemes include security categories? Is security testing performed internally, by an independent third party, or by both? What release criteria does your company have for its products with regard to security? x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing Criticality Role 3 3a 3b x x x 3c x x x 3d x x x 3e x x x x 3f x x x 3g x x x x 3h x x x x 63 Software Security Acquisition Guide Number/Question 3i Has the software undergone any third-party security assessments? When? By whom? Are the test results available? x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x Criticality Role 1 2 3 4 5 6 Rating (check one) Factor ID Assurance 1 2 3 4 NA Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues TBD Notes NI M H L C.2.4.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version.  7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 C.2.4.7 References Clinger-Cohen Act (CCA) of 1998, Public Law 104-106. Section 3541 of Title 44, USC, Federal Information Security Management Act of 2002 (FISMA). http://csrc.nist.gov/policies/FISMA-final.pdf Committee on National Security Systems Instruction (CNSSI) No. 4009, National Information Assurance Glossary, May 2003. http://www.nsa.gov/ia/academia/caeFAQ.cfm?MenuID=10.1.1.2 NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html National Security Telecommunication and Information Systems Security Instruction (NSTISSP) No. 11, National Information Assurance Acquisition Policy, July 2003. http://niap.nist.gov/cc-scheme/nstissp_11_revised_factsheet.pdf DoDI 8500.2, Information Assurance (IA) Implementation, February 6, 2003. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt DODI 8580.1, Information Assurance (IA) in the Defense Acquisition System,‖ July 9, 2004. http://www.dtic.mil/whs/directives/corres/html2/d85001x.htm DoDI 5000.2, Operation of the Defense Acquisition System, May 12, 2003. http://www.dtic.mil/whs/directives/corres/text/i50002p.txt DCID 6/3, Protecting Sensitive Compartmented Information Within Information Systems, June 5, 1999. http://www.fas.org/irp/offdocs/DCID_6-3_20Policy.htm 64 Software Security Acquisition Guide 1 2 3 4 5 6 7 Appendix C. Generic Questionnaire DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v08 %2001092006.pdf OWASP, Guide to Building Secure Web Applications and Web Services, July 27, 2005. http://www.owasp.org/documentation/guide.html Fred Cohen, Enterprise Patch Management: Strategies, Tools, and Limitations, January 9, 2004. http://www.burtongroup.com 65 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 C.2.5 PREVENTIVE MEASURES C.2.5.1 Objective Acquirers need software systems today to resist attack from malicious adversaries. To do this effectively, software developers should use ―security-minded‖ risk-driven development methods that will make them are of the threats to which their software is subject, and of the techniques they can use to defend their software against those threats. Detection, tracking, and mitigation of defects is one important tool in reduction of security risk in software. The primary objective of this section is to provide a set of questions that would help the acquisition manager in identifying specific preventative measures the supplier has implemented to mitigate risks to the software. C.2.5.2    Assumptions The following assumptions have been made in preparing this section: The supplier does not know the level of risk of the environment in which the software will execute. The supplier‘s assumptions about the execution environment should include the possibility that the software will be subjected to a high level of risk. The acquirer will require the software to be able to resist most attacks and to recover quickly from those they cannot resist. C.2.5.3 Approach The considerations for this phase are divided into five sections: (1) ―Security-Minded‖ Software Engineering. Software is more likely to be able to resist and recover from attacks when risk management activities and checkpoints are integrated throughout the software development lifecycle. A ―security-minded‖ software development process includes activities and controls throughout the lifecycle that explicitly address the security issues—threats, attack patterns, and vulnerabilities—associated with software ―Security-minded‖, or ―risk-driven‖, software engineering applies the discipline of risk management to the software development process. Because predicting all future environments in which the software may someday operate is impossible, risk-driven engineering focuses its efforts on anticipating the most likely threats and associated attack patterns, and on performing a series of ―pulse checks‖ starting in the requirements analysis phase of the lifecycle, and iterating through the high level design/architecture, detailed design, coding, integration, and preparation-for-distribution phases. These pulse checks are intended to reveal any vulnerabilities in the software (represented by its artifacts at each lifecycle phase, e.g., its detailed design specification, its source code, its binary executable) that could be targeted or exploited by any of the anticipated threats. The requirements specification must then be modified to add measures that will minimize the software‘s exposure of such vulnerabilities to the anticipated threats, and the risk that any of the threats will be successful against the software. Meanwhile, throughout the lifecycle, new threats and associated attack patterns will emerge, so that the 66 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix C. Generic Questionnaire need to protect the software against each of them must also be fed back into the software‘s requirements specification. (2) Software Self-Defense. There is a minimum set of self-defense capabilities desirable in all software, but absolutely requisite in software that is likely to be used in ―high consequence‖ applications (i.e., applications in which a failure would threaten human life, safety, health, freedom, or financial well-being, or from which compensation of users from loss would be impossible or extremely expensive). These capabilities are designed to minimize the exposure of the software‘s vulnerabilities to external threats and to keep the software in a secure state regardless of the input and parameters it receives from its users or environment. Software self-defenses include such capabilities as:    Validation to detect and filter out or reject all inputs or parameters that are incorrect or malformed; Recognition and defense against attempts to exploit incorrect and hidden assumptions, in order to force the software‘s components to behave insecurely; Ability to handle unexpected, unlikely, and even presumably ―impossible‖, events in ways that do not leave the software, the data it ―touches‖, or its environment vulnerable to compromise or subversion; Ability to isolate and contain the damage resulting from a successful attack so that the damage does not affect other parts of the software, the data it ―touches‖, or its execution environment; Ability to recover quickly after a failure, either through its own built-in fault-tolerance capabilities, or by being designed to rapidly notify and support recovery actions by the administrator.   (3) Defect and Vulnerability Management. Security vulnerabilities can manifest from defects introduced into software at any lifecycle phase. The resulting security vulnerabilities can be targeted by knowledgeable attackers in order to compromise the security of the critical, sensitive information that is handled by that defective software. The supplier should have a mature process that routinely collects data and metrics on defects and their mitigation. This demonstrates a dynamic, ―closed loop‖ feedback process to track software quality trends and remediation activities. In addition, the supplier should have a process for obtaining, tracking, and prioritizing reported vulnerabilities and security incidents involving the software, as well as an established methodology for rapidly addressing high priority vulnerabilities in the software. Refer to Section 5 Contracting: ―Securely Configuring Commercial Software‖ for more details. (4) Security Knowledge of Developers. A large percentage of security defects in software could be avoided if developers consciously thought about avoiding them. Acquirers should seek software suppliers that educate their developers in security best practices. The vast majority of developers are not being taught how to recognize and understand the security implications of their development practices. Nor are they being taught how to change their current development practices in order to develop software more securely. Although internalizing the importance of secure software principles will not solve all security problems related to software, it does instill in developers the discipline of thinking through possible errors, of checking for corrupt inputs and parameters, and of programming defensively to handle unexpected problems. The result will be that they develop programs that are better thought out, better structured, and more secure. Defensive programming teaches students how to look for hidden assumptions in their programs, and how to defend 67 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Appendix C. Generic Questionnaire against attempts to exploit those assumptions to cause their programs to behave in unexpected or undesirable ways. In addition, software organizations need to not only ensure that their developers obtain and maintain their security knowledge, but need to reward the application of that knowledge through consistent use of secure development practices and production of secure software, and also to remediate the inadequate practices of developers who consistently produce insecure software. (5) Software from ―Third Party‖ Developers. Many software organizations are themselves acquirers of software, and outsourcers of development services. These software organizations need to ensure that security criteria are included among the selection criteria used in choosing the external entities who they contract to develop software for them. Furthermore, the organizations need ensure that those entities understand the security requirements for the software they deliver. Finally, a software organization that obtains software from an external entity needs to include in its own lifecycle processes the necessary security checks to ensure that the outsourced software is no less secure than the software developed by the organization itself, or that if it is less secure, the overall software package into which it will be incorporated contains the necessary self-defense measures to reduce the risks posed by using the less-secure outsourced software. Extra considerations need to be factored into risk mitigation when the third party software in ―open-source software.‖ C.2.5.4 Value Suppliers that implement the above preventative controls are more likely to produce software that can:    Resist and/or withstand the majority of anticipated attacks; Recover rapidly with a minimum amount of damage from the most ingenious, competent anticipated attacks. Provide management with information that the metrics will give them proof that the software being acquired is trustworthy. C.2.5.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Role 1 1a “Security Minded” Software Engineering What is your software development methodology? Secure risk-driven methodology Does your organization incorporate security risk management activities as part of this methodology? If yes, please provide a copy of the documentation of this methodology, or information on how to obtain it from a publicly-accessible source. NOTE: If the answer is “yes”, the supplier needs answer only those of the following questions that are not clearly addressed in the documentation of the secure development methodology used. x x x 68 Software Security Acquisition Guide Number/Question 1b Use of threat modeling: Are anticipated threats to the software identified, assessed, and prioritized? If so, what techniques and tools are used? When and how often are threats reassessed and reprioritized? How is this information used in the development of the software? Frequent security checkpoints: Does the development process include security analyses, reviews, and/or tests (as appropriate) at each phase of the development lifecycle? What techniques and tools are used for each analysis, review, and test? NOTE: Answer for all lifecycle phases that are relevant given the type of development effort and the methodology used. Security exit criteria: Do the exit criteria for each lifecycle phase include security criteria that expressly check for the following?:  The correct, predictable, and consistently reliable behavior of the software throughout its execution  The absence of exploitable defects (i.e., vulnerabilities)  The ability of the software to resist attempts to intentionally subvert it during execution (for example, through insertion of malicious logic)  The ability of the software to resist attempts to intentionally induce its failure during execution (i.e., denial of service)  The ability of the software to recover from failures, including intentionally-induced failures NOTE: Answer for all lifecycle phases that are relevant given the type of development effort and the methodology used. Secure configuration control: Are configuration/change controls in place to prevent developers from making unauthorized modifications or additions to any of the software artifacts at any point in the development lifecycle? Do these controls detect and report unexpected modifications/additions to artifacts? Do they aid in rolling back an affected artifact to a pre-modified version? Tool support for secure development: Are tools provided to help developers (1) produce secure software; (2) verify that the software they have produced is secure? x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing Criticality Role 1c x x x x 1d x x x x 1e x x x 1f x x x 69 Software Security Acquisition Guide Number/Question 2 2a Self-Defending Software Secure design and implementation: Has the software been developed using secure software design and implementation best practices? NOTE: At a minimum, these best practices should include those discussed in Appendix G of the DHS document entitled Security in the Software Lifecycle, Version 1.0. Security-aware exception handling: Does the software’s exception handling mechanism prevent all faults from leaving the software, its resources, and its data (in memory and on disk) in a vulnerable state? Does the exception handling mechanism provide more than one option for responding to a fault? If so, can the exception handling options be configured by the administrator? Attack-awareness: Is the software able to detect, recognize, and respond to attack patterns in input it receives from human users and external processes? If more than one response to an attack pattern is possible, can the responses be configured by the administrator? Constrained execution environment: Has the software been designed to execute within a constrained execution environment (e.g., virtual machine, sandbox, chroot jail) designed to isolate and minimize the extent of damage possible by a successful attack? Explicit administrator approval of new code: Does the software default to requiring the administrator (or user of a single-user software package) to expressly approve the automatic installation of patches/upgrades, downloading of files, execution of plugins or other “helper” applications, and downloading and execution of mobile code? Defect and Vulnerability Management Defect and vulnerability reporting: How are reports of defects, vulnerabilities, and security incidents involving the software collected, tracked, and prioritized? EXAMPLE: Does the software include an automated reporting capability whereby failures and anomalies trigger automatic transmission of a notification message from the software to the organization’s defect management system? x x x x x x COTS Custom Appendix C. Generic Questionnaire System Integration Service & Outsourcing Criticality Role x 2b x x x x 2c x x x x 2d x x x x 2e x x x x 3 3a x 70 Software Security Acquisition Guide Number/Question 3b Handling of reported defects/vulnerabilities: At each priority/severity level, how and when is a reported defect or vulnerability in the software addressed? Security Knowledge of Developers Security training of developers: Are the organization’s developers trained in secure development practices? If so, describe this training. Is the training optional or mandatory? Secure development standards/guidelines: Does the organization provide secure development standards and/or guidelines to developers? Software from “Third Parties” Presence of third-party content: Does the software include content produced by an entity external to the main supplier organization? NOTE: If the answer is “no”, the organization need not answer the remaining questions in this section. Evaluation criteria for third-party developers: What security criteria, if any, are considered when selecting third-party developers to produce software for the organization? Third-party developer contractual obligations: Is delivery of demonstrably secure software a contractual requirement? If yes, what criteria are used to operationally define “secure software”. Evaluation of third-party sourced software: How is the security of software produced by third-party developers assessed by the organization? Do the acceptance criteria for such software include the security criteria described in 1d above? Risk management for third-party sourced software: Are additional risk management measures in place in the software’s design to mitigate risks posed by use of third-party components? x x x x x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x Criticality Role 4 4a 4b x x x x 5 5a x 5b x x 5c 5d x 5e x x 1 2 3 4 5 C.2.5.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Rating (check one) 71 Software Security Acquisition Guide Facto r ID Medium Risk Cues Appendix C. Generic Questionnaire NA Risk Factors Low Risk Cues High Risk Cues NI TB D M H Notes Preventive Measures 1 2 3 4 5 1 2 3 4 5 C.2.5.7  References DHS: Security in the Software Lifecycle, April 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v08% 2001092006.pdf L  72 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 C.2.6 QUALITY CONTROL C.2.6.1 Objective Inasmuch as software must be designed and developed with consideration for minimization of exploitable defects, it should also be designed to operate within a welldefined ―quality continuum‖. The level of quality inherent to software is ultimately a byproduct of the quality of its ―supply chain‖; i.e. software Quality of Service (QOS) can be somewhat inferred by examining quality metrics at each of the stages implemented to produce and manage the software. Beyond assessing correctness of operation after the software is deployed, it is important to evaluate the models, methodologies, and tools used to develop and assemble the software for quality. This may include gauging the effectiveness and depth of configuration management practices employed by the vendor as the software is developed. In addition, providing the vendor has supplied and/or fielded previous software products in the target infrastructure, evaluators may elect to gather quality-related metrics relevant to the management support contracts for these products, in order to approximate the level of support quality that will likely be available to the software integrator once the software under consideration is fielded. Examples of quality-related metrics include: frequency/average number of trouble-ticket events per product, mean time to vendor response to issue, mean time to resolution, etc.) The intent of this section is to arm the acquirer with questions relevant to the quality of the vendor‘s software supply chain, including the following areas of interest: Definition – Questions related to addressing QOS at the concept definition phase or business tier. Design/Development – Questions related to the quality, robustness, and maturity of design methodologies, models, and tools, as well as supplier-side software component assembly and development. Testing - Questions related to supplier-side configuration management practices and consistency of design (see technical approach). Installation/ Acceptance – Questions related to the quality of software distribution entities and depth of supplier-provided acceptance training program(s). Maintenance – Questions related to quality of post-acquisition support services, such as trouble ticketing, patch distribution, and help desk support, for example. * * Note: Maintenance concerns are also addressed in Section 2.7: Operations and Support. As such, this section will only address Maintenance concerns from a quality-based perspective – to include questions relevant to inferential metrics, as discussed above. C.2.6.2 Assumptions The following assumptions have been made in preparing this section: Software Quality on the whole can be reasonably inferred by individually analyzing quality at each of any number of relevant Software Development Lifecycle (SDLC) phases. Software Quality can be reasonably inferred by analyzing the quality of other products under the vendor‘s purview, including examining support contracts for these products. 73 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Appendix C. Generic Questionnaire The acquirer has knowledge of the configuration management practices employed internally by the vendor(s)/ supplier(s). The acquirer has knowledge of the design models/ methodologies used to develop the software. C.2.6.3 Approach The considerations for this section are divided into several phases, consistent with the areas of interest previously addressed. (1) Definition. End-to-end software quality assurance requires an appropriate level of management and business tier buy-in during the software concept definition phase. As with Information/ Software Assurance, an organization‘s level of commitment to Quality of Service (QOS) or Total Quality Management (TQM) can be partially assessed by evaluating organizational policies (see Section 2.2). Evidence of implementation of quality-focused process models and methods, such as ISO 9000, Six-Sigma, and/or CMM, can provide indications of the maturity and depth of the supplier‘s TQM program, which would ideally carry over to every software-related project. In addition, data gleaned through software and supplier pedigree analysis (Section 2.3) may suggest how well the supplier has historically accounted for quality considerations. (2) Design/Development. Organizational TQM processes should carry through to the software design phase; however, in the case of maturity ratings for software, evaluators should confirm that the software is certified to at least the same level of maturity as the organization itself. Beyond evaluating process-level maturity, acquisition managers may assess individual software design models for indications of design robustness – including robustness of quality elements. If available, software use cases can provide insight into design thoroughness, depending on the depth of usage scenarios. Materials related to the supplier‘s risk analysis program or any variation of a software threat modeling program may also be useful. Given the relationship between providing sustained QOS in operation and maintaining availability of services to end customers, these materials may suggest how well the supplier has committed to reducing software vulnerabilities in design that could impact availability, such as buffer overflows and race conditions, for example. In general, the more design artifacts the supplier can make available to the evaluator, the better the supplier‘s implied level commitment to TQM will likely be throughout the full scope of the product‘s lifecycle. (3) Testing (supply-side). Quality control mechanisms must also carry through to the supplier‘s software testing practices. The existence of a well-defined version control and bug tracking system, for example, can suggest a well-contained and organized development process – resulting in a well-contained and organized end product. Depending on the variety and type of internal functional tests performed, a certain degree of quality can logically be assumed. For example: Performing software component-level tests versus fully-integrated functional system tests allows for the means to more granularly assess software correctness and quality. In addition, the existence of TQM byproducts, such as decision trees, may indicate how the supplier manages and orchestrates design changes from one organizational tier to another. Another consideration in this phase is the notion of ―consistency of design‖, whereby software should be verified to operate clearly within the bounds of its underlying requirements and design specifications. Somewhat akin to ―transparency of function‖, design consistency can also be assessed by comparing design artifacts from the previous 74 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Appendix C. Generic Questionnaire phase against one another, in order to assure that design objectives and requirements are properly promulgated and consistently represented across these artifacts. (4) Installation/ Acceptance. Continuing the end-to-end TQM program, software quality should also be maintained throughout the installation and acceptance phases. This may also require an analysis of entities affiliated with the shipping and/or distribution of the software, providing a ―middle-man‖ exists between the supplier and the integrator. To this end, many of the same questions in Section 2.1 including those related to organizational pedigree, may be relevant in this phase – however directed towards the distributing organization. The supplier must also be committed to providing an acceptable level of support during the installation process, and specific metrics such as installation and configuration times may be relevant in this phase. Finally, by evaluating the extent, quality, and depth of supplier-provided training and certification programs, evaluators can also assess the supplier‘s commitment to acceptance once the software is acquired. (5) Maintenance. As previously stated, operational maintenance is additionally addressed in Section 2.7, however there are several maintenance considerations that are specifically relevant to quality assurance, and the questions provided reflect these concerns. In general, these concerns include the following: Robustness of patch distribution services/ functions Availability/distribution of functionality updates Quality of trouble-ticketing and escalation services Help Desk response and depth of service Inferential quality-relevant support metrics As discussed in the objective to this section, several metrics may potentially be gathered from other products to infer the potential level of operational QOS the product under evaluation may provide once it is fielded. These metrics are by no means definitive; however they may establish trends that reasonably suggest prevalence of incidents, average downtimes, response and resolution times, and a general indication of the quality of support the supplier provides to its customers. C.2.6.4 Value The value for addressing Quality Control and TQM in this section includes the following: Software quality that can be reasonably assured from end-to-end; Indication of a supplier‘s commitment to software quality; Software that is robust, limited in defects, and transparent in function. C.2.6.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Role 1. 1a Definition Does the company have a formal Quality of Service or Total Quality Management program? If yes, are staff dedicated to the QOS or TQM program throughout a software product’s development lifecycle? What are their roles and responsibilities? x x x x 75 Software Security Acquisition Guide Number/Question 1b Are there formal software quality policies in place? How are they enforced? Is the supplier ISO 9000, CMMI, or Six-Sigma certified? If yes, what is the current certification level? When was the certification obtained? What tools and/or techniques are used to facilitate meeting quality goals? Design/Development What analysis, design and construction tools are used by your software development teams. What development methodology, if any, is used? How is its use enforced? Are software interfaces documented in published documentation? How are confidentiality, availability, and integrity addressed in the software design? What threat modeling process, if any, is used when designing the software? How are design artifacts for completed software applications archived? Testing What version control, bug and issue tracking processes and policies are in place. What tools are used to support the processes and policies? What types of functional tests are/were performed on the software during its development (e.g. spot checking, component-level testing, security testing, integrated testing, etc.)? To what frequency are/were functional tests performed? What processes are in place for communicating design/code changes throughout the organizational hierarchy? What tools, if any, are utilized? Installation/Acceptance If the vender is responsible for installing the software, is this done by the vendor’s professional services organization, or through 3rd party consultants? If consultants are used, is there a process for certifying them? x x x x x x x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x Criticality Role 1c x x x x 1d x x x x 2 2a 2b x x x 2c 2f x x x x x x 2e x x x 2f x x x 3 3a 3b x x x 3c 3d x x x x x x 4 4a x 76 Software Security Acquisition Guide Number/Question 4b What are the average times for a) processing of orders, b) delivery of products, c) installation of software, d) initial configuration of software? What training programs, if any, are available or provided through the supplier for the software? Does the supplier offer certification programs for software integrators? Does the supplier offer training materials, books, CBTs, online educational forums, or sponsor conferences related to the software? Maintenance How are patches and Service Packs distributed to customers? How are trouble tickets submitted to the support organization? How are support issues escalated? What is the average response time for responding to a trouble ticket? What is the average time for closing a trouble ticket? What services does the help desk, support center, or (if applicable) online support system offer What is the average response time of the help desk or support center? Are multiple tiers of support contracts available? If yes, please describe the support plans available. Are help desk or support center personnel internal company resources, or are these services outsourced to 3rd parties? If help desk or support center services are outsourced to 3rd parties, are they located in foreign countries? x x x x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing x Criticality Role 4c x x x x 5 5a 5b x x 5c 5d 5e x x x x x x x x x x x x 5f 5g x x x x x x x x 5e x x x x 5f x x x x 1 2 3 4 5 6 Rating (check one) Factor ID Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues TBD NA Notes NI M H L C.2.6.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Quality Controls 1  77 Software Security Acquisition Guide 2 3 4 Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 C.2.6.7 References NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v08 %2001 092006.pdfOWASP, Guide to Building Secure Web Applications and Web Services, July 27, 2005. http://www.owasp.org/documentation/guide.html Fred Cohen, Enterprise Patch Management: Strategies, Tools, and Limitations, 9 January 2004. http://www.burtongroup.com 78 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Appendix C. Generic Questionnaire C.2.7 OPERATIONS AND SUPPORT C.2.7.1 Objective Operations and Support is the last phase of the SDLC (other than disposal). In this phase, software is in-place and operating, and upgrades or patches to the software are developed by the supplier. The software is monitored for continued performance in accordance with user requirements, and needed software modifications are incorporated. The operational software is periodically assessed to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization‘s needs. When modifications or changes are identified as necessary, the software may reenter another phase of the life cycle. It is important to find out from the supplier how will they provide ongoing support of software as well as how proactive they are in addressing vulnerabilities. The primary objective of this section is to provide a set of questions that would help the acquisition manager in identifying specific operations and support risks and the adequacies of the approaches proposed to mitigate those risks. C.2.7.2 Assumptions The following assumptions have been made in preparing this section: The acquirer has an understanding of, or assistance with, Information Assurance issues. The acquirer follows its security policies or other security policies set forth by other organizations such as NIST or ISO. There are adequate controls in place for configuration management. There is buy-in from top management for acquiring secure software. C.2.7.3 Approach The considerations for this phase are divided into the following six sections. (1) Configuration Management. Information systems will typically be in a constant state of migration with upgrades to hardware, software, or firmware and possible modifications to the surrounding environment of the system. The schedules and frequency of new releases, updates, and security (and non-security) patches, and response times for technical support by software suppliers, are beyond the control of the acquirer. Weak change control procedures can corrupt software and introduce new security vulnerabilities. Preferably, the software should have the ability to ―phone home‖ to check for newer versions and alert system administrators when new versions are available. If this is not possible, for example, in highly protected environments where ―phone home‖ features are not allowed, another method should be offered to keep the administrators up to date. (2) Continuous Monitoring. Patches and upgrades make direct changes to the software and potentially the configuration of the operating system to which they are applied. The changes may degrade performance, introduce new vulnerabilities, or reintroduce old vulnerabilities. In order to understand the patch risks, the patch process must be examined in some detail. Many companies apply patches to test systems before releasing them throughout the enterprise. However, as the scale of the patch management problem grows, this becomes problematic. Unless the software package comes with a validation test suite, it is difficult to determine if the software is operating properly after a patch. In addition, most validation suites do not test software to their failure points. 79 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Appendix C. Generic Questionnaire Instead, they perform simple operational tests to determine if normal operations will work in simple conditions. In addition to the patches themselves, hardware, drivers, and detailed configuration settings for the operating system and each of the applications on the system impact the proper functioning of patches. The software and its operating environment should be regularly reviewed through periodic testing and evaluation. This continuous monitoring helps ensure that controls continue to be effective and that they have not unintentionally been relaxed. Refer to Section 5 Contracting: ―Securely Configuring Commercial Software‖ for more details. (3) Validation. One of the most common patch failures stems from a lack of encryption and authentication in the deployment process. Suppliers should provide updates in a secure fashion. There should be no doubt that the source is legitimate and the update‘s integrity is maintained in transit. End-to-end assurance of patch integrity using vendor-supplied public keys for verification is one of the prudent approaches to this process, but it is by no means the only one or a perfect one. Support personnel that require access to the software should have credentials that can be validated prior to access. (4) Support of Old Releases. It is normal within the industry to provide support for n1 to n-2 versions of software. If the acquirer knows that they will not keep up with the supplier‘s release schedule, the acquirer will need to determine if there is a point at which the non-updated version of the software will no longer be supported by that supplier and some form of source revision control will be necessary to manage security bug fixes to avoid regression errors. The risks associated with using unsupported software will then have to be weighed against the risks of adopting a new version of the software, or replacing it with an alternative product. The supplier‘s support policy for security fixes should also be clearly communicated to the acquirer, to ensure understanding of which versions are supported for security fixes and when products are due to be end of lifed. The supplier‘s willingness to support older versions for a fee may be something worth negotiating during acquisition. (5) Timeliness of Vulnerability Mitigation. Large numbers of vulnerable systems exist today, predominantly because the designers and implementers of those systems, or components of those systems, are unable or unwilling to produce systems that are free or close to free of those vulnerabilities. A large number of attackers have the skills required and discover these vulnerabilities at a significant rate. Software suppliers with a good record of security fixes will often gain early insight into security vulnerabilities. Others will have many public vulnerabilities published to 0 day boards or mailing lists. Software support should incorporate a process to update and patch software to mitigate newly discovered vulnerabilities. Sometimes it can be extremely difficult to make the software supplier take notice and repair software to eliminate reported vulnerabilities. COTS vendors are notoriously unwilling to divert resources and change their release schedules to accommodate customer requests for corrections or improvements to their products. Vendors are also notorious finger-pointers: any reported vulnerability would, of course, lie not with their software but with someone else‘s. Such vendor reactions are not intentionally malicious, but they have the result of rendering many software packages less than optimally secure nonetheless. In the case of security patches, acquirers can never be sure when or even if the supplier of software will release a needed security patch for a reported vulnerability that might render software otherwise unacceptable for use. (6) Component Assembly Support. For secure integration/assembly of acquired or reused software components to be possible, the components selected must be thoroughly vetted for their security properties, secure behaviors, and vulnerabilities. The acquirer needs to determine and understand how the security of the assembled/integrated 80 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Appendix C. Generic Questionnaire application may be affected by new behaviors or interfaces introduced in the updated software. This is particularly true because suppliers often embed non-security-related features in their ―security patches‖, i.e., features that will later appear in the next full release of the software. Unfortunately, these as-yet-undocumented features are seldom announced when delivered with the patch. Detecting such features can present a significant challenge to acquirers who must understand their potential impact on a component‘s behavior when interfacing with other components. There should be an ongoing analysis operations phase to assure that its security requirements remain adequate and that it continues to satisfy those requirements correctly and completely even as acquired or reused components are patched, updated, and replaced. Software/applications are executed by and are supported by an operating system for interfaces to the network, other applications, or data. It is important that the operating system be hardened to minimize vulnerabilities. Changes to operating system configurations may degrade the security of applications that rely on the operating system. Generally, management should implement an operating system change control process similar to the change control process used for application changes. In addition, management should review application systems following operating system changes to protect against a potential compromise of security or operational integrity. C.2.7.4 Value The value for addressing operations and support security issues includes: Software that can be properly maintained post deployment; Minimized attack surface throughout the production life cycle; Security defects are fixed properly and in a timely fashion; Raised awareness of potential support issues. C.2.7.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Role 1. 1a 1b 1c 1d Configuration Management How frequently are major versions of the software released? How frequently are incremented minor versions of the software released? How frequently are patches and Service Packs released ? How many patches released in the previous 12 months were critical security updates, or highly recommended security updates? How extensively are patches and Service Packs tested before they are released? Does the vendor provide a validation test suite or diagnostic software and/or hardware to validate that the application software is operating correctly after being installed? Can patches and Service Packs be uninstalled? Are the procedures for uninstalling a patch or Service Pack automated or manual? x x x x x x x x 1e x x 1f x x x 1g x x x 81 Software Security Acquisition Guide Number/Question 1g How are customers informed that a patch or Service Pack is available? Does the vendor provide an automatic update service? Continuous Monitoring Will software changes, updates and patches be prohibited from making any changes to configuration settings, such as reverting them to default or null values? Validation Is there a method of obtaining updates or patches from a known, trusted source? How can the integrity of the update/patch be verified to ensure that it is correct and unaltered (e.g., comparisons of cryptographic hashes)? What credentials are required to gain access to patches and Service Packs? What credentials are available for support resources that require access (remote or on-site) to the software? Support of Old Releases Does the vendor have a formal Support Lifecycle Policy that provides consistent and predictable guidelines for product support availability at the time of product release? Does this policy apply to patches and Service Packs? For products that release new versions annually, what is the minimum duration of support from the product's date of availability? Historically, how long are software products maintained before support is terminated? Much notice is provided before termination of support? Historically, what is the time interval between the announcement of a support expiration date and actual termination of support? Is extended maintenance available beyond the announced expiration of support? How long can extended maintenance be provide? Timeliness of Vulnerability Mitigation Does the supplier have a vulnerability management and reporting policy? x x x x x x x x x x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x Service & Outsourcing Criticality Role 2 2a 3 3a 3b x x x 3c x x x 3d x x x 4 4a x 4b x x x x 4c x x x x 4e 4f x x x x x x x x 4g x x x x 5 5a x 82 Software Security Acquisition Guide Number/Question 5b Will the supplier continue support for older releases for an additional fee? How long is such extended support available? Historically, what is the average duration of time between identification of a verified vulnerability and release of a patch. Does the supplier publish a security section on their web site? If so, does it have the ability to submit a security vulnerability? Can the vulnerability be submitted in a secure fashion (such as exchange of PGP keys or via SSL)? Component Assembly Support Does the software have any security critical dependencies or need additional controls from other software (e.g., Operating System, directory service, applications), firmware or hardware? If yes, please describe. Does the vendor have a matrix by platform of any security critical dependencies? Does the software have any undocumented features? What is the vendor’s policy regarding undocumented features? Are there any undocumented features present not intended for use by end users, but available for use by the vendor for technical support and development? Does the software utilize closed source APIs that have undocumented functions ? Is technical support provided for undocumented features? x x x x COTS Custom x Appendix C. Generic Questionnaire System Integration x x Service & Outsourcing Criticality Role 5c x x x x 5d x x x x 6 6a 6b x x x 6c x x x x 1 2 3 4 5 6 Rating (check one) Factor ID Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues TBD NA Notes NI M H L C.2.7.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Operations and Support 1 2 3 4  83 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 Appendix C. Generic Questionnaire C.2.7.7 References NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20 v08%2001092006.pdf OWASP, Guide to Building Secure Web Applications and Web Services, July 27, 2005. http://www.owasp.org/documentation/guide.html Fred Cohen, Enterprise Patch Management: Strategies, Tools, and Limitations, 9 January 2004. http://www.burtongroup.com 84 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 C.2.8 SERVICE GOVERNANCE C.2.8.1 Objective If a supplier is offering to provide a service, instead of a stand-alone software package, the acquirer should consider the governance of these services. Governance refers to the programs and processes that an organization puts in place to ensure that things are done right, where ―right‖ means in accordance with best practices, architectural principles, federal regulations, and other determining factors. The following are the types of threats to which acquirers using services may be vulnerable: Failure of available service, due to failure of a component denial of service attack inadequate capacity or performance attacks against infrastructure unauthorized or uncontrolled modification of content of a transaction unauthorized or uncontrolled modification of system or application software unauthorized or uncontrolled access to web site content non-malicious error Failure of integrity, due to - Failure to preserve confidentiality of sensitive customer information, due to - unauthorized or uncontrolled access to confidential data - unauthorized or uncontrolled modification of software - non-malicious error The primary objective of this section is to provide a set of questions that would help the acquisition manager in identifying specific risks that should be considered by the service provider, the adequacies of the security measures to mitigate those risks, and the evidence that those measures are enforced and effective. C.2.8.2     Assumptions The following assumptions have been made in preparing this section: The supplier is providing access to software through a service. The service may be a Web service, a managed service, an ASP, or some other service type. The acquirer does not possess the software and is not in control of the platforms on which it resides. The supplier controls the operating environment in which the software executes. C.2.8.3 Approach Good governance of services is required to ensure that the acquirer‘s sensitive data will be adequately protected and be available when needed. Control structures must not only ensure the appropriate operation of access controls, but they must also carry out security obligations such as audit, monitoring, and alerting. 85 Software Security Acquisition Guide 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Appendix C. Generic Questionnaire Web services provide a cross-platform application-integration fabric for enterprise computing. Web services models will further fragment resources by breaking applications into subcomponents. Service Oriented Architecture (SOA) is a software design discipline in which Web services and infrastructure functionality is implemented. On one side, a SOA initiative strives to open up IT systems to enable greater visibility and integration. But on the other side, it‘s critical to ensure that these systems are also properly protected. A SOA infrastructure must provide mechanisms that protect services from unauthorized, fraudulent, or malicious use. It must protect the confidentiality and integrity of message traffic. It must protect IT systems from viruses, worms, Trojan horses, and other malware. In many cases, service interactions will cross security domains; therefore, the SOA infrastructure must provide mechanisms that support identity credential mapping and crossdomain identity federation. C.2.8.4 Value The value for addressing service-related security issues include: Understanding of the controls the supplier has established to operate the software in a secure manner; Identification of deferent service levels available that could enhance security and better meet acquirer needs for CIA; Acquirer can manage risks associated with supplier‘s operating environment once they are known. C.2.8.5 Questions to Consider Asking the Suppliers Number/Question COTS Custom System Integration Service & Outsourcing Criticality Roles 1. 1a Service Policies and Procedures What are your customer confidentiality policies? How are they enforced? What are your customer privacy policies? How are they enforced? What are your data backup policies and procedures? How frequently are your tape backup procedures verified? What are your procedures for intrusion detection, incident response, incident investigation/ escalation? Do you have audit procedures for enduser network security (to assure that other end-users will not compromise host or production backbones)? What service level guarantees do you provide? What is the physical security at your facility hosting the service (e.g., Data Center). If multiple facilities are in use, are the physical security measures essentially the same at each Data Center? X X X X 1b 1c X X X X 1d X X 1e X X 2 2a 86 Software Security Acquisition Guide Number/Question 2b If properly identified and previously authorized acquirer representatives (employees and contractors) must have access to the supplier’s data center(s), how would the supplier support this requirement? What if such visits were unannounced? Operating Environment Who owns the server equipment? Who configures and deploys the servers? Are the configuration procedures available for review, including documentation for all registry settings? What type of periodic maintenance is performed on the servers? What are the procedures for evaluating operating system vendor security alerts and installing patches and Service Packs? How are patches and Services Packs applied? Is testing done after changes are made to servers? What are your backout procedures in the event of problems resulting from installing a patch or Service Pack? What reporting do you provide on server utilization, performance, etc.? What are the agents or scripts executing on servers of hosted applications? Are there procedures for reviewing the security of these scripts or agents? What are the procedures and policies used to approve, grant, monitor and revoke access to the servers? Are audit logs maintained? How are virus prevention, detection, correction and updates handled for the servers? What type of firewalls (or application gateways) do you use? How are they monitored/managed? What type of IDS/IPS do you use? How are they monitored/managed? What are your procedures and policies for the handling and the destruction of very sensitive data on electronic and printed media? Do you have a formal disaster recovery plan? What actions will be taken to recover from a disaster? Are warm or hot-backups available? X X COTS Custom Appendix C. Generic Questionnaire System Integration X Service & Outsourcing X Criticality Roles 3 3a 3b X X 3c 3d X X X X 3e 3f X X X X 3g 3h X X X X 3i X X 3j X X 3k X X 3l 3m X X X X 3n X X 87 Software Security Acquisition Guide Number/Question 3o What are the procedures used to approve, grant, monitor and revoke file permissions for production data and executable code? Is two-factor authentication used for administrative control of all security devices and critical information systems? Security Services Available What are the policies and procedures used to protect sensitive information from unauthorized access? How are the policies enforced? What are the set of controls to ensure separation of data and security information between different customers that are physically located in the same Data Center? On the same host server? What are the types of IA services you provide? What are the various levels intrusion detection/prevention/response services that your company can support? Do you provide application and transaction-based intrusion detection services? Will you provide on-site support 24x7 to resolve security incidents? What are your policies and procedures for hardening servers? Are there any single points of failure in your system and network architecture? Is your system and network architecture based on a high availability design that includes redundant firewalls, routers, switches and IDS, and load balanced or clustered servers? Security Monitoring Do you have regular security audits performed by third-party security organizations on your data center and services? Do you perform regular reviews of system and network logs for security issues? Do you have an automated security event management system? Do you provide write-once technology for storing audit trails and security logs? X X COTS Custom Appendix C. Generic Questionnaire System Integration X Service & Outsourcing X Criticality Roles 3p X X 4 4a X 4b X X 4c 4d X X X X 4e X X 4f 4g 4h X X X X X X 4i X X 5 5a X 5b X X 5c 5d X X X X 88 Software Security Acquisition Guide Number/Question 5e How do you control physical and electronic access to the log files? Are log files consolidated onto single servers? Do you provide security performance metrics to the customer at regular intervals? Are security alerts from agencies such as CERT and SANS reviewed? Administrative Personnel What information security qualifications and/or certifications do your administrators possess? Do you perform background checks on all personnel with administrative access to host servers, applications and security devices? Web Services and Service Oriented Architectures Does your company’s requirements analysis process explicitly address quality requirements, security requirements, other non-functional requirements, and architecture, design, implementation, and testing constraints? What review processes are implemented to ensure that security requirements are unambiguous, traceable and testable throughout the entire SDLC Are security requirements, architecture and designs developed independently of the rest of the software engineering activities, or are they integrated into the mainstream activities? Do you have a security-focused quality assurance (QA) program in place? Do you have a security-focused quality control (QC) program in place? Do you provide penetration testing of the service? If yes, how frequently are penetration tests performed? Are the tests performed by internal resources or by a 3rd party? Do you provide automated vulnerability testing of the service? ? If yes, how frequently are the tests performed? Are the tests performed by internal resources or by a 3rd party? Do you provide manual or automated source code analysis on the service? If yes, are the tests performed by internal resources or by a 3rd party X X COTS Custom Appendix C. Generic Questionnaire System Integration X Service & Outsourcing X Criticality Roles 5f X X 5g 6 6a X X X 6b X X 7 7a X 7b X X 7c X X 7d 7e 7f X X X X X X 78 X X 7h X X 89 Software Security Acquisition Guide Number/Question 7i Does your company offer training related to defining security requirements, secure architecture and design, secure coding practices, and security testing? This may include traditional classroom training, eclasses (scheduled, instructor-led classroom experience delivered over the Web),workshops, and seminars. Is this training optional or mandatory? Does your company offer continuing education and training programs related to application security? Are continuing education and training programs optional or mandatory? What development methodology do you use? How do you address security issues in your development methodology framework? COTS Custom Appendix C. Generic Questionnaire System Integration X Service & Outsourcing X Criticality Roles 7j X X 1 2 3 4 5 6 C.2.8.6 Response Interpretation The table below represents an approach to assist the acquirer understand how to use the responses to the questions in their risk management decision process. It needs further development and will be populated in a future version. Rating (check one) Factor ID NA Risk Factors Low Risk Cues Medium Risk Cues High Risk Cues TBD Notes NI M H L Service Governance 1 2 3 4  7 8 9 C.2.8.7  References Gary McGraw, Software Security and SOA: Danger, Will Robinson! February 2006. http://www.cigital.com/papers/download/bsi12-soa.doc.pdf 90 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 C.3. References The documents below were used to help create the Questionnaire. Clinger-Cohen Act (CCA) of 1998, Public Law 104-106. Cohen, Fred, Enterprise Patch Management: Strategies, Tools, and Limitations, 9 January 2004. http://www.burtongroup.com Committee on National Security Systems Instruction (CNSSI) No. 4009, National Information Assurance Glossary, May 2003. DHS, Security in the SDLC, January 2006. https://buildsecurityin.uscert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20 v08%2001092006.pdf DCID 6/3, Protecting Sensitive Compartmented Information Within Information Systems, June 5, 1999. http://www.fas.org/irp/offdocs/DCID_6-3_20Policy.htm DODD 8500.1, Information Assurance, 24 October 2002. http://www.dtic.mil/whs/directives/corres/html2/d85001x.htm DoDI 5000.2, Operation of the Defense Acquisition System, May 12, 2003. http://www.dtic.mil/whs/directives/corres/text/i50002p.txt DoDI 8500.2, Information Assurance (IA) Implementation, February 6, 2003. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt DODI 8580.1, Information Assurance (IA) in the Defense Acquisition System,” July 9, 2004. http://www.dtic.mil/whs/directives/corres/html/85801.htm McGraw, Gary, Software Security and SOA: Danger, Will Robinson! February 2006. http://www.cigital.com/papers/download/bsi12-soa.doc.pdf National Security Telecommunication and Information Systems Security Instruction (NSTISSP) No. 11, National Information Assurance Acquisition Policy, July 2003. NIST Special Publication 800-64 REV. 1, Security Considerations in the Information System Development Life Cycle. http://csrc.nist.gov/publications/nistpubs/index.html OWASP, Guide to Building Secure Web Applications and Web Services, July 27, 2005. http://www.owasp.org/documentation/guide.html Section 3541 of Title 44, USC, Federal Information Security Management Act of 2002 (FISMA.) http://csrc.nist.gov/policies/FISMA-final.pdf 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 91 Software Security Acquisition Guide 1 Appendix D. Specific Questionnaire Appendix D. Due Diligence Questionnaire Specific D.1.0 Medical Devices The following is an example of a due diligence questionnaire that has been tailor to a specific software-intensive product. This questionnaire was developed by the Healthcare Information and Management Systems Society (HIMSS) IT Systems Security Workgroup. See http://www.himss.org/ASP/index.asp for more on the Society. The HIMSS IT Systems Security Workgroup membership consists of representatives from the medical device industry, medical device standards bodies, health care organizations, academia, United States Veteran‘s Health Administration, and United States Federal Drug Administration. See http://www.himss.org/content/files/MDSWorkgroupRoster.pdf for a membership list. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Questions to Assess Application Vendor Capabilities (V.5) Application name and vendor: Primary business functions supported: Instructions: Check ―Yes‖ to indicate the application‘s capability. If the system lacks the capability or the control is not in place then check ―No.‖ If you are unsure of the answer, then check ―D/K‖ for ―don‘t know.‖ Check ―N/A‖ if the question is non-applicable. Please provide any comments or explanations of other compensating controls as attachments to this form. 1. 1.1 1.2 1.3 1.4 1.5 ACCESS MANAGEMENT Does the application support integration with enterprise identity management system (e.g. Directory Services)? Does the application prohibit users from having multiple concurrent connections (active sessions)? Does the application force “new” users to change their password upon first login into the application? Can the user change their password at any time? Can the system administrator enforce password policy and/or complexity such as minimum length, numbers and alphabet requirements, and upper and lower case constraint, etc.? Can the application force password expiration and prevent users from reusing a password? Does the application send a notification alert to the “system administrator” after a predetermined number of consecutive unsuccessful logon attempts? a. If yes, indicate the alert (such as locking the user account, entry into audit log, e-mail notification, etc.): Is password transmission and storage encrypted and unviewable even to the systems administrators? Is user authentication controlled by other means besides user account and password? a. If yes, indicate what other mechanisms are used (e.g. certificates, token, biometric, etc.): Are there procedures to activate and inactivate a user who is no longer allowed access (e.g. a former employee for deactivation and emergency account for activation)? Yes No D/K N/A 1.6 1.7 1.8 1.9 1.10 92 Software Security Acquisition Guide Appendix D. Specific Questionnaire 1.11 1.12 Does the application have an automatic session lock or log-off security feature triggered after a defined period of inactivity? Can access be defined based upon the user’s job role? (Role-based access)? a. If yes, can application generate the list of users by job role? 2. 2.1 2.2 AUDIT CAPABILITIES Is audit log tracking a security feature available in the current version of this software application? If yes, then continue with 2.2; If no, continue with 2.9 Does the audit logging feature capture user access activity? a. If yes, list the data elements contained in the audit log: Yes No D/K N/A 2.3 Does the audit logging feature capture data access INQUIRY activity? a. If yes, list the data elements and levels of access contained in the audit log: 2.4 Does the audit logging feature capture data ENTRY activity? a. If yes, list the data elements contained in the audit log: 2.5 Does the audit logging feature capture data CHANGE activity? a. If yes, list the data elements contained in the audit log: Are audit log reports available for the current version of this software application? a. If yes, specify the types of reports: b. If yes, indicate if additional hardware or software (including any third-party software required to activate or utilize the audit logging and/or reporting feature: 2.6 2.7 2.8 2.9 Can the audit log “data” be exported to an external system for storage and or further analysis? Are audit log files protected from unauthorized alteration from system users and/or by the vendor support staff? Will a software enhancement for audit logging and/or reporting be available in the future? a. If yes, indicate when enhancements will be available: 3. SECURITY OF REMOTE ACCESS AND SUPPORT Yes No D/K N/A If the application does not support remote access and remote support, then skip to section 4. 3.1 Which connection method(s) are used to accomplish remote support? a. Dial-up b. Secure web tunneling c. VPN Client (specify authentication method here: d. Business-to-Business VPN using IPSec 93 Software Security Acquisition Guide e. Other: 3.2 Which remote support applications are utilized? a. PCAnywhere b. Remotely Anywhere c. VNC d. Telnet e. Other: 3.3 3.4 3.5 3.6 3.7 3.8 4. 4.1 Appendix D. Specific Questionnaire Indicate if the system supports wireless networking capabilities that might also be used for remote support? (I.e., satellite, GSM, WLAN, Bluetooth, etc.) Is the system capable of permitting the operator to accept or deny remote support attempts? Can remote support activities be directly linked back to an individual employee of the vendor? Do vendor support personnel have specific roles and accesses that limit access to ePHI? (see section 1.12) Does the audit system log remote support connection attempts and remote support actions such as application or configuration modifications? What additional security controls are used to mitigate the risks associated with remote access? PROTECTION FROM MALICIOUS CODE Is the system compatible with commercial off the shelf (COTS) antivirus software products for protection from malicious code? a. If yes, indicate types of programs (anti-virus, anti-spyware/adware, antispamware)? b. Does the system support "on-access" virus scanning? Yes No D/K N/A 4.2 4.3 4.4 5. 5.1 Does the system require an active connection to the Internet for operations or for support? Need to reword because a “yes” answer does not indicate a “good security” Indicate if the system communicates over any IP ports (e.g., FTP, HTTP, other non-standard): Does the system require administrator rights (e.g., local, domain, etc.) to function? Need to reword because a “yes” answer does not indicate a “good security” CONFIGURATION MANAGEMENT AND CHANGE CONTROL Are the medical device(s) and associated COTS hardware/software platforms default configured in accordance with a recognized configuration benchmark? a. If yes, indicate type of benchmark used: Has all application software used in operation of the device(s) been demonstrated to be fully functional on the associated software/hardware platform hardened in accordance with a recognized configuration benchmark? Will software updates be provided to the user in the form of complete replacement software images or incremental software patches/updates? a. If no, will software changes, updates and patches be prohibited from making any changes to configuration settings, such as reverting them to default or null values? Yes No D/K N/A 5.2 5.3 94 Software Security Acquisition Guide 6. 6.1 Appendix D. Specific Questionnaire DATA EXPORT AND TRANSFER CAPABILITIES Does the application send data using the HL7 standard transaction format? a. If yes, indicate the version(s) of HL7 supported: Yes No D/K N/A 6.2 6.3 6.4 6.5 6.6 Does the application accept data formatted in HL7 transaction formats? Does the application format data using ANSI X.12 standards? Does the application support CCOW authentication? Can the system support extract and formatting of messages and transactions for other formats and emerging standards (such as Continuity of Care Record)? Does the system encrypt messages before sending? a. If yes, indicate the encryption used: 7. 7.1 7.2 OTHER CAPABILITIES Does the application use standard port assignments per the list of registered ports published by IANA? Does the application provide for integration into standard network domain structures? Yes No D/K N/A 1 REFERENCES SECTION 3. Remote Access and Support REFERENCE 1. (Clinical and Laboratory Standards Institute. Remote Access to Clinical Laboratory Diagnostic Devices via the Internet; Proposed Standard. CLSI document AUTO9-P [ISBN 1-56238560-7]. Clinical and Laboratory Standards Institute, 940 West Valley Road, Suite 1400, Wayne, Pennsylvania 19087-1898 USA, 2005.) 2. REMOTE SERVICE INTERFACE – SOLUTION (A) Revision 2: IPSec over the Internet Using Digital Certificates. Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC). Secretariat: NEMA (National Electrical Manufacturers Association) www.nema.org 1300 North 17th Street, Suite 1847, Rosslyn, VA 22209 USA 3. Security and Privacy for Remote Servicing. Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC). Secretariat: NEMA (National Electrical Manufacturers Association) www.nema.org 1300 North 17th Street, Suite 1847, Rosslyn, VA 22209 USA 5. Configuration Management And Change Control 4. For configuration benchmarks, reference: Center for Internet Security http://www.cisecurity.org 2 3 95 Software Security Acquisition Guide Appendix D. Specific Questionnaire 1 DEFINITIONS OF TERMINOLOGY Authentication The process of determining that an entity (someone or something) is the one claimed to be. The process of granting rights or access to systems, applications, or networks. Authorization determines who is trusted for a given purpose. HL7 provides the standard for clinical context management -- called CCOW -- that establishes the basis for ensuring secure and consistent access to patient information from dissimilar sources. CCOW was pioneered in 1996 by an independent consortium of vendors and healthcare providers Authorization CCOW CCOW formerly stood for Clinical Context Object Workgroup, but is now just an acronym COTS Healthcare organization (HCO) IANA Commercial Off The Shelf software All components of an organization where the IT application is installed (Internet Assigned Numbers Authority, www.iana.org) The Internet body that was responsible for managing Internet addresses, domain names and protocol parameters. It has been superseded by ICANN (Internet Corporation for Assigned Names and Numbers), which was formed in 1998. IANA was chartered by the Internet Society (ISOC) and Federal Network Council (FNC) and has been located at and operated by the Information Sciences Institute at the University of Southern California. Source: TechEncyclopedia (www.techweb.com/encyclopedia) 2 96 Software Security Acquisition Guide 1 Appendix E. Bibliography [CCA] Clinger-Cohen Act of 1996, Public Law 104-106. [CNSSI No. 4009] U. S. Committee on National Security Systems. (May 2003). National Information Assurance (IA) Glossary. Ft Meade, MD: National Security Agency. [COHEN] Cohen, F. (9 January 2004). Enterprise Patch Management Strategies, Tools, and Limitation. [DCID 6/3] Protecting Sensitive Compartmented Information Within Information Systems, 5 June 1999. http://www.fas.org/irp/offdocs/DCID_6-3_20Policy.htm [DoDI 5000.2] Department of Defense Instruction (12 May 2003). Operation of the Defense Acquisition System. Washington, DC: U. S. Department of Defense. http://www.dtic.mil/whs/directives/corres/text/i50002p.txt [DoDD 8500.1] Department of Defense Directive 8500.1 (24 October 2002-certified current as of 21 November 2003). Information Assurance (IA). Washington, DC: U.S. Department of Defense. http://www.dtic.mil/whs/directives/corres/html2/d85001x.htm [DoDI 8500.2] Department of Defense Instruction 8500.2 (6 February 2003). Information Assurance (IA) Implementation. Washington, DC: U.S. Department of Defense. http://www.dtic.mil/whs/directives/corres/text/i85002p.txt [FAR, 2005] Federal Acquisition Regulation. http://farsite.hill.af.mil/archive/Far/200505_27Jul05/31.htm [FIPS Pub 199] Federal Information Processing Standard (FIPS) Publication 199 (February 2004). Standards for Security Categorization of Federal Information and Information Systems. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/index.html [FIPS Pub 200] Federal Information Processing Standard (FIPS) Publication 200 (July 2005). Minimum Security Standard for Federal Information Systems. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/index.html [FISMA 2002] Federal Information Security Management Act of 2002, 44 U.S.C. § 3541 et seq. http://csrc.nist.gov/policies/FISMA-final.pdf [GAO-04-393] Defense Acquisitions. (March 2004). Stronger Management Practices are Needed to Improve DoD’s Software-Intensive Weapons Acquisitions. Washington, DC: General Accountability Office. http://www.gao.gov/new.items/d04393.pdf [IBM CO] No Author (2006). Certificate of Originality. Poughkeepsie, NY: IBM Corporation. [INPUT 2005] O‘Flaherty, Tom (December 2005). The Impact of Software Assurance on the Procurement Process. INPUT, TargetVIEW, Volume 1, Issue 10. Reston, VA: INPUT. [McGraw] McGraw, G. (February 2006). Software Security and SOA: Danger, Will Robinson! http://www.cigital.com/papers/download/bsi12-soa.doc.pdf [NIST Special Pub 800-23] National Institute of Standards and Technology (NIST) Special Publication 800-23, Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products. Gaithersburg, MD: U.S. Department of Commerce, August 2000. http://csrc.nist.gov/publications/nistpubs/index.html 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 97 Software Security Acquisition Guide 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [NIST Special Pub 800-30] National Institute of Standards and Technology (NIST) Special Publication 800-30, Risk Management Guide for Information Technology Systems. Gaithersburg, MD: U.S. Department of Commerce, July 2002. http://csrc.nist.gov/publications/nistpubs/index.html [NIST Special Pub 800-37] Ross, Ron, Marianne Swanson, Gary Stoneburner, Stu Katzke, and Arnold Johnson. NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems. Gaithersburg, MD: U.S. Department of Commerce, May 2004. http://csrc.nist.gov/publications/nistpubs/index.html [NIST Spec Pub 800-53] No Author (February 2005). National Institute of Standards and Technology (NIST) Special Publication 800-53. Recommended Security Controls for Federal Information Systems. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/index.html [NIST Special Pub 800-55] National Institute of Standards and Technology (NIST) Special Publication 800-55. Security Metrics Guide for Information Technology Systems. Gaithersburg, MD: U.S . Department of Commerce, July 2005. http://csrc.nist.gov/publications/nistpubs/index.html [NIST Special Pub 800-67] National Institute of Standards of Technology (NIST) Special Publication 800-67, Rev 1. Security Considerations in the Information System Development Life Cycle, Gaithersburg, MD: U.S . Department of Commerce, June 2004. http://csrc.nist.gov/publications/nistpubs/index.html [NSTISSAM INFOSEC/2-00] National Security Telecommunications and Information Systems Security Advisory Memorandum (NSTISSAM)/2-00, Advisory Memorandum on the Strategy for Using the National Information Assurance Partnership (NIAP) for the Evaluation of Commercial Off-The-Shelf (COTS) Security Enabled Information Technology Products. Fort Mead, MD: U.S. National Security Agency, 8 February 2000. [NSTISSP No. 11] National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11, National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology Products. Fort Mead, MD: U.S. National Security Agency, July 2003. [OWASP--SSDC] Secure Software Development Contract Annex. The Open Web Application Security Project. Columbia, MD: Aspect Security, Inc. http://www.owasp.org/documentation/guide/guide_about.html [OWASP--SWA] Guide to Building Secure Web Applications and Web Service. The Open Web Application Security Project., 27 July 2005. Columbia, MD: Aspect Security, Inc. http://www.owasp.org/documentation/guide.html [SwA CBK] Redwine, S. T., Baldwin, R. O., Polydys, M. L., Shoemaker, D. P., Ingalsbe, J.A., Wagoner, L.D. (2006). Secure Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software. Washington, DC: Department of Homeland Security. https://buildsecurityin.uscert.gov/bsi/docs/Secure%20Software%20Assurance%20CBK%20DRAFT%20v09%2001090 6.pdf [SwA SDLC] Goertzel, K., McKinley, H.L., and Winograd, T. (2006). Security in the Software Lifecycle. Washington, DC: Department of Homeland Security. https://buildsecurityin.us- 98 Software Security Acquisition Guide 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 cert.gov/bsi/docs/Security%20in%20the%20Software%20Lifecycle%20DRAFT%20v08%20 01092006.pdf [US DoD 2004] U. S. Department of Defense. (September 2004). Interim Report on Software Assurance: Mitigating Software Risks in the DoD IT and National Security Systems. [US PITAC 1999] U.S. President‘s Information Technology Advisory Committee. (February 1999). Information Technology Research: Investing in Our Future. Arlington, VA: National Coordination Office for Information Technology Research and Development. http://www.nitrd.gov/pitac/report/ [US PITAC 2005] U.S. President‘s Information Technology Advisory Committee. (February 2005). Cyber Security: A Crisis of Prioritization. Arlington, VA: National Coordination Office for Information Technology Research and Development. http://www.nitrd.gov/pitac/reports/index.html [Williams, J.] Williams, J. (January 2004). Let’s Sue the Idiots—Security, Software, Contracts, and Lawyers. Columbia, MD: Aspect Security, Inc. http://www.aspectsecurity.com/article/sscl.html 99 Software Security Acquisition Guide Appendix C. Generic Questionnaire 1 Appendix F. Acronyms List CAPEC CBT CERT CIA CLASP CMM CMMI COI CORUS COTS CVE CWEC DCID DHS DODD DoDI DREAD EAL FAR IA ID/IQ ISO IT Microsoft DREAD NIST NVD OWASP PGP QA QOS RFI RFP RUP SANS SDLC SME SOA SOW SSL Evaluation Assurance Level Federal Acquisition Regulation Information Assurance Indefinite Delivery/Indefinite Quantity International Standards Organization Information Technology Risk Management or Threat Modeling Program National Institute of Technology National Vulnerability Database Open Web Application Security Project Pretty Good Privacy Quality Assurance Quality of Service Request for Information Request for Proposal Rational Unified Process The SANS Institute (www.sans.org) Software Development Life Cycle Subject Matter Experts Service Oriented Architecture Statement of Work Secure Socket Layer 100 Director of Central Intelligence Directive Departments of Homeland Security DoD Directive DoD Instruction Commercial-Off-the-Shelf Common Vulnerabilities and Exposures Computer Aided Process-Product Engineering Center Computer Based Training Computer Emergency Response Team Central Intelligence Agency Common Lisp Analytical Statistics Package Capability Maturity Model Capability Maturity Model Integration Community of Interest (COI Software Security Acquisition Guide TQM UML ―Due Diligence Questionnaire‖ or ―Questionnaire‖ Total Quality Management Unified Modeling Language Appendix C. Generic Questionnaire Software Assurance Acquisition Due Diligence Questionnaire 101 Software Security Acquisition Guide 1 Appendix C. Generic Questionnaire 102