Maintain Security Post Release
Learning Objectives
After completing this unit, you’ll be able to:
- Describe how to execute a successful ownership plan.
- Assign responsibility for patching future vulnerabilities.
Steps to Successful Ownership
Congratulations—your product is released! Now is the time to make sure you have a plan for service ownership going forward. Security attacks evolve and proliferate over time. Your team is responsible for mitigating new vulnerabilities as they are exposed. And because it's impossible to plan for all security threats, an owner can help quickly respond to any security incidents your project may face.
What do you need to prepare for successful ownership?
- Relevant materials from the design stage of your project
- Documented ownership describing who owns and is responsible for the service
- Documented escalation paths for product and security issues
- A service catalog entry that you can submit to the service catalog team
- Consensus on a service-level agreement (SLA) and best practices so relevant security patches can be quickly installed
- Agreement on a roadmap for the remediation of noted risk exceptions
- Agreement on maintenance and updates of your threat model
Patching Vulnerabilities
Part of ownership involves patching the third-party code your project lives on. Not patching is similar to not mitigating threats during the design stage. Attackers are out there looking for unpatched vulnerabilities.
Attacks on known vulnerabilities that have gone unpatched can result in adversaries gaining access to system user credentials, which lets them control web server processes. This is one reason that security best practices advise setting up your system so users have only least privilege or just-in-time access privileges. In this case, attackers cannot penetrate your systems deeply during a breach.
Patching is not just about operating systems—it includes the components and configurations that make up your system. Are you using third-party components? Are they up to date? Do you have a plan to keep them up to date? Third-party component vulnerabilities are usually subject to the same SLAs as the code you write. If a vendor-provided fix is not available, the ideal path forward might be to replace the component with a more secure alternative.
Reflect on What You’ve Learned
There’s much to learn every time you go through the secure development lifecycle (SDL) process. Take some time to reflect on your experiences. Some good ideas include the following.
- Meet with your team to discuss and reflect on the overall SDL process.
- Collect and document notes and ideas about what went well and what didn’t.
- Identify your security wins. Did you solve an architectural problem during design? Did you find and close a significant gap during testing? These are also great experience points you can share with other teams.
- Post to the security groups in your organization. Other teams can learn from your experiences.
Finally, celebrate your accomplishment. You released an awesome project, and you did so securely!
Sum It Up
You’ve now learned how to build security into every stage of your project. From design to build and from test to release, thinking about security both streamlines your work and leads to better, more secure products. As a developer, it is critical that you learn to work with security at the forefront of everything you do. Interested in learning more about cybersecurity best practices? Check out the Cybersecurity Learning Hub on Trailhead.
Resources
Quiz
Omar and his team have learned everything they need to know about security and the secure development lifecycle (SDL). They are ready to appropriately verify, test, and take ownership of their project.
