| | |  | Manager's Guides to Computing | Home » » » Threat Modeling (Microsoft Professional) | | | | | | | Description: | | In this straightforward and practical guide, Microsoft® application security specialists Frank Swiderski and Window Snyder describe the concepts and goals for threat modeling—a structured approach for identifying, evaluating, and mitigating risks to system security. Discover how to use the threat modeling methodology to analyze your system from the adversary’s point of view—creating a set of data points that help drive security specifications and testing. You’ll review application scenarios that illustrate threat modeling concepts in action, understanding how to use threat modeling to help improve the built-in security of a system—as well as your customer's confidence in the security of that system—regardless of development environment.
Gain an in-depth, conceptual understanding—along with practical ways to integrate threat modeling into your development efforts:
- Help anticipate attacks by seeing how adversaries assess your system—and compare their view to the developer’s or architect’s view
- Employ a data flow approach to create a threat profile for a system
- Reveal vulnerabilities in system architecture and implementation using investigative techniques such as threat trees and threat model-directed code reviews
- Develop a credible security characterization for modeling threats
- Use threat modeling to help verify security features and increase the resilience of software systems
- Increase customer confidence in your products!
| | | Product Details: | | | Author:
| Frank Swiderski | | Paperback:
| 288 pages | | Publisher:
| Microsoft Press | | Publication Date:
| July 14, 2004 | | Language:
| English | | ISBN:
| 0735619913 | | Product Length:
| 9.26 inches | | Product Width:
| 7.48 inches | | Product Height:
| 0.59 inches | | Product Weight:
| 1.09 pounds | | Package Length:
| 8.98 inches | | Package Width:
| 7.24 inches | | Package Height:
| 0.94 inches | | Package Weight:
| 0.75 pounds | | Average Customer Rating:
|  based on 9 reviews |
| | | | Customer Reviews: | |
Average Customer Review:
 ( 9 customer reviews )
Write an online review and share your thoughts with other customers.
Most Helpful Customer Reviews
26 of 27 found the following review helpful:
 Comprehensive, but stodgy and full of unnecessary fillerOct 04, 2004
