« It's Not the Size of the Company That Determines Security | Main | Insiders Now The Biggest Security Threat »

Listen to or download the 11:27 min. podcast below:

Download file

What follows is the transcript of my discussion with with Brian Chess, the founder and chief scientist for Fortify Software and also the author of the excellent book, Secure Programming with Static Analysis. In this podcast we discuss static source code analysis (also referred to as application security testing), how it defends against cross-site scripting, how static analysis can keep up with the ever-evolving threats, key PCI requirements that companies need to be concerned with, and finally, how static analysis helps protect against the dangers of Web 2.0.

Also, I highly recommend checking out Fortify's excellent White Paper, Web Applications Under Attack: Four Eye-Opening Findings.

Can you give me an overview of what static source code analysis is and how it works?

Static analysis really refers to any process for analyzing code where you don't run the code. And that might seem a little odd at first, because code is built to be run. But when you do analyze the code statically, you have an opportunity to explore many, many more possibilities than you can when you have to actually run the code and put it in a variety of different states.

So most people are familiar with static analysis tools, although they might not call them that. For instance, "compiler." When it does type checking, is performing static analysis. There are a lot of different static analysis tools out there. Some of them are pretty basic. They are basically grepping through code for patterns of, you know, letters or characters or white space and triggering on that sort of thing.

The static analysis tools I'm much more interested in are a lot more advanced than that. They are actually tracking paths through the code and trying to figure out how an attacker might actually be able to manipulate a piece of code.

For more than a few people, 2007 was probably the first they even heard of application security testing. Why don't most of the standard security solutions protect against these types of vulnerabilities?

Historically speaking, we've been able to get away with building software that contains security defects and then somehow putting some protection around it. For instance, a firewall protects a potentially vulnerable internal network from all the bad stuff out there on the Internet that might want to get at it. And that works just fine until you want to hook up that internal software so it can talk to the outside world. And now we've really got to depend on the ability of the software to defend itself. So we can no longer put some sort of prophylactic around it. We've got to make the software itself secure. And that's really what has changed over the last five years, is we've started exposing all sorts of systems to the Internet. And then depending on those systems to be secure.

And now that means we've got to go inside and look at the code and make sure that the code is written the right way in a tenable fashion, a way that's going to allow legitimate users to get what they want out of it and not allow malicious users to get anything else out of it.

Looking over Fortify's Web site, I really enjoyed your demonstration on cross-site scripting. And I was quite surprised at how vulnerable many Web sites still are. How does static source code analysis help defend again cross-site scripting?

You hit on a topic that I like a lot. I think cross-site scripting stands a good chance at being the new buffer overflow. And let me explain what I mean when I say that. So, let's back up and talk about buffer overflow for just a second. So, buffer overflow attacks are deadly because they allow a bad guy to overwrite your program and essentially insert their own code into your program. There are also really easy mistakes to make in C and C++ because C and C++ weren't designed with much security in mind. So they leave the possibility of errors that lead to buffer overflow wide open.

So now let me make the comparison to cross-site scripting. So cross-site scripting is, in most Web-facing languages, a really easy mistake to make. It happens when you allow some piece of input that an attacker can control to be reflected directly into the Web page that you are creating. And so in order to see this analogy, you have to understand that modern Web pages just aren't static things anymore. They're really more like programs that you're downloading into a browser.

And so now what we're giving is the attacker an ability to almost rewrite that program that you're downloading into the browser. So here you've got a mistake that's easy to make and that gives an attacker quite a bit of control over what gets executed in a Web browser. Now to back up five or maybe even ten years, cross-site scripting was sort of a novelty item. You could go to somebody's "sign my guest book" page and maybe put "Barney the Dinosaur" on their page so you couldn't see any of the other stuff on it and ha ha, isn't that funny?

And more recently, cross-site scripting has been about phishing attacks. So you send somebody to a Web site that looks like it's trusted, but really, the bad guy is going to harvest the user name and password information off of what appears to be a trusted site. Even more recently than that, people are starting to figure out that you can use cross-site scripting to attack internal networks. You can really use cross-site scripting to bypass a firewall and start exploring on the inside of a victim's network.

So back to your question about, well, what does static analysis do for you? Really, what static analysis does is it allows you to look at all of the different things that are influencing the Web page that you generate. And if one of those things that is being put into the Web page is something that the attacker controls, then cross-site scripting is a possibility. And so what we can do is point out to people where they need to go back and take extra precautions in their code in order to prevent the vulnerability.

