Evolving Threat Modeling - Taking Longer Strides

How can you get started with threat modeling?

For those of us not intimately familiar with the subject; threat modeling is a structured process which allows us to identify security requirements, recognize security threats and potential vulnerabilities. Ultimately allowing us to quantify threats, determine the criticality of vulnerabilities and prioritize remediation methods.

All lofty goals, but where do we start?

The accepted norm is to follow “Shostack's Four Question Framework”^*

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

“What we are working on”, you would hope was easy to determine. Surely you have requirements? An architectural diagram? Assuming that you do understand what you are working on then that is when things get interesting, now we need to identify “what can go wrong”, so how do we do that?

Black magic...

If only it was that easy, as with most things security related, it requires a great deal of skill, knowledge and not least some imagination to sit back and think like an attacker. So just how would someone gain access to my brand-new smart freezer, sitting in my home, connected to my network, connected to my ISP, connected to the internet? And why would they want to? Well in the not-so-distant future, your smart freezer will have the capacity to restock itself, when you’re low on milk, or perhaps more exotic content such as eggs…. In order to do so, it would need to pay for those things, it would need access to a payment facility, a delivery location, and other personal identifiable information. And who’s to say that someone would not take it upon themselves to redirect orders, or even start to place orders for non-food produce; how often do you check your credit card bills to validate transactions? So how long would it take to spot that 75” OLED TV that your freezer just ordered?

Threat modeling resources and methodologies

So how do we stop such outright thievery? We have great resources available to us, things like CAPEC, which provides cyber-attack patterns, or Mitre Att&ck, which provides access to a knowledge base of attacker tactics and techniques based on real-world observations, which is great when we know what we know but what about the stuff we don’t know? If we are new to this game, where do we start?

Probably the most well-known starting point is STRIDE, short for:

Spoofing
Tampering
Repudiation
Information disclosure (privacy breach or data leak)
Denial of service
Elevation of privilege

There are lots of resources and methodologies that can help you start your threat modeling journey, and how to utilize STRIDE, but how can we evolve our threat modeling?

Once you start Threat Modeling with STRIDE, you begin to identify threats associated with the systems or subsystems that make up our smart freezer. By implication you are building a knowledge-base representing the risk for those systems. And just to emphasise, this is a really important moment in your threat modeling journey! This library of risk is not just applicable to your smart freezer, much of it can be ascribed to other smart devices that you may have in your home, the TV, the toaster and so on.

Identifying threats

