Attachement D1 -CDC Secure Software Development.pdf

U.S. Department of Health and Human Services

Centers for Disease Control and Prevention

Secure Software Development Standard

Version 1.0

Approved:

9/3/2019

X Cheri L. Gatland-Lightner Cheri L. Gatland-Lightner CDC Chief Information Security Officer Signed by: Cheri L. Gatland-lightner -S

Secure Software Development Standard v1.0

VERSION CONTROL

Date Author/Major Contributors Version Notes

08/22/2019 Anil Ninan/Brian Lee, Jared Brown, Anes Aref

1.0 • Initial Release

1. PURPOSE

In compliance with Office of Management and Budget (OMB) Circular A-130 and Health and Human Services (HHS) Information Systems Security and Privacy Policy (IS2P), this standard establishes the minimum secure coding practices that must be implemented to ensure secure code is designed in the early phases of the software development lifecycle.

This standard for development, coding techniques, and security testing requirements is intended to:

• Improve the quality of CDC software and information systems by reducing the probability of vulnerabilities. Building in security in the early phases of the software development life cycle allows for the identification of vulnerabilities when remediation cost is least expensive, and can greatly reduce risk to CDC’s mission and operations as well as privacy of individuals.

• Guide CDC system development in order to better protect and secure all CDC information systems.

This standard and CDC IT Guard Rails supersedes the JavaScript Coding Standard and Best Practices at CDC and OCISO Standard for AJAX and JavaScript Libraries.

2. SCOPE

This standard applies to all activities requiring software developed by or on behalf of CDC1, including those outside the continental United States. Implementation of this standard must be incorporated into applicable contract language when contracting for the development of software on behalf of CDC.

3. REQUIREMENTS

All software developed by or on behalf of CDC must be based on CDC secure coding best practices available on CDC IT Guard Rails. If a CDC-defined secure coding best practice is not available, follow secure coding best practices published by US-CERT Build Security In and/or Open Web Application Security Project (OWASP).

Regardless of the software development best practice in use, appropriate due diligence must be exercised in development, testing, and deployment of all software developed for CDC by ensuring the following minimum requirements are adopted:

• Security requirements must be defined during the initial design and planning stages as this allows development teams to integrate security in ways that minimize disruption and remediation cost.

• Applications must be configured to validate input properly and restrictively, allowing only those types of input that are known to be correct.

• Applications must execute proper error handling so that errors will not provide detailed system information, impair security controls, or create infrastructure instability.

• Processes must execute with the least set of privileges necessary to complete the job. Any elevated permission must only be accessed for the least amount of time required to complete the privileged task.

1 Code that is first produced in the performance of a Federal contract or is otherwise fully funded by the Federal Government. It includes code, or segregable portions of code, for which the Government could obtain unlimited rights under Federal Acquisition Regulations (FAR) Pt. 27 and relevant agency FAR Supplements. Custom-developed code also includes code developed by agency employees as part of their official duties. For the purposes of this policy, custom-developed code may include, but is not limited to, code written for software projects, modules, plugins, scripts, middleware, and APIs; it does not, however, include code that is truly exploratory or disposable in nature and not used to process sensitive or production data, such as that written by a developer experimenting with a new language or library.

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf https://max.omb.gov/community/download/attachments/705988687/HHS+Information+Security+and+Privacy+Policy+-+2014+Edition.docx?version=2&modificationDate=1409754137520 https://max.omb.gov/community/download/attachments/705988687/HHS+Information+Security+and+Privacy+Policy+-+2014+Edition.docx?version=2&modificationDate=1409754137520 https://it-guides.cdc.gov/source-code/ http://intranet.cdc.gov/ocio/docs/information-systems-security/JavaScript_Coding_Standard_and_Best_Practices.pdf http://intranet.cdc.gov/ocio/docs/information-systems-security/OCISO_AJAX-JavaScript_LIbrary_Standard.pdf https://it-guides.cdc.gov/source-code/ https://www.us-cert.gov/bsi https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

• Logging must be implemented to the extent practical and ensure that sufficient error and security monitoring details are included.

• Libraries and components must be kept up to date and a tool similar to OWASP Dependency Check should be used to identify project dependencies and publicly disclosed vulnerabilities for all third party code. SAST tools must be used to validate that the open source components do not contain unreported security vulnerabilities.

• All developed software must include Static Application Security Testing (SAST) using OCIO provided Fortify Static Code Analyzer prior to deployment to production. See Section 5 for exceptions procedure to use an alternate SAST scanning tool.

• All developed web applications must additionally include Dynamic Application Security Testing (DAST) using OCIO provided WebInspect prior to deployment to production. See Section 5 for exceptions procedure to use an alternate DAST scanning tool.

• Software security testing tools must be configured to test for all known software vulnerabilities.

• Ensure OWASP Top 10 application security risks are addressed during code review and testing phases and all findings are addressed.

• Documentation describing the security architecture of the application, including how data is classified and protected must be maintained.

• All developed software must use source code repositories approved by CDC Software Assurance

Program.

• Threat modeling (e.g. Microsoft Threat Modeling) should be used to identify threats, attacks, vulnerabilities, and countermeasures that could affect the application.

• Code should be reviewed and tested throughout the development cycle.

4. ROLES AND RESPONSIBILITIES

The following responsibilities may be carried out by the named role or by others acting on their behalf.

Associate Directors of Informatics must:

