Customer Rating: 
Summary: Ok, so maybe I didn't read the book...
Comment: ...but Frank was a heck of alot smarter than me in high school, so I'm sure everything in there is right.
-David Wedeberg
Customer Rating: 
Summary: Good coverage of the material, but far too redundant
Comment: 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.
Customer Rating:
Summary: A practical method for doing Threat Modeling
Comment: 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.
Customer Rating:
Summary: Takes a rudimentary exercise to new levels of tediousness
Comment: 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.
Customer Rating:
Summary: lots of good ideas, lots of annoying flaws
Comment: 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.
|
|
