Customer Reviews

Software Security: Building Security In

5 star:		(18)
4 star:		(1)
3 star:		(0)
2 star:		(0)
1 star:		(1)

 

 

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.

Gary McGraw's book gets my vote as the best of the six because it made the biggest impact on the way I look at the software security problem. First, Gary emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). He shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. Gary applauds the diversity of backgrounds found in today's security professionals, but wonders what will happen when this rag-tag bunch (myself included) is eventually replaced by "formally" trained college security graduates.

Second, Gary explains that although tools cannot replace a flaw-finding human, they can assist programmers trying to avoid writing bugs. Gary is the only author I encountered who acknowledged that it is unrealistic to expect a programmer to keep dozens or hundreds of sound coding practices and historical vulnerabilities in his head while writing software. An automated tool is a powerful way to apply secure coding lessons in a repeatable and measurable manner. Gary also reframed the way I look at software penetration testing, by showing in ch 6 that they are best used to discover environmental and configuration problems of software in production.

Third, Gary is not afraid to point out the problems with other interpretations of the software security problem. I almost fell out of my chair when I read his critique on pp 140-7 and p 213 of Microsoft's improper use of terms like "threat" in their so-called "threat model." Gary is absolutely right to say Microsoft is performing "risk analysis," not "threat analysis." (I laughed when I read him describe Microsoft's "Threat Modeling" as "[t]he unfortunately titled book" on p 310.) I examine this issue deeper in my reviews of Microsoft's books. Gary is also correct when he states on p 153 that "security is more like insurance than it is some kind of investment." I bookmarked the section (pp 292, 296-7) where Gary explained how the "19 Deadly Sins of Software Security" mix "specific types of errors and vulnerability classes and talk about them all at the same level of abstraction." He's also right that the OWASP Top Ten suffers the same problem. Finally, Gary understands the relationships between operators and developers and the importance of security vocabulary.

I was pleasantly surprised by "Software Security". I reviewed an early draft for Addison-Wesley and wondered where the author was taking this book. It ended up being my favorite software security book, easily complementing Gary's earlier book "Building Secure Software." In my opinion, Gary is thinking properly about all the fundamental issues that matter. This book should be distributed to all Microsoft developers to help them frame the software security problem properly.

On the one hand, it is risky for me to praise this book. I make my living teaching and practicing computer security. If everyone writing software these days were to read this book, I might eventually find myself out of business.

Gary McGraw, one of the leading security luminaries int he world, has got it right. Security cannot be added to systems once they are built. It must be designed in from the very beginning. The security posture and design must be considered in every phase of the development of a system - from the early design to the actual coding of the instructions.

Gary has done a fanstastic job explaining how to build secure systems, and detailing the importance and complexity of software security.

I've always been a big fan of Gary's, and with this latest installment in his 3 part series, Gary has provided readers with the most important advice and instruction to help keep the bad guys out of your systems.

The root cause of many security vulnerabilities is poorly written software. Often, software applications are written without security in mind. The logical, yet elusive, solution is to ensure that software developers are trained in writing secure code.

Software Security: Building Security In is a valiant attempt to show software developers how to do just that. The book is the latest step in Gary McGraw's software security series, whose previous titles include Building Secure Software and Exploiting Software.

In past decades, writing secure code was left to the military and banking industry. Today, with everything on networks, all sectors must get into the act.

Much of the problem is that organizations target their security elsewhere--specifically on networks--rather than on software. But so many malicious attacks are directed at software that it is foolish to leave this vulnerability exposed.

McGraw goes into detail not only about writing secure code but also about key related areas, which he terms "the seven touchpoints of software security."

These points comprise code review, architectural risk analysis, penetration testing, risk-based security tests, abuse cases, security requirements, and security operations. A major portion of the book effectively discusses these "touchpoints," making the work a recommended tool for inculcating software developers with a security mind-set.

When my company began to investigate software security, we all mistakenly assumed it would be possible to just train the developers what mistakes not to make and all would be well with the world. This book was the first step toward fixing that misunderstanding. Dr. McGraw does an excellent job of describing the environment and the practices that are required when implementing secure coding in the lifecycle. But, he's also manage d to prioritize the "touchpoints" so that each can be added in turn to a new development effort rather than requiring any single massive change. Overall and excellent read and good set of guidelines for implementation

