Practically every day, we read about a new type of attack on computer systems and networks. Viruses, worms, denials of service, and password sniffers are attacking all types of systems -- from banks to major e-commerce sites to seemingly impregnable government and military computers --at an alarming rate. Despite their myriad manifestations and different targets, nearly all attacks have one fundamental cause: the code used to run far too many systems today is not secure. Flaws in its design, implementation, testing, and operations allow attackers all-too-easy access. Secure Coding, by Mark G. Graff and Ken vanWyk, looks at the problem of bad code in a new way. Packed with advice based on the authors' decades of experience in the computer security field, this concise and highly readable book explains why so much code today is filled with vulnerabilities, and tells readers what they must do to avoid writing code that can be exploited by attackers. Writing secure code isn't easy, and there are no quick fixes to bad code. To build code that repels attack, readers need to be vigilant through each stage of the entire code lifecycle:

• Architecture: during this stage, applying security principles such as "least privilege" will help limit even the impact of successful attempts to subvert software.

• Design: during this stage, designers must determine how programs will behave when confronted with fatally flawed input data. The book also offers advice about performing security retrofitting when you don't have the source code -- ways of protecting software from being exploited even if bugs can't be fixed.

• Implementation: during this stage, programmers must sanitize all program input (the character streams representing a programs' entire interface with its environment -- not just the command lines and environment variables that are the focus of most security analysis).

• Testing: during this stage, programs must be checked using both static code checkers and runtime testing methods -- for example, the fault injection systems now available to check for the presence of such flaws as buffer overflow.

• Operations: during this stage, patch updates must be installed in a timely fashion. In early 2003, sites that had diligently applied Microsoft SQL Server updates were spared the impact of the Slammer worm that did serious damage to thousands of systems.

Beyond the technical, Secure Coding sheds new light on the economic, psychological, and sheer practical reasons why security vulnerabilities are so ubiquitous today. It presents a new way of thinking about these vulnerabilities and ways that developers can compensate for the factors that have produced such unsecured software in the past. It issues a challenge to all those concerned about computer security to finally make a commitment to building code the right way.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 16 Ratings

Required reading for programmers serious about security - 2004-01-02
Reviewer Rating:
In the movie Seabiscuit, the titular racehorse doesn't appear on screen until almost an hour into the movie. Nevertheless, the wait is worth it, and the movie was a blockbuster. While no one would confuse this uplifting Depression-era tale with a book on computer code, Secure Coding shares a basic similarity with Seabiscuit: The former doesn't trot out its subject--an actual piece of software code--until page 76, and the result is outstanding nonetheless.

The similarity ends there. While moviegoers eagerly awaited Seabiscuit's appearance, security professionals might well dread the first appearance of code. Refreshingly, the book contains only seven pages of software code.

Similarly themed books spend most of their time in the nitty-gritty of actual code. This one is a horse of a different color, dealing with what needs to be done before the first line of software code is actually written. With the goal of helping developers create applications that are resilient against attacks, the authors develop the book around three categories of software development: architecture and design, implementation, and operations.

Above and beyond technical aspects of software development, the authors describe how serious security vulnerabilities leak into the software-development process. These include ignorance, psychological issues, and the short time spans allotted to the development process.

This book is a sure bet to help developers and project managers create secure software applications without bogging down in specific code.

Just plain good - 2004-01-28
Reviewer Rating:
My job is fixing security vulnerabilities in applications.

This book offers a great description of how to creat applications that don't need fixing. It should be required reading for anyone involved in the world of software creation - from management to coders.

The content is well explained, engaging and clearly written.

A good job well done!

"Secure Coding" Should Be THE BIBLE For IT Professionals - 2005-07-13
Reviewer Rating:
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.

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 Scorecard

Double Eagle on a Par 5

much-needed and indispensable - 2004-02-08
Reviewer Rating:
This is an excellent book that should be read by all software developers, script writers, system administrators, application designers, and system maintainers. The book is short, to-the-point, and hits the important points as well as giving numerous real-world examples. It is easy to read, and not dependent on any specific software life cycle model or methodology--though it brings home the point that if you aren't following such a process, you'd do well to implement one. This is a must-read and must-refer-to book that no organization that uses customized software or develops software in-house should be
without.

Looking to get started with Software Security? Start Here. - 2007-02-14
Reviewer Rating:
When my clients are starting down the road to software security and ask me what book is the best starting place, this is the one I recommend.

The hardest thing about software security is that in most organizations no one person or group really owns it. So you have this dichotomy where software people don't really have the requisite security knowledge, and security people don't really understand all the details of software development. It is difficult to navigate the terrain in between these domains, in a way that is specific enough to understandable and actionable, without overwhelming the reader from one background or the other. This is what makes Seucre Coding such a great starting point.

Chapter 1 hits a number of important software security issues, and most importantly for software developers, provides an intro to thinking about the software design from the attacker's point of view. The authors also hit an extremely important point on composition, quoting an expert bridge player saying "No one made any mistakes. Only the result was ridiculous." The fact that most OO and distributed systems are built on composition, is a major issue in security because security mechanisms and protocols are generally not composeable.

Chapters 2 and 3 examine security architecture and design, this is generally where the most egregious issues come into play. As with the majority of the book, there are actionable steps laid out to help you incorporate the secure coding principles the authors describe. And the authors detail a good balance of what to do and what not to do. Too many security books only address the latter.

Chapters 4,5, and 6 look at the remainder of the development lifecycle, defining practical ways to integrate security into software implementation, testing, and operations. What is most valuable in the author's approach is that a top down methodology is not required on the part of the enterprise to begin down the software security path. The authors do describe some top down techniques, but each and every phase described in the book contains numerous actions that enterprises can adopt with little to no cost. For example, the implementation chapter looks at peer reviews and checklists for secure coding, and the operations chapter looks at specific ways to implement security event logging, there is effectively a very low barrier to entry for organizations to deploy any number of the concepts described in this book.

This book does not contain the nth layer of every major security design decision you need to make, but it is a great place to begin the journey. Quoting Martin Fowler "comprehensiveness is the enemy of comprehensibility."

Browse Similar Topics

Top Level Categories:
Computer Science
Networking
Security

Sub-Categories:
Computer Science > Coding
Networking > Security
Security > Operating Systems