ISO 27001:2022 A 8.25 Secure development life cycle

Audio version of the article

Rules for the development of software and systems should be established and applied to developments within the organization. Secure development Life cycle is used to ensure that development environments are themselves secure and that the processes for developing and implementing systems and system changes encourage the use of secure coding and development practices. It will include showing how security needs to be considered at all stages of the development life cycle from design through to live implementation. Specific coding languages and development tools have different vulnerabilities and require different “hardening” techniques accordingly and it is important that these are identified and agreed upon and developers are made aware of their responsibilities to follow them. Compliant policies will address security checkpoints during development; secure repositories; security in version control; application security knowledge; and developers’ ability to avoid vulnerabilities, then find and fix them when they occur. The auditor will be looking here to see that security considerations are appropriate to the level of risk for the systems being developed or changed and that those doing the development understand the need to include security considerations throughout the development lifecycle. Strong initial screening in hiring for these skills, in-life management, and training of resources is essential and practices like pair programming, peer reviews and independent quality assurance, code reviews, and testing are all positive attributes.

Control

Rules for the secure development of software and systems should be established and applied.

Purpose

To ensure information security is designed and implemented within the secure development life cycle of software and systems.

ISO 27002 Implementation Guidance

Secure development is a requirement to build up a secure service, architecture, software and system. To achieve this, the following aspects should be considered:

1. separation of development, test and production environments;
2. guidance on the security in the software development life cycle:
   • security in the software development methodology;
   • secure coding guidelines for each programming language used ;
3. security requirements in the specification and design phase;
4. security checkpoints in projects;
5. system and security testing, such as regression testing, code scan and penetration tests;
6. secure repositories for source code and configuration ;
7. security in the version control ;
8. required application security knowledge and training ;
9. developers’ capability for preventing, finding and fixing vulnerabilities;
10. licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues .

If development is outsourced, the organization should obtain assurance that the supplier complies with the organization’s rules for secure development .

Other information

Development can also take place inside applications, such as office applications, scripting, browsers and databases.

The SDLC is a process that standardizes security best practices across a range of products and/or applications. It captures industry-standard security activities, packaging them so they may be easily implemented. The lack of a standard approach to securing products causes problems. For one thing, vulnerabilities run rampant in shipped products. The second problem is that developers tend to repeat the same security mistakes, each time expecting a different response. The standard approach to SDLC includes requirements, design, implementation, test, and release/response.

• The requirements phase: In the requirements phase, best practices for security are integrated into a product. These practices may come from industry standards or be based on responses to problems that have occurred in the past. Requirements exist to define the functional security requirements implemented in the product, and include all the activities of the SDLC.
• The design phase: The design phase of the SDLC consists of activities that occur prior to writing code. Secure design is about quantifying an architecture (for a single feature or the entire product) and then searching for problems.
• Implementation or coding: The next phase is implementation, or writing secure code. The SDLC contains a few things programmers must do to ensure that their code has the best chance of being secure. The process involves a mixture of standards and automated tools.Implementation tools include static application security testing (SAST) and dynamic application security testing (DAST) software.
• The test phase: Formal test activities include security functional test plans, vulnerability scanning, and penetration testing. Vulnerability scanning uses industry-standard tools to determine if any system-level vulnerabilities exist with the application or product.
• The final phase: Release/response. Release occurs when all the security activities are confirmed against the final build and the software is sent to customers (or made available for download). Response is the interface for external customers and security researchers to report security problems in products. Part of the response should include a product security-incident response team that focuses on training and communicating product vulnerabilities, both individual bugs and those that will require industry-wide collaboration

To build secure software products, systems, and architecture, the organisations should comply with

1. Development, test, and production environments should be segregated.
2. Organisations should provide guidance on:
   • Security considerations in the software development methodology
   • Secure coding for each programming language.
3. Organisations should establish and implement security requirements that apply to the specification and design phase in accordance .
4. Organisations should define security checklists for the projects .
5. Organisations should perform security and system testing such as penetration tests and code scanning.
6. Organisations should create safe repositories storing source codes and configuration .
7. Organisations should maintain security in the version control as prescribed .
8. Organisations should ensure all personnel involved in the development has sufficient application security knowledge and are provided with the necessary training as defined .
9. Developers should be capable of identifying and preventing security vulnerabilities .
10. Organisations should comply with licensing requirements and should evaluate the feasibility of alternative cost-effective methods as prescribed .

Furthermore, if an organisation outsources certain development tasks to external parties, it must ensure that the external party adheres to the organisation’s rules and procedures for the secure development of software and system.

