Customer Reviews

Software Security Engineering: A Guide for Project Managers

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

 

 

The Addison-Wesley Software Security Series is generally a great collection, with titles like Software Security: Building Security In (my rating: 5 stars), Rootkits: Subverting the Windows Kernel (my rating: 4 stars), and Exploiting Software: How to Break Code (my rating: 4 stars). I particularly liked the first of those three (SS:BSI), which I reviewed last year. I felt Gary McGraw wrote "a powerful book with deep truths for secure development." Software Security Engineering (SSE), by a collection of authors, pales in comparison to SS:BSI. You can skip SSE and stick with SS:BSI.

I started reading SSE very closely, underlining key concepts and looking for important ideas. About halfway through the book I realized it was mainly a collection of ideas from other sources. Very rarely do I read books that successfully present a dozen approaches to the same problem. What usually happens (as is the case with SSE) is the reader is left reading overlapping material and fragmented points of view. Frequently I found myself wondering "so what am I supposed to do with this? Where do I start? What approach matters?"

It is especially problematic when a book contains articles essentially republished from magazines. Each article author needs to frame the problem to make sense for the short period during which he has the attention of the reader. That works for a stand-alone article, but it doesn't work when all of these previously stand-alone articles are collected in one book. I can accept a book published as a series of independent works, with an editor overseeing the affair. I can't accept a book published as a single work, with magazine articles inserted at various intervals. It's incoherent and confusing.

Still, I found a few ideas interesting. Page 79 (a reprint of a 2004 IEEE article) says "Security is an emergent property of a system, not a feature. This is similar to how 'being dry' is an emergent property of being inside a tent in the rain. The tent keeps people dry only if the poles are stabilized, vertical, able to support the weight of wet fabric, and so on. Likewise, the tent must have waterproof fabric that has no holes and is large enough to protect all the people who want to stay dry. Lastly, all the people who want to be dry must remain under the tent the entire time it is raining. Whereas it is important to have poles and fabric, it is not enough to say, 'The tent has poles and fabric, thus it keeps you dry!'"

Page 73 (a reprint of a 2006 Build Security In article) says "When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access."

Page 59 (another reprint of a 2006 BSI article) says "Software can be designed and developed to be extremely secure, but if it is deployed and operated in an insecure fashion many vulnerabilities can be introduced. For example, a piece of software could provide strong encryption and proper authentication before allowing access to encrypted data, but if an attacker can obtain valid authentication credentials he/she can subvert the software's security. Nothing is 100 percent secure, and the environment must be secured and monitored to thwart attacks."

Pages 39-40 say "In software systems that include acquired or reused (commercial, government off-the-shelf, open-source, shareware, freeware, or legacy) binary components, application defense techniques and tools may be the only cost-effective countermeasures to mitigate vulnerabilities in those components."

Page 35 says "Maliciousness... makes the requirements of software security somewhat different from the requirements of safety and reliability. Failures in a reliability or safety context are expected to be random and unpredictable. Failures in a security context, by contrast, result from human effort (direct, or through malicious code)."

If you want to read a good overall book on software security, read McGraw's SS:BSI.

"Software Security Engineering" is an extremely broad overview of software security engineering practices. The first two chapters deal with defining why software security is an important topic and characterizing general attributes of secure software. The middle of the book highlights the software development lifecycle including requirements, architecture, design, coding, and testing. The book concludes with integration issues, governance, and a getting started guide.

A project manager new to the concepts of software security engineering would likely find the book to be a good overview for understanding the tasks and practices that should be implemented on a secure software development effort. It provides just enough information to be able to accurately assess if development efforts are on target and on track. From the opposite perspective, a software security engineer might find the book a useful tool to convince a recalcitrant project manager of the necessity of certain tasks and activities during the development process.

The experienced security software engineer will not find much of practical use in the material covered. The authors are coming primarily from the perspective of process maturity models, and the material is fairly thin on implementation details. It does, however, provide an overview of considerations for developing secure software, and it can be used as a pointer to other sources and materials referenced in the book, which the software engineer will find useful.

The book includes several reprints from IEEE Security & Privacy magazine, and these contained some interesting and novel ideas. A prime example is the concept of "Misuse and Abuse Cases" in which abnormal and malicious behavior from actors in the system is anticipated and documented. This is a new and unique aspect on traditional requirements engineering Use Cases.

"Software Security Engineering" is a highly credible book produced by a panel of highly regarded software security researchers and consultants. It is highly recommended for project managers new to software security engineering concepts, or as a general high level reference for experienced secure software developers.

Ideal for people who are discovering topics of apps security ... and of course for software developers