C. Warren Axelrod

The Quest for Secure and Resilient Software

Secure and Resilient Software Development (CRC Press, 2010) by Mark Merkow and Laksh Raghavan is a really good book. It addresses a key security area that is generally given short shrift, even though purportedly more than 70 percent of breaches result from attacks on the application layer. The book is one of only a handful of texts about information security written by practitioners for practitioners.  Even fewer practitioner books address software security … and most of those have been written or co-authored by Mark! The majority of publications in the field of software security are written by academics or vendors’ employees, both of whom have their own agenda. That of the former group is dominated by publishing or perishing; whereas the latter generally promote particular products or methodologies supplied by the vendors. The true value of Mark and Laksh’s book is that it is both impartial and extremely informative.

I have known Mark for quite a few years through our joint work at FSSCC, BITS, FSTC, FS-ISAC and other financial services industry groups – all these organizations are mentioned in the book. I met Laksh at the 2010 RSA Conference. Both are with PayPal, which is known for its sophisticated, leading-edge approach to security.

The book is comprehensive. It covers areas with which most infosec professionals and software developers are not likely to be familiar. For example, the authors recount the history of application security testing as far back as to the Orange Book and Common Criteria (CC). Incidentally, Mark co-authored an excellent book on the CC, namely “Computer Security Assurance Using The Common Criteria” (Thomson, 2005). In the current book, issues with the CC approach are raised … and by someone who should know!

Among the many useful chapters, I personally derived the most from Chapters 8 and 9, which are about testing custom applications and commercial-off-the-shelf software respectively. But that is because I managed a project for BITS/FSTC on software assurance for financial firms, which is actually mentioned on page 210. I also was interested in reading Chapter 11 on metrics and maturity models. I found the coverage to be extensive, although I have my own opinions regarding the lack of meaningful metrics for security in general and application security in particular.

I suspect, however, that many readers will be more interested in the design and coding phases of the SDLC (software development life cycle), rather than the testing stage. And these readers will not be disappointed. It was encouraging to see that resiliency is given top billing, as it is often neglected by developers, although software engineers might well see the importance of building resilient systems. To illustrate my own recognition of the importance of resiliency, I recently published an article “Investing in Software Resiliency” in the September/October issue of Crosstalk magazine, which is available at http://www.stsc.hill.af.mil/crosstalk/2009/09/0909axelrod.html

Having given the reader a taste of what he or she needs to know in order to produce or acquire secure and resilient software, the authors point the reader to sources of further education, including the various certifications that can be earned.

The book is rounded out with a very helpful glossary of terms, and a couple of appendices. The first covers the top 25 most dangerous programming errors (according to CWE/SANS), and the second describes OWASP’s Enterprise Security API project.

All in all this is a book packed with valuable information for those designing, developing or supporting secure and resilient software. It is full of useful and actionable suggestions. And it fills a gap that really needed filling. It gives the reader a sound grounding and good understanding of the issues relating to the development of secure and resilient software and points the reader in the right direction for building further upon the base established by the book.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*