K.I.S.S. on a Threat Model, Like it is Hot P.1

Photo by Javier Miranda on Unsplash

Per Wikipedia, the core definition of threat modeling is “Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized.”

If we want to get practical and decode this into something that everyone could understand, it's answering four simple questions:

What are we planning to do?

• Do we have a new Auth mechanism we want to implement in the next sprint?
• Do we have a new feature that we will release to the customer soon?
• Do we plan a new microservice?
• Do we discover that some of the components we use are compromised?
• Do we plan to buy a new car?

What could go wrong?

• The attacker can exploit our new Auth mechanism because we didn't protect all the ports.
• A botnet can bring our new service down by executing a DDoS attack
• We ship our new component with a default admin password.
• The car comes with a remote control that anyone can easily hijack.

What are we doing to do about it?

• Protect our apps by reducing the attack surface and removing the ports or end-points we don't use.
• Leverage a CDN to limit the impact of a DDoS attack.
• Disable default accounts and do not send passwords via e-mail.
• Buy a protective case for your new car keys.

Did we do a good job?

• Measure the success of the mitigation.
• Has this attack happened and what was the outcome?
• How many DDoS attacks were we able to mitigate?
• How many complaints about customer data leaks have we had?
• Is your car still in your garage?

Cognitive Model

If you look out of the window and stop reading this text to analyze what you just learned, you will realize that all of these sounds logical. This is how we humans are wired to self-defend, and we have the habit of following this model in almost every situation.

Do you need an example? All right, here I go:

What are we planning to do?

