Threat Modeling

Rating:
Summary: Takes a rudimentary exercise to new levels of tediousness
Review: 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.

Rating:
Summary: great insight from those in the know
Review: I know of Frank and Window by reputation, and was excited to see they finally put some of their ideas to paper. Threat Modeling really identifies threats I need to understand as a systems administrator and software developer. I have applied some of their ideas into our company's development processes, and have already seen tremendous success. I urge anyone with even an interest in security to buy this book!

Rating:
Summary: Comprehensive, but stodgy and full of unnecessary filler
Review: 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.

Rating:
Summary: lots of good ideas, lots of annoying flaws
Review: 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.

Rating:
Summary: The best text on threat modeling - by far.
Review: Threat modeling is in theory really simple and there are a lot of good texts and papers describing different ways to present the threat model once it is there. How to get that information from a planned or current application is often not described but rather it seams that it is supposed to pop up from nowhere in some ad-hoc way, which makes you wounder if those authors have ever tried to do a threat model on a larger app than Hello World.

This book separates itself from the others by not only describing a way to present the model but also processes to get that vital information. You can really tell that these two guys has done a lot of threat modeling (and not only in theory).