Threat Modeling (Microsoft Professional) (Paperback)

by Frank Swiderski (Author), Window Snyder (Author) "Software security is not a new field..." (more)
Key Phrases: price quote website, remote administration interface, user with read access, Fabrikam Phone, Datum Access Control, Humongous Insurance Price Quote Website (more...)

Editorial Reviews

Product Description
Threat modeling has become one of the top security analysis methodologies that Microsoft’s developers use to identify risks and make better design, coding, and testing decisions. This book provides a clear, concise explanation of the threat-modeling process, describing a structured approach you can use to assess the security vulnerabilities for any application, regardless of platform. Software designers and developers discover how to use threat modeling during the specification phase of a new project or a major revision—from verifying application architecture to identifying and evaluating threats and designing countermeasures. Test engineers discover how to apply threat-modeling principles when creating test plans to verify results. It’s the essential, high-level reference for software professionals responsible for designing, refining, and maximizing the security features in their application architecture.

About the Author
Frank Swiderski currently works for Microsoft as an application security specialist. Prior to joining Microsoft, Frank spent two years as a security consultant for @stake and has been in the security industry for four years. He is responsible for defining and improving the threat-modeling process in the Developer Division.

Window Snyder is a program manager at Microsoft on the Secure Windows Initiative Team. Prior to joining Microsoft, Window was director of Security Architecture at @stake, a security consulting company. She has spent eight years in the security industry as a consultant and as a software engineer.

Product Details

• Paperback: 288 pages
• Publisher: Microsoft Press (July 14, 2004)
• Language: English
• ISBN-10: 0735619913
• ISBN-13: 978-0735619913
• Product Dimensions: 9 x 7.2 x 0.9 inches
• Shipping Weight: 12 ounces (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars See all reviews (8 customer reviews)
• Amazon.com Sales Rank: #445,915 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #57 in

  Books > Computers & Internet > Security & Encryption > Windows Security

Customer Reviews

Most Helpful Customer Reviews

21 of 21 people found the following review helpful:

3.0 out of 5 stars Comprehensive, but stodgy and full of unnecessary filler, October 3, 2004

By	D. Brankin (USA) - See all my reviews (REAL NAME)

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.

15 of 17 people found the following review helpful:

2.0 out of 5 stars Takes a rudimentary exercise to new levels of tediousness, December 18, 2004

By	The Grumpy Hacker (Milwaukee - Top 5000 Reviewer!) - See all my reviews

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.

8 of 8 people found the following review helpful:

3.0 out of 5 stars lots of good ideas, lots of annoying flaws, October 15, 2004

By	Alton Naur - See all my reviews

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.