What This Book Is About

This book presents a coherent and detailed approach for putting software security into practice. Through the unification of proactive design and careful exploit-driven testing built on a foundation of risk management, Software Security explains in detail how to properly address software-induced security risk.

The book is divided into three parts. Part I, Software Security Fundamentals, is an updated introduction to the field of software security. Readers of Building Secure Software and Exploiting Software will find themselves in familiar territory here, though the treatment of the problem has been updated with new numbers.

Chapter 1, Defining a Discipline, begins with an in-depth description of the computer security problem and explains why broken software lies at its heart. This may be old news to some, but the trinity of troubleconnectivity, extensibility, and complexitydeeply impacts software as much as ever. Software is everywhere and is the lifeblood of business and society. Software security is relevant to the kind of software found in your phone, your car, and your washing machine (not to mention your computer and the Web-based applications it makes available to you). For this reason, a critical distinction is drawn between application security and software security. This book is about making all software behave, and how to do this in light of modern security demands. The most important material in Chapter 1 is the introduction of the three pillars of software security: applied risk management, software security best practices (touchpoints), and knowledge. Each of the three pillars is a necessity for software security.

Chapter 2, A Risk Management Framework, describes my philosophy of risk management and how to put it into practice. All too often in computer security, risk management is paid only lip service. We know we're supposed to be doing it, but nobody ever says how. Chapter 2 fixes that. A continuous risk management framework encompasses identifying, synthesizing, ranking, and keeping track of risks throughout software development. Only by practicing risk management and factoring in critical business information about impact will software security begin to enjoy the business relevance it deserves.

Part II of this book, Seven Touchpoints for Software Security, is devoted to software security best practices. The touchpoints are one of the three pillars of software security. Attaining software security may not be easy, but it doesn't have to be a burden. By describing a manageably small set of touchpoints based around the software artifacts you already produce, I avoid religious warfare over process and get on with the business of software security. You don't have to adopt all seven touchpoints to begin to build security in (though doing so is highly recommended). The figure on the inside front cover of the book shows the seven touchpoints ordered according to effectiveness and importance. The touchpoints are designed to fill the gap between the state of the art and the state of the practicesomething that can be done only through the common adoption of best practices.

Touchpoints are a mix of destructive and constructive activities. Destructive activities are about attacks, exploits, and breaking software. These kinds of things are represented by the black hat (offense). Constructive activities are about design, defense, and functionality. These are represented by the white hat (defense). Both hats are necessary.

Chapter 3, Introduction to Software Security Touchpoints, provides a flyover of the touchpoints and discusses the critical idea of pushing security as early into the software lifecycle as possible (mostly to save money). I also discuss who should practice software security and how to build a software security group.

Chapter 4, Code Review with a Tool, is about one of the two most important software security best practices. Though not all software projects produce specifications, or even properly document requirements, they all produce code. Bugs (simple implementation errors in code) are responsible for 50% of all software security problems, so finding and fixing security-critical bugs at the code level is essential. Automated code review is a white hat (constructive) activity informed by a black hat history of known defects and exploits. The idea is to avoid implementation problems while we build software to be secure. Code review for security has come a long way in the last few years, and commercial tools are now mature enough to be put in use by all software practitioners. This chapter describes how.

The best practice described in Chapter 5, Architectural Risk Analysis, is just as important as code review. Flaws (architectural and design-level problems) are responsible for the other 50% of all software security problems. Unfortunately, identifying security flaws is more difficult than looking for bugs in code. This is partly because many software projects have only the most rudimentary handle on software architecture, and it's partly because finding software security flaws requires expertise and experience. Architectural risk analysis is a white hat (constructive) activity also informed by a black hat history of known defects and exploits. In this case, we work to avoid design flaws while we build software to be secure. Chapter 5 also describes a mature process for risk analysis developed over the last ten years at Cigital.

Chapter 6, Software Penetration Testing, covers a very common but often misapplied software security best practice. All too often, penetration testing devolves into a feel-good security activity: Security consultants are hired to "hack into" an application, and they almost always find a serious hole (usually in the configuration of the network or the commercial off-the-shelf products the application is built on). The hole gets fixed, and everyone declares security victory and goes home. Usually the developers don't learn anything profound (since the problems found tend to be operational in nature), and worst of all, no real understanding of wholesale software security risk is gained. Penetration testing is a black hat (destructive) activity. The best kind of penetration testing is informed by white hat knowledge of design and risk; but all the penetration testing in the world will not build you secure software. In Chapter 6, I describe an enhanced approach to penetration testing that takes an insideout approach to testing as opposed to strictly outsidein. This makes penetration testing much more useful.

