Threat Modeling should be as frequent as the changes in your software.
Here is something we can all relate to:
When getting ready for an interview with a company, we do a couple of things. We expect questions (obviously), so Google becomes our friend and suggests numerous questions for us to practice.
If we have the network, we reach out to an employee of that same company to learn about them and the interview processes. Maybe you practice in front of a mirror so you assess how confident you look.
The process is not perfect, but you brainstorm possible interview scenarios and prepare yourself for them.
And, on the day of the interview, you go through your checklist, confirm you've done everything in your power, and head on to take your interview.
So technically, you brainstormed on the possible scenarios the interviewer could ask you and you prepared yourself to answer them with the resources you could get.
That's Threat Modeling.
First, we imagined the typical scenarios the interviewer could put us through (the threats).
Then, we researched the questions that may lead to those scenarios. Even better, we reached out to an employee to get a better grasp of how those possible scenarios could play out.
Then, we prepared for those scenarios (the model’s security requirements).
Threat modeling is a structured process that identifies and pinpoints security threats and potential vulnerabilities in a software’s design, helps understand the cyberattack kill chain, and improves its security posture.
Threat modeling is the most effective way to find design flaws early in the software development cycle, even those missed by security methods such as penetration testing and code review.
Is Threat Modeling a Basic Security Measure?
Yes, it is. Or rather, should be.
Ordinarily, when software engineers code they should integrate security into their processes. Frankly, some do. But is HTTPS on your web application or a captcha, for instance, enough to say your software is secure? Far from it.
Only a few software engineers take security to such a high level and prioritize it as much as they produce code.
I'll mention here that bugs are different from design security flaws. While some bugs may result in security flaws, they are not one and the same.
So, if your security engineers are cleaning out their bugs, awesome! But it doesn't translate to comprehensive security.
Threat modeling is assessing your software risk landscape in line with design and implementation and working to identify design weaknesses and potential vulnerabilities. Threat modeling doesn't result in ALL of your vulnerabilities being fixed. However, it does result in a smaller attack surface and awareness of existing and future security weaknesses.
One of the most popular processes for Threat modeling is by Adam Shostack called the Four Question Framework:
1. What are we working on?
This is where you highlight your software design details. What it can and can't do. Its entry points. You lay your software bare to all involved.
2. What can go wrong?
This is where everyone involved wears their black thinking hats. Nothing is too small a threat if it can affect usability or privacy. Every possible threat from every possible angle is written down. It doesn't have to be a 50-page document, but it should be concise and detailed enough for your company and software.
3. What are we going to do about it?
Now is when you mitigate the found vulnerabilities. If there are protective measures to be taken, they go down as action points with time frames on them. If other vulnerabilities aren't serious, they can be tracked as other threat modeling sessions come up.
4. Did we do a good job?
If your software developers have mitigated your most crucial vulnerabilities to the best of your abilities, then you have. If there are still major loopholes in the design, you should go back to number 3.
Myths about Threat Modeling that Impede Software’s Security Growth
1. My App is Already Deployed
If anything, this is a sign to start threat modeling, not ignore it. What you are saying is that your app is out in public and you know nothing about its security flaws, most especially, the app’s design flaws.
So if a hack occurs today, you would be at its mercy. Plus, you would have no idea the source, taking even longer to recover from it. Understanding your weaknesses allows you to react to attacks faster and more efficiently.
This sums it up:
“You won't know [your vulnerabilities] and your attackers will know because they will be probing your system and finding out all of your weaknesses.”
- Brook Schoenfield, Cybersecurity Expert, CTO at Resilient Software Security.
If your app is deployed, start threat modeling now. It's never too late to start threat modeling.
This will allow you to close major vulnerabilities and stay aware of the other “minor” ones.
2. We haven’t found any flaw
Flaws, whether found or not, say nothing about hidden vulnerabilities. You might have performed penetration tests, but it doesn't reduce the value of threat modeling.
3. We don't have the experts needed for the threat modeling
That may be true. But it doesn't mean threat modeling should be put on hold. Any threat model is better than none. You don’t have to be an expert to produce a useful model. Of course, having a threat model expert available will likely produce much better, more comprehensive results.
So what you need to do is to get your developers and users (if you have them) to collaborate and analyze the attack surface of your software!
Yes, some things may be missed, but as said before, any threat model is better than none.
But, if you do want an expert to guide or help threat model, there's still no need for a full-time hire, Resilient can help.
4. We are just a startup. Threat modeling isn't important right now.
Well! This would be the time to let you know that 56% of cyber attacks target startups. It doesn't matter what stage you're in; there's always something to lose. Attackers only care about what they can gain through the attack. Your organization’s context is irrelevant.
Plus, if you go down this path, it's like waiting till the day before the interview to start preparing. Because when you do decide to push modeling years downline, with a strong assumption you haven't been a victim of any attacks, you would be looking at a mountain of vulnerabilities to fix, and increasing panic when you do see the number of important vulnerabilities you let lie.
5. We've threat modeled before.
I love to break it to you: threat modeling isn't a one-time thing! Your software is constantly being updated, your bugs are being found and removed, and more bugs are being introduced as a result of your updates.
Even more importantly, the threat landscape is constantly expanding.
Even if, you haven't made one edit to your software and you believe that you monitor all of the vulnerabilities found then. The security landscape is expanding so fast that current security may become obsolete. Or the vulnerabilities you deemed minor because there was no known attack to that section, could very well move to the top of the list.
“A threat model is a living document when you change the architecture, even some design choices will change the model” – Brook Schoenfield, Cybersecurity Expert, CTO at Resilient Software Security.
The Way Forward
You can start threat modeling right now with the software developers you have on your team.
Have them sit together and go through the 4 step framework. That is way better than doing nothing. And it's a holistic approach that allows everyone to know how and where they can contribute.
Now, practice makes perfect or at least progression. Your team is just about to start their first threat model. It may be second or third since we’ve finally convinced you to pick it back up.
At Resilient though, we have professionals who have thousands of threat models under their belt. Combined we have a century of cyber security experience.
So, if you want guidance to be able to cover as much of your attack profile as possible, we’re only one click away → Start Threat Modeling