CyberSec Tales

The adventure

Let’s say you have to develop an innovative feature or perhaps a completely new application. You have a budget, a team of highly salaried developers, and very tight timelines. You plan your sprints and go to the different phases of your project being sure everything is fine. You finish very close to the date, maybe a bit later after all those problems that come with software development, if you know what I am talking about. Then you ask yourself, what can go wrong?

What if?

The last thing you want to find is that your application or business case is introducing risks or vulnerabilities. Yes, those evil mysterious ethereal entities that can make your system not applicable, can reduce their value, you know, making it “not enterprise level”, or can make it difficult/expensive to fix in a moment when almost for sure you won’t have enough budget. So how can you, in a timely manner, prevent yourself and your organization from being in this situation? Welcome to threat modeling :).

Threat Modeling and the purpose of this article

Let me summarize what threat modeling is by saying it is about identifying early, commonly during design, what can go wrong in the system, and being sure you know what to do to get a happy ending. I am not talking about that happy ending that comes after the suffering of remediating risks after the solution was supposed to be finished, I am talking about the happy happy ending you get when you identify your risks and security requirements early in your project, thanks to a threat model :).

Threat modeling is a big thing, you will hear about it at conferences, see it listed as a requirement in job descriptions, there’s even a threat modeling manifesto (https://www.threatmodelingmanifesto.org). If you want to learn how to threat model or want to improve your skills I have good news, today there’s plenty of material on the topic. Yes, today, because years ago it was not the case, in those years we all read the same book and reached our conclusions. 

Our good old friend OWASP has good resources for threat modeling (https://owasp.org/www-community/Threat_Modeling), there are also books, videos, and all what you can imagine, so it is not my intention to teach you to threat model in this article, what I am going to do is share practical lessons I have learned during years of practice that I haven’t seen documented in other places. 

If you want ideas on how to learn to threat model, see the section “You will learn to threat model if you want and have the time” in this article.

Define an approach that will work for your organization

Threat modeling is not a one size fits all. Organizations come in all flavors and sizes, some are agile, others may be bureaucratic, some prioritize security, others don’t. You may want to run a PoC to understand how to make this practice work better in your organization. Consider the following:

• If threat modeling is a new practice in your organization you will want management support, so go talk with them. If it’s a new practice in a dev area, talk to the manager of that area; yes, even if your CISO already approved the initiative.
• Be sure to explain how threat modeling will benefit the organization.
• How are new initiatives communicated in your organization, and how are they communicated to your target audience? 
• What pushback or concerns is the organization expressing? Be ready to answer objections, preferably with metrics and facts. A PoC will help on this. Resolving honest and valid concerns will help you make your threat modeling program more successful 🙂.
• Who is going to support the initiative? 
• What detractors may the initiative find and for what reasons? 

Today is not as hard to justify and explain a threat modeling program as it was some years ago, but it is better to be ready :).

Make Threat Modeling a team effort

This is where the meat is. Meet with the Dev team in charge of whatever you are threat modeling and run the exercise with them. What to do in this meeting? the following steps have given me good results:

1. Get a brief description of what is being threat-modeled.
2. Draw a diagram. See more in the Diagrams section of this document.
3. Identify what can go wrong. Make questions to invite people to collaborate.
   1. What can go wrong?
   2. How can the system be abused?
   3. What is going to happen if “this” and “that”. Here you will want to be secretly ready with a list of threats and security issues you identified before the meeting. Yes, this means you already threat modeled the system to some extend. This list will be your homework and I can tell it will pay dividends. Make questions to help the participants identify the issues from your secret list by themselves. This will help you to coach them and will help them to learn 🙂.
4. How can the issues be prevented? The answer will give you a list of security controls required by the solution. Just as in the previous point, come secretly ready with your own list of controls.

After the meeting:

5. Document how the security controls prevent the threats from capitalizing. Document at least the riskier threats.
6. Share the results with the team.
7. Add the results to the Threat Models repository.

As mentioned in another section, the team will learn from these exercises will eventually be capable to threat model by themselves. Then your participation will be just review and approve, so your life can continue beyond this practice :).

Your Engineers will learn

Be sure to communicate this as a benefit :).

In my experience, engineers learn very quickly to treat model… at least the Sr Engineers who get interested in the topic 😐. 

In the initial sessions with a team almost for sure you are gonna need to do everything, create diagrams, bring questions, and maybe even push to get answers. But after every session, the engineering team will become more familiar and will understand better what this is about. 

In my experience, after 3 sessions an engineering team will be capable of doing it all by themselves and go to you only to review their findings and conclusions. At some point, your participation might be translated into a review and an email approval, so the process will happen faster. But to get there you will need to follow a very well-structured approach, Don’t make it about your feelings or instincts, Ok? Keep reading.

Follow a structured approach

Do you want your engineering teams to learn to threat model so you don’t need to spend the rest of your life doing it? Then, follow a structured approach that makes sense and works for them. 

A structured approach will make it easy to improve and adapt the thread modeling practice as well. Don’t make it about your feelings or instincts, even if it works for you, this will confuse everybody else. Yes, believe it or not, some people feel like a special instinct is required, but it doesn’t need to be this way. You will need to think as an attacker, though.

Think as an Attacker

Nothing new here. Remember you want to know what can go wrong, and what better way of achieving this that thinking about how the system can be attacked and screwed up? And you know what, the people who are working on the system can have tremendous ideas on this. And I know you also can. Free your mind and be destructive!

If you are not a member of the Development team, chances are you are not familiar with the system/project/requirements yet. How can you get up to speed? This is where diagrams come handy.

Diagrams

Yes, diagrams. Some people may believe they are useful only to pass a class in college, but they are very useful to threat model as well. Don’t worry, you don’t need to become an expert on UML or anything like that, but I have found the following valuable to threat model:

• Architecture diagram in the context of the network. One that makes sense. Not that super high level diagram but the one that shows you the components of the system and how they interact, who calls who, in the context of the network.
  • What does this mean? You want to see where in the network are the different components located and how they interact with each other.
  • Why is this valuable? It will show you very clearly the components and important trust boundaries in your system 🙂.
• Dataflow Diagram. I suggest you use the same architecture diagram in the context of the network from the previous point, but this time showing where the data is stored, its classification, and from where to where is that it flows. So don’t worry, is the same diagram from the previous point but showing different arrows and information on top of it.
• Interaction between the user and the system, and the system components. This is not a diagram but helps to understand complex systems. Consists of a narrative of the steps describing the interaction of the user and the system components. Don’t worry, you can use the diagram of the first bullet for this. 

Keep a repository

Keep a repository so the threat models are searchable. Will be great if you use a solution where the threats can be mapped to the security controls defined by your standard, or by NIST, ISO, or some other standard. In other words, will be great if you can integrate your threat models with your GRC system, if you have one. If you dont have one, done let this stop you, you can still implement a great threat modeling program.

You will learn to threat model if you want and have the time

You will find recommendations in this article and will find techniques to threat model in all those materials available on OWASP and other places. There are:

• Techniques like STRIDE and attack threes.
• Lists of application and system security requirements that can be used as reference, together with vendor security benchmarks and CIS benchmarks.
• Resources to feed your hacker mindset like the MITRE Attack framework (https://attack.mitre.org/) and the MITRE Atlas for AI (https://atlas.mitre.org/).
• Again, the threat modeling manifesto (https://www.threatmodelingmanifesto.org).
• Again, OWASP (https://owasp.org/www-community/Threat_Modeling) 
• and many other resources… uff!. 

So don’t worry, you are covered 🙂. 

Happy threat modeling!