Author: admini

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.

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. 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. 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-lead-time 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.

Software Design
Design-driven threat modeling is threat modeling based on where your fences and windows are. You draw diagrams and worry about what can go wrong with each thing in your diagram. (This is the essence of the SDL threat modeling process today because everyone in software knows how to draw diagrams on a whiteboard.) The software equivalents of fences and windows are the various forms of attack surface, such as file parsers or network listening services—sockets, remote procedure call (RPC) services, Web services description language (WSDL) interfaces, or AJAX APIs. They’re the trust boundaries where you should expect an attacker to first get a foothold.

A Quick and Dirty Threat Model
Threat modeling doesn’t have to be a chore. Following the process illustrated in Figure 1, here is the outline of a basic threat modeling process that will get you going quickly and painlessly: Diagram your application, and use this to tell your app’s story in front of the whiteboard (see Figure 2). Use circles for code, boxes for things that exist outside of it (people, servers), and drums for storage. Our team uses funny looking parallel lines for data stores. Draw some trust boundaries using dotted lines to distinguish domains. When you get stuck, apply the STRIDE threat model, described in Figure 3, on each element of your app. All the threats in one place may mean you’re worried about the front door and not worrying about anything else. A third order defense might be an alarm system on the door, and to mitigate the threat of someone cutting the wire, you send a regular message down the wire. If you find yourself worrying about the software equivalent of what happens when someone cuts the phone wire to the alarm system before you worry about locks on the doors, you’re worrying about the wrong things.

File bugs so you can fix what you found threat modeling. Modifying a DLL on disk or DVD, or a packet as it traverses the LAN. Allowing someone to read the Windows source code; publishing a list of customers to a Web site. Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole. Elevation of Privilege Authorization Gain capabilities without proper authorization.

Finally, you need to account for the availability of time and resources both for your threat modeling process and any resulting mitigation and testing.

Microsoft has found that threat modeling works better with a security expert in the room, but there isn’t always one available. You can get decent results by giving people structure and feedback on their work, and by breaking it down into small, easy pieces with rules and self-checks in each one. For problems validating the threat model and your mitigation plan, look to see whether the diagrams represent the code and whether you have agreement between developers and testers on that.

http://msdn.microsoft.com/en-us/magazine/cc700352.aspx