Threat Modeling 101: Ten Common Traps Not to Fall Into

Image

As part of Tripwire’s Threat Intelligence University webcast series, we recently had the pleasure of hosting industry expert and renowned author Adam Shostack who shared with us how threat modeling can effectively drive security through your product, service or system. Shostack has championed several security start-ups and previously led Microsoft’s Software Development Lifecycle (SLD). His latest widely acclaimed book, Threat Modeling: Designing for Security, provides actionable advice and practical tips on how to begin threat modeling using various approaches. So, what exactly is threat modeling? Shostack describes the practice as “something you can do while preparing to deploy or build a system to think about the threats associated with it.” In other words, strategically thinking about what might go wrong. Shostack outlined a simple threat modeling approach, which is centered around answering the following four questions:

1. What are you deploying/building?
2. What can go wrong?
3. What are you going to do about it?
4. Did you do an acceptable job at 1-3? (For quality assurance)

A good place to begin threat modeling is by creating a data flow diagram, which includes the representation of external entities, processes, “swim lanes” and trust boundaries, demonstrating what it is you are building or deploying. Next, to help brainstorm risks to the data and the system, Shostack recommends referring to STRIDE: Spoofing, Tampering, Repudiation, Denial of Service, Information Disclosure and Elevation of Privilege. STRIDE is a great way to help focus your answer of what can potentially go wrong. Now, to determine what you’re going to do to resolve these issues, Shostack points out that each of the STRIDE threats is the opposite of a property that you want your system to have. For example, the opposite of spoofing is authentication, and the opposite of tampering is integrity. Each of these threats has a set of standard defenses techniques to help you implement it. If you’re concerned about the integrity of files, for example, you can ensure that the permissions (or ACLs) are set correctly, or use digital signatures, etc.

Image

With the previous four questions in mind, Shostack outlined some of the most common threat modeling mistakes or “traps” that he’s encountered:

Trap #1: “Search your feelings!”

People need a degree of structure, and that’s what STRIDE is there for. “It helps you structure your thinking, so you can systematically and repeatedly go through a system and find the same sorts of problems,” said Shostack. Saying things like, “Search your feelings,” or “Think like an attacker,” doesn’t give people what they need. Instead, say something like, “Let’s go through this in a structured way and find the real problems.”

Trap #2: “You’re never done threat modeling.”

As an expert and enthusiast, Shostack says he believes he’s never quite done threat modeling. There’s always something more to find, or something else that needs to be done. However, that might not fit well into a project or product plan, so he suggests thinking of it as four steps, which is a more linear approach to the same four questions above.

1. Model
2. Identify Threats
3. Mitigate
4. Validate

Trap #3: “The Way to Threat Model Is…”

You may have a different approach to threat modeling depending on your skill set. Consider threat modeling as a monolithic process, such as a set of "building blocks" that can lock together, and use these modeling approaches in junction with other ways to identify threats – STRIDE, CAPEC, the Kill Chain or Attack Trees. Similarly, there are different building blocks you can use for thinking about privacy, as well as security. It’s important to remember that there is really no perfect way to threat model, and what may work for you, may not work for others. The different building blocks make sense for different people – STRIDE may be a great tool for security experts, meanwhile CAPEC may be a better tool for experts in databases or networking.

Image

Trap #4: Thinking of Threat Modeling as One Skill

Shostack stresses that there are a set of techniques (DFDs, STRIDE, Attack trees) and repertoire (SSLSpoof, Firehseep) to help you do a better job at threat modeling. Also, reading books like Mitnick or Cuckoo’s Egg can you give stories and examples to put things into context when working with others.

Trap #5: Threat Modeling is Born, Not Taught

“Threat modeling is like playing the violin,” said Shostack. When someone is learning to play, they need to develop and maintain muscles – beginners need easy tunes they can learn to play. It’s important to keep in mind that not everyone wants or needs to be a virtuoso, and that’s fine.

Trap #6: The Wrong Focus

It’s easy to begin threat modeling with the wrong focus. A common mistake is thinking that threat modeling is all about finding threats. In reality, it’s just a step on the way to fixing them. Remember Trap #3: “The Way to Threat Model Is…” – focusing on your assets or focusing on your attackers may work for you or your organization, but not for everyone. “If you’re just getting started or if the approach you currently have isn’t working, consider if you’re focus is correct and if you’re starting in the right place,” said Shostack.

Trap #7: Threat Modeling is for Specialists

Threat modeling is often seen as a skill that only specialists can do well, when really it’s a lot like version control.

“… No professional developer would think of building software of any complexity without a version control system of some form. Threat modeling should aspire to be that fundamental.” – Threat Modeling: Designing for Security

Every developer should know version control, and most sysadmins know how to leverage it to manage configuration files. Meanwhile, many large organizations have a full-time person “managing trees” – this is a stretch goal for threat modeling.

Trap #8: Threat Modeling in a Vacuum

There are some things that are “easy” for a developer to fix, and there are some things that are “easy” for operations to fix, says Shostack. Understand that good threat modeling can build connections between the different disciplines, groups and organizations. If you threat model in a vacuum and assume that everything can be fixed in one place, you’re going to run into trouble. Leverage the Security Operations Guide or a set of non-requirements as a form of communication to set the expectations for both groups.

Trap #9: Laser-Like Focus on Threats

Shostack explained there’s an interplay of attacks, mitigations and requirements. First, there is the interplay that requirements can help you understand what the threats are and threats can also expose requirements. Similarly, there’s an interplay that threats need mitigations, while mitigations can be bypassed. Lastly, un-mitigatable threats drive requirements, and that interplay may be where compliance comes in.

Trap #10: Threat Modeling at the Wrong Time

The last common mistake is to start threat modeling when the time isn’t right. Clearly, you don’t want to be on the brink of launching your product or deploying your software, and finding there are still threats that haven’t been addressed or analyzed.   Shostack concluded saying that anyone can threat model, and urges that everyone should – the skills, techniques and repertoire can certainly be learned. Threat modeling will enhance your security posture, reduce the things that can go wrong, and improve the communication between teams. In addition, this approach can provide the business with visibility into the risks associated with the system, service or software. You can listen to Adam Shostack’s full webcast here, including additional resources, and a few more bonus traps that you don’t want to fall into. _{Title image courtesy of ShutterStock}