7 of 8 people found the following review helpful
The best how-to security book,
This review is from: Secure Coding in C and C++ (Paperback)
This is an important book for people that write computer programs and their managers.
It is also very well organized and well written. Seacord reveals how the bad guys take
advantage of bugs in programs to break into a system or damage it. It is the most
complete list of exploitable bug types that I am aware of.
Many examples are given, naming software that have been exploited by bad guys. Some
may protest that this provides the bad guys with a list of easy targets. All of the
vulnerable software has been updated to fix the bug, and the improved version has been
available for a long time.
Everyone that writes software intended to be used by someone else should read this book.
Every organization that writes software should have a copy.
Most of the security flaws are buffer overflows. Secord shows how, from the simple use of
gets() through mistakes triggered by subtle differences in the rules for signed and unsigned
integers of various sizes. There are other ways, and some are quite subtle, but still
preventable. The bad guys are not Jay Leno's "Dumb crooks."
The primary way to frustrate the bad guys is to not have any of the bugs they exploit.
Seacord admits zero bugs is an elusive goal and recommends defense in depth by the use of
various freeware or commercial packages intended to trap or prevent certain errors.
He lists and describes many, with their strengths and weaknesses.
Read this book and make your code better. Read it again, next year.
The following are my opinions, based on over 40 years writing software, but I doubt
Seacord would disagree. Every security bug is also a bug that can cause a crash or a
wrong output from a program. The major cause of fewer bugs is the attitude of the
programmer. Managers can affect the attitude of the programmers by their choice of
questions. Do not ask "Is it done yet?" Instead try approaches like: "Tell me about how
you validated the inputs and how you identified all the inputs." "Who reviewed your test
cases?" "How did you decide you had tested enough?" The fewer bugs of any kind in your
product, the less likely the bad guys are going to target it, other things being equal.