| 2.3.12-6-1 Ensure there is a Secure Coding Standard that covers, at a minimum the topics in TOR-2013-00742, Secure Software Assurance Coding Guidance |
Phase B |
Phase C |
Phase D1 |
|
Ensure the contractor maintains and follows a document which may be an appendix to the Software Development Plan which defines their secure software coding criteria. This document, or appendix, should be reviewed and approved by the Government.
|
NA
|
NA
|
NIST Special Publication 800-64, Revision 2, Security Considerations in the System Development Life Cycle; NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations; System and Services Acquisition (SA) family of controls; TOR-2013-00742, Secure Software Assurance Coding Guidance
|
| 2.3.12-6-2 Ensure the developed application code conforms to the Secure Development Standard with automated tools and/or manual methods |
Phase B |
Phase C |
Phase D1 |
|
Ensure program unique developed code is reviewed against the Secure Development Standard as part of the development process both using secure code static and dynamic analysis tools. The criteria for both automated and manual review is contained in the Secure Development Standard.
|
NA
|
NA
|
Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53; System and Services Acquisition (SA) family of controls; TOR-2013-00742 Secure Software Assurance Coding Guidance
|
| 2.3.12-6-3 Ensure there is an adequate policy and practice for handling Free and Open Source Software (FOSS) and third party software which includes FOSS component life cycle management |
Phase B |
Phase C |
Phase D1 |
|
Ensure that license and security issues are addressed and appropriate controls are in place. Ensure that FOSS libraries contained and/or used by FOSS and third party software are configuration managed and that FOSS vulnerabilities are tracked and mitigated.
|
NA
|
NA
|
FS-ISAC Third Party software Security Working Group White Paper, "Appropriate Software Security Control Types for Third Party Service and Product Providers"
|
| 2.3.12-6-4 Ensure compliance with the Secure Development Standard is required and that deviations result in Discrepancy/Deficiency Reports as with other software defects |
Phase B |
Phase C |
Phase D1 |
|
Ensure deviations from the Secure Development Standard are treated as DRs and tracked until corrected as with any other software defect.
|
NA
|
NA
|
Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53; System and Services Acquisition (SA) family of controls; TOR-2013-00742 Secure Software Assurance Coding Guidance
|
| 2.3.12-6-5 Ensure the developed application software, and any open source software in use, is compliant with the Design & Development Category I, Category II and Category III requirements imposed on the Designer covering Access Control, Authentication, Best Practice, Canonical Rep, Cryptography, Data, Documentation, Input Validation, Mobile Code, and Race Conditions as defined in the DISA Application Security & Development Security Technical Implementation Guide (STIG) |
Phase B |
Phase C |
Phase D1 |
|
Ensure program unique developed code is reviewed against the Secure Development Standard as part of the development process both using secure code static analysis tools such as Coverity or Fortify and manually when static tools are insufficient. The criteria for both automated and manual review is contained in the Secure Development Standard. Special attention should be paid to the Category I areas addressed by the DISA Application Security & Development Security Technical Implementation Guide (STIG) including Access Control, Authentication, Best Practice, Data, Hidden Fields, and Input Validation. Special attention should be paid to the Category II areas addressed by the DISA Application Security & Development STIG, including Access Control, Application Information Disclosure, Application Registration of Ports & Protocols, Audit, Authentication, Best Practice, Canonical Rep, Cryptography, Data, Documentation, Input Validation, Mobile Code, and Race Conditions. Special attention should be paid to the Category III areas addressed by the DISA Application Security & Development STIG, including 3-Party Products, Audit, Data, and Race Conditions. This covers Access Control, Authentication, Best Practice, Data, Hidden Fields, Input Validation, Application Information Disclosure, Application Registration of Ports & Protocols, Canonical Rep, Cryptography, Documentation, Mobile Code, 3-Party Products, and Race Conditions.
|
NA
|
NA
|
Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53; System and Services Acquisition (SA) family of controls; TOR-2013-00742 Secure Software Assurance Coding Guidance; DISA Application Security & Development Security Technical Implementation Guide (STIG)
|
| 2.3.12-6-6 Ensure there is a documented and implemented process for addressing security patches and notifications, including assessment for applicability to the system and off-line testing for impacts before deployment to the development or operational system |
Phase B |
Phase C |
Phase D1 |
Phase D2 |
Phase D3 |
|
Ensure there is a documented and implemented process for addressing security patches and notifications, including assessment for applicability to the system and off-line testing for impacts before deployment to the development or operational system since most of the systems are in some form of operational use with continuing development/upgrade).
|
NA
|
NA
|
Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53; System and Services Acquisition (SA) family of controls; TOR-2013-00742 Secure Software Assurance Coding Guidance; DISA Application Security & Development Security Technical Implementation Guide (STIG)
|