The 8-step SDLC process described includes initiation, requirements, architecture, design, development, testing and validation, release and maintenance, and disposal. The document outlines the key activities that occur in each phase, with a focus on incorporating security practices like threat modeling, secure coding, and testing throughout the development lifecycle.
The 8-step SDLC process described includes initiation, requirements, architecture, design, development, testing and validation, release and maintenance, and disposal. The document outlines the key activities that occur in each phase, with a focus on incorporating security practices like threat modeling, secure coding, and testing throughout the development lifecycle.
The 8-step SDLC process described includes initiation, requirements, architecture, design, development, testing and validation, release and maintenance, and disposal. The document outlines the key activities that occur in each phase, with a focus on incorporating security practices like threat modeling, secure coding, and testing throughout the development lifecycle.
The 8-step SDLC process described includes initiation, requirements, architecture, design, development, testing and validation, release and maintenance, and disposal. The document outlines the key activities that occur in each phase, with a focus on incorporating security practices like threat modeling, secure coding, and testing throughout the development lifecycle.
1. Initiation The initiation phase involves project conception and development of the business case. It is in the initiation phase that the viability of the software project is determined.
2. Requirements In the requirements phase, the customer’s requirements for working software are captured and documented. The requirements phase includes the gathering and documentation of overall system requirements as well, including the functional and nonfunctional requirements. Security requirements are gathered and documented in this phase.
3. Architecture Although sometimes skipped or often combined with the design phase, the architecture phase is the time to build security into the architecture requirements of both the software development environment and the application to be built. The architecture should also align with the organization’s architectural strategy. The architecture phase is your first line of defense in determining the technical security posture of the software application. On an architectural level, this phase offers the opportunity to conduct threat modeling to identify threats to the application, to apply security principles and controls to mitigate those threats, and to satisfy other security and nonfunctional requirements.
4. Design In the design phase, the customer, application, and security requirements are translated into designs that ultimately can become working software. The design phase is the opportunity to build security into the software’s blueprints. Threat modeling and abuse cases can be used to determine
1 CBK SDLC – 8 Steps Taken from the Official (ISC)2 Guide to the CISSP CBK Reference
what needs to be protected in the application and then, after designs are made, to validate or improve the design and its selection of patterns and structures to mitigate these threats. Vulnerabilities found and fixed in the design phase are multiple times more cost-saving than remediation performed at later phases.
5. Development The development phase is when the software’s architecture and designs are translated into working software implemented in code. There are a number of essential practices to follow for security in the development phase. One is to follow the secure coding practices and conventions of your organization. Comprehensive testing should be used to verify and maintain an evolving baseline of correct functionality and security during ongoing development. Use frameworks, libraries, and patterns from trusted sources to enhance the security features and functionality of your application. Integrated development environments (IDEs) automate many of these features, making their use more natural in a developer’s workflow.
6. Testing and Validation
The testing and validation phase formally amplifies the quality control measures utilized in the development phase. This phase employs comprehensive automated and manual testing and evaluation to determine whether the software meets its functional and nonfunctional requirements. Nonfunctional requirements are those that define the architectural and security qualities of the system being built, such as availability, scalability, maintainability, and the security control environment, to name a few. During this phase, comprehensive security testing is done, which commonly includes penetration testing, static and dynamic code testing, and customer acceptance testing. Preproduction testing prior to release is performed to determine the application’s fitness for deployment to its production environment.
7. Release and Maintenance
After the software is deemed fit for use, the release and maintenance phase is when it goes into production. The security control requirements for releasing an application to production are much higher than those required to secure the development and test environments. Production releases are typically controlled ceremonies. During production deployment, an application must be protected from internal abuse, tampering, and mistakes as well as the potential abuses coming from the untrusted external environment. Maintenance covers ongoing bug fixes and future development.
8. Disposal When the software reaches the end of its useful life, it is subject to the disposal phase. There are a number of key information security concerns in the disposal phase. NIST SP 800-64 outlines the key security activities for this phase as follows: • A transition plan for the software • Archiving of critical information • Sanitization of media • Disposal of hardware and software 2
