Read Time:3 Minute, 28 Second
This is the final article of the DevSecOps series and how it overlays onto DevOps lifecycle. In the first article, we discussed build and test in DevSecOps. In the second article, we covered securing the different components of the deploy and operate process. The final phases of the DevOps lifecycle are monitoring the deployed applications and eventually decommissioning when they are no longer needed.
The goal for DevSecOps is to have awareness and visibility into the entire application lifecycle to keep the system secured, healthy, and available. And when it’s time to decommission, follow the business processes to safely transition users and retire the application.
Monitoring
A system must be able to manage the failure of any application or hardware component. The goal of monitoring is to reduce the risk of failure by providing awareness and visibility into the behavior and health of applications and the overall system. When establishing a continuous monitoring program, consider the following security related items as part of the overall strategy.
The health of all applications and systems are visible through monitoring.
Understand the threats and vulnerabilities that put each application at risk.
Identify and create policies that define what security controls are needed, where they should be applied, and track gaps in controls using a risk register.
Logs and event data gathered by the tools should be segmented from the application, centrally collected, correlated, analyzed, and reported on for investigation.
All stakeholders have a role in security, and they need to be trained on how to take action to protect the organization.
Risk management must be dynamic to provide continuous monitoring and proactive resolution of security issues.
Monitoring starts with the planning phase and continues through the entire lifecycle of the application. It should be designed into the application and not an afterthought at the end of delivery. Empowering stakeholders with monitoring information can provide greater security to keep applications healthy and available throughout their lifecycle.
Decommission
The most important step when decommissioning an application is obtaining awareness and support through a transition plan and schedule with the stakeholders and users. Companies can ease the transition by having an overlap period between the new application and the one being retired. During the overlap period, users can be moved in groups to ease the efforts needed to support and troubleshoot migrating users.
Once users are transitioned and the legacy application is ready to be decommissioned, backups of the system should be performed. Any supporting infrastructure is turned down and returned to the pool of available resources. This reduces the attack surface of the organization and the administrative overhead of keeping a system secured.
Developers also have a role in decommissioning the application. The following items should be addressed as part of retiring an application.
Developers and any stakeholders with code checked out of the application source code repository need to check in their final versions and delete the code off their development workstations.
The repository should have any merge requests to feature, or the master branches denied or approved before archiving.
Developers should clean up the feature branches to reduce the size and complexity of the archived repository.
Once the source code repository is cleaned up, it should be set to read-only and access removed for everyone except the necessary] stakeholders.
Only the DevOps administrator should have access to the application code repository. In the future, the administrator can give access on a case-by-case basis.
Turning down the infrastructure and development resources for the decommissioned application reduces the company’s attack surface, helps maintain a clean DevOps environment, reduces infrastructure costs, and removes unnecessary monitoring.
Conclusion
This series has covered many of the fundamental security practices used by DevSecOps and shows how it overlays onto DevOps. The role of DevSecOps is to help the stakeholders (who ultimately own and are responsible for the risk) protect their business systems. For DevSecOps to be successful, the organization must make the cultural shift from traditional siloed groups to an integrated DevOps team. With the integrated team operating as one, digital transformation using DevOps and DevSecOps is delivered at the speed, scale, and security needed for success.
