Most security books are targeted at security engineers and specialists. Few show how build security into software. None breakdown the different concerns facing security at different levels of the system: the enterprise, architectural and operational layers.
Security Patterns addresses the full spectrum of security in systems design, using best practice solutions to show how to integrate security in the broader engineering process. Essential for designers building large-scale systems who want best practice solutions to typical security problems Real world case studies illustrate how to use the patterns in specific domains
For more information visit www.securitypatterns.org
User review
Interesting view
It's an interesting idea to recast security principles as design patterns, but it lacked the succinctness of the GoF patterns.
User review
Security Patterns Review
I bought this book because i am new in the field. This book gives me a lot of practical tips. The examples in this book are great to use in architecturale documentation i have to write.
User review
Objective, Clear and To-the-Point
Patterns well documented and references are very rich. I suggest in a next book edition the inclusion of some diagrams to depict relationships among patterns.
User review
Good concepts but no implementation advice
I'm now just more than half way through with this book. So far I find the book with good concepts and patterns that addresses a list of issues for security development. I find the patterns described lack implementation advice and how to verify them in real-world deployment. The authors might know when it comes to security development the devil is in the details and this book lacks those details - just how to implement them. From my experience so far I liked the following books - Gary McGraw's `Software Security: Building Security In`, for Microsoft security - Mike Howard's `Writing Secure code` and for Java/J2EE Security - `Core Security Patterns`.
Overall this book aims at people of academic interests than software projects.
User review
An interesting application of a software development technique to the security space
I read six books on software security recently, namely `Writing Secure Code, 2nd Ed` by Michael Howard and David LeBlanc; `19 Deadly Sins of Software Security` by Michael Howard, David LeBlanc, and John Viega; `Software Security` by Gary McGraw; `The Security Development Lifecycle` by Michael Howard and Steve Lipner; `High-Assurance Design` by Cliff Berg; and `Security Patterns` by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the production of more security software.
It's important to recognize that `Security Patterns` (SP) is not as narrowly focused as a similar book, Cliff Berg's `High-Assurance Design.` SP applies to code, but also to enterprise architecture, and even non-IT scenarios. A case study involving protecting a museum runs throughout much of the text, for example. SP introduces several helpful concepts as well, such as security `properties` (CIA), `services` (authentication, authorization, accounting, auditing, non-repudiation), `approaches` (planning, prevention, detection, response), and `mechanisms` (access control, etc.).
The first part of SP explains the important of patterns, which I found useful as a non-professional programmer. I realized that patterns are significant not just because they help define a solution, but also because they can assist in properly scoping the problem (p 35). However, these patterns do not provide code samples. It's more conceptual than actionable.
Similar to Microsoft's books on secure software development, I thought SP suffered from confusing terminology. For example, SP decides to include `accountability` as a security `property`. I am not sure this qualifies as a property, since it's really only needed to know who violated one of the CIA properties. CIA violations should be labeled disclosure, corruption, and denial of service.
SP stumbles when it discusses `threat assessment,` defining terms like `threat source` (which should be just `threat`), `threat action` (i.e., `attack`), and `threat consequence` (really an `incident` or `violation`). In several places (pp 116. 118) SP ignores the fact that threats and vulnerabilities are independent aspects of security; they are not synonyms.
Although SP's pattern approach is interesting, sometimes the execution is weak or incorrect. I found the hand-drawn stick figures in ch 9 to be laughable. I cringed when I read about `today's more popular remote shell, /usr/bin/rsh`. The authors didn't know what they were talking about when discussing firewalls, either. Packet-filtering firewalls don't just work by inspecting `addresses,` and the BSD Packet Filter is a stateful packet filter, not an address-inspecting packet filter. I thought the architecture diagrams were far too simplistic and in some cases poor, such as showing a mainframe and a public Web server in the same network segment.
Overall, I think the idea of using security patterns to provide tools for developers and architects is powerful. Perhaps a second edition or later books will better execute on this idea. I still think SP deserves four stars for breaking fairly new ground with this approach, and using non-digital examples to emphasize concepts applicable to information security problems.
