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.

Average Customer Review: ( 19 customer reviews )
Write an online review and share your thoughts with other customers.

This book teaches you how to *think* about security, how to think about and *design* code that will be secure. It isn't a "add this snippit of code to your input buffer validation function" sort of book. There are many of these books, and they're useful in their place, but this book writes about the design of secure code, not the actual specifics.

To continue the cooking analogy, this is a book on how to write receipes, not a book *of* receipes.

Disclaimer, I helped review this book - and I think it's the sort of work that has been sorely missing in the field (I was also given a free copy for doing the review work).

Jeremy Allison,
Samba Team.

20 of 21 found the following review helpful:

Holistic SecurityNov 29, 2003
By Brad Friedlander
In the 11th century, Moses Maimonides taught us that the highest form of charity is to teach a man to fish. If you give him a fish, he can eat today. If you teach him to fish he can eat forever.

In the same way, Mark G. Graff and Kenneth R. van Wyk have provided an excellent book that gives us a framework for thinking about security rather than trying to give specific rules that might have been invalid before the book came off the press. "Secure Coding" gives the reader the ability to envision, architect, design, code, and implement a security framework that truly meets the needs of its stakeholders.

The authors don't provide a cookbook. In their own words: "When you picked up this book, perhaps you thought that we could provide certain security? Sadly, no one can."

Instead, they deliver a robust mental model and a framework to understand security and to architect, design, develop, and operate secure systems. They present best practices in the field of security, the reasons for using them, and suggestions on deciding which practices are appropriate in your particular case.

Their approach is to realize that the objective is not to make a system totally secure, but to make it just secure enough. Deciding what is "just secure enough" is a business and not a technical decision. It is based on weighing risk versus cost.

There are substantial references throughout the book as well as an appendix of resources. The book is filled with examples of security failures and, more importantly, an excellent post mortem on each to show what could have been done to avoid the problem. The authors are extremely familiar with UNIX environments and this comes through in the examples. However, you don't need to be a UNIX guru to glean valuable lessons from the examples.

One key message is that security is not something you can bolt onto an application. You must take a holistic approach to the overall system in which the application is being used. It's worth noting that many secure applications become extremely insecure because of the system environment (including networks) in which they exist.

A second key message is that, while you can retrofit a insecure application, it is far easier and far less costly to incorporate security as an integral part of the entire development life-cycle including requirements, architecture, and design. The security architecture and design must be well-documented so that future maintenance does not inadvertently introduce gaping security holes.

The book is primarily intended for those who architect, design, and code secure applications. However, I believe that it is a must read for those who manage and those who implement secure applications and systems.

21 of 23 found the following review helpful:

A good step in the right directionOct 08, 2003
By wiredweird "wiredweird"
You may have a hi-tech lock on your door, 100% unpickable. If I can just slam my shoulder against the door and jerk it loose from the frame, the fancy lock is irrelevant.

Passwords, encryption, and all the rest are the lock. This book is more about making the door and frame strong. Remember the Blaster worm? That wasn't a 'security' problem. It exploited bugs in Windows that supposedly had nothing to do with security.

This book is about building programs that resist attack. That doesn't mean copying a safe code fragment into your program and declaring it safe - that idea is ludicrous. Instead, this book is about the process that designs and implements strong programs. It starts with architecture and design documents, then follows through to design and maintenance.

The weakness of this book is lack of detail - how to build fail-safe code, what needs to be on design and inspection checklists, etc. There's good reason for that: each sub-topic needs books, if not whole libraries of its own. Take fault tolerance, for example. It may not sound like security, but an attack is meant to cause system failures, and fault tolerance is design to withstand failures. Fault tolerance is a huge topic, with journals and literature all its own. This book can barely mention the idea, while still giving other topics their due. It's a start, though.

Much of the advice may sound drearily familiar: code reviews, security audits, configuration control, error checking, and all the other things that take the 'fun' out of programming. If people want that kind of 'fun', then stop calling them software engineers. They're not ready for adult responsibilities.

Before anything else, software security requires correct behavior from a program. I really hope I don't hear objections to that as a basic design goal.

13 of 14 found the following review helpful:

Just plain goodJan 28, 2004
By Richard Barrell
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!

13 of 14 found the following review helpful:

If you manage coders, read this bookAug 11, 2003
By Stephen Northcutt
In information security there are books about things and books on how to do things, this is a book *about* things.

Secure coding doesn't tell you how to write secure code, the purpose is to you a clear understanding of the enviornment needed to ensure application development is being done in a sane and robust way.

I was a bit nervous when one of the authors asked me to do a review of this book; I had just finished reviewing Inside Java, a masterpiece, but a tough read with a code example on every other page. Secure Coding is almost the polar opposite. There are only a couple examples of actual code. Instead the book weighs in at less than 200 content pages and is very approachable.

If you are responsible for managing software developers, then you should buy this book, read this book and make certain you understand what it teaches! This will prepare you for serious discussions with your coders and give you the questions to ask to ensure they are using good practice.

See all 19 customer reviews on Amazon.com