You decided to go on a vacation and realized that you need someone to take care of your plants while away because you love those little green souls so much. ( And you should, but that's another topic).

What could go wrong?

You might want to give your keys to your neighbor and task her with the mission, but she just rented the place next to you, and you don't know if you can trust her. Maybe she can rob your apartment or throw a party. The probability is low, you think, but it still is there.

What are we doing to do about it?

Maybe move your plant to the garage and give her the keys to the garage. Limit the access and still achieve your goal.

Did we do a good job?

After you go back from your vacay, you see your plants alive, your home in order, and your neighbor happy to help you. I call this success.

Of course, she copied the key so that she can enter the garage at any time, but you still don't know about it :)

It’s a process

Every cognitive pattern is a process.

Now let's go and look step by step how you can build a very efficient thread model.

As a beginning, I will start with the steps helping you answer the first question - What are we planning to do?

Step 1: Gather your team together

To have a helpful session, you need your whole team. Most of the time, the modeling is done by one or two persons because they know most of the system or the company believes that this exercise is not valuable. By inviting your whole (agile) team, you include many experiences, different points of view, and diverse opinions.

Step 2: Identify objects (components) in the system under assessment by writing a low fidelity diagram at first

The most knowledgeable person in the room (onsite or virtual) draws a low-fidelity diagram of all the components you need to model against and explains what they represent. Here is the time to talk about different trust boundaries you might have.

Practical Tip: K.I.S.S.: Keep it simple, stupid. Do not draw a highly complex system with tens of components and boundaries. Start with the part of your system if needed or a simplified view. Then repeat later if you want to go deeper.

If you go with the whole complexity of your solution, you might lose some of the attendees or, the following steps will produce hundreds of threats that will not flow well through the system, and your session will become less efficient.

Step 3: Recognize the flows between those objects

After you have the components draw lines between them to show how the data flows to help your team realize what they need to do later to protect the data in motion.

Practical tip: While drawing that, please explain the process and why this is happening while drawing. For example: When the user visits the application website, they can see the login page served by the Apache server. Then the credentials are sent to the application server via an HTTPS connection and checked for validity against the customer DB.

You need to explain the system well, so the team would understand it before moving to the next part.

Now let's move to the most exciting part.

Now we answered the first of the four questions, "What are we planning to do?" and now it's time to brainstorm on What could go wrong?

Step 4: Identify the attacker personas

Given your product value and architecture, who is your attacker? The usual suspects are:

• A competitor - maybe a company that runs in the same market segment would like to bring our services down or steal our customer data.

• A Bot - automated attack service without human interaction. Your internal employee - willingly (bad morale) or unwillingly (social engineering or phishing) could harm your product.

• A random internet user - an unknown source with no apparent motivation.

• Another exploited service - a service/module you use with a new vulnerability.

  You know your system, be creative here, and identify the attack actors. Look at similar Threat Models and see what attackers exist there that you could reuse. The more time you spend here, the more impact you will have later. Remember, this is a model. There are no wrong ideas here. Your cat can be an attacker if you leave your computer unlocked. (read an article entitled How to Fix Common Tech / Computer Issues Caused By Cats)

If you want to extend the knowledge, you can build the personas, adding their motivation and likely attacking you to have the complete profile.

As this is optional, please remember the more time you spend modeling, the less time you will have to remediate security issues later. This rule applies to every step in this section.

Step 5: Create an Inventory of Assets in Interest.

Look at the diagram you created in the previous step and the attacker personas to analyze the assets you need to protect.

Again let's start with the usual suspects:

• Your DB - The data you store is the primary interest of almost any attack.
• Keys - the keys to encrypt your information or to authenticate users.
• API Ports/resources - an available port is always a good entry point of an attack.

You could apply to same rule here - look at the low-fi diagram you created as part of the threat modeling session and ask yourself - If I am an attacker, what would I want to steal/do?

Step 6 - Create a register of threats.

Use one of those methods or a combination of a few to build a register of threats for your product.

Method one: Brainstorm

Spend 15 min individually to look at the low-fi diagram, the assets you identified, and the possible attackers and write down all the things you believe could go wrong: How any of the attackers can harm any of the assets.

Then, each one of the team would place a sticky note next to the Asset or the Component where this attack is most likely to happen.

Please make sure:

• Each member of your team has the right to talk and add their attacks on the board.
• Anything is possible; there is no lousy attack scenario at this moment.
• If there are similar attacks - combine them in affinity groups to look at them in detail later.

Method two: Use similar Threat Models.

If your product is built on K8s or uses a known scenario as Oauth 2.0, probably there is a publicly available thread model for it.

• Download and verify the source of it
• Use it to see what of the threats are applicable against your infrastructure.
• Identify gaps and add them to your register of threats.

You could also look at your company register of threats (if any) and/or similar services like yours already with a threat model for inspiration and ready-to-use work.

Please remember these models are outdated, and you need to use them as a start and not rely on them entirely.

Method three: Use STRIDE

STRIDE is a good framework for doing Threat modeling for web applications. It was created by Microsoft and contained a register of threats divided into six categories.

• Spoofed Identity - How hard is it for an attacker to pretend to be someone with authority to use the system? An example of identity spoofing is an attacker breaking a poor user password and gaining access to the system. Spoofed identity in the offline world could happen if you have a note with your pin stuck on the back of your Credit card.

• Tampering with input - How hard is it for an attacker to modify the data they submit to your system? An example is when an attacker submits a SQL injection attack via a web application and uses that action to view everything in the database. Or, in the offline world, imagine someone saying your name in the post office, and they give them all of your precious packages without checking for proof.

• Repudiation Attack - How hard is it for users to deny performing an action? An example is where a user has deleted some sensitive information, and the system cannot trace the malicious operations.

• Information Disclosure - Can someone view the information they are not supposed to have access to? An example is when a user can read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers.

• Denial of Service - Can someone break a system so valid users are unable to use it? An example is where a Web server has been made temporarily unavailable or unusable with a flood of traffic generated by a botnet. A DDoS attack is like an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving at its destination in the offline world.

• Elevation of Privilege - Can an unprivileged user gain more access to the system than they should have? An example is where the attacker could use unprotected service using a service account to access the protected data. In the offline world, this could be a thief breaking through the window to enter your house, otherwise protected with a very secure door.

Each of those categories contains applicable attacks against your system, which you could use to get started.

The way it works is you start from the top category and read the first threat, and then if you see that it can be executed against one of your components, you add it on the board and then move to the next one.

At the end of this exercise, you have a good register of threats to start with.

Use the force, Luke

Remember that you still need to put your brain to work and think about other threats not included in the framework, and the more time you spend modeling, the less time you will have to remediate security issues later.

Since we already know What we are going to work on and What could go wrong, In the next part of this article, I will focus on the following two questions and give you some good practical advice on doing a great and valuable Threat Model.

Smile more and think about security all the time!

Partially published here.