6. Software Security [SS] 6.1. Policy Objective The purpose of this policy is to define the importance of including security in the process of software development and acquisition, rather than adding it as an add-on. This policy defines security as it applies to the various phases of the Software / System Development Life Cycle (SDLC). This policy also covers security controls for commercial applications deployed within an Agency. 6.2. Policy & Baseline Controls – Software Development & Acquisition In order to comply with this policy, Agencies MUST ensure: SS 1. Security is considered in all phases of the SDLC and that it is an integral part of all system development or implementation project. SS 2. *All applications (including new and developed) are classified using the National Information Classification Policy [IAP-NAT-DCLS] and accorded security protection appropriate to its Confidentiality, Integrity and Availability ratings. SS 3. Security requirements (functional, technical and assurance requirements) are developed and implemented as part of system requirements. SS 4. *Dedicated test and development infrastructure (systems and data) are available and is separate from production systems. Furthermore, information flow between the environments SHALL be strictly limited according to a defined and documented policy, with access granted only to system users with a clear business requirement and write access to the authoritative source for the software SHALL be disabled. SS 5. All applications (acquired and/or developed) are available for production use only after appropriate quality and security assurance tests and checks to ensure that the system confirms and complies with the intended security requirements. SS 6. *Software developers use secure programming practices when writing code, including: a. complying with best practices, for example the Mitre top 25 most dangerous programming errors [Mitre] b. designing software to use the lowest privilege level needed to achieve its task c. denying access by default d. checking return values of all system calls e. validating all inputs. SS 7. Software should be reviewed and/or tested for vulnerabilities before it is used in a production environment. Software SHOULD be reviewed and/or tested by an independent party and not by the developer. SS 8. System (acquired and/or developed) complies with all legal requirements including license, copyrights, IPR etc. SS 9. All systems (acquired and/or developed) are adequately documented. SS 10. *Source code of custom developed critical applications is available and in the case of commercial applications (serving critical applications / processes) a Agency SHOULD look into options of arranging an escrow for the source code. SS 11. Prior to commissioning of applications, they are certified as specified in section B- 13, Audit & Certification [AC]. 6.3. Policy & Baseline Controls – Software Applications In order to comply with this policy, Agencies MUST ensure: SS 12. All server and workstation security objectives and mechanisms are documented in the relevant system security plan. SS 13. *Workstations use a hardened standard operating environment (SOE) covering: NATIONAL INFORMATION ASSURANCE MANUAL 36