I was watching the TV series, La Casa De Papel (Money Heist), on Netflix a few weeks ago. I realized that the story of the gang can reveal some best practices we should use while dealing with the security of the products we build.

Beware – this text contains spoilers. If you haven't watched the show until the end and you are planning to, please visit the article on a later day. Or proceed at your own risk :)

Threat modeling can protect you against unexpected events

First of all, what is threat modeling?

Threat modeling, in layperson's terms, is an analytical process. In it, the engineers who build a product coordinate with the security team. They collaborate towards the security architecture of the product.

More specifically, it's the model – how someone can attack the product – and what is worth protecting (assets). They also model what they can be less concerned about. Less concerned not because they don't care. But because protecting it can be more costly than the asset itself.

Threat modeling can get you a long way and protect you from certain events, against the odds.

What is threat modeling in our "Money Heist" case? It is Professor's (aka Sergio Marquina's) plan against all potential routes the plan will take. In having alternatives, even for the edgiest scenarios. The assets are clearly the stolen money or his comrades in the heist.

A single point of failure can cause a chain of bad reactions

Threat modeling might help you recover from many security problems that will arise. You can recover from a cyber-attack, but things will never be the same. A crack in the security wall can have a domino effect.

Imagine a lake dam, with a few cracks around it going unnoticed and being exploited by nature. You can always fix it, but it might take time for the lake visitors to establish trust again.

In the same way, small companies that experience a security issue might close in the next few months, according to a survey.

This is like the Professor, where he lost respect after the gold (temporarily) vanished. Even though his great problem-solving skills helped resolve the issue, things got hairy very fast.

Luck is not a strategy in the long term

In the show, there are some provocative cases of luck. For example:

• Raquel renegading the police organization
• Police and army failing plans to invade the bank
• Failing to shoot to the target many times. Especially by troops that are supposed to be professional shooters.

After all, in the pragmatic programmer book, there is a whole chapter about how bad it is to program by coincidence. It likens luck-as-strategy with the soldier that moves without a plan in a field full of landmines.

Snitches and worse-than-expected defense might give you some extra time to move with your plan or escape. But you have to take advantage of it. To either move with your plan or escape. Always think your luck might go away, any time soon.

Never drop the weapons

This is not specific to cybersecurity but to life in general.

Pain is temporary, quitting lasts forever. Accept your mistakes, remediate them and learn from them. As long as your heart is pumping blood, you are not dead yet.

• Architectural mistake? Patch it immediately and re-architect the product (yeah, I know...delivery and business constraints)
• Below expectations monitoring? Fix it now. Add more people and see how they can be more effective
• Serious defects in the code? Train your team in secure practices and code reviews focused on security. Buy a license to a package like Snyk or Nessus. Plan some percentage of your capacity to patch the most severe ones

Even in the worst of moments, keep your composure

Imagine a ransomware attack. It is there, it is happening. Screaming over people's heads will not solve the problem.

When you cannot win against an attack, you still have to do your best, to at least not lose. For sure, don't panic. As the Stoics say, you have to be your best self on the things you control. And let the rest just be. Accept them.

You cannot control the next stage of an attack. But you can do your best to prevent it, to not repeat the same mistakes, and to close the open doors that exist now.

That is true for non tech issues too. If a pipe broke at home what would you do? First, you stop the damage and maybe provide a sustainable fix (given the timeframe). Then you try to see how this will never happen again.

Don't lose your temper and clear mind, like Tamayo lost it, when he realized the gang was blackmailing him for various reasons.

He got angry, he got blackmailed, he was even ridiculed in the eyes of the European Central Bank. And what was the result? He lost, hands down, even though he lied to the media about winning.

Conclusion

Top-notch cybersecurity is not a free lunch. And not everyone can do it, as the caveats are so many. But with some discipline, retrospection, and humility, you can do wonders. Also, the show is great, if you haven't seen it, please do.

It’s far more fun to draw the tire swing, front porch, and swimming pool than to worry about how a ten-thousand-gallon bucket of water stays suspended in midair.

With too much attention spent on fun and flashy features, foundations suffer.

