Alex - stock.adobe.com
Threat modeling and DevOps: A partnership in the making
Proactive threat modeling is a perfect fit for DevOps' iterative nature. Follow DevOps principles of collaboration, automation and feedback for a successful pairing.
Thinking through all the potential threats against an application must start in development. Threat modeling is a structured process that enables IT teams to imagine potential threats against their applications, as well as pinpoint vulnerabilities.
Cloud service providers reinforce the importance of threat modeling to their customers. AWS includes threat modeling as part of its Well-Architected Framework. Microsoft Azure offers its Microsoft Threat Modeling Tool. Google Cloud Platform includes vulnerability and threat data as part of its Security Command Center dashboard. There are also industry standard threat modeling tools for DevOps organizations, including Kenna.VM, Open Web Application Security Project Threat Dragon and ThreatModeler.
The Threat Modeling Manifesto captures the benefits of threat modeling in simple and familiar business terms and starts with four questions that apply to DevOps projects:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
These are questions you can and should ask at each phase of the DevOps lifecycle -- development, integration, testing, deployment and monitoring -- because applications grow in complexity over time. Partnering DevOps and threat modeling makes business and strategic sense because of the data-rich, gated and iterative development framework that DevOps offers.
Making the partnership between threat modeling and DevOps a reality requires establishing some best practices and acknowledging the challenges.
DevOps and threat modeling best practices
Here are some best practices to implement threat modeling as part of your IT organization's DevOps practices.
1. Start by thinking where things can go wrong
Start simple with the development team, and determine where things can go wrong in the project, coupled with what actions to take to resolve them. The STRIDE framework -- Spoofing identity, Tampering with data, Repudiation threats, Information disclosure, Denial of service and Elevation of privileges -- is an accessible starting point to threat modeling.
2. Factor in business risk from the beginning
The shift to a DevOps organizational model removed the silos between developers and sys admins. When you bring threat modeling into DevOps, IT teams must assess business risk in the beginning of the project.
In this way, threat modeling can act like a preliminary gate before the project's starting line, in the same way that security and testing act as checkpoints throughout the CI/CD pipeline. Include business stakeholders in the DevOps process early and often. Document the business risks in terms that resonate with the technology teams. And maintain open channels of collaboration between technologists and business teams.
3. Implement DevSecOps
The case for threat modeling is a straightforward entry point for an evolution of the DevOps model into DevSecOps. Account for threat modeling in the road plan and budget to train teams on threat modeling best practices and to instate appropriate tools.
4. Choose a pilot project
Start your IT org's move into threat modeling in the same way it began its DevOps journey: Choose a small project with stakeholders and a team that will benefit the most from threat modeling. For example, select a project that must meet heightened security and compliance standards -- and, ideally, is led by a highly security-conscious team.
5. Mind the gap
One of the reasons DevOps manifested was to close the gap between development and operations teams, tightening communication pathways and shortening deployment cycles. The introduction of threat modeling is another step to close the gap. Provide all stakeholders -- especially the business -- visibility into the project, as well as a platform to air questions or concerns. Healthy pessimism and overthinking are welcome in these conversational spaces, but those concerns should lead to an executable plan.
6. Automate threat modeling with tools
As with all other elements of a DevOps initiative, seek out every opportunity to automate threat modeling, but limit this to what makes sense for the given project to avoid overextension -- both in budget and staffing terms. Threat modeling expertise can be hard to find, even without the complications of a DevOps transformation. Seek out a threat modeling tool that integrates with your IT org's DevOps toolchain and includes a base set of threat definitions, along with documentation and training for IT teams.
Add threat modeling to DevOps: The challenges
Adding threat modeling to DevOps processes and toolchains might raise some challenges for your organization.
1. Developer pushes back
Threat modeling represents a major change to developer workflows, so some teams might push back against the change. Some developers will resist doing threat modeling because it they see it as a niche cybersecurity skill set beyond the developer's job description. Factors that contribute to pushback include the following:
- lack of awareness or a bad experience from past projects;
- concerns about friction with the DevOps process; and
- budget concerns and internal politics, such as poor relationships between developers and the security team.
The traditional ways to mitigate developer pushback all apply here. Make an extra effort to include developers in both planning and strategy discussions from the beginning. Then, look for ways to build threat modeling expertise in-house via the same strategies used in your IT org's DevOps transformation, such as internal or online training and pilot projects.
2. Threat modeling processes are abundant
Threat modeling approaches and processes vary greatly. One school of thought says threat modeling works best at the beginning of the project. Another says threat modeling works best halfway through the project. Then, again, another claims threat modeling works best at the end of the project.
Using industry research, pilot projects and industry best practices, you can narrow down to the threat modeling process that best serves your projects and industry customers.
3. Breaking down threats is complex
Determining even high-level threats to break them down into easily addressable subthreats can be a challenge for some organizations. To skirt this challenge requires training, best practices and accrued experience over time. Dedicate time to project management to work through this transition to ensure that lessons learned aren't forgotten.
