Example of Secure Development and Secure Coding Policy

1 Introduction

To ensure that information security is designed and implemented within the development life cycle for applications and information systems. The purpose of this document is to set out XXX’s policy in the development of software applications and components in a way which maximizes their inherent security. Secure development contributes to the reliability of the IT environment by ensuring that as many vulnerabilities as possible are designed and tested out of software before it is deployed into the live environment. Many security breaches around the world occur due to the exploitation of such vulnerabilities in system and application software, including the use of data that was not envisaged when the software was designed and tested. The growth of cloud applications that are developed using methods such as Agile and DevOps and incorporate very fast development to deployment times means that emerging techniques such as DevSecOps are evolving rapidly to try to keep pace. This document sets out the precautions that must be taken during the software development life cycle to minimize the risk to the organization whilst ensuring that the benefits set out in the original business case for the software are still realized. As such, this document will represent an initial design for the enhancement of existing development processes and will be updated on at least an annual basis thereafter as XXX and its needs develop.

2 Software development approaches

The process of software development fits in with the higher-level process of project management of new or enhanced information systems.
This process has the following major stages in a project:

• Proposal
• Planning
• Design and Development
• Transition
• Project Closure
  

The software development life cycle sits mainly within the Design and Development stage and consists of the following sub-stages:

• Design and Development
• Business requirements specification
• System design
• Development
• Testing

The way in which the stages of the software development life cycle are approached will depend upon the development approach used. The two main models of software development used within XXX are Waterfall and Iterative. The choice of approach will be made on a project by project basis.

2.1 Waterfall development approach
The classic Waterfall approach to software development involves the planning and completion of each stage before moving on to the next, in a sequential manner. Functional requirements are defined in detail and signed off before the design stage may begin. In turn, design must be completed before development starts etc. This has the advantage that it is possible to ensure that adequate planning takes place and to include security checkpoints at the end of each stage. These will ensure the inclusion of adequate security criteria at the requirements stage and correct security controls at the design stage. The common disadvantage with the Waterfall approach is that it is less flexible as circumstances and requirements change. If the project lasts for an extended period of time, there is the danger that what is delivered is no longer what is required.

2.2 Iterative development approach
As an alternative to Waterfall, an Iterative approach may be taken. Such approaches include Rapid Application Development (RAD), Prototyping and, more recently, Agile and DevOps. The Iterative approach typically involves significant stakeholder involvement throughout the development lifecycle and concentrates on producing frequent new versions of the software that may be evaluated and tested before further functionality is added. The process loops round with each of the stages being carried out many times in small iterations (in the Agile method these are called “Sprints”). Approaches such as CI/CD (Continuous Integration/Continuous Delivery) and Continuous Deployment have evolved from the use of readily available cloud environments, and further reduce the time between code completion and its deployment. An Iterative approach may be appropriate where exact requirements are less certain and frequent communication between developers and users (and within the development team) is possible. The inclusion of security requirements and controls within an Iterative development approach needs to be carefully managed to ensure that functionality is not preferred to the exclusion of effective security measures. The speed involved and the potential lack of structured design documentation mean that effective training of developers in security matters and possibly the regular involvement of a security specialist are recommended. The use of roles such as Security Champion or Security Advocate within the development team may be appropriate to achieve the required focus on the security of the code deployed. The set of techniques used to provide security in a highly iterative development environment is often referred to as “DevSecOps”.

3 Security in the software development lifecycle

This section describes the way in which information security considerations must be incorporated into the various stages within the software development lifecycle.

3.1 Business requirements specification
The focus within the business requirements stage is on the functionality of the new system. This will be expressed in business rather than technical terms and should tie in with the business case that was produced prior to the initiation of the project. The business is uniquely placed to give a clear understanding to the development team of the security requirements of the information that the new system will hold and process. In particular the business requirements must specify:

• The value of the information involved
• The sensitivity of the information-will personal data be held?
• Who the information owner is or will be
• The classification of the information according to the scheme used within the organization
• The environment in which the information will be accessed or processed-will access be available in public areas?
• The criticality of the new system and the information it holds – what is the business impact if it is not available?
• The legal, regulatory and contractual environment the system must operate within

