Web application security has gotten a lot of attention over the past few years. Where have we made progress, and where are we still lacking?
What I'm working on, and what Fortify is working on, certainly involves Web application security, but it's really about software security. There's software everywhere, and when you put some faith into the idea that software is going to do what you expect it to do, you end up with the opportunity for a security problem.
The good news is that there is a market for software security and software security tools. That means people are starting to realize they've got new risks in the form of security problems that they have to take into account when they build software. So where we've made progress is that there is an acknowledgement that security is about the code; it's about the application, not just the periphery.
Where we're losing ground is complexity. We're building bigger and bigger systems at an astounding rate, so our complexity is growing exponentially, and our ability to manage that complexity is not growing with it. You can see the evidence of that as new types of vulnerabilities start to arise, without fixing what came before them.
The two don't move independently. You can never be sure what the attacker is going to do next, but you can be reasonably sure they're going to be looking for the path of least resistance. The most common vulnerability is easily cross-site scripting. Because of the programming languages we have and the way people develop Web software, it's an easy mistake to make. Increasingly, that's a mistake we'll see people exploiting. Usually SQL injection is a more dangerous problem because you can get access to everything in the database, but cross-site scripting is the much harder one to get rid of, and people are working on better exploits all the time, so the threat level there is increasing. Can you give me a brief description of your new book?
We're trying to explain the importance of thinking about security when you're writing the code, and showing how people can use static analysis to avoid common programming errors. Probably the easiest analogy is the spell checker. Everybody learns how to spell, yet everybody continues to uses spell checkers because knowing how to spell isn't good enough. Even if you're a good speller, sometimes you hit the wrong key. The same is true when you're writing code. We need programmers to understand security, but just understanding security is not enough. We need some way to check what they produce in order to figure out if they made a mistake. And static analysis is absolutely great in that role. So in the first part of the book we explain what the software security problem is, what static analysis is and how it works, and then the majority of the book is going through software security problems, showing how they occur, what they look like in code and how you can use static analysis to find them. What is some advice the book gives about integrating static analysis into the software development life cycle (SDLC)?
Software developers have lots of tools -- IDEs, debuggers, profile tools --so you might think static analysis will work just like any other tool. The key thing to realize is, a lot of times when a static analysis tool comes along, it's the very beginning of the developers thinking about security. So that tool doesn't map in the same way a new compiler or a new version of their IDE would. This is thinking about security as a new activity for them. What that means is, they need to set aside some time to make use of the tool, and they need to do that before it's too late. If you wait until the night before you're supposed to deliver a product, and that's when you start thinking about security, no tool is going to rescue you. You need to plan for how you're going to do security review and then build that into your plan for creating new software.
So the biggest lesson, and the big one I'm pushing this year at Fortify, is that static analysis tools are very flexible in terms of what they can check for. In a commercial tool you might get a certain set of checks out of the box that look for SQL injection or cross-site scripting, but there are a lot security vulnerabilities that don't categorize so easily. You may have vulnerabilities that are specific to your Web site or your piece of software. You can customize static analysis tools to find those kinds of errors, too. The programmers are in the best position to know what that code is supposed to do and what it's not supposed to do, so we spend time explaining how you might apply customization to the static analysis process.
Integration into the security process is not for free. It really merits some serious attention, and it's not as easy as just giving them a new tool.
And hopefully you start to feed back some of the stuff the tool tells you. For instance, you might find out that your software developers don't really understand SQL injection even though you sent them to training class. So you try to feed [information from the tool] back into another training module that explains to them in the context of their program what SQL injection can do. Or you could take metrics from these tools and use them to target the training to attack the vulnerabilities that are worst in your code. What are some tips the book offers for making the most of static analysis during a security code review?
We're talking about bringing security to the software developers and having them participate in making their code secure, where they didn't have to do that before. What they'd really like to hear would be: "I'll sell you a big red button, and all you have to do is push the big red button and your code is secure." Security is harder than that. There's not going to be any magic tool that makes your code secure. What you've got to do is read that code with an eye toward security. The best way to think of static analysis tools is they make that process more efficient, but they don't fix your code for you. That means you have to run the static analysis tool and then sit down and review the code, looking at the tool output, and fix the problems you find. That's much closer to doing a traditional code review than it is to some kind of magic fix.
Static analysis provides a list of things to look at, and hypotheses that can be tested about that code. So instead of starting from scratch with a code review, you're almost turning it into a multiple choice test.
This is really important if you're going to have people who aren't security experts contribute to the security process. These programmers are never going to be security experts because they're programming experts. A static analysis tool brings them some ideas about what they need to be looking for in their code so that they can help with security. Why do you think developers have been slow to adopt static analysis tools that look for security vulnerabilities?
It has to do with the immediacy of the payoff. With security, often a bad outcome isn't obvious because in order for something bad to happen, you have to make a mistake in your code, and nobody wants to think they make mistakes. Then someone has to take advantage of that mistake. Maybe that will happen tomorrow, maybe that will happen next year, maybe that will never happen. There's no way to tell for certain. So it's an easy problem to push off to the back of the queue. That's the number one reason software developers haven't immediately embraced security -- because they have a lot of other things to do. But nobody is in a better position to help with security [than the developers]. Your book includes techniques for making static analysis more effective on your code. Can we talk about a few?
This is all about how to tailor the static analysis tool to work on your code. Probably the number one thing on that list is to identify where the input is coming from. A cell phone is a good example. A static analysis tool wasn't written with cell phones in mind; it may not understand the interface between the analog radio and the digital portion of that phone. As a developer of software for cell phones you need to bridge that gap and explain to the tool, "Hey, the things that show up in this part of memory are coming from the radio, so you need to treat like it might be malicious." The second is to focus the tool. It may be checking for a lot of things that don't apply to your code. If it doesn't apply to your code, turn it off. The last thing you want to do is send a bunch of software developers on a wild goose chase for things that can't actually happen to them. How has the market for static analysis tools for security changed?
It's much easier going than it was two years ago. For the most part software developers aren't nearly so resistant to the idea that they need to contribute to security. We spend a lot less time trying to convince them there are bugs in the code and a lot more time trying to convince them that we can help make the process of doing security more efficient for them. We've also come a long way in terms of the numbers of languages we can analyze. What is the book's takeaway?
That they [developers] have security problems, but their security problems are not out of their reach. The most important thing is to give people the idea that there are things they can control about the security of the systems they produce.
Brian Chess, Ph.D., is founder and chief scientist at Fortify Software, and co-author of the upcoming book Secure Programming with Static Analysis (Addison-Wesley, June 2007). He received his Ph.D. from the University of California at Santa Cruz, where he applied his background in integrated circuit test and verification to the problem of identifying security errors in software.