The Business Controls Caddy

Permalink Book Review: Secure Coding - Principles and Practices




There are some books that I believe should be mandatory reading for any person studying computer science, information technology auditing, or some other related fields, and that should also be on the must read lists of any technology professional. I do not often come across a book like this. Secure Coding: Principles and Practices (204 pages , O'Reilly Media, 2003, ISBN 0-596-00242-4) by Mark C. Graff and Kenneth R. van Wyk, however, meets my "must-read" criteria and then some.

Why do I feel this way? The first reason is that the credentials of the authors far exceed those of many other authors I have read. For starters, van Wyk has his engineering degree from Lehigh University, which in some quarters used to be regarded as a far superior engineering schools than Stanford and MIT. As one of the founders of the Computer Emergency Response Team (CERT) at Carnegie Mellon University, van Wyk also served as the Operations Chief of the Defense Information Systems Agency (DISA). Graff, at the time he wrote the book, was the Chief Cyber Security Officer at Lawrence Livermore National Lab and often serves as an Congressional expert witness on Internet security.

When people have credentials such as these, a reader might be afraid to pick up a book like this for fear of being intimidated by the writing of such highly qualified people. But that is the very first surprise of the book: it is written in such a plain-speak fashion with little or no unneeded fluff, that it is extremely easy to grasp their message and see how it would apply to an information technology professional's daily work routine. This is not something easily discounted, as there are many other books out there two to three more pages long that convey less than 50% of what is offered in this book.

The authors follow a very simple and well laid out path in presenting their story. They are up front in saying that if someone claims to be an expert or that they claim they can lock down an application 100%, you should run for the hills (well not exactly in those words). But this extreme is countered with a discussion of why people write bad code, a reason that is often lost on security "experts" and auditors: people are human and respond to the various stimuli in their environment. Nobody likes to write bad code they posit, but sometimes there is not often a choice.
Last year I asked the question ""If you accept the principle of writing code that is "just secure enough" for your own applications, do you think it is socially responsible for software vendors to do the same?" on the blog to see what readers of this site felt. Here is a sampling of some of the responses:

One of the things I've come to realize over the past few years is that there's no such thing as a true computer expert.  There are only computer INsecurity experts.   Someone who says that a particular piece of complex software is "secure" is not an expert, because you can never really know.  Someone who says that a piece of complex software is "secure against all known attack methods" is an expert, because s/he is aware that that is the most that you can ever say authoritatively.  - Richard Schwartz

Definitely NOT (with one exception). Definitely not because just secure enough usually means it is secure enough in "my" current context which is usually very limited due to the number of operating systems, hardware, configurations etc, tested on - even if my current context is a company with several thousand users, because almost all companies are somewhat standardized. The exception is people who define "just secure enough" as "secure to the greatest possible extent" including the outside of their current infrastructure's boundaries. In my opinion this is also one of the major differences between standard and custom tailored software development. - Florian Vogler

If I write down my password in Notepad, and somebody finds it out, I can't really blame Microsoft for Notepad's lack of security, as it was evident before I started using it.  On the other hand, if I use a password system in MS Word to secure a document and find out the password gets stored in plain text in the file, and that is not clearly noted, I have a right to be angry at Microsoft. -  Ben Langhinrichs





As I read more of the book, I felt that these two individuals should be teaching IT audit classes and security audit classes. They are not afraid to point out that policy (and be extension business processes) should drive architecture and design decisions, not the other way around. They do not pull punches in saying that it can be dangerous to over-architect or over-design an application or system. They clearly lay out their arguments in terms that should be familiar to any IT auditor: controls, risk assessments, threats, and more. For IT developers and administrators, there are more than enough examples and discussions so that their points hit home. There are more than enough tips in the book that taught me new ways to approach my coding.

If you are serious about wanting to do the best job possible, regardless of what you do and want value in any resources you purchase. This book is it. In fact, you can download the first chapter in PDF format from O'Reilly (see link below) to get a feel for what I am talking about.

The Business Controls Caddy Scorecard

Double Eagle on a Par 5

Related Links (open in new browser windows)



free html hit counter