A risk assessment must be carried out as part of the project to ensure that the implications of the above issues are fully understood by all parties.

3.2 System design
Based on the risk assessment and the classification of the information that is to be held in and processed by the new system, the design must provide for appropriate security features to be available. These will be largely defined by XXX’s established security architecture as documented in Principles for Engineering Secure Systems. This extends not only to the creation and maintenance of user accounts and permissions but also the following areas:

• Data input validation controls
• Data flow
• Data output
• Interfaces with other systems
• Reporting
• Restart and recovery
• Time stamps
• Logging (e.g. of transactions and access)
• Journaling of before and after images
• Batch and transaction counters
• Monitoring facilities
• How non-repudiation requirements will be met
• Ongoing patching arrangements
• Use of cryptography
• Need for digital certificates and signatures

For systems designed as part of a Waterfall approach these aspects will be included as part of the design documentation. If an Iterative approach is used, the development team will need to ensure that these areas are considered during every iteration and that changes do not invalidate controls implemented during an earlier iteration.

3.3 Development
Before starting to write code, a secure development environment must be established for the project. Depending on the coding environment, languages, databases, tools and other components selected, the appropriate guidelines for secure coding and configuration must be adopted. These must be evaluated to ensure they will provide adequate protection from the various types of potential attack identified in the risk assessment, such as:

• Buffer overflow
• Time of Check/Time of Use
• Memory Reuse
• Malformed input
• SQL injection

For a lengthy project it will be necessary to obtain regular updates regarding newly identified vulnerabilities and exploits associated with the technology components in use.

3.4 Testing
During the lifecycle of a software application, many different forms of testing will be carried out, including unit, system, integration, performance, user acceptance and operational acceptance testing. Security controls will to some extent be tested as part of these exercises. However, it is recommended that a separate exercise of security testing be carried out against the security requirements that were established during the business requirements and design stages. Initial security testing must be carried out within the development project with the same degree of rigour and formality as other forms with a suitable range of test inputs being specified. Once this has been completed to the development team’s satisfaction a further phase of security testing must be carried out by an independent party separate to the development team to verify correct operation of controls. Adequate controls must be put in place to protect test data. Where appropriate (and with prior approval on each occasion), a live to test copy may be made in order to provide representative test data. However, if this contains sensitive information such as personally identifiable data this must be removed or obscured before use. In a CI/CD (Continuous Integration/Continuous Delivery) or Continuous Deployment scenario, in which the testing and deployment of code to the cloud may be automated, testing frameworks such as the OWASP (Open Web Application Security Project) Application Security Verification Standard (ASVS) must be used as a basis for testing application technical security controls.

4.0 Secure Coding

All software written for or deployed on systems must incorporate secure coding practices, to avoid the occurrence of common coding vulnerabilities and to be resilient to high-risk threats, before being deployed in production. The items enumerated in this standard are not an exhaustive list of high-risk attacks and common coding errors but rather a list of the most damaging and pervasive. Therefore, code written must contain mitigating controls not only for the items specifically articulated in the standard below, but also for any medium and high-risk threats that are identified during a system’s life cycle.
High risk threats include, but are not limited to:

1. Code Injection
2. Cross-site scripting (XSS)
3. Cross-site request forgery (CSRF)
4. Information leakage and improper error handling
5. Missing Authentication for Critical Function
6. Missing Encryption of Sensitive Data
7. URL Redirection to Untrusted Site (‘Open Redirect’)

Developers are required to independently remain aware of updates to these lists and incorporate any new recommendations. Use of common security control libraries and common API’s, that have undergone security testing, is required to ensure a consistent approach that minimizes defects and prevents exploitation. When available, publicly available or vendor-supplied libraries or APIs should be used unless there’s a business case developed and exception granted by the Chief Information Security Officer (CISO)/designated security representative to develop a custom library. To prevent defects or detect and remove them early, thereby realizing significant cost and schedule benefits to the entity, code must be checked for errors throughout development and during maintenance. Entities must verify that the software assurance model used by the vendor is in line with this standard through vendor assurances, security testing and/or contract requirements

5 Security in outsourced development

