Adam Shostackby Adam Shostack
Wouldn't it be nice to be able to anticipate security problems and design to minimize them?
Many software engineers see security as something to handle "later on," with code analysis, fuzzing, or penetration testing. But good design can eliminate entire categories of problems. Those design choices include memory safe languages, not running as root, and use of good libraries that, for example, manage Javascript or SQL for you in ways that make it hard to mess up. But even with those, security problems can creep in. Are you authenticating well? Are you ensuring that each part of your code carefully parses its input to attenuate the control it allows? (For example, do you make sure that all paths are relative and don't contain ..? That no files you open are symlinks?)
Threat modeling is a collection of techniques to help you do this before you've written a line of new code. At its heart, threat modeling is very simple. We ask four key questions:
- What are we working on?
- What can go wrong?
- What are we going to do about each?
- Did we do a good job?
Simply asking these questions is a great first step, and there are tools and techniques we can use to answer each. For example, Data Flow Diagrams help us express 'what are we working on', while STRIDE helps us discover what can go wrong. STRIDE is a mnemonic. It stands for:
- Spoofing
- Tampering
- Repudiation
- Information disclosure
- Denial of service
- Expansion of authority
You can use it to help you think through the question of what can go wrong, and you don't have to. Some people find other security-specific tools, like an OWASP Top 10 list, work better for them.
Our diagrams also include trust boundaries - we use dashed lines to indicate different user ids, permissions and other places where code at different trust levels interact. Data flow diagrams are not unique to threat modeling, but they're now so associated with it that we sometimes hear them called threat model diagrams.
There are lots of techniques here. I want to encourage you to start with two specific ones: data flow diagrams and STRIDE. Other 'getting started' guides suggest trying a smorgasboard, and I see that leading to a lot of confusion. Persevere, learn a few techniques, and branch out. This is very much like programming: if you try to learn Python and Lisp at the same time, you're going to get confused. Learn one, do a few projects in it, gain proficiency. And if, like me, you find Lisp syntax hurts your head, feel free to jump to something else.
What are we going to do about each item in STRIDE? We can redesign our system by adding controls or separating components, and frankly, that's the best approach. When that's hard, we can bring use risk management strategies beyond mitigation, such as risk transfer (to customers or insurance) or acceptance by the business. Whatever we do, we need to track and manage the changes that threat modeling illuminates. And these changes are easier the earlier you identify them. Changes to APIs, file formats and other places people take dependencies get harder as time goes on.
Lastly, we ask "did we do a good job." That involves both checking your work, and your satisfaction with the work. Do you have a diagram? A list of threats? A list of mitigations? Are you happy you took the time? Would you recommend threat modeling to your colleagues? This is here because many organizations don't have healthy cultures of introspection and reflection, and both are important as you adopt a new practice. Even if you have a healthy retrospective culture, making specific time as part of adopting threat modeling can be helpful.
These simple techniques -- asking the Four Questions -- are a great starting point to threat modeling, delivering secure by design systems and spending less energy on re-work, arguments or escalations because of security flaws that have been baked in before you see them.
Learn more about threat modeling, start with the Threat Modeling Manifesto. To learn more about threats and get started with threat modeling, check out these free resources from OWASP:
Please also consider my book, Threats: What Every Engineer Should Learn from Star Wars.
--
OWASP is a non-profit foundation that envisions a world with no more insecure software. Our mission is to be the global open community that powers secure software through education, tools, and collaboration. We maintain hundreds of open source projects, run industry-leading educational and training conferences, and meet through over 250 chapters worldwide.