Security is a requirement that must be included within every phase of a system development life cycle. A system development life cycle that includes formally defined security activities within its phases is known as a secure SDLC. Per the Information Security Policy, a secure SDLC must be utilized in the development of all applications and systems.
At a minimum, an SDLC must contain the following security activities. These activities must be documented or referenced within an associated information security plan. Documentation must be sufficiently detailed to demonstrate the extent to which each security activity is applied.

1. Define Security Roles and Responsibilities
   Security roles must be defined and each security activity within the SDLC must be clearly assigned to one or more security roles. These roles must be documented and include the persons responsible for the security activities assigned to each role.
2. Orient Staff to the SDLC Security Tasks
   All parties involved in the execution of a project’s SDLC security activities must understand the purpose, objectives and deliverables of each security activity in which they are involved or for which they are responsible.
3. Establish System Criticality Level
   When initiating an application or system, the criticality of the system must be established. The criticality level must reflect the business value of the function provided by the system and the potential business damage that might result from a loss of access to this functionality.
4. Classify Information
   As per the Information Security Policy, all information contained within, manipulated by or passing through a system or application must be classified. Classification must reflect the importance of the information’s confidentiality, integrity and availability.
5. Establish Identity Credential Requirements
   All applications or systems which require authentication must establish a user identity credential. The identity credential must reflect the required confidence level that the person seeking to access the system is who they claim to and the potential impact to the security and integrity of the system if the person is not who they claim to be.
6. Establish Security Profile Objectives
   When initiating an application or system, the security profile objectives must be identified and documented. These objectives must state the importance and relevance of identified security concepts to the system and indicate the extent and rigor with which each security concept is to be built in or reflected in the system and software. Each security concept must be considered throughout each life cycle phase and any special considerations or needs documented. The purpose behind establishing system security profiles and monitoring them throughout the lifecycle is to be actively aware of the relative priority, weight and relevance of each security concept at each phase of the system’s life cycle. Entities must verify that the security profile objectives adequately consider all federal, state and external security mandates for which the system must be compliant.
7. Profile the System: The system or application being developed must be iteratively profiled by technical teams within the SDLC. A system profile is a high-level overview of the application that identifies the application’s attributes such as the physical topology, the logical tiers, components, services, actors, technologies, external dependencies and access rights. This profile must be updated throughout the various phases of the SDLC.
8. Decompose the System: The system or application must be decomposed into finer components and its mechanics (i.e. the inner workings) must be documented. This activity is to be iteratively performed within the SDLC. Decomposition includes identifying trust boundaries, information entry and exit points, data flows and privileged code.
9. Assess Vulnerabilities and Threats: Vulnerability assessments must be iteratively performed within the SDLC process. Threat assessments must consider not only technical threats, but also administrative and physical threats that could have a potential negative impact on the confidentiality, availability and integrity of the system. Threat assessments must consider and document the threat sources, threat source motivations and attack methods that could potentially pose threats to the security of the system. Threat assessments must adhere to all relevant state and federal mandates to which the entity must comply and follow industry best practices including the documentation of the assessment processes. Threat assessments and the underlying threat modeling deliverables that support the assessment must also be fully documented.
10. Assess Risk: Risk assessments must be iteratively performed within the SDLC process. These begin as an informal, high-level process early in the SDLC and become a formal, comprehensive process prior to placing a system or software into production. All realistic threats and vulnerabilities identified in the threat assessments must be addressed in the risk assessments. The risk assessments must be based on the value of the information in the system, the classification of the information, the value of the business function provided by the system, the potential threats to the system, the likelihood of occurrence, the impact of the failure of the system and the consequences of the failure of security controls. All identified risks are to be appropriately managed by avoiding, transferring, accepting or mitigating the risk. Ignoring risk is prohibited. Risk assessments must adhere to all relevant state and federal mandates that the entity must document and be compliant. The risk assessments must be periodically reviewed and updated as necessary whenever the underlying threat assessment is modified or whenever significant changes are made to the system.
11. Select and Document Security Controls
    Appropriate security controls must be implemented to mitigate risks that are not avoided, transferred or accepted. Security controls must be justified and documented based on the risk assessments, threat assessments and analysis of the cost of implementing a potential security control relative to the decrease in risk afforded by implementing the control. Documentation of controls must be sufficiently detailed to enable verification that all systems and applications adhere to all relevant security policies and to respond efficiently to new threats that may require modifications to existing controls. Residual risk must be documented and maintained at acceptable levels. A formal risk acceptance, with executive management sign-off, must be performed for medium and high risks that remain after mitigating controls have been implemented. Security control requirements must be periodically reviewed and updated as necessary whenever the system or the underlying risk assessment is modified.
12. Create Test Data
    A process for the development of significant test data must be created for all applications. A test process must be available for applications to perform security and regression testing. Confidential production data should not be used for testing purposes. If production data is used, entities must comply with all applicable federal, state and external policies and standards regarding the protection and disposal of production data.
