Expert author, Gary McGraw, shows how to build more secure software by building security in.

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 inBuilding Secure SoftwareViega and McGraw 2001 andExploiting SoftwareHoglund and McGraw 2004. This book begins where its predecessors left off, describing in detail how to put software security into practice. After completingJava SecurityMcGraw and Felten 1996 and following it up withSecuring JavaMcGraw and Felten 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 toBuilding 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 antivirus mechanisms came to understand and embrace the necessity of better software.BSSprovides 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 how to break software and how malicious hackers write exploits.ESis 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 Securityunifies 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 Securityis 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 best practices (which I call touchpoints) throughout the software lifecycle, follow a risk management framework, and call 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 justify 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 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 development shops. 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