A comic I drew about building stable foundations. It's not that funny.

Of course, spending undue hours building a back end like Fort Knox may not be necessary for your application, either. Being an advocate for security doesn’t mean always wearing your tinfoil hat (although you do look dashing in it) but does mean building in an appropriate amount of security.

How much security is appropriate? The answer, frustratingly, is, “it depends.” The right amount of security for your application depends on who’s using it, what it does, and most importantly, what undesirable things it could be made to do.

It takes some analysis to make decisions about the kinds of risks your application faces and how you’ll prepare to handle them. Okay, now’s a good time to don your tinfoil hat. Let’s imagine the worst.

Threat modeling: what’s the worst that could happen?

A threat model is a stuffy term for the result of trying to imagine the worst things that could happen to an application. Using your imagination to assess risks (fittingly called risk assessment) is a conveniently non-destructive method for finding ways an application can be attacked.

You won’t need any tools – just an understanding of how the application might work, and a little imagination. You’ll want to record your results with pen and paper. For the younger folks, that means the notes app on your phone.

A few different methodologies for application risk assessment can be found in the software world, including the in-depth NIST Special Publication 800-30. Each method’s framework has specific steps and output, and will go into various levels of detail when it comes to defining threats.

If following a framework, first choose the one you’re most likely to complete. You can always add more depth and detail from there.

Even informal risk assessments are beneficial. Typically taking the form of a set of questions, they may be oriented around possible threats, the impact to assets, or ways a vulnerability could be exploited.

Here are some examples of questions addressing each orientation:

• What kind of adversary would want to break my app? What would they be after?
• If the control of x fell into the wrong hands, what could an attacker do with it?
• Where could x vulnerability occur in my app?

A basic threat model explains the technical, business, and human considerations for each risk. It will typically detail:

• The vulnerabilities or components that can cause the risk
• The impact that a successful execution of the risk would have on the application
• The consequences for the application’s users or organization

The result of a risk assessment exercise is your threat model. In other words, it's a list of things you would very much like not to occur.

It is usually sorted in a hierarchy of risks, from the worst to the mildest. The worst risks have the most negative impact, and are most important to protect against. The mildest risks are the most acceptable — while still an undesirable outcome, they have the least negative impact on the application and users.

You can use this resulting hierarchy as a guide to determine how much of your cybersecurity efforts to apply to each risk area. An appropriate amount of security for your application will eliminate (where possible) or mitigate the worst risks.

Pushing left

Although it sounds like a dance move meme, pushing left refers instead to building in as much of your planned security as possible in the early stages of software development.

Building software is a lot like building a treehouse, just without the pleasant fresh air. You start with the basic supporting components, such as attaching a platform to a tree. Then comes the framing, walls, and roof, and finally, your rustic-modern Instagram-worthy wall hangings and deer bust.

The further along in the build process you are, the harder and more costly it becomes to make changes to a component that you’ve already installed.

If you discover a problem with the walls only after the roof is put in place, you may need to change or remove the roof in order to fix it. Similar parallels can be drawn for software components, only without similar ease in detangling the attached parts.

In the case of a treehouse, it’s rather impossible to start with decorations or even a roof, since you can’t really suspend them in midair.

In the case of software development, it is, unfortunately, possible to build many top-layer components and abstractions without a sufficient supporting architecture.

A push-left approach views each additional layer as adding cost and complication. Pushing left means attempting to mitigate security risks as much as possible at each development stage before proceeding to the next.

Building bottom-to-top

By considering your threat model in the early stages of developing your application, you reduce the chances of necessitating a costly remodel later on. You can make choices about architecture, components, and code that support the main security goals of your particular application.

While it’s not possible to foresee all the functionality your application may one day need to support, it is possible to prepare a solid foundation that allows additional functionality to be added more securely. Building in appropriate security from the bottom to the top will help make mitigating security risks much easier in the future.

Digital attacks are more and more frequent, and the first step in securing your app is understanding the threats and how to counter them.

Threat modeling is an approach that analyses the security of an application. It is a structured way to identify, quantify and mitigate the security risks in an application.

