“Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win” - Sun Tzu

Welcome back to my series where I am breaking down application security so that anyone can do it without hiring expensive teams of employees. Today we’re finally going to get in to the mindset of the attacker that we talked a bit about before through a process called threat modeling!

This is what it looks like when most security engineers are asked to threat model:

Lucky for you, you’re going to know exactly what to do after reading this.

Know Your Enemy

We’re continuing from this here.

What does that consist of? We’ll explore this through a scenario.

Preparation Is Key (heist example)

Much like the quote I have in my blog’s subtitle, preparation is always key. Attackers don’t blindly attack things when they’re dedicated. They always have a plan.

Let’s imagine that you’re one of the team members of a group planning a heist (think any old heist movie/show like Oceans series, Money Heist, 6 underground, Baby Driver, etc.). What you’ll understand through this process (or the movies) is that a heist consists of a few factors:

1. Target (Asset): heists always consist of a target. If the goal of a heist is to obtain some valuable worth money, the definition of the target would be:

   1. which currency (USD, JPY, Euro, etc.) or resource (gold or jewelry? blueprints for something? data on server(s)? etc.),

   2. how much of it (millions/billions in currency, how many rooms of treasures, how many servers)

   3. the value of the asset in the heist team’s hands (once the team takes the asset, how much is it worth if they liquidate, how much to receive as ransom, or reversely, how much cost would it be to the institution where the asset is held)

2. Blueprint (architecture): the leader of heists usually pull out a large sheet, rolls it out on the table, the sheet shows schematics of the internal entry/exit points of the building along with routes internally, points to different parts of the schematic and starts placing figurines to indicate different team member roles. They’ll know everything that is to know about the place they are about rob. If you observe a bunch of these heist movies, some explain that the blueprints were created by careful observation over time on the workflows/processes of the business, or obtained the schematics through an insider or 3rd party who built the building(s), or even working at the building itself.

3. Flaws (vulnerabilities): through careful observation and analysis, the leaders usually point to certain parts of the operations of the building or flaws in the architecture that allow the heist to happen. All of the vulnerabilities put together, can form various ways to enter and exit certain parts of the building and each of them can be used as backups for each other. We’ll show later how we can use individual vulnerabilities to “chain” them together. Consider some of these examples:

   1. the guards rotate for a “lunch rotation” at midnight, allowing a 30 second window where there’s a gap in visibility for the team to infiltrate the gate

   2. employee badges can be cloned, so the leader had the team clone a badge of maintenance staff weeks prior

   3. there’s an unknown underground entrance to the building from the building next door that is abandoned

With the above parts of a heist, we’ve now understood how most successful heists or hacks are successful. It’s not because these people are geniuses, nor is it because of terrible security, it’s because attackers spend hours, days, months, and even years dedicated understanding exactly all the things about your application, poking and prodding all the things that can go wrong, and using all this information to get what they want.

Threat Modeling

I first learned to threat model in my Master’s program at NYU Tandon. In my first class under Professor Justin Cappos, I learned the different frameworks that security engineers use to model threats. I will talk about them briefly below, then I will discuss how I think about it.

Frameworks

If you look up threat modeling on Google, you’ll find that there are a variety of frameworks of understanding to do threat modeling. Some of them include:

• PASTA

• STRIDE

• DREAD

You can read about an overview from the U.S. govt here. You can also find some more acronyms/frameworks and a comprehensive understanding from OWASP (Open Web Application Security Project) here.

Frameworks are heavily abstracted tools to understand and start doing things (think about all the frontend frameworks). This applies here to threat modeling. Abstraction is good, but there’s always a tradeoff with abstractions: quick understanding vs loss of details. The easier it is to understand, the less understanding you truly have in what it takes to produce a really good threat model for the application at hand.

It seems like a new threat modeling tool, framework or ways to do/think about threat modeling is being put out every week. If we truly solved threat modeling, there wouldn’t be so much variety. The reason we can’t solve it is because we don’t truly understand what it means to model threats to a system. You really can’t model how things will go wrong with something you’ve built without first understanding what you’ve built.

Do it better

You’re going to learn to do it better!.. but how?
It’s much easier than you think, ONLY if you’ve been paying attention to what we’ve learned so far:

• Have you understood your application?

• Have you understood what routes don’t have authentication when they need it or not?

• Have you understood what parts of your application have routes don’t have proper authorization when needed?

• Have you tracked how untrusted input (sources) flows into different areas of your program (sinks) potentially unsafely?

• Have you mapped out where in your application that your business logic could go wrong?

You have all this data above from all the stuff you’ve done and learned about all the things that could go wrong. We can start synthesizing all of this information and start mapping out what we just learned above about heists!

1. Write down all the things that are valuable to you/your application. Is it the server that the application is sitting on? The memory holding the environment variables? The user data in your database? Other services that your application uses (your cloud environment? your email infrastructure? texting platform?…etc?)… anything that is pertinent to what makes your application a gateway to the things you hold value in that you wouldn’t want any semblance of control by the attacker

2. Next write down all parts of your application and starting connecting them and drawing out a “schematic/blueprint” of what the application looks like and how it flows. This gives you a higher level understanding that others can also view and help elucidate potential weak areas.

3. Next write down all the different vulnerabilities that you found from your analyses. Tie them to your “schematic/blueprint”. This now provides an understanding of how things could go wrong.

Voila you have all the necessary understanding, pieces of the puzzle, to see how attacks can happen. You’ve successfully mapped out how things can truly go wrong and what targets are vulnerable and what threats there are to your application!

Guess who is now an expert at threat modelling?

You’re an expert at threat modelling! See I told you it’s not that hard or convoluted!

Next time we’ll talk about ensuring your threat model is actually right because after all, it’s just a model of what could go wrong:)

Pigeon is a NYC Cybersecurity Services company, specializing in Application Security. If you or anyone you know needs application security services, please reach out to me at david@pigeonlabs.ai. We’re willing to work with you near and far!