1.11 Understand and apply threat modeling concepts and methodologies

A Threat Model is an abstract idea of the harm that people are trying to cause us.  We can use a Threat Model to help design a better system.  The threat model might include the type of threat, its attack surfaces (how it gets into our system), the likelihood that it will take place, and how much damage it could cause. 

We should not build a system and then go back and try to figure out what threats it could face and attempt to protect against them.  Instead, we should keep the threat model in the back of our minds while designing a system.  Why?

  • This avoids rework (having to go back and correct the system later), which is expensive.

  • We might not be able to correct the system later.  For example, if we designed a network cabinet and forgot to leave room for the firewall, we might not be able to go back and install it.  If we designed an integrated system like a medical device, it might not be possible to redesign or install the protection later.

  • Threats can infiltrate the system while it is being built.  If we aren’t thinking about threats while we’re building or designing the system, we might introduce threats that can’t come out.  For example, if we’re writing source code for a smartphone’s operating system, and malware is introduced directly into the source code, this malware would be deployed to millions of devices. 

Not all threats can be predicted despite our best efforts.  It is impossible to know what we don’t know, and new threats are being introduced.  We will need to go back and patch any threats that were missed.

How do we identify threats?

  • We can think about the stuff we have (assets) and then figure out how people will try to attack them.  For example, how would people attack a server?  They might connect through a remote desktop protocol.  They might physically connect a monitor and keyboard and attempt to log in.  Or they might try to install a software update that contains a virus.

    Once we know how the device can be attacked, we can create policies and controls to prevent those attacks.

  • We can think about who is trying to attack us (attackers).  Who wants to attack us and what do they have to gain?  Attacks can come from hackers who want to show off to their friends, fraudsters, criminal organizations, political activists, rogue employees, and even the government.

    Once we know who is trying to attack us, we can think about the ways in which they will accomplish these attacks and the amount of resources that they have.  We can use this to prioritize our response.  We should spend more time and money to protect against attacks that are more likely to occur or that will cause more severe damage.

    We should not use the attacker approach by itself, because we would miss some assets.

The STRIDE model gives us a starting point for identifying threats.  It contains

  • Spoofing – gaining access to a resource through false credentials.  A hacker can fake his IP address, MAC address, username, password, e-mail address, hostname, SSID, etc..  The resource sees the spoofed credentials and assumes that the hacker is a legitimate user.

  • Tampering – making an unauthorized change to data.  The data might be in transit or at rest.  A hacker might tamper with data in order to obtain unauthorized access to a resource or to cause damage.

  • Repudiation – a hacker denies that they performed an action.  A hacker might structure his attack in such a way that it is impossible to prove that he was behind it.

  • Information Disclosure – leaking confidential information.  This may take place on purpose or by accident.

  • Denial of Service (DoS) – attacking a resource so that legitimate users are unable to access it.  A DoS attack might be permanent or temporary.

  • Elevation of Privilege – a user attempts to gain access to resources that he is not entitled to.  The user may be a legitimate user attempting to gain access to resources or a hacker who has obtained the user’s credentials.

The PASTA (Process for Attack Simulation and Threat Analysis) model allows us to define threats

  • Stage I: Definition of the Objectives for the Analysis of Risks

  • Stage II: Definition of the Technical Scope

  • Stage III: Application Decomposition and Analysis

  • Stage IV: Threat Analysis

  • Stage V: Weakness and Vulnerability Analysis

  • Stage VI: Attack Modeling & Simulation

  • Stage VII: Risk Analysis & Management

There are other techniques for modeling risk including

  • Trike

  • DREAD – Damage, Reproducibility, Exploitability, Affected Users, and Discoverability

    • Damage – how much damage will the threat cause?

    • Reproducibility – how difficult is it for a hacker to copy the exploit causing the threat?

    • Exploitability – how difficult is it for a hacker to implement the threat?

    • Affected Users – how many users will be affected by the attack?

    • Discoverability – how difficult is it for a hacker to discover that the system has a vulnerability that can be exploited?

  • VASTVisual, Agile, and Simple Threat

  • NIST 800-154 Guide to the Data-Centric System Threat Modeling

    • Identify systems that could be attacked

    • Identify methods of attack for each system

    • Choose security controls for each attack

    • Analyse the threat model

We asked the question: what are the threats facing our business?  We can draw them out to see how a hacker could carry out one of those threats.  We should make a diagram of our infrastructure, showing how data flows.  We can then determine where in the diagram a threat could attack.  We can also understand how data moves through the organization.  The diagram is not necessarily a network diagram.  It could also document business processes.

For example, we can document the accounts payable function

  • A vendor submits an invoice

  • A clerk receives and reviews the invoice

  • The clerk verifies that the invoice matches a valid and completed purchase order

  • The clerk pays the invoice

At each stage, false information could be introduced.  A hacker could submit a false invoice or could send an invoice with a virus.  A malicious account manager could issue a purchase order for goods that are not delivered.  A clerk could pay an invoice for a purchase order that wasn’t completed or for an invoice that does not have a corresponding purchase order.

We should document every portion of the diagram with the type of physical equipment involved, including its firmware version.

Once we’ve identified all the potential threats and their entry points, we must perform reduction analysis.  We want to understand the logic behind each element in the diagram.  We look at the following areas

  • Trust Boundary – a location on the diagram where the security level changes.  For example, the boundary between the public internet and the private network is a trust boundary.

  • Data Flow Paths – how data moves throughout the network.

  • Input Points – where data enters the network.

  • Privileged Operations – activities that require an administrator to perform.

  • Security Stance – what the security policy describes.

We must ask three questions:

  • How will the threat take place? 

  • What system or technology will the threat attack? 

  • What are the consequences?  How much damage will the attack cause?

We can use this information to rank the threats based on

  • How much damage the threat will cause.

  • How likely the threat is to take place.

We might multiply each threat’s probability by its potential damage to obtain a risk severity score.  The higher the severity, the more we should spend to prevent it.  We might rank the threats on a scale of 1 to 100 or on a High/Medium/Low scale.

Our organization may have a limited budget.  A threat may have a very low probability of taking place and/or a low amount of damage, but the cost of protecting against it is very high.  The organization must weigh the cost of the threat protection against the cost of the damage.