Epilogue

To a large extent, this book is about all of the little things that programmers need to get right in order to create secure code. The devil is in the remarkably long list of details that, if overlooked or misunderstood, give attackers what they need to compromise a system. We’ve looked at endemic problems such as buffer overflow in C and session management with HTTP. We’ve seen numerous cases where security hinges on seemingly unrelated trivia: ignoring error conditions, using the wrong output encoding, or giving away too much information about the system.

Fewer words have gone towards the design decisions that affect software security. Good design and good implementation need each other; one is useless without the other. But design and implementation are intertwined in another way too: An unfortunate design decision is behind every one of the implementation problems we have examined. Buffer overflow has its roots in the design of the C language, but the problem is made much worse by subsequent design decisions related to string representation and manipulation. Cross-site scripting owes its ubiquity both to Web standards that make it easy to mix active and passive content and to server-side frameworks that make output encoding an afterthought. There is a common thread to these design problems. They require programmers to make security-relevant decisions without advertising them as such, or they require programmers to make so many security-relevant decisions that a vulnerability is all but inevitable.

In his essay “No Silver Bullet: Essence and Accidents of Software Engineering,” Fredrick Brooks divides software problems into two groups: the essential and the accidental [Brooks, 1987]. Essential problems are hard and remain hard regardless of the programming language, operating system, or development methodology you choose. For example, there is no way to eliminate complexity from software—we craft complex requirements, and that complexity cannot be factored out of the resulting code. Accidental problems, on the other hand, are artifacts of our own creation. The expressiveness of our programming languages, the power of our development environments, and the quirks of our communication protocols are all under our control. We can hope to wrestle these problems and tame them.

With this outlook, it might seem reasonable to conclude that software security, at least insomuch as it applies to the kinds of implementation problems that commonly lead to vulnerabilities, is an accidental problem. Should we look forward to a day when it is vanquished? Can we learn from our mistakes and put them behind us? The difficulty is that the magnitude of a design problem often comes to light only after the design is in widespread use and is almost impossible to fix. Say what you like about the C language or the HTTP protocol, but both will be with us for the foreseeable future. Even if security problems often manifest themselves as accidents, they spring from an essential flow of new designs, new scenarios, and unforeseen consequences. We need to be ready for the kinds of accidents we know are with us today and the ones we know are coming tomorrow.

Once we discover a flaw or a quirk in a widely-used system, what next? If the flaw is fatal, as was the case with the security of the Wireless Encryption Protocol (WEP), then we begin a transition to a new design. More often, a flaw is venomous but not necessarily deadly. The flaw that allows format string attacks in C is of this variety. If a programmer is aware of the problem and vigilant about preventing it, then it can be avoided, but neither the knowledge nor the vigilance is easy to come by. Authors are continually generating guidelines and coding standards in an effort to raise awareness and teach techniques for coding around design landmines, but more often than not these documents are either too broad and vague to be of practical value or too specific and narrow to apply outside of a small domain.

This is where static analysis tools fit in. A static analysis tool can compare a large body of code against an extensive list of possible problems. Tools are more malleable than languages or programming frameworks, so the list of problems they identify can change faster than languages or frameworks. The problems they identify can also change depending on the type of code being analyzed or the needs of the person running the analysis. No tool is a replacement for security training, good design, or good programming skills, but static analysis is a great way to equip programmers with the detailed knowledge and vigilant attention to detail that they need to create secure code on top of imperfect languages, libraries, and components.

We expect that, as more programmers become familiar with static analysis, they will find many ways to apply the tools for their own purposes. There is considerable power in the ability to customize a tool to check against the semantics of the program at hand. As more people understand the capabilities of the tools, they will begin to take tools into account when they design systems. The Singularity Project from Microsoft Research is an operating system built from the ground up to be amenable to static analysis, and serves as an excellent example of this evolution. We also expect to see a great deal of growth in the way organizations apply tools. Already, we see a shift away from reactive tactics for trying to find and eliminate only provably exploitable errors towards proactive enforcement of best practices.

Tools, not just their users, have a long way to go too. The last ten years have brought tremendous gains in static analysis capabilities, but we need tools that understand a wider variety of languages, libraries, and programming styles. We need faster tools so that programmers can get immediate feedback on the code they write. And of course we will always need better algorithms for identifying and prioritizing problems in code.

—Brian Chess, Ph.D. and Jacob West, April 2007