If we capture this information (so it's not just running around in our heads) we typically create a catalogue or library that we can reference in the future. This information can also now be socialised across our team(s). If we are being agile (and aren’t we all?) then the next iteration in our DLC (development lifecycle), or our other projects, can more easily identify potential threats. That’s not to say there may not be some lateral thinking required to look at other potential vulnerabilities, but we can be more efficient with our time given that we are not starting from scratch every time.

Over time, and with ever increasing confidence, we can expand our understanding of the potential threats by including other more extensive resources to our risk patterns, we can start to look at CAPEC, at Mitre Att&ck and at other security knowledge-based resources and incorporate them into our threat modeling.

STRIDE is still a useful tool when thinking about new systems/ subsystems/ components, periodically reviewing our existing threat content, re-examining the risk profile and understanding any new or emerging attack techniques, or defence options. But at the heart of our threat modeling we have a risk library that can help us improve our efficiency, repeatability, and provide more consistent results.

Mitigating threats

At this point we have focused on what can go wrong, but that is only the first part of the security puzzle (the Ying). Addressing Adam Shostacks’ 3^rd Question we also need to determine what we are going to do about these threats (the Yang).

The universal truth is that we can’t fix everything, some things (especially in existing systems) are just too difficult, costly, or impractical to implement security controls. For those unfamiliar, security controls, allow us to mitigate the threats we identified as part of our threat model, putting in a Web Application Firewall can help protect web applications from attacks such as cross-site-scripting (XSS), file inclusion, and SQL injection, among others. However, we should fix or at least look at the root cause within the Web Application, because if there is a flaw, then there are people out there who will find a way around or through security controls such as your WAF. We can build protections within our Web Application by implementing controls within the code of our web application, for example to prevent SQL injection, we might suggest:

Use Prepared Statements (with Parameterized Queries)
Use Properly Constructed Stored Procedures
Perform Input Validation
Escape User Supplied Input

We might also want to look at a more generic controls to enforce least privilege access.

Our risk libraries can play a big part here, once we have identified the necessary controls that address a threat, we can document these controls.

What can go wrong?

Attacker can perform SQL injection

What are we going to do about it?

Use Prepared Statements (with Parameterized Queries)
Use Properly Constructed Stored Procedures
Perform Input Validation
Escape User Supplied Input
Enforce Least Privilege Access

I highlighted previously that threats are not just limited to one system/ subsystem or component, they can be applied to many, and by implication the same or similar controls can also be applied. So, our risk library now starts to look more like a series of questions with answers, a series of patterns that make up our very own threat modeling cheat sheet, making it much easier to answer the 3^rd question “what are we going to do about it” when threat modeling our projects.

Impact and prioritization of threats

To understand the impact of any threat, and ultimately prioritize what security controls are required (or nice to have), we need to be able to calculate the risk for each threat. In simple terms we need to understand the potential impact of the threat. There are many possible ways to calculate risk (just Google ‘security risk calculator’) typically based around confidentiality, integrity, availability, and ease of exploitation, although many go into more detail regarding both business and technical impacts etc. This individual threat risk can be aggregated along with the overall risk score for our project.

We can even go further and look at the security controls, to determine the cost of implementation, is there a training or infrastructure cost? How easy is it to implement the control, how much time would it take?

All this information can help us decide on how to answer question 3; 'What are we going to do about it?'

With all of this intelligence our security controls can now be interpreted as Security Requirements, that we can pass onto our engineering teams to instruct them on what they need to do to ensure as secure a project as possible.

Tracking your efforts

Whatever mechanism we use, from an excel spreadsheet to Jira tickets, we do need to track what is going on. Those security requirements that have been implemented, rejected or are still outstanding. This helps us understand the risk associated with all projects and using reusable risk libraries we can quickly threat model our projects and provide consistent feedback to ensure that we build secure systems by design.

The more we threat model, the more we understand, the better our risk libraries become. The faster we can threat model, the more effective our threat modelling can be.

The unfortunate reality of the situation is that as our business grows, then so does the burden on our technical resources, developers, security teams, operations teams, and at some point, we need to start looking at injecting technology. This allows us to scale, become more repeatable, and more efficient with the use of our scarce technical teams.

Risk patterns

At IriusRisk what has been described is exactly what our security team are doing and have been doing day in day out for the past 7 years, creating libraries which document risk patterns. These risk patterns document threats, weaknesses, and their associated security controls (or as we describe them as countermeasures) for commonly used components across domains, such as cloud infrastructure (AWS/Azure/GCP), industrial controls (ANSI/IEC 62443), Docker/Kubernetes, application functions, and beyond. The IriusRisk platform takes your architectural diagram, enhanced by detailed questionnaires to identify, and prioritize threats and countermeasures based on these risk patterns.

For those who already threat model and have already documented risk libraries, this content can be added to the platform. For those who are relatively early in their adoption of threat modeling, this provides you with a quick start. Risk libraries that you can use out of the box, that you can tailor over time to your needs. If you’re really new to threat modeling and feel overwhelmed by all the content or, the volume of threats, our customer success team can advise you on the best way to start consuming IriusRisk Threat Intelligence. If you want to keep it simple, start capturing threats with STRIDE, turn off the risk libraries, until you feel ready, and take a look at Jonny Tennyson's article of STRIDE and CAPEC with IriusRisk.

You might not be able to just sit back, relax and enjoy the sun just yet, as there are always new projects, new features, new systems, that need threat modelling and, new threats or controls that need to be assessed. But at IriusRisk we’re here to help you to evolve, and successfully threat model, to ensure your design is as secure as possible.

*Source: Shostack, Adam. Threat Modeling: Designing For Security. John Wiley & Sons, 2014

‍