Where software development is wholly or partially outsourced to a third party, due care must be taken to ensure that the policies of XXX are still followed where possible. XXX will remain legally responsible for the use of the software created an the information contained within it even though it didn’t write the software. Therefore, the same level of rigour must be applied to outsourced software development as that created in-house.

5.1 Selection of outsourced developer
Standard procurement procedures must be used in the selection and engagement of an appropriate outsourced developer. Use of these procedures will ensure the developer:

• Is capable of delivering the software to the required standard
• Can meet the delivery timescales required
• Represents best value for the organization
• Can meet the security requirements specified
• Use of sub-contractors by the outsourced developer for any aspects of the development must be understood and an assessment of these sub-contractors included.
  

5.2 Communication of requirements
The contract with the outsourced developer must require compliance with this policy and include a clear statement of the requirements for secure design, coding and testing of the software. The developer must also be required to establish a secure development environment in accordance with XXX standards. Requirements definition must be carried out by XXX so that a clear definition of the software to be created (including its security features) is agreed with the business and used as a contractual starting point for development. Whilst the outsourced developer may in some circumstances assist in the definition of requirements, the exercise should be led, managed and ideally carried out by internal resources so that there is a clear separation between requirements and design/development. A comprehensive picture of the anticipated threat model faced by the software should be provided to the outsourced developer so that a clear understanding is gained of the types of vulnerabilities that must be avoided if the software is to be secure.

5.3 Supervision and monitoring
Measures must be put in place to ensure adequate supervision of the activities of the outsourced developer and regular monitoring of progress. For a large project with significant time gaps between deliverables, an agreed method of verifying interim progress must be in place so that early warning is given of delays.

5.4 Reviews and acceptance
Review points must be established as part of the project planning process to verify progress and give formal acceptance of the software deliverables created. These will involve appropriate testing activities and code reviews. The outsourced software developer must be required to provide evidence of the security testing activities carried out during the development, including tests for concealed malware, back doors and known vulnerabilities. Where appropriate a security review of developed code may be engaged with a suitable third party with the relevant security expertise.

5.5 Audit of development methods
XXX must have the contractual right to undertake a second party audit of the outsourced development provider. This may be to review whether the development methods used comply to our policies and that all information provided to the supplier is protected by appropriate security controls. For larger projects it is recommended that an audit be carried out prior to the placing of the order for software development to ensure that assurances given during the sales process are valid.

5.6 Intellectual property
Unless the software is licensed under a formal agreement, contractual arrangements with an outsourced software developer must state that the ownership of the code produced on our behalf rests with XXX. It is important that any software that is developed under an outsourcing contract is understood to be our intellectual property. Appropriate legal advice must be taken particularly if the outsourcer is based outside of our home country.

5.7 Escrow
Arrangements must be made for XXX to be able to legally access the source code of any developments undertaken, in the event that the outsourcer ceases trading for any reason. This must be the case during development and if appropriate after the code has been delivered.

6 The Secure Software Development Framework

6.1 Prepare the Organization (PO): Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

1. Define Security Requirements for Software Development: Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of
   effort can be minimized because the requirements information can be collected once
   and shared. This includes requirements from
   internal sources (e.g., the organization’s policies,
   business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).
2. Implement Roles and Responsibilities: Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.
3. Implement Supporting Tool chains: Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Tool chains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.
4. Define and Use Criteria for Software Security Checks : Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development
5. Implement and Maintain Secure Environments for Software Development: Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

6.2 Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.

1. Protect All Forms of Code from Unauthorized Access and Tampering : Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.
2. Provide a Mechanism for Verifying Software Release Integrity : Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.
3. Archive and Protect Each Software Release: Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release

6.3 Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

1. Design Software to Meet Security Requirements and Mitigate Security Risks : Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.
2. Review the Software Design to Verify Compliance with Security Requirements and Risk Information: Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.
3. Verify Third-Party Software Complies with Security Requirements
4. Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality : Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.
5. Create Source Code by Adhering to Secure Coding Practices : Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
6. Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security : Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.
7. Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements : Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human- readable.
8. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements : Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.
9. Configure Software to Have Secure Settings by Default : Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

6.4 Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

1. Identify and Confirm Vulnerabilities on an Ongoing Basis : Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers
2. Assess, Prioritize, and Remediate Vulnerabilities : Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.
3. Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.