Chapter 7, Risk-Based Security Testing, is very similar in philosophy to Chapter 6. I discuss an approach to test planning and test execution that is directly aligned to risk analysis results coming out of an architectural risk analysis. I introduce a real-world case study. Risk-based security testing is a mix of constructive and destructive activities that requires a holistic black-and-white approach. Risk-based security testing is driven by abuse cases and risk analysis results.

Chapter 8, Abuse Cases, covers just that. Software security requires the ability to "think like an attacker." Abuse cases help to formalize this activity. Abuse case development is based on understanding and applying known attack patterns and also thinking about anti-requirements. A simple process is introduced to make adoption of abuse cases easier. Abuse cases are tricky. You might guess by the name that abuse cases involve only black hat (destructive) activities. That would be wrong. Abuse cases are themselves driven by the two threads. White hat thinking (constructive) drives security requirements, which are a necessary foundation for a goodly percentage of the abuse cases. Black hat thinking in the form of attack patterns drives the remaining portion. Although abuse cases clearly involve a mix of both black and white hats, the black hat is predominant.

Software security can benefit greatly from experience gained by practicing network security. Chapter 9, Software Security Meets Security Operations, describes how network security professionals can get involved in carrying out the touchpoints, providing experience and security wisdom that might otherwise be missing from the development team. Operations is a white hat activity, but it is only very weakly constructive. Operations is essential to security, of course, but in terms of building security in, the day-to-day tactics carried out by ops people are largely defensive.

Part III, Software Security Grows Up, contains a far-ranging treatment of essential software security knowledge and of large-scale software security programs.

Chapter 10, An Enterprise Software Security Program, describes an approach to the kind of cultural change required to adopt software security in a large organization. Because of this, Chapter 10 is the most business-oriented of the chapters in Software Security. There is little doubt that adopting software security touchpoints in a development organization that is running 100 miles an hour is like fixing your engine while your car is zooming down the highway, but it is possible. This chapter draws on years of experience at Cigital, helping large companies implement software security programs. A completely integrated Secure Development Lifecycle (SDL) is the result of combining your existing approach to software development with the software security touchpoints.

Chapter 11, Knowledge for Software Security, describes one of the three pillars. This chapter presents a taxonomy of seven knowledge catalogs useful to practitioners: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks. These knowledge catalogs are directly applicable throughout the software development lifecycle when you put the security touchpoints into action.

Chapter 12, A Taxonomy of Coding Errors, introduces a classification of common software security bugs. My goal is to make the taxonomy as simple as possible, but still fundamentally useful. Though there are literally hundreds of potential coding problems that can lead to security problems, I find that they fit very nicely into seven "kingdoms." This work hints at the coming maturity of software security, where science and technology begins to dominate over intuition and raw intelligence.

Finally, Chapter 13, Annotated Bibliography and References, has three parts: a list of the top five readings in software security, a complete list of references from this book, and a list of other important references. Each entry includes a sentence or two describing what I find valuable or useful about the reference.

Four appendices round out Software Security. Appendix A is a tutorial accompanying the CD that comes with this book. The CD introduces Fortify Software's Source Code Analysis Suite. Appendix B is a very basic list of coding rules from the early source code analysis tool, ITS4. This list serves two purposes. First, a glance through the list will expose you to the somewhat large pile of things that can go wrong in C (at the code level). Second, all source code analysis tools for security must make sure to cover this list. Publishing the list widely makes it more likely they will. Appendix C is an exercise in architectural risk analysis featuring the Smurfs. What more could you want? Finally, Appendix D is a very small glossary of terms.

Icons

The three icons used throughout this book are meant to help you navigate the waters of software security. The icons demarcate material in large sections of the book (chapters and parts).

Fundamental material is covered under this icon (which also adorns the cover of the book). The yin/yang design is the classic Eastern symbol used to describe the inextricable mixing of standard Western polemics (black/white, good/evil, heaven/hell, create/destroy, and so on). Eastern philosophies are described as holistic because they teach that reality combines polemics in such a way that one pole cannot be sundered from the other. In the case of software security, two distinct threadsblack hat activities and white hat activities (offense/defense, construction/destruction)intertwine to make up software security. A holistic approach, combining yin and yang (mixing black hat and white hat approaches), is required.

The three pillars of software security are applied risk management (Chapter 2), software security touchpoints (Part II), and knowledge (Chapter 11). Each of these major sections is marked with the pillar icon.

Seven best practices, the software security touchpoints, are introduced and discussed at length in the heart of Software Security. The touchpoints collectively make up one of the three pillars. Each touchpoint chapter is branded with the touchpoint icon.