MSDN Magazine - July 2008 - (Page 117)

AdAM ShoSTAck Security BriefS Reinvigorate Your Threat Modeling Process My colleague Ellen likes to say that everyone threat models all the time. We all threat model airport security. We all threat model our homes. We think about threats against our assets: our families, our jewelry, and our sentimental and irreplaceable photographs (well, those of us old enough to have photos that never existed in digital form do). We model threats based on architecture: there’s a wall here, a picture window there, and an easily climbed tree that we can use when we forget our keys. And we model threats based on attackers. We worry about burglars and kids falling into pools. We also worry about the weather, be it earthquakes, snow, or tornadoes. If I wanted to sound like a management consultant, I’d say you employ a mature, multi-dimensional assessment process, with a heavy reliance on heuristics and low reproducibility across instances. At the same time, it’s likely you won’t have thought of everything or implemented defenses against every possible attack. It’s very unlikely you have a home defense management plan or have ever run a penetration test against your home. As we build software, regardless of whether we’re in an agile or a waterfall world, we need agreement on what we’re building, what we’re not building, and what we’re doing to ensure we’re building the right thing. In the past few years, a perception that threat modeling is a heavy, bureaucratic process has been generated. There are some good reasons to move toward adding processes; I’d like to talk about them, some lessons learned from these processes, and how to put the fun back in threat modeling while making it an efficient, agile-friendly activity that anyone can do. There are more threat modeling methods out there than I can dream of covering in one column. There’s also a tremendous diversity of goals. Should your threat modeling process be fast or deep? Should it focus on assurance and completeness, or ease of use? Should you involve experts or developers in every meeting? Do you have organizational or industry rules you need to follow, such as the Microsoft® Security Development Lifecycle (SDL) or the rules for medical device manufacturers? The high level objective should be to understand security issues early so you can address them in the design rather than try to overcome design flaws later. Some of the major ways to approach threat modeling activity include the following: Assets Asset-driven threat modeling is much like thinking about what you want to protect in your house. You start by listing what assets your software has associated with it, and then you think about how an attacker might compromise those assets. Examples include a database that stores customer credit cards or a file that contains encrypted passwords. Some people may interpret an asset as an element of the threat modeling diagram, thinking that a Web server itself is an asset. That way lies madness. Digital assets are things an attacker wants to read, tamper with, or deny you the use of. Attackers Attacker-driven threat modeling involves thinking about who might want your assets, and it works from an understanding of their capabilities to an understanding of how they might attack you. This works great when your adversary is a foreign army with a known strategic doctrine, physical world limits, and long-leadtime weapons systems development. This works less well when your adversary is a loosely organized group of anonymous hackers. More generally, it’s not clear this is useful in software threat modeling. There are certainly people for whom “think like an attacker” is an effective part of design analysis. It’s less clear that this is a reproducible process in which people can get training. If you’re going to start from attackers, it’s probably worth using a standard set. It will be helpful to have a small set of these anti-personas written out. Approaches to Threat Modeling There are many things called threat modeling. Rather than argue about which is “the one true way,” consider your needs and what your skills, abilities, and schedules are, and then work with a method that’s best for you. As part of that approach, some people ask, “What’s your threat model?” and “Have you threat modeled that component?” One is requirements elicitation, the other design analysis. At Microsoft, we almost always mean the latter technique. Figure 1 The Threat Modeling Process July 2008 117

Table of Contents Feed for the Digital Edition of MSDN Magazine - July 2008

MSDN Magazine - July 2008 Contents Toolbox CLR Inside Out Flex Your Data Data Points Advanced Basics Office Space Cutting Edge Data Services ADO.NET Data and WPF Transactions WCF P2P Test Run Security Briefs Foundations .NET Matters {End Bracket}

MSDN Magazine - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.