Vous voulez voir cette page en français ? Cliquez ici.

Have one to sell? Sell yours here
Tell the Publisher!
I'd like to read this book on Kindle

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Threat Modeling [Paperback]

Frank Swiderski , Window Snyder

Available from these sellers.

Join Amazon Student in Canada

Book Description

June 25 2004 0735619913 978-0735619913 1

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!

Special Offers and Product Promotions

  • Join Amazon Student in Canada

Customers Who Bought This Item Also Bought

Product Details

Product Description

About the Author

Frank Swiderski is a Software Security Engineer at Microsoft® and is responsible for helping Microsoft product teams evaluate the impact of threats to their product or component. He has specialized in application security for several years, including serving as a managing security architect for @stake, a leading digital security consulting firm.

Window Snyder is a program manager for the Microsoft® Secure Windows® Initiative Team. She is the former director of Security Architecture for @stake, and has dedicated eight years to the security industry as a consultant and as a software engineer.

Inside This Book (Learn More)
First Sentence
Software security is not a new field. Read the first page
Explore More
Browse Sample Pages
Front Cover | Copyright | Table of Contents | Excerpt | Index | Back Cover
Search inside this book:

Sell a Digital Version of This Book in the Kindle Store

If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store. Learn more

Customer Reviews

There are no customer reviews yet on Amazon.ca
5 star
4 star
3 star
2 star
1 star
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com: 3.7 out of 5 stars  7 reviews
28 of 29 people found the following review helpful
3.0 out of 5 stars Comprehensive, but stodgy and full of unnecessary filler Oct. 3 2004
By D. Brankin - Published on Amazon.com
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.
10 of 10 people found the following review helpful
3.0 out of 5 stars lots of good ideas, lots of annoying flaws Oct. 15 2004
By Alton Naur - Published on Amazon.com
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 people found the following review helpful
4.0 out of 5 stars Good coverage of the material, but far too redundant July 7 2005
By Heath Stewart - Published on Amazon.com
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.
3 of 3 people found the following review helpful
3.0 out of 5 stars A practical method for doing Threat Modeling June 24 2005
By Amazon Customer - Published on Amazon.com
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.
3.0 out of 5 stars Multiple reading issues Oct. 12 2011
By Cristian Rojas - Published on Amazon.com
Format:Kindle Edition|Verified Purchase
Content is very interesting, but reading is laggy, a little boring, and the e-book itself has issues. Some words glue together at small font sizes, and tables are lacking (Entry Points, Assets, etc). Needs to improve.

Look for similar items by category