By D. Brankin
In my review Thread Modeling (spelt with captials) refers to the book, thread modeling (spelt without capitals) refers to the subject.
Open the cover of this book and the first thing you see in large, bold print is `Reviewer Acclaim for Frank Swiderski, Window Snyder, and Threat Modeling'. I doubt that I'm the only one to notice that ALL the quotes are from current Microsoft employees! Look further and you notice that the content stops and the appendixes start on page 173 (of a 259 page book).
Considering that Chapter 4 of Writing Secure Code 2nd Edition does a much better job or covering threat modeling, you have to wonder what sort of padding is going on to fill 172 pages. In fact, I have to say the signal to noise ratio of this book isn't very good at all - unless you are interested in applying threat modeling to the security of your home or touch-tone telephone system!
If you know anything about threat modeling already, you'll also want to know why all (and I mean ALL - no exceptions) of the threat diagrams in this book show a DREAD score of 0 - why wasn't somebody proof reading this stuff? I don't expect to have to wait long before hearing "MS don't take security seriously - in their latest book they've rated [insert favorite threat here] a 0!"
The diagrams in Threat Modeling are also unnecessarily harder to read than the diagrams in Writing Secure Code. Threat Modeling uses the same square boxes for unmitigated conditions and mitigated conditions. This makes it impossible to tell at a glance whether a threat is outstanding or not. Writing Secure Code's use of circles for Mitigated / Resolved conditions at the leaf of the tree made it easy. I also miss Writing Secure Code's use of dotted lines to indicate unlikely attack paths.
Threat Modeling is not without some redeeming features. The idea and reasons for reducing the DREAD range from 1-10 to 1-3 is a welcome refinement and non-programmers may find the wealth of non-relevant examples helpful in assimilating the underlying concepts. Threat Modeling also covers DFDs (Data Flow Diagrams) which Writing Secure Code regrettably does not.
Threat Modeling is not a complete waste of space. It covers the material it sets out to cover and you should have no trouble producing threat models are reading this book. But if you only have time to read (or the money to buy) one MS security book, you won't regret making it Writing Secure Code instead.
16 of 18 found the following review helpful:
 Takes a rudimentary exercise to new levels of tediousnessDec 19, 2004
By The Grumpy Hacker
I believe threat modelling is a concept you either get or you don't--like how for some people building things comes naturally, but for others it's breaking things. This book attempts to formalize and codify the creative thought process of the latter while over-emphasizing its importance and severely trivializing the effort required to do it. Let's face it, creating a threat model for a telephone or a single web page is one thing, but doing it for a complex client-server application or networked system is a serious undertaking.
Strange that I don't recall the book ever mentioning the threat modelling software tool free from Microsoft (which they should have included on a CD with the book), given the pervasive "not invented here" attitude in the book and the numerous plugs for or from other Microsoft people. Having a software tool to assist with or at least record threat models is a great idea because make no mistake, threat modelling is a worthwhile endeavor. But no one's going to make diagrams by hand.
Speaking of diagrams, I found those in the book to be unnecessarily curvy and asymmetrical, making them difficult to read. A diagram should either be intuitive at first glance or flow nicely from one section to another--this book's diagrams are just a mess. Except perhaps the attack trees; not a new concept to security pros, these were the most sensical diagrams in this book about diagramming. Color would have been welcome to better differentiate the various pieces, and at least rough threat modelling seems to lend itself to the whiteboard, on which you can write using a rainbow of colors.
The book is also full of new terminology--which isn't such a bad thing if it's trying to standardize the disparate threat modellers' vocabularies, but it's not--and acronyms, from DREAD to STRIDE to "SPMs" in both cases seemingly presented as a refresher of historical fact. One term the book uses repeatedly (and repetitiveness is rampant) is penetration testing, mentioning that threat models make good pen test plans. Unfortunately pen testers think differently than this book seems to try to persuade threat modellers to think: certain attack vectors are summarily dismissed whereas a pen tester would take whatever he could get. The book also mentions code review as a testing tool, but never seems to say much about the traditional software QA tester playing a role.
Another blow to the book's potential value is the fact that the last third is devoted to threat model examples. Since the three example targets are discussed throughout the book it doesn't make sense to me to do this rather than in context. In general the book is too drawn out and would have been better suited to a whitepaper. It makes reference to Writing Secure Code which also covers threat modelling, as well as Assessing Network Security (yet another Microsoft book, go figure) which isn't a bad book but is less on-topic than perhaps the non-Microsoft title not referenced, How to Break Software Security.
While the subject of the book is important, and the book's introduction does a good job of getting the reader's attention, I don't think this book is worth the cover price or the time it'll take you to suffer through its dry presentation, unless you've been assigned to do threat modelling in your job and you have no idea where to begin. In that case you should definitely download Microsoft's free tool for it as well.
Edited to add:
Maybe you don't trust me but surely you trust Bruce Schneier who said in his book Secrets and Lies: Digital Security in a Networked World, "Threat modeling is, for the most part, ad hoc. You think about the threats until you can't think of any more, then you stop. And then you're annoyed and surprised when some attacker thinks of an attack you didn't." This book, at its best, gives a neophyte some structure with which to do that if he can't come up with it himself, however, no book is going to teach him how to be effective or comprehensive in threat modelling. As I said, either you get it or you don't, and even if you do, it's easy to miss things.
9 of 9 found the following review helpful:
lots of good ideas, lots of annoying flawsOct 15, 2004
By Alton Naur
This was a very frustrating book to read. It appears to be targeted to a very specific type of reader, yet this reader isn't well described. It exists in a disciplinary vacuum; there are only two references; one of them is to the excellent Howard/LeBlanc "Writing Secure Code", the other is to a book written ten years ago. If you have to ask "what is UML and why is it important?", this book won't help.
On the other hand, if you're a member of a large software development team using formal design methods, this book will give you a workable approach to making sure that the security aspects of your project are comprehensively addressed.
There are two serious defects in the approach described by Swiderski and Snyder. The first is that their approach has serious scalability problems. Like nearly all software modeling methods, it's based on drawing pictures and making lists that must be manually collated and organized. (...)
The other defect in the book is its assumption that "an adversary will not attack the system without assets of interest." In fact, the vast majority of attacks these days are blind attacks from viruses and worms that attempt to invade any host they can gain access to, regardless of the value of any assets it may contain or represent. This fact requires the designer/defender to exhaustively address all possible vulnerabilities, not just the important ones. Managing the enormous list of possible attacks against possible vulnerabilities makes scalability a critical issue.
The threat modeling approach is probably the best one available for identifying security issues that must be addressed in a software system, but its current state is far from satisfactory.
4 of 4 found the following review helpful:
 Good coverage of the material, but far too redundantJul 08, 2005
By Heath Stewart
The book is short at only a 169 pages but it could be shorter. My biggest complaint with this book is that it's incredibly redundant. The first two chapters are spent discussing why threat modeling is important. It is a valid point, as many people may be wondering why threat modeling is important or even what it is. Two chapters may be a little extensive, though, and constantly repeat the same ideas.
Page 13 of the introduction does make a statement that might help in avoiding much of this redundancy:
"Development team members who want to skim this book for an overview should look at Chapter 2, which describes the overall threat modeling process. Chapters 3 and 5 will also be valuable to those looking for shortcuts because they describe entry points, assets, and the threat profile. Chapter 4 describes bounding the threat modeling discussion. The rest of the chapters, which flesh out the threat modeling process, will be most important for a project's security process manager."
I, of course, read the whole thing. So, some redundancy is warranted, since this book itself implies that it is a sort of reference book. But even consecutive sections within the aforementioned chapters repeat the same statements. There is a difference between driving a point home and driving your reader crazy.
I would also add that - if you are going to use the book as a reference - you take a look at Part 4 - appendices A, B, and C - which are entire threat model documents for the three example features used throughout the book.
This book is a good book for anyone in software design and development to understand how to write secure software. Every entry and exit point is a threat, and unmitigated threats are vulnerabilities. Feature- and program-level threat modeling can help to mitigate those threats by identifying use cases and non-use cases for those entry points, roles accessing those entry points, threats associated with those entry points using the STRIDE classification (Spoofing, Tampering, Repudiation, Denial of service, and Elevation of privilege), the risk a threat poses using a DREAD rank (Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability), and internal and external notes about the threats. The book also points out that a threat model document is a living document, meaning that it should be kept current as the design of the feature or program changes.
-- Excerpt copied from my blog.
2 of 2 found the following review helpful:
A practical method for doing Threat ModelingJun 25, 2005
By coffee_fan
This book describes one method to do Threat Modeling. There are many methods to do threat modeling, and the main objectives and meta-objectives such an exercise has are:
1) Avoid analysis paralysis.
2) Find a way of modeling your security as faithfully as possible.
3) Document interesting information that could influence your security.
4) Based on all the above make sure your system is managing its security properly.
The book presents an approach which is coherent, not always easy, as developing either a threat tree or the right DFD are no easy tasks, but yet one way.
It is imporant to note that the model presented works mostly for applications; not for drivers.
See all 9 customer reviews on Amazon.com
| | |
* Estimated shipping rate for US 48 states. Final rate calculated at checkout. |