You are about to read a short briefing I wrote for myself some time ago, made up from information I’ve collected by dissecting several other articles. The idea behind this article is for it to act as a reminder and to be as short as possible but still hold relevant information.

So with that being said, let’s write the most common definition of threat modeling:

Threat modeling is a security process with goals to identify objectives and vulnerabilities and then define countermeasures to prevent or lessen the effects of threats to the system.

I’ve also read that threat modeling gives answers to these four questions:

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good job?

And I couldn’t agree more. That’s why threat modeling is composed of four parts, where each part answers one question:

• Decomposing the application.
• Determining the threats.
• Determine counter measures and mitigations (reducing the danger).
• Rank threats.

Decomposing the application

The goal of this step is to understand the application by decomposing it into parts and seeing how those parts interact with external entities. The way to do this is to gather information and documentation by mapping the application’s entry points, elements/assets and dependencies.

• Decompose the application by drawing a diagram of various components in the application. You can do this with Data Flow Diagrams.
• Identifying entry points — Software entry points may serve as entry points of an attacker( login pages, search fields, HTTP requests etc.). It is essential that all entry points are identified and documented.
• Identifying the elements/assets — that have a value, and therefore a risk of being attacked. An asset can be in a form of data like a list of customer information, it can also be in different forms: overall application availability, organizations reputation.
• Dependencies are parts of the app that lay outside of the application’s code. As these items are outside of your control they may pose a threat if they are not properly maintained so identifying these dependencies will minimize the application’s overall risk.

Determining threats

Determining threats can be done by threat categorization STRIDE. STRIDE is an approach from the attackers perspective, and it is used to determine threats. While there are other approaches such as ASF (Application security framework — an approach from the defenders perspective to determine countermeasures), in this article I will be focusing on STRIDE.

STRIDE categorization outlines six most common types of threats and their countermeasures.

STRIDE

1. Spoofing identity — Impersonating someone or something else.
2. Tempering with data — Modifying some data on disk, network, memory.
3. Reputation — Denial of proof of some action.
4. Information disclosure — Exposing information to someone not authorized to see it.
5. Denial of service — Deny or degrade service to users.
6. Elevation of privileges — Unauthorized gaining of more rights than originally intended.

Determining countermeasures

Every threat from STRIDE has a countermeasure.

1. Authentication (for Spoofing) — Establishing a verifiable identity.
2. Data protection (for Tempering with data) — Maintaining data and ensuring consistency of data and methods that work on data.
3. Confirmation (for Reputation) — Every action against the application must be logged.
4. Confidentiality ( for Information disclosure) — Restricting access to system and data.
5. Availability(for Dos) — Leverage levels of redundancies.
6. Authorization (for Elevation of privileges) — Limiting access to data, actions and services.

Rank Threats

To tackle the problem of ranking threats Microsoft devised a risk assessment model called DREAD, a model which provides five rating categories for each threat. In the beginning they used the rating from 1 to 10, ex. for every threat in each category a rating from 1 do 10 would be given.

However, as different people selected very different numbers, there was a shift away from DREAD ratings within high number ranges towards some simpler classification with 4 different levels of risk:

• 1: low
• 2: medium
• 3: high
• 4: critical

Sum of all ratings for a given threat is used to prioritize it among other threats.

The categories to rank for every threat are:

• Damage — how bad would an attack be?
• Reproducibility — how easy is it to reproduce the attack?
• Exploitability — how much work is it to launch the attack?
• Affected users — how many people will be impacted?
• Discoverability — how easy is it to discover the threat?

For every threat in each category a rating from 1 do 4 is given and the sum of all ratings for a given threat is used to prioritize it among other threats.

Up until now we decomposed the application, analysed functionalities, determined possible risks and identified weak points that could be exploited. Then we determined the countermeasures and used DREAD to rank the risks. The only thing left is to act accordingly in solving those risks.

Thank you for reading! Check out more articles like this on my freeCodeCamp profile: https://www.freecodecamp.org/news/author/goran/ and other fun stuff I build on my GitHub page: https://github.com/GoranAviani