- Amazon Student members save an additional 10% on Textbooks with promo code TEXTBOOK10. Enter code TEXTBOOK10 at checkout. Here's how (restrictions apply)
Software Security: Building Security In Paperback – Jan 23 2006
Special Offers and Product Promotions
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
"Overall, I rekon this was the best new security book I've seen this year. It certainly made me think more than any other security book I've read recently. I'd consider it a must-buy for the serious practitioner."--Ross Anderson, Professor of Security Engineering, University of Cambridge Computer Laboratory
From the Inside Flap
Software security has come a long way in the last few years, but we've really only just begun. Software security is the practice of building software to be secure and to function properly under malicious attack. The underlying concepts behind Software Security have developed over almost a decade, and were first described in Building Secure Software (Viega and McGraw) and Exploiting Software (Hoglund and McGraw). This book begins where its predecessors left off, describing in detail how to put software security into practice.
After completing Java Security (McGraw and Felten) in 1996 and following it up with Securing Java (McGraw and Felten) in 1999, I began wondering how it was that such excellent designers, engineers, and architects went astray when it came to security. What was it about software that made security such a problem? If you wanted to build secure software, how would you do it? These questions and the perseverance of John Viega led to Building Secure Software.
Building Secure Software (BSS), the white hat book, seems to have touched off a revolution. Security people who once relied solely on firewalls, intrusion detection, and anti-virus mechanisms came to understand and embrace the necessity of better software. BSS provides a coherent and sensible philosophical foundation for the blossoming field of software security.
Exploiting Software (ES), the black hat book, provides a much needed balance, teaching about how to break software and how malicious hackers write exploits. ES is meant as a reality check for software security, ensuring that the good guys address real attacks and invent and peddle solutions that actually work. The two books are in some sense mirror images.
Software Security unifies the two sides of software security--attack and defense, exploiting and designing, breaking and building--into a coherent whole. Like the yin and the yang, software security requires a careful balance.Who this Book is For
Software Security is a "how to" book for software security. In most organizations, software security is nobody's job, when software security really should be everyone's job. Hopefully this book will help explain both why this is so and what to do about it.
The number one audience for the book is software security professionals. If your job is to analyze software for security problems, you will find this book filled to the brim with ideas and processes that you can apply today. Software security professionals should seek to use each of the touchpoints throughout the software lifecycle, following a risk management framework, and calling on software security knowledge. If you're a software security person, I'm afraid you'll have to read the whole book.
As computer security evolves, the job of security analysis gets more complicated. Computer security professionals will benefit greatly from Chapters 1, 2, and 9. Chapter 1 provides a discussion of the software security problem and can help in justifying attention to software security. As philosophy in action, the risk management framework of Chapter 2 is directly applicable to computer security, regardless of software. Chapter 9 in particular was written for computer security professionals who may not necessarily know all that much about software. Turns out there is plenty for operational security people to do to enhance and support software security. We need your help.
Software developers and architects almost always enjoy learning new things. Hopefully, the lessons of Software Security will find their way into many a development shop. Software people will probably benefit most from the description of code review and architectural risk analysis in Chapters 4 and 5 as well as the taxonomy of coding errors described in Chapter 12. Of course, all of the best practices described in this book are designed to be directly applicable by those at the rock face (Part II), so benefit should be derived from each chapter in Part II. If you're a coder and you've ever wondered what to do about software security other than wring your hands, this book will give you some concrete ideas. Also note that the chapters in Part II include a feature called "Coder's Corner" that was written with developers in mind.
Business people and technical managers may be surprised that we geeks don't have as much of a handle on the security problem as we should. Business leadership will benefit from Part I of the book, though it may make you sleep a little less soundly. Risk management comes naturally to business executives, and putting in place a risk management framework as described in Chapter 2 is very valuable (and can yield useful metrics to boot). Chapter 10 should also prove valuable, especially to upper management worrying about how to transform an organization so that it produces good solid, secure software.
Academics and researchers will probably appreciate Chapter 12 the most, though I am sure to be flamed to a crisp by some professor or other. Useful to new scientists is the annotated bibliography. I would hope that each of the best practices (which I call touchpoints) provides enough in the way of open questions to spark many a research program.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 Basics, 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 trouble--connectivity, extensibility, and complexity--deeply 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 (called 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 the 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 that 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 back 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 practice--something that can only be done by 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 the kinds of things represented by the white hat. 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 describes a mature process for risk analysis developed over the last ten years at Cigital.
Software Penetration Testing is the subject of Chapter 6. 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 COTS 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 inside→out approach to testing as opposed to strictly outside→in. 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 is about Abuse Cases. 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. Though 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 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, is a far ranging treatment of essential software security knowledge and 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 about 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 describes one of the three pillars, Knowledge for Software Security. This chapter presents a taxonomy of seven knowledge catalogs useful to practitioners. These include: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks. These knowledge catalogs are directly applicable throughout the software development life cycle when you put the security touchpoints into action.
Chapter 12, A Taxonomy of Coding Errors, introduces a taxonomy 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 presents an Annotated Bibliography and References. There are three parts to this chapter, 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 off, 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). Secondly, all source code analysis tools for security must make sure to cover this list. Publishing the list widely makes it more likely that 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.
0321356705P10212005 See all Product Description
Most Helpful Customer Reviews on Amazon.com (beta)
Gary McGraw's book gets my vote as the best of the six because it made the biggest impact on the way I look at the software security problem. First, Gary emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). He shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. Gary applauds the diversity of backgrounds found in today's security professionals, but wonders what will happen when this rag-tag bunch (myself included) is eventually replaced by "formally" trained college security graduates.
Second, Gary explains that although tools cannot replace a flaw-finding human, they can assist programmers trying to avoid writing bugs. Gary is the only author I encountered who acknowledged that it is unrealistic to expect a programmer to keep dozens or hundreds of sound coding practices and historical vulnerabilities in his head while writing software. An automated tool is a powerful way to apply secure coding lessons in a repeatable and measurable manner. Gary also reframed the way I look at software penetration testing, by showing in ch 6 that they are best used to discover environmental and configuration problems of software in production.
Third, Gary is not afraid to point out the problems with other interpretations of the software security problem. I almost fell out of my chair when I read his critique on pp 140-7 and p 213 of Microsoft's improper use of terms like "threat" in their so-called "threat model." Gary is absolutely right to say Microsoft is performing "risk analysis," not "threat analysis." (I laughed when I read him describe Microsoft's "Threat Modeling" as "[t]he unfortunately titled book" on p 310.) I examine this issue deeper in my reviews of Microsoft's books. Gary is also correct when he states on p 153 that "security is more like insurance than it is some kind of investment." I bookmarked the section (pp 292, 296-7) where Gary explained how the "19 Deadly Sins of Software Security" mix "specific types of errors and vulnerability classes and talk about them all at the same level of abstraction." He's also right that the OWASP Top Ten suffers the same problem. Finally, Gary understands the relationships between operators and developers and the importance of security vocabulary.
I was pleasantly surprised by "Software Security". I reviewed an early draft for Addison-Wesley and wondered where the author was taking this book. It ended up being my favorite software security book, easily complementing Gary's earlier book "Building Secure Software." In my opinion, Gary is thinking properly about all the fundamental issues that matter. This book should be distributed to all Microsoft developers to help them frame the software security problem properly.
Gary McGraw, one of the leading security luminaries int he world, has got it right. Security cannot be added to systems once they are built. It must be designed in from the very beginning. The security posture and design must be considered in every phase of the development of a system - from the early design to the actual coding of the instructions.
Gary has done a fanstastic job explaining how to build secure systems, and detailing the importance and complexity of software security.
I've always been a big fan of Gary's, and with this latest installment in his 3 part series, Gary has provided readers with the most important advice and instruction to help keep the bad guys out of your systems.
Software Security: Building Security In is a valiant attempt to show software developers how to do just that. The book is the latest step in Gary McGraw's software security series, whose previous titles include Building Secure Software and Exploiting Software.
In past decades, writing secure code was left to the military and banking industry. Today, with everything on networks, all sectors must get into the act.
Much of the problem is that organizations target their security elsewhere--specifically on networks--rather than on software. But so many malicious attacks are directed at software that it is foolish to leave this vulnerability exposed.
McGraw goes into detail not only about writing secure code but also about key related areas, which he terms "the seven touchpoints of software security."
These points comprise code review, architectural risk analysis, penetration testing, risk-based security tests, abuse cases, security requirements, and security operations. A major portion of the book effectively discusses these "touchpoints," making the work a recommended tool for inculcating software developers with a security mind-set.
development, and software security specifically-test, neither assume nor guess.
This book puts software security in its place, integral to your software development process. Whether you're agile, extreme, rational, or perhaps teetering at the top of a waterfall, this book will guide you in building security into your methodology. Theory and abstractions aside, Dr. McGraw concretely describes actual, and scarily common, security vulnerabilities he has encountered in the field. He goes on to show that security issues are inherently related to gaps in the development process, and expertly guides you to improvements in that process.
Look for similar items by category
- Books > Business & Investing > Industries & Professions > E-commerce
- Books > Computers & Technology > Certification Central > Exams > Security+
- Books > Computers & Technology > Computer Science > Software Engineering
- Books > Computers & Technology > Databases
- Books > Computers & Technology > History & Culture > Privacy
- Books > Computers & Technology > Internet & Social Media
- Books > Computers & Technology > Networking & Cloud Computing > Internet, Groupware, & Telecommunications
- Books > Computers & Technology > Networking & Cloud Computing > Network Security
- Books > Computers & Technology > Networking & Cloud Computing > Networks, Protocols & APIs
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Security & Encryption
- Books > Computers & Technology > Software
- Books > Computers & Technology > Web Development > Security & Encryption > Encryption
- Books > Textbooks > Computer Science & Information Systems > Networking
- Books > Textbooks > Computer Science & Information Systems > Software Design & Engineering