• Ensure that center governance, system development, security, and acquisition practices align with secure coding practices.

• Coordinate resources between system owners, Information System Security Officers (ISSOs), Office of the Chief Information Officer (OCIO) and other stakeholders to ensure timely remediation of findings.

System Owners must:

• Maintain compliance with this standard and ensure that all software development under their purview is in accordance with secure coding practices.

• Define roles and responsibilities for all members of the software development team.

• Ensure that all vulnerabilities are addressed and remediated prior to production.

• Perform the role of the software security testing tool provider for any self-provided software security testing tools.

• Obtain approval (see Section 5, Exceptions) when mission requirements necessitate deviation from this standard.

ISSOs must:

• Support the implementation of this standard and advise system owners on security risks and remediation.

https://esp.cdc.gov/CDCWW/SoftwareAssurance/SitePages/SA-RequestFortifySCASoftware.aspx https://esp.cdc.gov/CDCWW/SoftwareAssurance/SitePages/SA-RequestWebInspectScan.aspx https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project https://it-guides.cdc.gov/source-code/knownRepos/ https://esp.cdc.gov/cdcww/softwareassurance/SitePages/Home2.aspx https://esp.cdc.gov/cdcww/softwareassurance/SitePages/Home2.aspx https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

• Ensure that all vulnerabilities are addressed and remediated prior to production.

Software Developers must:

• Ensure software design and development activities are in compliance with this standard.

• Validate scan results by negating false positives2 through Security Testing Tool Providers or Security

Testers.

• Ensure the use of source code repositories approved by CDC Software Assurance Program.

• Maintain documentation describing the security architecture of the application.

• Contribute to CDC IT Guard Rails using subject matter expertise on software engineering.

Security Testing Tool Providers must:

• Provide training and guidance on software security tools (e.g. OCIO provides guidance and training on Fortify Static Code Analyzer and Web Inspect).

• Provide Security Testers access to software security tools based on the principle of least privilege.

• Assist software developers to validate scan results by negating false positives and define processes for false positive validation.

• Configure security testing tool to ignore reporting on validated false positives.

• Define the roles and responsibilities of the security tester, including the requirements to be a security tester.

• Document procedures required for the CISO and Security Testers to fulfill their responsibilities.

• Ensure security scanning tools report scan findings to the central repository in accordance with the specifications and procedures provided by the CISO.

• Contribute to CDC IT Guard Rails using subject matter expertise on software security tools.

Security Testers must:

• Provide detailed security testing results to software developers to support remediation.

• Assist software developers to validate scan results by negating false positives.

• Ensure security testing tools are configured to test for all known software vulnerabilities.

• Contribute to CDC IT Guard Rails using subject matter expertise on software security testing.

OCIO Software Assurance Team must:

• Design, implement, and support use of enterprise Fortify Static Code Analyzer and WebInspect as part of CDC Software Assurance function.

• Perform the role of the security testing tool provider for Fortify Static Code Analyzer and Web Inspect.

• Develop security scanning strategy by working with stakeholders for software systems not supported by Fortify Static Code Analyzer and Web Inspect.

• Provide scanning tool configuration requirements to security testing tool providers and security testers.

• Facilitate multi-center collaboration among cybersecurity and engineering SMEs to develop and implement a secure software development framework.

2An instance in which a security tool incorrectly classifies benign content as malicious.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf https://it-guides.cdc.gov/source-code/knownRepos/ https://esp.cdc.gov/cdcww/softwareassurance/SitePages/Home2.aspx https://it-guides.cdc.gov/data/ https://it-guides.cdc.gov/data/ https://it-guides.cdc.gov/data/ https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf

• Implement enterprise knowledgebase of common software issues/bugs, and vulnerabilities identified with appropriate access for software development teams.

• Document procedures for requesting review and approval of new source code repositories.

• Maintain CDC IT Guard Rails with software assurance guidance and best practices.

The CISO must:

• Implement a central repository (e.g. Splunk) for the collection of scan findings from Security Testing Tool Providers.

• Document specifications and procedures necessary for Security Testing Tool Providers to upload scan findings to the central repository and create POA&Ms for scan findings.

• Provide stakeholders (e.g. System Owners, ISSOs) with access to scan findings and POA&Ms.

• Provide role based training to those who contribute to the development of secure software.

• Contribute to the CDC IT Guard Rails using subject matter expertise on cybersecurity.

5. EXCEPTIONS

All exceptions and deviations shall be documented and approved by the CDC CISO or designated official. For exception and deviations requests, follow the policy exception and waiver process.

6. DEFINITIONS

Definitions of key cybersecurity terms can be found here Glossary of Key Information Security Terms.

C/I/Os must migrate Dynamic Application Security Testing (DAST) to OCIO provided WebInspect by October 1, 2019.

Implementation of all other requirements in this standard must be completed within 180 days from the approval date of this standard.

https://it-guides.cdc.gov/source-code/knownRepos/ https://it-guides.cdc.gov/source-code/ https://it-guides.cdc.gov/source-code/ http://intranet.cdc.gov/ocio/information-systems-security/change-management/index.html#policy-exceptions https://esp.cdc.gov/sites/ociso/ISSO/Decision_Papers_Standards/Glossary%20of%20Key%20Information%20Security%20Terms.pdf https://esp.cdc.gov/CDCWW/SoftwareAssurance/SitePages/SA-RequestWebInspectScan.aspx