Software Security is the best book for learning to integrate security throughout your software development lifecycle. It contains all the security material that is missing from software engineering books. The author understands that your software development lifecycle is different from his, and so focuses on seven touchpoints that can be introduced into any software development lifecycle, instead of attempting to sell you a new lifecycle. He also understands that no matter how important security is to you, you can't change everything about you develop software tomorrow, so he introduces the touchpoints in order of effectiveness based on his extensive consulting experience, starting with tool-assisted code reviews and architectural risk analysis.

If you're a software developer, Software Security is an essential book to have on your shelf, and you'll also want a secure programming book like Secure Programming with Static Analysis (Addison-Wesley Software Security Series) or the author's own Building Secure Software: How to Avoid Security Problems the Right Way.

Software security is a continual process, requiring first an understanding of the issues. To be effective, this understanding and knowledge must then be incorporated into the software development lifecycle including design, coding, testing, and deployment. Several years ago I helped build a security analysis tool for Windows NT, called NtSpectre. We built the tool to analyze the security configuration of servers designed for an online game played for money. The game idea remained simply an idea, but our tool developed a nice cult following, and my understanding of the layers of security and their complexity grew considerably. This experience left me with one main philosophical and practical approach to software
development, and software security specifically-test, neither assume nor guess.

This book puts software security in its place, integral to your software development process. Whether you're agile, extreme, rational, or perhaps teetering at the top of a waterfall, this book will guide you in building security into your methodology. Theory and abstractions aside, Dr. McGraw concretely describes actual, and scarily common, security vulnerabilities he has encountered in the field. He goes on to show that security issues are inherently related to gaps in the development process, and expertly guides you to improvements in that process.

McGraw offers many spot on tips for programmers and software architects to embed security into your products. Perhaps the most cogent is to recognise the difference between bugs and flaws. Bugs are coding errors. Not just those syntactical ones caught by the compiler or interpreter. But also those that compile fine. Flaws, on the other hand, arise from the overall design of the product. In his experience, each represent around 50% of the defects. Hence just trying to debug the bugs will not suffice.

Finding flaws is a subtler, harder task. One better suited for the experienced programmer or architect. Which also tells you that if you are a programmer, and you want to burnish your skills, then moving to finding and fixing flaws is a value-added utility.

Also, from the very definition of a flaw, it implies that you have a design, don't you? Well, if you or your team has bought into the Extreme Programming mindset, then the code is the design. McGraw strongly dumps on the entire XP approach, as being bad for reducing defects.

Amongst the many other interesting issues he raises is one of "ambiguity analysis". Where a group of experienced architects analyses a project design. Each person separately does her own analysis. Then the group assembles and compares these. Invariably, differences will arise. Due perhaps to ambiguities or omissions in the design documentation. This can help indicate flaws.

McGraw's previous books set a very high standard for technical content, relevance and writing clarity. "Building Security In" has raised the bar even higher.

This book is based on years of experience in developing secure software, but what really sets McGraw apart is the clarity of his thinking and the natural, conversational tone of his writing.

I was particularly impressed by the methodical and consistent treatment of all aspects of secure code design, development and validation. McGraw covers the all the territory and with style.

Excellent high-lvel book for anyone involved with software development and implementation. This book digs deep with enough details of security in coding and testing practices and how to avoid security related bugs and vulnerabilities. The book also does well in terms of secure coding, white box and black box testing very well.

Few things where this book falls short "Ignorant" to emerging application landscape and the coding complexities in a multi-platform and application integration environment - J2EE, .NET, XML Web Services and SOA. I am sure, the author will agree on those gaps hopefully we see in the next edition of this book.

The book deserves 5 stars for the concepts + illustrations and 3 stars for those keen on development details for distributed applications.

A required reading for anyone involved with software development and implementation. This book drills-down to security in coding and testing practices and how to avoid security related bugs and vulnerabilities. The concepts illustrated on secure coding, white box and black box testing are excellent. As a developer/architect, I thoroughly enjoyed this book and I suggest to everyone who wants to get started on secure coding and testing practices.

Couple of things I QUIBBLE with are... the book does'nt realize the emerging issues and how-to's for build/refactor security for distributed application proliferation as your it - Portals, Web Services and SOA. The way we develop software is changing, the applications are becoming more pervasive and no-longer contained standalone to a system which makes the built-in security brittle impeding the agile business requirements for application/process orchestration, b2b federation and Web based application mashups. I am sure, the author will realize those gaps in the next edition of this book.

Havingsaid - This book is still a must-read for the budding security developer who wants to focus on secure programming and testing.

What is MISSING - You will not find answers for how you do secure web-centric applications, XML Web services - message-level security, identity federation and other b2b application complexities.