Imagine your application has broken auth mechanisms which leads to data leakage. If that’s not scary enough, imagine you’re finding out about this two weeks before the release—because that’s usually when teams start running security checks. Don’t you wish they had thought about security from the beginning? It’s much better to invest in it throughout the development rather than pay for your mistakes tenfold near the end.
The good news is you can actually reduce design flaws by shifting security left (figuratively speaking, of course). Read on to learn more about this approach and see how threat modeling can become your first step toward it.
What is shift-left security?
The shift left is becoming a standard requirement for secure systems design. In short, it means addressing security concerns as early as possible in the development. With this approach, dev, ops, and infosec teams collaborate closely throughout the whole software delivery lifecycle. They enact security practices early on at certain points of development.
The motivation for using the shift-left approach is simple: the cost and time-to-market of addressing security only after an incident (i.e., passively) are just too much.
By contrast, shift-left security is a proactive approach that offers:
- Low cost of security incidents thanks to early discovery
- More secure software by design
- Holistic security that doesn’t blindly rely on an annual penetration test.
In fact, according to the State of DevOps Report 2020, 45% of companies with full security integration can remediate critical vulnerabilities within a day.
Removing the development and security friction
The shift-left approach removes friction between the development and security teams. Previously, developers addressed security concerns somewhere near the end of the cycle. They’d run pentests, and the security team would deal with their results. With shifting security left, there’s no need in this traditional ping-ponging anymore.
Now dev, ops, and infosec teams are encouraged to work together on the system’s security like one big team. Naturally, this might pose some new challenges, as the team might not be aware of specific security issues. But you can solve this easily by organizing security training or separating the roles of security champions.
Also, the shift-left approach integrates well with Agile methodologies:
As a result, security becomes an integral part of the development process and a solid product feature. From being an obstacle, it turns into a business enabler.
What’s inside the shift left?
Let’s take a look under the hood. In general, shift-left security includes:
- Architecture security review
- Threat modeling
- Secure coding practices
- Penetration tests
- Secure operations (monitoring, logs, vulnerability scans, etc.)
The shift-left approach perfectly integrates with the DevOps tooling, in particular:
- Static application security testing (SAST)
- Dynamic application security testing (DAST)
- Container scans
- Compliance scans
- Dependency scans
Moreover, these measures resonate with classic Secure SDLC frameworks – OWASP SAMM, Microsoft SDL, and others.
You have to keep in mind, though, that the shift left is not so much about specific activities as it is about the right mindset. In this approach, security becomes an indispensable part of overall quality, and every team eventually finds its own way of implementing it.
Threat modeling: a pillar of the shift-left approach
Now, let’s talk about threat modeling, one of the first steps you can take toward shift-left security. This technique helps you identify and understand various potential threats to your system. Vulnerabilities, countermeasures, attacks, and other risks—this method can reduce all of them.
Threat modeling often means answers the following questions in the technical steps:
- What are you building? You need to establish what kind of system you’ll build and define the scope of your Threat Model.
- What can go wrong? Next, you do the research and identify potential threats to your system.
- What should you do about those things that can go wrong? Identify the steps you need to take to address the issues.
- Did you do a decent analysis? Finally, double-check what you’ve done.
In a nutshell, this technique allows your team to look at the system through the hacker’s eyes. This way, they can come up with hacking/risk scenarios and anticipate the threats.
This approach offers several benefits:
- Better security design and balance. Since the team knows the weak security spots, they can invest more effort into those specifically.
- Designing a secured system from the very start. Threat modeling allows you to make the right security decisions from the get-go instead of fixing system design flaws after it’s gone live.
- A security mindset. Joint brainstorming and close collaboration on security objectives make the team more security-aligned and aware.
Is it hard to do threat modeling?
The good news is threat modeling is a flexible approach. You can easily apply it on your own and choose your perfect match out of the many methodologies available. Pick one depending on the level of effort your team wants to invest in threat diagraming, formalization, and structuring.
The most common methodologies include:
- Attack libraries (CAPEC, OWASP Top 10)
- Agile approaches, such as Evil user stories or OWASP Cornucopia (EoP game)
You can choose a range of tools, too: from heavy commercial tools with automatic threat modeling to lightweight open-source solutions like OWASP Threat Dragon. Alternatively, you can even go with the no-tool approach.
Do keep in mind that it takes some time to find the right balance and implementation resources. But once it’s done, your team armed with the right mindset can support the threat model with ease.
Threat modeling is not rocket science, but still requires a specific mindset, hence it’s still good to have an expert who could guide you through the process. Contact Iterasec’s professionals to help you along the way.