Customer Reviews

Secure Coding: Principles and Practices

5 star:		(15)
4 star:		(1)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

Some of the reviewers here are missing the point of this book. It's not a "secure code cookbook" in that it doesn't give specific code examples. Such things are quickly obsolete anyway.

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.

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.

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.

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!

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.

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.

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

Ken and Mark have written the playbook for writing secure code. The book focuses on security principles and doesn't use complicated code-based examples to explain these essential security practices. The authors use very easy-to-understand examples that help to illustrate the security principles they discuss.

Step-by-step, they take readers through the levels of security from the initial architecture right through to the QA process. These practices and examples are not the product of reading what someone else wrote and regurgitating it in another form (as so often security publications are these days) but rather the product of experience, and mistakes. That is truly where this book's value rests.

This book is truly a triumph in security. With a combination of good examples and well thought-out text, this book is a must read.

My only criticism of the book is that people might dismiss it as a coder's guide books by the title. The book is not just for coders, its for anyone involved in anyway with computer security.

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.

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."