Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Threat Modeling for Mere Mortals

DZone's Guide to

Threat Modeling for Mere Mortals

Do you need a quick intro to threat modeling? We've got you covered.

· Security Zone
Free Resource

Discover an in-depth knowledge about the different kinds of iOS hacking tools and techniques with the free iOS Hacking Guide from Security Innovation.

In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.

A More Formal Definition

For somebody with a security mindset, the previous definition might be not very formalized, so let's try a new definition. But beforehand, let's look at some other definitions:

  • asset  - an asset is what must be protected. In the context of software, it could be the infrastructure, the software installed, the user data, etc.
  • vulnerability - a vulnerability is a weakness that can be present in one of the assets.
  • threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
  • risk – the potential for loss, damage, or destruction of an asset as a result of a threat exploiting a vulnerability.

So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated into the SDLC (Software Development Life Cycle) with the goal of finding and addressing (mitigate, eliminate, transfer, or accept) all possible risks for a specific software functionality.

The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earlier the problems are found, the easier it will be to fix) and could even modify or adjust the requirements.

The Threat Modeling Process

The threat modeling process has 3 phases:

  1. Model the system for which you want to find the threats.
  2. Find the threats.
  3. Address each threat found in the previous step.

Let's go in depth for each one.

1. Model the System

The goal is to have a diagram representing the system under process. In specialized literature, the Data Flow Diagrams are very often used because it easily represents all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding "trust boundaries" — boundaries where data changes its level of "trust".

2. Find the Threats

After having a diagram of the system then you can ask how an attacker could attack the system. There are different approaches that can be used to find out "what can go wrong":

  • STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
  • Threat/Attack libraries - libraries containing common and already known attacks. A Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries include OWASP Top Ten, CAPEC, and CWE.
  • Misuse cases - These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed or areas where there are none.

3. Addressing the Threats

Once identified, each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available, the business case, and the system requirements.

This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation (if you decide to mitigate it).

Not all threats can be mitigated; it is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transferred (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).

Further Learning

If you want to go further and dig deeper hare are some links that I found useful:

Leveraging Humans to Get the Most Out of Tools

Topics:
security ,risk analysis ,threat modeling

Published at DZone with permission of Adrian CITU, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}