13. Test Security Controls
    All controls are to be thoroughly tested in pre-production environments that are identical, in as much as feasibly possible, to the corresponding production environment. This includes the hardware, software, system configurations, controls and any other customization. The testing process, including regression testing, must demonstrate that all security controls have been applied appropriately, implemented correctly and are functioning properly and actually countering the threats and vulnerabilities for which they are intended. The testing process must also include vulnerability testing and demonstrate the remediation of critical vulnerabilities prior to placing the system into production. Appropriate separation of duties must be observed throughout the testing processes such as ensuring that different individuals are responsible for development, quality assurance and accreditation.
14. Perform Accreditation
    The system security plan must be analyzed, updated, and accepted by executive management.
15. Manage and Control Change
    A formal change management process must be followed whenever a system or application is modified in order to avoid direct or indirect negative impacts that the change might impose. The change management process must ensure that all SDLC security activities are considered and performed, if relevant, and that all SDLC security controls and documentation that are impacted by the change are updated.
16. Measure Security Compliance
    All applications and systems are required to undergo periodic security compliance assessments to ensure they reflect a security posture commensurate with the definition of acceptable risk. Security compliance assessments must include assessments for compliance with all federal, state and external compliance standards for which the entity is required to comply. Security compliance assessments must be performed after all system and application changes and periodically as part of continuous system compliance monitoring.
17. Perform System Disposal
    The information contained in applications and systems must be protected once a system has reached end of life. Information must be retained according to applicable federal and state mandates or other retention requirements. Information without retention requirements must be discarded or destroyed and all disposed media must be sanitized in accordance with applicable federal and state standards to remove residual information.

Responsibility for each security activity within the SDLC must be assigned to one or more security roles. To accomplish this, the default definition of an SDLC role may be expanded to include security responsibilities and/or new security roles may be defined to encompass security activities. In all cases, the assignment of security activities to roles, and the identification of persons given responsibility for these roles, must be clearly documented.

Secure Development life cycle best practice

1. Think security from the beginning: Before creating a single line of code, begin planning how you will integrate security into every phase of the SDLC. Engage the power of automation in testing and monitoring vulnerabilities from day one. Security needs to be baked into your culture and code, and there’s no better place to start than in the earliest development phase.
2. Create a secure software development policy: This will provide a guideline for preparing your people, processes, and technology to perform secure software development. This formal policy supplies specific instructions for approaching and instrumenting security in each phase of the SDLC. In addition, it provides the governing rules and defines roles to help your people, processes, and tools minimize the vulnerability risk in software production.
3. Employ a secure software development framework: A proven framework like NIST SSDF will add structure and consistency to your team’s effort in adhering to secure software best practices. Frameworks can help answer the “What do we do next?” question and benefit all new software developers.
4. Design software with best practices to meet security requirements: Clearly define all security requirements, then train developers to write code in alignment with these parameters using only secure coding practices. Ensure all your third-party vendors are aware of your security requirements and demonstrate compliance, as they can provide an easy pathway for an attack.
5. Protect code integrity: Keep all code in secure repositories allowing only authorized access to prevent tampering. Strictly regulate all contact with the code, monitor changes, and closely oversee the code signing process to preserve integrity.
6. Review and test code early and often: Breakaway from the traditional development pattern of testing code toward the end of the SDLC. Instead, use both developer reviews and automated testing to continually examine code for flaws. Catching vulnerabilities early in the life cycle saves money and time while preventing developer frustration later on.
7. Be prepared to mitigate vulnerabilities quickly: Vulnerabilities are a fact of life in software development. It’s not if they occur, but when, so be ready with a team, plan, and processes in place to address incidents in real-time. Remember, the faster you can identify and respond to vulnerabilities the better, shortening the window of opportunity for exploitation.
8. Configure secure default settings: Many customers remain vulnerable simply for lack of knowledge of their new software’s functions. This added customer service touch ensures the consumer will be protected in the early stages of adoption.
9. Use checklists: There are many moving parts to track and monitor during secure software development. Help your team by using action checklists at periodic intervals such as weekly or monthly meetings to ensure all necessary security policies and procedures are current and functional.
10. Remain agile and proactive: Wise software developers study vulnerabilities—learning their root causes, spotting patterns, preventing repeat occurrences, and updating their SDLC with improved knowledge. They also watch trends and stay up-to-date on best practices. Dave Brennan offers some parting advice here, “The big picture is knowing and staying current on the industry and best practices. The space is always evolving; security best practice approaches aren’t standing still. So no matter what you’re doing with security, it’s critical to look ahead to see what’s coming, keep learning, and identify better ways to secure your software development process.”