
|
|
|
The development group I work with these days is easily the most professional I've ever been part of. We go through analysis, design, and review before starting to code, have automated nightly builds, keep everything under version control, and use a bug-tracking system to ensure that everything found by QA is eventually fixed by developers. There are still occasional late nights and weekends, but by and large, we ship what we've promised to, when we promised to, over and over again.
That said, there are still a lot of things we could be doing better, the most important of which would be to tighten up our coding practices. Many features in legacy languages such as C and C++ encourage sloppy programming: pointers that can be assigned arbitrary values, memory that has to be managed by hand, arrays whose bounds aren't checked, and so on. There are also higher level pitfalls, such as assuming that data is in canonical form, or not setting the tightest possible security restrictions on files, operating system handles, and other resources. Most of these things are simple enough to do, once programmers know to do them. The problem is in finding out what ought to be done.
Michael Howard and David LeBlanc's new book, Writing Secure Code, is a very good guide to both what and how for the Windows platform. Its 477 pages describe common security problems, analyze them, and explain appropriate remedies. Along the way, the authors also show how security analysis itself works (i.e. how to go through your product systematically to find weaknesses before the guys in black hats do).
Material is organized into four sections: "Contemporary Security," "Secure Coding Techniques," "Network-Based Application Considerations" (which I learned the most from), and "Special Topics," including .NET, testing, and installation. The writing is clear throughout, although in a few places it was a little too obvious that the authors both actually work for Microsoft. The examples are clear too, or at least as clear as they can be, given the intrinsic complexity of the topic, and the accidental complexity of the Windows security APIs. With a little more critical appraisal, and some coverage of UNIX, this book would qualify as a classic.
|
-- Gregory V. Wilson (gvwilson@ddj.com) |
From Byte On-Line, May 6, 2002 |