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.
