This site graciously hosted
by our friends at
Reader Comments and Reviews
Below is a sampling of some of the reviews we've seen in various media...
They say you should never judge a book by it's cover, but in the case of 'Secure Coding' I'm inclined to make an exception. OK, the front cover picture's never going to make it up onto the wall, but on the back we have glowing recommendations from some very high-profile figures, such as Dr Vinton G. Cerf (co-designer of the TCP/IP protocol) and Dr John J. Hamre (former U.S. Deputy Secretary of Defense).
The authors start by examining a variety of attack types and looking at some of the possible defences. It is illustrated how difficult it is to write a truly secure program, especially in modern systems where multiple components interact. To quote my favourite line from the book; 'In computer security, the sum of the parts is often a hole'. We are shown by real-life examples that this statement is very true.
The next few chapters are structured to follow the typical software development process, from architecture and design, through implementation, then on to deployment, operations, and maintenance.
A very important point which is raised, is that we may never be able to achieve 100% security within the constraints of a particular project, so the aim should actually be to develop applications that are 'just secure enough'. The answer to the question 'How secure is enough?' will be different for each system, and it is at the architecture level that this needs to be addressed. The analysis and engineering practices to answer this question and develop a sound security architecture are looked at in depth, and while at face value much of this can seem obvious, it is (or not, depending on your point of view) sup rising how often such principles are ignored.
Moving on to the implementation phase, we are shown a range of both good and bad practices which can be used as a checklist for developers and code reviewers. Here I would challenge any programmer not to find at least one bad practice that they have at some point been guilty of!
While there are very few listings of source code (wherever possible the book is language agnostic, concentrating on techniques rather than specific implementations), 'Secure Coding' contains numerous case studies both of secure and insecure systems. These are real eye-openers to the range of issues that can occur, and at times it does seem like we are fighting a losing battle. But the examples do have the desired effect of promoting a much more security conscious way of thinking.
I also liked the fact that the authors have managed to keep the book very concise. At less than 200 pages, 'Secure Coding' certainly keeps to the point. Such a wide ranging topic could easily have produced an 800 page monster - the sort of book that looks impressive on a shelf but in reality will never get taken down to read. By producing such a readable text the authors have gone a long way to ensure that people will actually keep the book to hand and refer to the procedures and principles described on a day to day basis.
However, 'Secure Coding' is in no way a panacea - undoubtedly programmers and engineers will read it and still write insecure code. Nor is it a cookbook - it isn't filled with 'cut & paste' recipes that will somehow make your applications resilient to attack. But in this rapidly changing field such an approach would be fundamentally flawed. A testament to this is that a common technique to prevent Ethernet packet sniffing (using switches instead of hubs) was for years assumed to be secure - until of course it was cracked. You never know what's around the corner.
The only realistic way to improve computer security in the longer term is to apply security focused methodologies at each stage in the development cycle. Designers and architects cannot leave security issues to the programmers, and coders cannot assume that the specifications can handle every test case in an appropriate manner. And this is where 'Secure Coding' really scores. Each chapter provides checklists and questions which are applicable to a wide variety of applications and environments, yet specific enough to pick out the security flaws which could very easily be missed.
Whatever area of software development you are involved in, if you are at all concerned with the security of the finished product (and if not, you almost certainly should be!), then you will find 'Secure Coding' to be an essential read.
Some of the reviewers [on Amazon] 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).
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!
Being in the internet security business, I was very interested in the new book Secure Coding from O'Reilly. Especially since, in my job, I see old mistakes being made again and again. Can this book make a change?
My first impression on seeing the book was: 'this is a small book'. It's only about 180 pages. Is that bad? No, but it does mean the topics are not discussed in-depth. For topics that interest you, you should read additional information. The book has many references to books and articles found on the web.
Because topics are not discussed in-depth, it becomes possible to discuss many different topics, and that is where the strength of this book is. It covers not only secure programming, but also secure architecture, secure design, secure implementation, secure testing and secure operation. This by the way is almost the chapter listing.
I would recommend the book to anybody who is involved in designing, programming, testing and operations of systems or applications, both off-the-shelf as well as homebrew applications. The lesson is that security considerations should always be in the back of your mind. You don't need to strive for 100% security (which is impossible) but you should build in enough security from the start. To find out how much is enough, you will need to think about it. The book gives hints about how to do this. It uses many examples from real systems to show possible ways to do things, and also to show some of the common mistakes that are being made.
In practice, designers and programmers who do want to think about security are held back by their bosses as it costs money. The authors show some interesting cost figures that will surely convince your boss to start spending some money on security right away. So this book is recommended read for all.
The most important lesson is one that I try to get across every time I give a security lecture: to protect yourself from attackers, you need to think like one. When designing an application, or a network, think like an attacker and see if you can break into your own creation.
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.
Perfect code may be possible, or it may be a dream, but many of the vulnerabilities that are discovered and exploited on an almost daily basis are the result of easily preventable mistakes in programming. Graff and van Wyk have compiled a masterpiece in Secure Coding Principles and Practices. The book is non-technical and relatively short. The lack of technical solutions providing specific code to fix the problems means that this book has value to everyone and not just to programmers using one specific language. This book discusses the concepts of secure coding and common mistakes from a theoretical point of view including many examples and case studies to illustrate the point. This book is a must read for anyone involved in programming.
This is a surprisingly short book, especially given the propensity of publishers to put out books of 800 pages without hesitation. Do not be fooled by the size. The book is packed with ideas and suggestions to improve the design of secure code. There is no code in the book, one of the reasons for the size. Instead the focus is on thinking before you start coding, something that should be standard procedure.
Unlike the cookbook approach, the authors are up a level or two looking at the software development process itself. They break it down into initial architecture, design, coding and operation -- what is called the waterfall development methodology. The context is important because the process methodology can be a help or hindrance when trying to produce a software application or system. Any general software development methodology will have stages equivalent to requirements, design, code and test. What this the authors add to the mix is what should happen at the various stages to keep the final product secure.
We often hear the mantra that security can not be retrofitted, so here is how it should be fitted in the first place. While the book does not include vulnerabilities per se, there are examples of past vulnerabilities to clarify the consequences of not following security principles at each stage. This is a case of a small item becoming a huge problem later on. On example used as a mouse driver bug. The mouse driver, like any driver, needs privileges, in this to move the mouse around the display screen. The author was focused on making it work -- after all it was just the mouse. Malicious code was written to overflow the numbers which kept track of the position. Oops.
The authors have determined that rapid prototyping is not a good idea for production systems. Instead, real engineering is required. If you do not understand this, reading the book will be helpful. They also deal with the problem of existing applications that perhaps cannot be rewritten or fixed easily. The idea of using wrappers is not new, but it is one of the many suggestions offered throughout the book to improve operations. Wrappers, in general, filter input and access to existing code to prevent insecure code from being attacked. The code for one wrapper is one the few code examples in the book.
Asking questions at the various stages is a key activity when systems of any kind are under development. This seems to be a lost art these days. Sometimes questions are few or not asked at all and sometimes the right questions are not asked. Throughout the book, lists of questions are offered to assist at each phase. While security is not achieved through a checklist, such a list should be an integral part of the development process. Any pilot I know uses a checklist before flying a plane. The list does not fly the plane, but its value is obvious.
The book is a easy and quick read. It was not intended as a deep level technical text. It does provide a number of real world examples that are enlightening and entertaining. The number of books available on secure coding is a small, but growing list. Thankfully, most are worthwhile, even if there are a few flaws here and there. Secure Coding Principles and Practices is a welcome addition to the collection. Definitely recommended reading.
Although it may seem at first as a highly technical book, Secure Coding is definitely not one, as it's meant for a much larger readership. This book aims to clarify the issue of secure coding to a broad audience ranging from academics, software developers, down to executives, project managers, other security professionals and why not, software users. And that's the main advantage of the book: because secure software is a goal that requires all parties to be adequately informed.
As for the primary party, the culprit if you wish - namely the software developer - this book doesn't offer detailed discussions of secure coding issues, but it will certainly produce a higher sense of awareness when coding for the next project. And that's a good start.
Click here to read the full review at the net-security.org website.
The same root cause lies beneath an incredible array of information security vulnerabilities: insecure code. But few developers can confidently claim to be writing secure code, because few developers have ever learned how. In Secure Coding, Mark G. Graff and Ken van Wyk present specific techniques for securing code throughout the entire development lifecycle: architecture, design, implementation, testing, and operations.
A surprising number of vulnerabilities are introduced before one line of code is written, in what the authors call "pure think time." Graff and van Wyk show how to identify potential architectural vulnerabilities and offer practical guidance on applying principles such as "least privilege" -- principles that are more widely recognized than utilized.
Next, you'll learn how to design software that won't be compromised by deliberately flawed input data. You've often heard that security has to be designed in up front, and that's certainly true -- but Graff and van Wyk also show how to retrofit software so that it can resist flawed inputs, even if you can't fix the bugs or access the source code.
In discussing implementation, the authors go beyond conventional coverage, showing how to "sanitize" the character streams that represent a program's entire interface with its environment. You'll learn how to test for security using static code checkers and runtime testing methods; and how to streamline updates to fix flaws found after release.
Traditionally, most developers have focused on solving problems, ignoring the other, malicious uses to which their solutions could be put. Read Secure Coding, and you'll never think about software that way again.
I'm reading Secure Coding: Principles and Practices from O'Reilly and I stumbled on something worth thinking about: should your software fail open or fail closed?
Say you're building a corporate firewall. What happens when it encounters a fatal error and can't figure out what's a good packet and what's a bad packet? Should it shut down and leave the machine open (fail open), or should it just stop evaluating and reject every packet (fail closed)? Arguments could be made for both options.
What if you're building a system to regulate the flow of oxygen to a deep sea submersible? Say the software encounters an error and has to shut down. Without regulation from the software, should the valve stay open or closed?
Think about magnetically controlled doors. Does the magnet hold the bar in the locked position against the tension device trying to unlock it? Or does the magnet hold the bar in the unlocked position, against the tension device trying to lock it? The answer is the difference between whether the door is locked or unlocked on a power failure (assuming the magnet needed power to have force). One answer is good for complete security (lock on power failure), but then what happens to the fire escapes?
Interesting concept . one of those things that hangs around in the back of your mind and never really gets a light shined on it. Good book, too.
As soon as I connect to this website, my computer begins to reboot, a colleague said to me, frustrated.
Ten minutes later, I figured out what was going on, thanks partly due to other people arriving in the office, asking an identical question. The year just gone by was a particularly difficult year for systems administrators due to the prevalence of a number of rather malicious internet worms. Several weeks later, reflecting on these frustrations, I discovered a book that was described in interesting terms.
On the back cover, it was written that, 'Secure Coding sheds light on the economic, psychological and practical reasons why security vulnerabilities are so ubiquitous today'. When received the book, I found a section entitled 'psychological factors'. The section introduction is tantalisingly concluded with the sentence, 'we've seen little in the way of careful thinking about the influence human psychology has on the frequency and nature of security vulnerabilities'. I tend to agree.
Chapters are divided up into parts of the ideal software development cycle. Following the introduction, it begins with architecture, goes on to design, operations and then automation and testing. Numerous case studies pepper these chapters, including a sprinkling of C code for those who are demanding the cryptic.
In the preface, it is stated that the book does not contain 'cookbook examples' of how to write code, instead exploring the issue of security at a higher level. Similarly, it does not cover details about particular platforms, analyses of exploit examples and issues surrounding the design of certain types of applications. Generality is considered to be key.
My favourite chapter is the chapter describing software architecture, specifically a 'security architecture'. It provides a list of things to think about, and then explains each one of them in turn. Whilst I have problems understanding the nebulous use of the word architecture, it seems to fit here - asking you to think about how things should go before going ahead and building.
This slim volume is well referenced. It contains references to our firm favourites, such as Gerald Weinberg's Psychology of Computer Programming, and that well respected favourite about mistakes, Human Error by James Reason. Another favourite that references many PPIG related papers, Code Complete by Steve McConnell, is also recommended reading.
Secure Coding reminds me of (and references) another related book that has been recently published, Writing Solid Code by Steve Maguire, published by Microsoft Press. This is another text that I hope to get around to reading, especially since this book is now considered to be 'required reading' on the Redmond campus.
Whilst the book's title makes an explicit reference to coding, it goes beyond what is normally considered to be coding. Many responsibilities in information technology are divided into artificial roles, such as software engineering and system administration, often for very pragmatic reasons. The authors feel that those who consider themselves as 'coders' should also have an appreciation of some of the topics found within system administration.
Computer programming is not merely about the somewhat simple act of coding. Secure Coding reminds the professional developer about what can go wrong. It reminds the developer to consider the environment in which software executes. It reminds the developer that his or her software may run in an environment that should be considered as hostile.
In one part of the book, the lesson is clear. No matter how well your programming may withstand certain types of programming attacks, all your hard work may be in vain if your system runs on an operating system or network that has not been configured correctly. A programmer or developer needs to know a little about what the systems administrator does and how he or she does it, and conversely a system administrator needs to know what kind of security is likely to be asked for by a programmer.
The advice is clear. Consider risk. Consider how your system generates and reports errors, consider whether an audit trail facility is needed. Consider technical issues and ensure you keep up to date with new releases. Consider thinking like an alien to break through the comprehension paradigm that the software developer has constructed.
Interestingly, Graff and van Wyk's book gives some attention to open source software, and describes a number of incredibly useful tools. If learning about these tools allows software developers and system administrators to effectively resolve a minor network vulnerability, this alone is likely to be worth the cover price.
The more one reads about computer security, the more one begins to feel afraid. We are in a world filled with software jails, buffer overflows, and at the mercy of third party libraries and operating systems comprising millions of lines of code. This distant fear may be similar to how one may feel whilst reading a book about real infectious agents.
Security is a topic that is only occasionally addressed by the psychology of programming community (from attending previous workshops). Security intersects many areas that we have an interest in, notably language design, software development methodology and models of program comprehension. Security is definitely something we need to think about.
Interest (and concerns) regarding software security will, in my view, continue to increase.
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.
Are the numerous security flaws we hear so much about week after week really avoidable? Mark G. Graff and Kenneth R. van Wyk, the authors of Secure Coding: Principles and Practices, believe so. Secure Coding is a fairly quick read that everyone can benefit from, regardless of their role in the development cycle. The book is not oriented towards any specific platform, language, or methodology. It looks at this huge problem the computer industry faces from the development side and leads the reader to a better understanding of the security they can design, build, and implement into an application. Graff and van Wyk show that securing your program is more than just paying close attention to your code. Everyone involved in the development of an application needs a solid understanding of what is really needed. The book provides more than just how-to solutions, it provides a new or more complete vision of the security necessary in today's market.
The authors have three goals for the readers: to understand the holistic nature of an application's security, apply sound security practices, and learn about available resources. The book opens giving the reader a psychological, technical, and practical real-world look at security and the lack thereof. Each chapter then focuses on the security concerns inherent with each phase of the development cycle and ensuring that the application is secure within its environment.
Throughout the book, the authors, both with impressive backgrounds in the computer security field, give insight from years of working with hundreds of systems. Each chapter provides advice, examples, good and bad practices, case studies, and throughts to consider with your own application. Readers can learn from the successes and failures Graff and van Wyk have encountered over the years. I highly recommend this book to anyone involved in the developement process.
This book goes beyond the technical aspects of security into things like psychology, economics, politics, and even history. "Why do good people write bad code?...To find security holes, think like an alien... How do economic and other social factor work against security quality?" These are just some of the things the authors touch on in presenting a holistic view of the security issues that must be dealt with when developing an application.
This is not a "cookbook" so don't expect to find many code examples; the few that you will find are in C. What you will find are a number of thought-provoking discussions and valuable insights into the root causes of security vulnerabilities. The authors share useful techniques, guidelines and checklists that they have used to create applications that are "just secure enough." They highlight both good and bad practices and present a number of case studies to help bring home important points. Managers, architects, designers, developers and even users will find something useful in this book.
This book will help you realize, if you haven't already, that security is neither trivial nor something that you can add on later: it needs to be designed into your application from the very start and continuously evaluated throughout the development process. And if you already knew that, you just might realize just how much more there really is to consider besides what you already do now to secure your applications.
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.
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.
Reviewer: Ben Rothke, CISSP (certified information systems security professional), is a New York City-based senior security consultant with ThruPoint, Inc. He is a member of ASIS International.
One of the most common causes of software vulnerabilities is poor programming practices. Often, developers sacrifice security to add additional features. Although most coders wish to write securely, many do not. At most universities security is not addressed in programming classes. The only training a student may receive is learning how to check input variables. I now understand that more universities are beginning to take software development security more seriously.
For those of us who code at work, or just as a hobby, how can we ensure that we're coding with best security practices? I recently had the pleasure of reading the recent O'Reilly book Secure Coding: Principles & Practices by Mark G. Graff and Kenneth R. van Wyk. Like all O'Reilly books, it is moderately technical and will not bore you with irrelevant narratives. The book weighs in at just over 200 pages and retails for $29.95 USD. I would normally consider this a bit pricy for a small book. However, in this case the information provided is well worth the money. Every serious developer should have a copy. This book is intended for moderately skilled programmers all the way up to expert level.
The best part of the book is that it is written primarily as informational text and theory. It contains very little source code. The authors chose to focus on the practice of secure coding, rather than specific techniques. The information found in this book can provide a strong foundation to the knowledge necessary to begin the secure development process. The beginning of the book provides an introduction to all types of attacks that affect software. Next, a chapter is devoted to secure design including coding steps, issues, and practices to be avoided. The book ends with techniques on how to successfully test software before release. Another valuable part of the book is the case studies provided. Each section contains several real world examples that can help you better understand each concept.
As previously stated, Secure Coding: Principles & Practices is highly recommended. If you have been waiting for the perfect book on secure coding, this may be it!
Judging by the number of security bugs that continue to emerge, a good book about writing secure code is quite timely. The authors of this guide have plenty of experience in trying to produce secure code, and those experiences shine through in the many real-world examples they give and the practical approaches they take in architecture, design, implementation, operations and testing.
This is an excellent book to dip into for ideas to improve coding practices in your organization. It doesn't go into all the technical details, but it does help you make sure that you're asking the right questions. Secure Coding includes a comprehensive bibliography and Web links.
I got this book expecting it to be the usual blur about how to do it or even worse I am the best developer out there & this is how I do it. I was both surprised and pleased when this book turned out to be not only interesting but filled with real world projects and examples of how not to do it or how to do it. All put forward in a pleasurable read not like other dry books that almost bring tears to your eyes through their boredom.
Site Contents Copyright (C) 2002, 2003 Mark G. Graff and Kenneth R. van Wyk. All Rights Reserved.