About 2.5 years ago, I wrote a series of articles about how we threat model at Microsoft, about 18 months ago, I made a couple of updates to it, including a post about why we threat model at Micrososoft, and a review of how the process has changed over the years.
It's threat modeling time again in my group (it seems to happen about once every 18 months or so, as you can see from my post history :)), and as the designated security nutcase in my group, I've been spending a LOT of time thinking about the threat modeling process as we're practicing it nowadays. It's been interesting looking at my old posts to see how my own opinions on threat modeling have changed, and how Microsoft's processes have changed (we've gotten a LOT better at the process).
One thing that was realized very early on is that our early efforts at threat modeling were quite ad-hoc. We sat in a room and said "Hmm, what might the bad guys do to attack our product?" It turns out that this isn't actually a BAD way of going about threat modeling, and if that's all you do, you're way better off than you were if you'd done nothing.
Why doesn't it work? There are a couple of reasons:
So how do we go about threat modeling?
Well, as the fictional Maria Von Trapp said in her famous introductory lesson to solfege, "Let's start at the very beginning, A very good place to start"...
One of the key things we've learned during the process is that having a good diagram is key to a good threat model. If you don't have a good diagram, you probably don't have a good threat model.
So how do you go about writing a good diagram?
The first step is to draw a whiteboard diagram of the flow of data in your component. Please note: it's the DATA flow you care about, NOT the code flow. Your threats come via data, NOT code. This is the single most common mistake that people make when they start threat modeling (it's not surprising, because as developers, we tend to think about code flow).
When you're drawing the whiteboard diagram, I use the following elements (you can choose different elements, the actual image doesn't matter, what matters is that you define a common set of elements for each type):
You build a data flow diagram by connecting the various elements by data flows, inserting boundaries where it makes sense between the elements.
Now that we have a common language, we can using it to build up a threat model.
Tomorrow: Drawing the DFD.
Adam Shostack here. I said recently that I wanted to talk more about what I do. The core of what I do
"Threats come from data, not code."
To which I reply, code IS data... Its ALL data!
Code is only data to the OS loader (and the filesystem). Since the loader's the component that turns the data into code, it needs to be fuzzed against malformed data that looks like code.
I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,
I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah
Adam Shostack here, with the second post in my series on the evolved threat modeling process. To summarize,
I know this is a little late but about Maria Von Trapp: When asked about the movie
"The Sound of Music", she replied "It is a very nice story. It is not *my*
story, but it is a very nice story."
Larry Osterman has an interesting series of posts on Threat modeling.. It starts from the basics and