Threat modeling without a diagram

Most threat model approaches (like e.g. STRIDE) assume you have a technical overview like a Data Flow Diagram. An interesting question therefore is; can you threat model when there is no such thing available? A common situation would be when your are forming an epic, but as an exercise let’s take a legal contract or service level agreement; can you threat model that? Let us find out….

At first sight this might be a stretch or weird thing to do as there are no assets to protect or technical risks to identify, but I will show you can still get interesting results by tweaking the process and making a translation first.

Identify false promises

ISO 15408 specifies ‘the evaluation criteria for IT security’ and provides a good overview on the relationships between Owners, Threats and Assets within the co-called ‘risk context’.

Looking at this concept, it becomes clear which parts we first need to identify in the threat model exercise:

• Assets – the things we care about
• Risks – things that would jeopardize the asset’s value
• Vulnerabilities – things that would allow the risks to become real
• Threats – things that make the vulnerability happen

So how would we translate this to for example a legal contract or service level agreement? A legal contract is in essence a long list containing

1. promises (as in promise theory) to your customer
2. the consequences when you cannot meet these promises

In other words, they represent a legal description of value. In this exercise we therefor consider these promises to be the assets.

Side note: looking at contracts as a set of promises is not a novel approach as this document from 1856 shows and is still being researched in modern times.

When a promise is given without validating if you can actually fulfill it, that would be a risk. It’s not said it will ever become a problem, but in general you should prevent making promises you cannot keep.

A vulnerability would be promises you know you cannot keep or cannot keep continuously. These parts have actual potential to do harm to your organization.

A threat would be a customer laying claim on the parts of your contract that contain the promises you cannot keep. These things have the potential to get you in trouble.

With this mapping it becomes more easy to threat model a contract:

• First you list the promises in the contract
• Second you start validating whether or not the promises can actually be fulfilled. A good exercise form to do this is TRIZ. TRIZ is a brainstorm exercise format for finding answers to questions like “under what condition would we not be able to fulfill this promise?” by thinking of ways to actively prevent promises to be fulfilled. (Try it; it’s fun and very insightful!)
• The third step would be to identify when these conditions can occur and if they are mitigated in some way

STRIDE translation

An interesting question now is: are the types of threats you are identifying in this exercise different from the ones you identify when threat modeling a technical diagram? Let’s take a look at STRIDE.

STRIDE is a very popular threat modeling approach used to identify threats in a (technical) design. STRIDE is an abbreviation of 6 threat categories you typically encounter in technical environments: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

Let’s find out how we can make a translation for the issues identified in a legal contract threat modeling exercise:

Spoofing is basically being able to impersonate someone. In this legal example we can translate that to “not verifying if the person making a claim is actually the owner of the contract”. This attack might be important if the claim is related to specific circumstances under which a promise becomes active. In these cases you want to make sure the person asking is authorized to do so.

Tampering is being able to modify data when you’re not supposed to be able to do that. In our example this might look as something not relevant as you cannot simply change a contract, but there is a catch. Contracts are based on language and language is susceptible to interpretation. A tampering attack can be translated as a promise that can be interpreted in a way that doesn’t reflect the original intention anymore. This can lead to difficult discussions and undesired outcomes.

Repudiation attacks normally mean that you cannot proof when someone did something. In a more legal context this is still a valid attack; especially when you end up in a discussion, it’s essential you have a way to keep a track record. Also when certain promises can only be claimed to a certain limit, it’s important to be able to prove previous claims.

Information disclosure is about leaking more information than necessary. This can also easily be translated in a more legal context when promises are made about sharing information. A nice example would be sharing information about existing vulnerabilities in the service. Often customers can request to receive these to update their own risk assessments. When you fail to specify what a customer is allowed to receive, you might share more sensitive information than you intended.

Denial of service are normally attacks that would render the service unusable for other customers. In a legal context we can translate that to claims that will take up more time than you can handle as an organization. An example would be a promise that allows for requests for information without specifying limits on how often a customer can do so. If a customer decides to hold you on this promise on a daily basis, you will quickly run out of time to do other things (and possibly will become subject to regulatory consequences for not meeting deadlines).

Elevation of privilege is normally an attack in which a user gets privileges not intended for his role. This is possibly the hardest threat to translate. In a contract sometimes only specific roles can activate a specific claim (e.g. the CFO or Data Protection Officer); failing to identify if the requester has this specific role can lead to a situation that falls into this category.

Conclusion

This simple exercise showed that threat modeling is not restricted to technical designs and just requires some creativity to make it applicable to any situation. Even when there are no technical specifications, it’s still possible to identify assets and therefor risks, vulnerabilities, and threats.