Acquisition and Outsourcing Working Group
Articles and Briefings
Directives, Laws, and Standards
Policies
Practices
Questionnaires
Reports and Guidance
RFP Language
Other Resources
Acquisition articles on Build Security In
CIO Executive Council. "New CIO Executive Council™ Poll Reveals CIOs Lack Confidence in Software." CIO Executive Council News Bureau, Oct. 11, 2006.
GFIRST panel presentation on Acquisition Working Group Activities (ppt), July 2007.
Martin, R. A. (2007, March). "Being Explicit About Security Weaknesses." CrossTalk—The Journal of Defense Software Engineering, Vol. 20, No. 3.
Evaluating and Mitigating Software Supply Chain Security Risk, May 2010
Epstein, Jeremy, Matsumoto, Scott, and McGraw, Gary. (2006, February). Software Security and SOA: Danger, Will Robinson!
Obasanjo, D. (2002). The Myth of Open Source Security Revisited v2.0.
O’Flaherty, T. (2005, December). The Impact of SwA on the Procurement Process. INPUT, TargetVIEW, Volume 1, Issue 10. Reston, VA: INPUT.
Outbrief at DHS SwA Forum, October 2007.
Polydys, Mary L. and Wisseman, Stan. (2007, May). "Software Assurance: Five Essential Considerations for Acquisition Officials." CrossTalk—The Journal of Defense Software Engineering, Vol. 20, No. 5.
"Software Supply Chain Risk Management: From Products to Systems of Systems"
Tutorial based on Software Assurance in Acquisition: Mitigating Risks to the Enterprise
Walker, E. (2005, July). "Software Development Security: A Risk Management Perspective." The DoD Software Tech News—Secure Software Engineering. Vol(8)No(2). Rome, NY: Data & Analysis Center for Software.
Wheeler, David A. (2005, October). Open Source Software and Software Assurance (ppt).
Wisseman, Stan. (2007, December). "Reducing Risks in the Software Acquisition Life Cycle" (ppt).
Desautels, Edward. (2008). "Software License Agreements: Ignore at Your Own Risk" (pdf).
Directives, Laws, and Standards
Clinger-Cohen Act of 1996, Public Law 104-106.
DCID 6/3. (1999, June 5). Protecting Sensitive Compartmented Information Within Information Systems.
Department of Defense Directive (DoDD) 8500.1. (2002, October 24-certified current as of 21 November 2003). Information Assurance (IA). Washington, DC: U.S. Department of Defense.
Department of Defense Instruction (DoDI) 5000.2. (2003, May 12). Operation of the Defense Acquisition System. Washington, DC: U.S. Department of Defense.
Department of Defense Instruction (DoDI) 8500.2. (2003, February 6). Information Assurance (IA) Implementation. Washington, DC: U.S. Department of Defense.
Federal Acquisition Regulation (2005).
Federal Information Processing Standard (FIPS) Publication 140-2. (2001, May). Security Requirements for Cryptographic Modules. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce.
Federal Information Processing Standard (FIPS) Publication 199. (2004, February). Standards for Security Categorization of Federal Information and Information Systems. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce.
Federal Information Processing Standard (FIPS) Publication 200. (2005, July). Minimum Security Standard for Federal Information Systems. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce.
Federal Information Processing Standard (FIPS) Publication 201-1. (2006, Jun. 26). Personal Identity Verification (PIV) for Federal Employees and Contractors. Gaithersburg, MD: National Institute of Standards and Technology (NIST), U.S. Department of Commerce.
Federal Information Security Management Act of 2002, 44 U.S.C. § 3541 et seq.
Institute of Electrical and Electronics Engineers (IEEE) Std 1062. (1998). Recommended for Software Acquisition.
ISO/IEC 15026. Information Technology -- System and Software Integrity Levels, 1998.
ISO/IEC 15408-1. Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 1: Introduction and general model, 2005.
ISO/IEC 15408-2. Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 2: Security functional requirements.
ISO/IEC 15408-3. Information technology -- Security techniques -- Evaluation criteria for IT security -- Part 3: Security assurance requirement.
ISO/IEC 17011. Conformity assessment—General Requirements for Accreditation Bodies Accrediting Conformity Assessment Bodies.
ISO/IEC 17025. General Requirements for the Competence of Testing and Calibration Laboratories, 2005.
ISO/IEC 17799. Information Technology -- Security techniques -- Code of practice for information security management, 2005.
ISO/IEC 27001. Information technology -- Security techniques -- Information security management systems -- Requirements, 2005.
General Overview: U.S. Government Executive Branch Information Assurance (IA) Acquisition Policies and Source Code Requirements, February 2006.
FAA Order 1370.109 - Software Assurance Policy
Acquisition Practices: Five Essential Considerations for Acquisition Officials
- Build Swecurity In: Create Acquisition Strategies and Plans that Include Essential SwA Considerations
- Require Secure Software: Include SwA Requirements in Software Requirements Document
- Be an Educated Consumer: Ask the Right Questions During the Contracting Process
- Demand Delivery of Secure Software: Ensure SwA Requirements Are Met During Contract Administration and Project Management
- Continue SwA for the Life of the Software: Maintain SwA in Follow-On Support
The questionnaires in Appendix D of Software Assurance (SwA) in Acquisition: Mitigating Risks to the Enterprise are provided here in Word format to make it easier to change the questions to suit your particular acquisition needs. The questionnaires are a tool to solicit information from software suppliers. They do not constitute a checklist nor a complete listing of all possible SwA/security concerns.
Questions should be reviewed prior to submission, and responses assessed, by knowledgeable SwA subject matter experts or other appropriate functional experts. In addition, when using a questionnaire as a tool, acquisition officials should ensure that they solicit evidence to support supplier responses when applicable.
- COTS software questionnaire (Word file)
- Custom software questionnaire (Word file)
- GOTS software questionnaire (Word file)
- Hosted applications questionnaire (Word file)
- Open source software questionnaire (Word file)
Your feedback on how to improve existing questions or suggestions of any additional questions are welcome. Please use the comment form.
Cohen, F. (2004, January 9). Enterprise Patch Management: Strategies, Tools, and Limitations.
Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, September 2006.
Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, September 2007.
Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, September 2007.
Defense Acquisitions. (2004, May). Knowledge of Software Suppliers Needed to Manage Risks [GAO-04-678]. Washington, DC: General Accountability Office.
Defense Acquisitions. (2004, March). Stronger Management Practices are Needed to Improve DoD’s Software-Intensive Weapons Acquisitions [GAO-04-393]. Washington, DC: General Accountability Office.
Department of Defense. (1992). A Guide to the Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements – Volume 1 of 4.
Department of Defense. (2004, December). Defense Acquisition Guidebook. Fort Belvoir, VA: Defense Acquisition University.
Department of Defense. (2004, September). Interim Report on SwA: Mitigating Software Risks in the DoD IT and National Security Systems.
Fedchak, Elaine; McGibbon, Thomas; & Vienneau, Robert. (2007, September). Software Project Management for Software Assurance: DACS State of the Art Report (DACS Report Number 347617). ITT Advanced Engineering and Sciences (prepared for Air Force Research Laboratory).
GAO-04-678. (May 25, 2004). Defense Acquisitions: Knowledge of Software Suppliers Needed to Manage Risks. GAO.
Global Information Technology Working Group, Committee on National Security Systems (CNSS) 145-06. (2006, November). Framework for Lifecycle Risk Mitigation for National Security Systems in the Era of Globalization. Ft. Meade, MD: National Security Agency.
Goertzel, K., et al. (2007, July 31). Software Security Assurance: A State-of-the-Art Report (SOAR). Herndon, VA: Information Assurance Technology Analysis Center (IATAC) and Defense Technical Information Center (DTIC).
Goertzel, Karen Mercedes; Winograd, Theodore; McKinley, Holly Lynne; & Holley, Patrick. (August 2006). Security in the Software Lifecycle: Making Software Development Processes – and Software Produced by Them – More Secure, Draft version 1.2. U.S. Department of Homeland Security.
Ibrahim, L, Jarzombek, J., et al. (2004, September). Safety and Security Extensions for Integrated Capability Maturity Models. Washington, DC: Federal Aviation Administration.
Lewis, J. Foreign Influence on Software. Center for Strategic and International Studies, March 2007.
National Defense Industrial Association (NDIA). Systems Assurance—Delivering Mission Success in the Face of Developing Threats, October 2007.
National Security Telecommunications and Information Systems Security Advisory Memorandum (NSTISSAM)/2-00. (2000, February 8). 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 Meade, MD: U.S. National Security Agency.
National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11. (2003, July). National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology Products. Fort Meade, MD: U.S. National Security Agency.
NIST Special Publication 800-23. (2000, August). Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products. Gaithersburg, MD: U.S. Department of Commerce.
NIST Special Publication 800-30. (2002, July). Risk Management Guide for Information Technology Systems. Gaithersburg, MD: U.S. Department of Commerce, July 2002.
NIST Special Publication 800-36, Guide to Selecting IT Security Products. Gaithersburg, MD: U.S. Department of Commerce, October 2003.
NIST Special Publication 800-53. (2005, February). Recommended Security Controls for Federal Information Systems. Gaithersburg, MD: U.S. Department of Commerce.
NIST Special Publication 800-55. (2005, July). Security Metrics Guide for Information Technology Systems. Gaithersburg, MD: U.S. Department of Commerce.
NIST Special Publication 800-64, Rev 1. (2003, October). Security Considerations in the Information System Development Life Cycle. Gaithersburg, MD: U.S. Department of Commerce.
Nuclear Procurement Issues Committee (NUPIC). (2001, July 5). Document No. 6, Nuclear Procurement Issues Committee Joint Audit Program.
Office of Management and Budget (OMB) M-04-04. (2003, December 16). E-Authentication for Federal Agencies. Washington, DC: Office of the President.
Office of Management and Budget (OMB) M-04-16 (2004, July 1). Software Acquisition. Washington, DC: Office of the President.
Office of Management and Budget (OMB) M-07-18 (2007, June 1). Ensuring New Acquisitions Include Common Security Configurations. Washington, DC: Office of the President.
OWASP Guide to Building Secure Web Applications and Web Services (Version 3.0). Columbia, MD: Aspect Security, Inc., June 2007.
PDA. (2004, October). Technical Report 32, Auditing of Suppliers Providing Computer Products and Services for Regulated Pharmaceutical Operations. Release 2.0, Volume 58, Number 5.
Redwine, S. T.; Baldwin, R. O.; Polydys, M. L.; Shoemaker, D. P.; Ingalsbe, J. A.; & Wagoner, L. D. (2007, October). Software Assurance: A Curriculum Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software. Washington, DC: Department of Homeland Security.
Ross, Ron, Marianne Swanson, Gary Stoneburner, Stu Katzke, and Arnold Johnson. (2004, May). NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems. Gaithersburg, MD: U.S. Department of Commerce.
Software Integrity Controls: An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain is available for free download.
The software integrity controls identified in the paper are used by major software vendors to address the risk that insecure processes, or a motivated attacker, could undermine the security of a software product as it moves through the links in the global supply chain. The controls aim to preserve the quality of securely developed code by securing the processes used to source, develop, deliver and sustain software.
The controls identified in the report cover issues ranging from contractual relationships with suppliers, to securing source code repositories, to helping customers confirm the software they receive is not counterfeit.
The work builds upon SAFECode's previously released "Software Supply Chain Integrity Framework," which defines a taxonomy for describing supply chain security in the context of software assurance. Broad industry adoption of software integrity controls can greatly improve customer confidence in IT systems.
To help achieve this goal, SAFECode encourages other producers and distributors of software to tailor and adopt these controls into their own supply chain processes, as well as continue future study and analysis on additional methods to improve software integrity. The paper also identifies areas that SAFECode believes deserve future industry-led collaboration and study.
The ideas proposed include improved supplier management and communications along the supply chain, additional research on software testing, and the development of effective strategies for software assurance measurement.
To continue the discussion, SAFECode encourages public comment on this paper and will consider feedback collected for future projects. To comment, please visit www.safecode.org.
In December 2008, the Center for Strategic & International Studies released a report entitled Securing Cyberspace for the 44th Presidency. The Commission came up with three major findings and around 25 recommendations for how to better secure cyberspace within the United States. One of the recommendations was to enhance acquisition rules to improve security:
The president should direct the NOC and the federal Chief Information Officers Council working with industry, to develop and implement security guidelines for the procurement of IT products (with software as the first priority).
Software Engineering Institute. (2003, May). SEI Case Study: Computer Supplier Evaluation Practices of the Parental Drug Association (PDA). Technical Report CMU/SEI-2003-TR-011, Software Engineering Institute.
Software Engineering Institute. (2010, November). CMMI for Acquisition, Version 1.3.
SwA Acquisition Working Group. (2008, October). Software Assurance in Acquisition: Mitigating Risks to the Enterprise. U.S. Department of Homeland Security.
U.S. President’s Information Technology Advisory Committee. (1999, February). Information Technology Research: Investing in Our Future. Arlington, VA: National Coordination Office for Information Technology Research and Development.
U.S. President’s Information Technology Advisory Committee. (2005, February). Cyber Securiy: A Crisis of Prioritization. Arlington, VA: National Coordination Office for Information Technology Research and Development.
Idaho National Labs. Cyber Security Procurement Language for Control Systems, Version 1.8.
The purpose of this document is to summarize security principles that should be considered when designing and procuring control systems products (software, systems, and networks), and to provide example language to incorporate into procurement specifications.
New York State has draft Application Security Procurement language that references the CWE/SANS Top 25 Worst Programming Errors.
Ounce Labs suggests addendum language for contracts to secure software.
See Software Assurance (SwA) in Acquisition for sample RFP language.
The OWASP Secure Software Contract Annex has been updated to allow for the use of the OWASP Application Security Verification Standard (ASVS):
Security Analysis and Testing. Developer will perform application security analysis and testing (also called "verification") according to the verification requirements of an agreed-upon standard. The Developer shall document verification findings according to the reporting requirements of the standard. The Developer shall provide the verification findings to Client.
We welcome your suggestions of sample RFP language. Send them via email to software.assurance [at] dhs.gov. Members of the working group will review them and, if they deem them appropriate, will publish them here.
Bumgarner, J. & Scott, B. (2006). The US-CCU Cyber-Security Check List. U.S. Cyber Consequences Unit.
Committee on National Security Systems (CNSSI) No. 4009. (2003, May). National Information Assurance (IA) Glossary. Ft Meade, MD: National Security Agency.
Common Weakness Enumeration (CWE™).
Gallagher, Brian & Allen, Julia. "Becoming a Smart Buyer of Software." Podcast in the CERT Security for Business Leaders Podcast Series, June 10, 2008.
Office of Management and Budget. Standard Form 328, Certificate Pertaining to Foreign Interests, 2004.
Open Web Application Security Project (OWASP) Secure Software Development Contract Annex, November 2006.
Veracode has a service that offers an alternative approach to what the DHS SwA Acquisition and Outsourcing Working Group has developed. Their Veracode COTS SecurityReview service has been presented at a couple of DHS SwA Forums and discussed in our working group meetings. Veracode's service scans executable or byte code rather than source code or other artifacts/development processes. They have been especially active in describing the software supply chain challenge and their approach may have merits.
OWASP Legal Project
The goal of the Open Web Application Security Project (OWASP) Legal Project is to ensure, at each stage of the life cycle, that appropriate attention has been paid to security. The cornerstone of the Legal Project is its Secure Software Development Contract Annex. The Contract Annex helps software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered.
Get a PDF Reader