Everyone loves a sandwich, but as a cyber security strategy, it’s terrible. Sadly, the sandwich security pattern is something we still see far too often. Security is taken into consideration once at the beginning and again at the end of a software delivery lifecycle, with no checks or re-assessments in between.
If an Agile team with a continuous delivery pipeline follows that security pattern, they could be deploying code to production systems multiple times a day without stopping to re-assess any risks, or take security into consideration at all. At best, that’s a bad idea. At worst, it’s critically dangerous, and a huge threat to the project and the organization at large.
Let’s walk through a quick example. Imagine you work for an e-commerce website that’s adding a new feature to its payment system. At the beginning of the delivery lifecycle, you have a discussion to outline any potential security risks associated with the project, along with the initial implementation details. But, as time goes on, small changes add up to a finished product that’s significantly different to what was initially discussed.
At the end of the project, a security expert is brought in to assess the product, and thanks to these changes in scope, they predictably find numerous vulnerabilities that your team must spend time and resources to fix. Then, in the rush to get everything “fixed” before the deadline, a serious security flaw gets introduced.
Before you know it, you’ve got a live product, in the hands of thousands of customers, exposing the entire organization to a whole world of sophisticated cyber threats.
Shift left from the sandwich with Agile Threat Modeling
We’ve all been there. But there is a far better way to manage security across Agile software projects.
At ThoughtWorks, we use Agile Threat Modeling throughout the software delivery lifecycle to identify potential risks in a system, decide what to do about them, and turn those decisions into actionable work — all in the space of 90 minutes.
Agile Threat Modeling is a tool used to understand and model how attack surfaces and other security considerations shift throughout the software delivery lifecycle. Instead of front-loading your security discussions and rushing to detect and fix issues at the end of a project, conversations and exploratory sessions happen throughout the project, helping everyone stay on top of developing issues, and use their insights to proactively detect potential flaws. During these sessions, action items are determined and added to the Agile board backlog.
Why use Agile Threat Modeling?
Completing those sessions regularly in the design phase of the software delivery lifecycle ensures that your security stays in step with the evolving architecture of your system. That allows for more frequent releases and higher performing teams. Plus, security considerations are addressed throughout the process, so there’s no more security crunch before launch, and far fewer opportunities for vulnerabilities to go undetected at the eleventh hour.
But, while the benefits of this approach are clear, it isn’t always easy to embed it into your design and development processes. The biggest challenge in Agile Threat Modeling is adoption — turning this into something that’s regularly done as part of your path to production. So what are the biggest challenges in adopting Agile Threat Modeling and how can you tackle them?
Challenge #1: Managing complexity
Most systems are complicated. The goal of Agile Threat Modeling is not to capture the complexity of the software accurately, but rather to do so sufficiently in order to understand high-risk potential threats. A good way to avoid any technical rabbit holes is to have a clear idea of when “enough is enough”.
Challenge #2: Maintaining motivation
Motivating your team is essential to the long-term success of Agile Threat Modeling. It’s important to explain the goal and outcomes of Agile Threat Modeling, and in particular, how this actually impacts the Agile board. Once the teams can clearly see the value it represents for them, motivation should improve.
Challenge #3: Securing buy-in from the business
Getting an organization to adopt a new practice is always challenging. To secure buy-in, you’ll need to communicate the resources needed to make these sessions happen, a detailed plan for building them into the software lifecycle, and a clear view of the value they’ll deliver to the organization.
Get started with Agile Threat Modeling today
Starting out with Agile Threat Modeling takes time, and it can take a lot of practice and experimentation to find the right fit and configuration for it within your team and organization. However, the results are more than worth the time investment needed to get it right and embed it across the software delivery lifecycle.
Are you tired of the raised pulse and chest pains associated with leaving security to the last minute? Then start Agile Threat Modeling today.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
