Tame The Beast - Building Security via Threat Model

Perhaps conversing on yet another topic seems to be a good way to deal with this unending today... so here I am - again.

In hindsight perhaps this should have been the first article in this series. It would help us align on the definition of security. Often termed as a domain by itself, security is really just a horizontally intercepting systemic thought process, a process that helps us protect what we wish to protect against what we consider adversaries.

On the other hand in my journey so far as a security engineer, I often saw security solutions built rather loosely without establishing the right borders and context of what needs to be protected against whom. It usually ends up with security being the beast that no one cares to invest in, often dreaded, and hated but one that becomes an overnight priority in the light of some incidents. Unfortunately, it can't be built backward & and all one can do is deal with repercussions.

So why do we need to & and how do we tame this beast called security? The method to tame this beast is referred to as threat modeling. Let's delve into some interesting aspects of it beginning with what is this much ado about nothing.

Let's take a shot at security!

Security is a systemic and systematic way to harden or secure any functionality and/or asset (hardware or software) against specific abuse, misuse, or attacks. This is a lucid thought process and needs to be applied & and adopted in a specific context of functionality.

• For an email or general cloud server catering services to a vast set of individual users, security is ensuring that one user's data is not visible, or usable by another user.
• Thinking of SoC, securing the boot process from unauthorized tampering becomes a secured boot, security paid content from unlawful access becomes something like Digital Rights Management (DRM), allowing controlled debug becomes secured debug & and so on.

Security is often at odds with usability. A perfectly secured system would be the one totally disconnected from any kind of interface (network, cable..) or going a step ahead powered off system - thus securing against any information theft - but I dont think we would find it usable. This story always plays out as two attention-grabbing kids yelling at each other.

A big part of defining security is establishing the threat model and designing appropriate mitigations.

What is the threat model?

A threat model is a way to box the problem! In simplest terms it allows us to establish the following in a given system context

• Asset - What do we wish to protect? A functionality? Encryption or signing Key? Some software sandbox-like specific applications? Perhaps hardware block?
• Attacker - Against whom do we wish to protect above identified asset?
• Adversary & Attack Profile: What attack paths are we considering to be protected out of all to justify the cost of the asset? Makes no business sense to build a security solution costing 10K USD to protect assets worth 100 USD?

Few formal methods do exist to help conclude such analysis in a quantitative & and qualitative way, commonly known as threat modeling techniques. But as it goes with most of the security, I see one key challenge with the known threat modeling techniques, each of these methods lacks objectivity in one or other aspect. Let's talk about prevalent threat modeling techniques & and some pro, and cons of each.

Threat modeling techniques

As of today, I see 3 different threat modeling techniques in play. Some more popular than others today, some were more popular yesteryears and fell out of favor now.

STRIDE

STRIDE is the most adopted and common threat model in use today. Each of these letters in its name corresponds to threats as listed below:

This list speaks to its limitations by itself. It leaves "what needs to be protected from these threats" out of the methodology for the threat modeler to decide. One of the other issues with STRIDE adoption is that it is mostly applied in software post-implementation. These two combined make STRIDE at best reactive threat modeling that highly relies on threat modelers' expertise.

When STRIDE needs to be applied to a huge system, say a few million lines of software or hardware code, it often fails to scale. It does seriously lack a method to point threat modeler to what really matters & and needs to be protected. It lacks formal methods to quantify the cost of asset breaches & and prioritize analyzing threats to those assets based on the costs.

DREAD

DREAD fell out of favor for a few reasons that we shall see below, but it was a popular technique at some point in time. It does address one of the shortcomings of STRIDE, viz. it comprehends formal constructs to quantify the cost of asset breach .. or at least get a sense of that cost if not absolute cost. For that reason, it is better phrased as a risk assessment method instead of a plain threat model method. Each letter in DREAD unfolds as below:

As each letter yells, this technique lets us define a way to quantify the cost of the asset. When applied to all assets known in a system, evaluating each of the assets in these categories allows the threat modeler to get a quantitative sense of asset costs.

It did come with its own challenges. It still does not have a formal method to define assets contained in a system and it sure does not attempt to deal attack paths or attack vectors to those assets.

Another challenge is the ability to objectively conclude some of the DREAD aspects like reproducibility or exploitability. Partly this technique fell out of favor for its shortcomings.

Attack tree

That brings us to the final threat modeling technique we wish to analyze, the Attack Trees. This method overcomes the limitations of the DREAD in that it has formal constructs to document all

• Assets contained in a closed system
• Attack paths to each of the identified assets
• Ability to associate the cost of a successful attack on each attack path

Rather than drawing a picture, I will borrow from the most often-used diagram from Schneier's text or Wikipedia

Once such an attack tree is drawn for all assets within a system, possible & and impossible attack paths are identified, the threat modeler can proceed to precisely define what assets and against whom the given solution will or should protect.

Summarizing it all

In my experience, none of these methods alone suffice to provide an adequate threat model and box the problem or say tame the beast. I ended up using all three in reverse order for the most successful threat models I ever defined. I propose we use

• Attack trees to identify all assets within the system, attack paths to those assets, and scope security solutions by combining assets and attack paths
• Use DREAD to understand the cost of each of the scope asset breaches and prepare a prioritized list of assets & and attack paths to focus on
• Use STRIDE through design and implementation to evaluate the robustness of the solution in place & and take corrective actions as needed

Anyway, that's me until we get to the next topic on our list. Til then happy threat hunting. BTW Mohit Arora thanks for the refreshing news - as you said its a gift for this day!