.png)
What Is SDLC and Why Should I Maintain it?
In simple terms, a System Development Life Cycle (SDLC) is a project management model that outlines the steps involved in bringing a project to life. Maintaining an SDLC is important for organizations that aim to work on internal development, however, it is not exclusive to organizations that perform development activities. All organizations that use information systems need to have some level of an SDLC process in place to support the management of the entire life cycle of information systems, applications, and infrastructure devices.
SDLC Lifecycle
As systems are acquired, they will need to be properly configured. Many systems will require changes and all systems will require patching or updating. Just like all technology today, systems will eventually be decommissioned. To combat this, a documented SDLC process enables organizations to manage this entire life cycle efficiently. This process is the focus of pitfall #63 and #64 in my eBook, Security Program Pitfalls and Prescription to Avoid Them.
Managing SDLC to Prevent Pitfalls
To prevent this pitfall, system security engineering principles should be applied for the specification, design, development, acquisition, implementation, modification, and decommissioning of information systems. Systems should be managed using a defined SDLC that incorporates Security Program controls and considerations. In-house or third-party developers should be required to follow a documented development process that explicitly addresses security control requirements.
Developers should be required, at all post-design phases of the SDLC, to:
Create and implement a security assessment plan.
Perform unit, integration, system, and regression testing. (This testing should result in an overall evaluation of the system.)
Produce evidence of the execution of the assessment plan, as well as the results of testing and evaluation.
Implement a verifiable flaw remediation process.
Correct flaws that are identified during testing and evaluation.
Documenting the Development Process
The documented development process should identify the standards and tools used for system or software development. The specific tool options and configurations used should be documented, as well as the integrity of changes to the process or tools used for development. Your organization needs to ensure the integrity and management of these changes.
The Separation of Development, Testing, and Production
Maintaining separate environments for your development, testing, and production is necessary to reduce the risk of unintended changes to an organization’s production environment. This is necessary whether an organization develops systems or applications internally, or only maintains a testing environment to test changes before implementation into the production environment (e.g., configuration updates, change requests, patching, etc.).
It is important that development, testing, and production environments are separated and controlled to reduce the risks of unauthorized access or unintended changes to operational systems in the production environment. The type of separation used between these environments can be either logical or physical as long as controls are implemented in each environment to prevent potential crossing over between environments or other operational issues.
Accommodating Risks
Organizations cannot accommodate the risks associated with making changes to configurations, systems upgrades, or application updates in the production environment without appropriate testing being completed in a non-production environment. If this happens, it will likely lead to system downtime or other unintended consequences that affect business operations.
Removing Account Information
Lastly, all test data and test accounts used for development or testing activities should be removed completely before systems or applications are placed into the production environment. This includes removing all custom accounts, user IDs, and default passwords. This is important to ensure that only accurate production data exists within the production environment. This also ensures that system or user accounts do not unintentionally conflict with the defined access control or other security requirements of the production environment that have been defined for your organization.
To learn more about this pitfall, and 99 more, get my book: 100 Security Program Pitfalls and Prescriptions to Avoid Them (available on Amazon here). Or register for a demo of the ASCENT Security and Compliance Portal and get a complimentary synopsis of the 100 Security Program Pitfalls eBook today.
Comments