How does static analysis keep up with the ever-evolving threats?

That's a really good point. Actually, both sides of the equation are both constantly changing. Let me tell you what the two sides I see are: one is how are people building software. And that's always changing because people are changing the programming languages that they like. They are changing the programming frameworks that they use within those languages. And really, software development just never holds still. So we constantly have to keep up with -- well, what are programmers trying to do with their software? And what kind of mistakes might they be able to make?

Now, on the other side of the equation, we've got to look at, well -- how are attackers going at the software? What kind of techniques are they using? What have they learned how to exploit in better or more malicious kinds of ways?

And so we've really got to look at what are the programming constructs and what are they vulnerable to, and then, how are they going to be exploited?

And so the end result of balancing that equation is a constant stream of new rules that we feed to a static analysis engine. So a program that looks like its completely secure today, we may find out tomorrow is actually susceptible to some new kind of attack and we'll want to go through that program using static analysis and a new rule set in order to find those types of weaknesses.

Now what are some of the key PCI requirements that a company needs to be concerned with and how does Fortify help address them?

I hear a lot of people talking about PCI today. I think it's a really good wake-up call to people, the security of their software matters and it matters in a couple of different ways. I'll tell you where most people come and talk to Fortify about PCI has to do with Requirement Six, which calls for developing and maintaining secure systems and applications. And that means doing things like checking your code against the OWASP top ten. You may perform a complete code review in order to meet requirement six. And those are the kinds of things that static analysis can help with.

Let me say that I think sometimes people overlook a couple of the other requirements. They overlook Requirement Three, which calls for protecting stored data. And that's something that actually using a static analysis tool can help with a lot because you can trace where the data in your code is going to. So, for instance, if you end of writing a piece to track credit card data to a log file without realizing it, that's the kind of thing that you might use a static analysis tool to trace through the code and find.

Similarly, Requirement Four requires that you encrypt transmissions of cardholder data and you can do the same thing: you can find out, well, where maybe am I putting credit card data onto the wire without encrypting it by using a static analysis tool.

How does application security testing help protect against the vulnerabilities of Web 2.0?

I really like the Web 2.0 story. Because it's yet another shift in the titanic battle between client and server. So, I mean, just the history of computing, you can frame in terms of this client/server balance. In the beginning, we only had servers because we only a couple of computers in the world and you had to go up to the front console of the computer and rewire it in order to program it. And then eventually, we figured out that we could hook up a bunch of terminals to the same computer. And then the thin client was really born. And then Xerox Park came along and introduced the Alto and that was a small personal kind of computer for the first time. And then, of course, the PC revolution was not far behind that.

And we ended up a lot of client-side computing. Then the Web came along and the Web pushed everything back onto the server. All the smarts were all on the server and all you had was this very simple renderer in the form of a Web browser to accept what the server sent down. Now Web 2.0 comes along and says, "Hey! That simple little renderer actually can execute scripting languages like, for instance, Java script. And you can start to make a really rich client experience by pushing a program down into that Web browser." What we've done is we've taken a big hive of complexity on the server and we've divided it up between the client and the server now.

What that makes for is a much more complex communication protocol between the client and the server. And what that means is that standard ways that were used to testing Web applications just don't work as well anymore. Because we've got a much more rich interaction. We've also got the opportunity to make all kinds of mistakes on the client that just weren't there before.

So what we have to do in order to make those systems adequately secure, is find a way to ignore those communication protocols and really get back to the root of, well -- what is it possible for a bad guy to do to this system? So, doing that is really all about analyzing that software and understanding what that software is capable of doing. And, you know, if I didn't put a whole lot of Web 2.0 buzzwords in there, if we haven't talked about Ajax a lot or maybe even Adobe Flash, or other sort of Web 2.0 technologies, it's because I think the fundamentals of what we've got to do with Web 2.0 are really independent of any of those technologies. And it really comes down to: is our software under our control? Do we know what it's capable of doing and what its limits are?

It sounds like fundamentally, that software just has to be tested or the bad guys are more than happy to test it for you.

And tested in such a way that you actually have confidence that you know what that software can do and what it won't do. And that's really, really important.

Posted by pschooff in Podcast |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/2306