Threat Modeling – how to start doing it?

The first article of this series explained why we need threat modelling, and what exactly is needed to make software development secure. This one will describe how to do it the right way.

Make a security a policy

First, you need board support and funding. The worst that can happen to Secure By Design policy, is having “cowboy projects”. Those that deliver the biggest revenue or income for the company, glorified by the management and having an “out of jail card” for pushing code to production without following the process. 

A good way to convince the “cowboys” to comply with the policies is showing them the advantages. You can start with one or two smaller projects. After such a Proof of Concept, measure the number and severity of security bugs, the cost of fixing them and of course include the cost of additional threat modeling sessions. Compare these numbers to the projects following the current methodologies. 

How to organize Threat Modeling Sessions?

To come up with valuable output, you need at least three groups of people:

• Security – who think like attackers and know technical ways of exploiting systems
• Business – because they know what would wake them up at night and can take decisions to accept or mitigate risks
• Technical – developers or administrators who know how their systems are built, or architects who are designing a new system

I suggest at least one person from each group. Generally – the more the better (keeping it up to 8-10 people in the room), however to minimise the costs a Lead Developer can take both Business and Technical role in the discussion.

How long should the sessions be? 

Generally, an effective meeting should not take more than 2-4 hours. Half a day is optimal for both generating a concise output and keeping everybody active in the discussions. 

What to cover in a threat modeling session? 

Apply ‘Breadth-first search’ methodology. Try to analyse the whole attack surface at some level, rather than digging into 2-hour discussion on potential attacks from insiders. You can always repeat the session for in-depth analysis of some functionalities.

What to (evil) brainstorm? Start from the potential attackers (threat actors) and their goals (threats) on the business level. Then, go through Data Flow Diagrams (DFDs), analyse all entry points and interfaces. Do not focus on whether an attack is possible or not as this wastes valuable brainstorming time – ignore all questions and comments such as “oh, this won’t be possible due to our firewall” – we analyse the potential threats and assume misconfigurations in all mechanisms. Ask a lot of questions “what if …”, “how about …”, “if this was possible, what …”. 

Threat modeling output

The expected output from a threat modelling session is a list of:

• Threat actors  (e.g. anonymous user)
• Threats (e.g. accessing admin panel)

Now it’s time for the security team to digest the data off-line and come up with:

• Attack vector or abuser story (e.g. log in with default credentials)
• Security requirement (e.g. a password policy)

The report may include an additional technical part of:

• Example vulnerabilities (e.g. SQL Injection in the log-in form)
• Test scenarios (fuzz the log-in form with default passwords and SQL Injection payloads)
• Mitigation (e.g. change all default passwords, protect the log-in form against injections)

Threat modeling report use-cases

A final threat modeling report with the above threats and corresponding attack vectors can be used in many different ways:

• For the management, as a help when assessing the risks
• For the clients, to know that a formal threat analysis was performed
• For the developers, as a reference to include security requirements/mitigations
• For the security department, to decide on the penetration testing scope and required resources
• For the penetration testers, to follow the test scenarios and map the vectors to threats
• For the security department, to measure the results of the test and applied mitigations

How to perform threat modeling at scale?

Having in mind that each threat modeling session requires somebody from a security team, you can quickly estimate that in certain methodologies (e.g. Agile), the above process will be either extremely expensive or impossible. Each project needs a security person for at least two days each sprint (one to organise threat modeling sessions, and second one to digest the output and write a report). This means you need to have 1 security person for each 5 agile teams, taking into account personal leave, holidays and training – it sounds more like 1 full-time employee for each 3 agile teams. With an average size of a team – 8 people – we are looking into 1 person working solely on threat modeling for each 24 developers. There is no way the board will approve such a budget! 

This requires a bit of a shift in the responsibilities and another idea of how to organise the sessions and log output:

• Initial threat modeling at the start of the project + regular sessions each month/quarter – to cover attack scenarios affecting the infrastructure, global use of technology/frameworks and other, not linked with specific user stories
• For each new user story, there needs to be an ‘abuser story’ – an evil scenario to exploit the functionality (e.g. user story: users download their transaction data; abuser story: one user downloads another user’s transaction data)
• Abuser stories are created ad-hoc by developers and project owners
• Abuser stories require a review from the security team member who can modify or add new items
• Designing abuser stories may be delegated to a new virtual role – security champion – within the development team

The advantages

• Developers already use tools to log user stories (ticketing systems)
• Quick reference for developers during coding phase (“remember about access control”)
• Automatic creation of (evil) test scenarios (e.g. “check cross-user data access control”) 
• While designing abuser stories and getting reviews from the security team, developers learn about new attack techniques and start to “think like an attacker”
• Minimum effort from the security team allowing threat modeling at scale

An example output logging the abuser story in online banking could look as below:

An example output logging the abuser story in online banking could look as below:

The next step is to build base threat models for a given technology and to stack them in a structure. Imagine there is an online banking which consumes SOAP API written in Java (Struts). We can build multiple base threat models:

SOAP API:

Java (Struts):

This approach allows us to save a lot of time when developing new API or new API methods, as all base threats apply and they are already logged in the system.

Summary

Threat modeling allows patching critical and architectural vulnerabilities during the design phase of development – before a single line of code is written. 
It also allows you to implement mechanisms to avoid whole classes of vulnerabilities before the code is tested. Depending on the methodology and company structure, it may require a different approach but it is possible and the advantages clearly outweigh the cost when you take into account the cost to fix bugs post-release. If you want to discuss how it may look on your end, whether you are a CISO, a project owner, a developer or a security tester – use our contact form.

Jakub Kałużny Principal IT Security Consultant
Head of Secure Development