Threat modeling is a process used to identify potential threats and weaknesses in a system. It involves breaking down a system and examining it to better understand what needs protecting, who might attack it, and how it can be protected.
So who needs to be involved? Well, as with all good questions, the answer is it depends. From here let’s assume that the target is a web application being built by a small-medium-sized development team.
In this case, we might include:
- Lead or Senior Developers
- Product Manager
- Pentester or Security Engineer
- Architect
If your team also includes DevOps engineers, sysadmins and other developers, then feel free to include them. However, once you go over about 6-8 people, things can become a bit chaotic, so keep that in mind.
A typical threat modeling session might look something like this:
1. Define the scope & collect information
It’s important to turn up to the session with information about the system or application you’re going to threat model on. Even if it’s half-complete architecture diagrams or confluence pages, you need as much information as you can get.
2. Create a Data Flow diagram
Ensuring you have an accurate representation of the system is vital, regardless if development has started yet or not. Everyone will be able to work from the same information and it helps tremendously when discussing potential attacks or weaknesses.
3. Identifying threats
Understanding your threat actors early on is going to save you a lot of time. Assuming that APTs are after you day and night and that they are going to find a zero-day in every part of your system is a waste of time. Start by looking at your previous incident reports, who was the threat actor? Then do some research into the industry you’re in, who are the consistent threat actors in your industry? Then, it’s also time to consider insiders. When in doubt, keep it simple, and keep moving forward, try not to get bogged down.
4. Evaluate risks
Look at what the threats or threat actors might achieve. Consider the likelihood of this happening, and then prioritise based on risk level. Remember that your risks should have three parts:
- The event itself
- The cause (e.g. a threat actor)
- The impact
5. Mitigate risks
Now it’s time to go back to your system and consider changes that need to be made to address risks, or controls that needed to be added. Note that not everything needs to be addressed. The whole point of prioritising is so that you can reduce your overall risk to an acceptable level. No system is 100% secure.
6. Review and update
It’s worth scheduling sessions that fit your development lifecycle. For example, if your development team are following 2-week sprints, having a session once per quarter with all of the stakeholders, and then bi-weekly 30-minute review sessions with the team is likely to be beneficial without being overwhelming.
Getting into the habit of threat modeling can:
- Help bolster the security culture at your organization
- Enable your team to find security issues early in the development lifecycle
- Improve communications between the security and development teams
- Improve the security posture of your organization