Saturday, 2 May 2009

Iron Chef Interviews Part 2: Sean Fay

« Iron Chef Interviews Part 1: Charlie Miller | Main | XSS for Fun (and profit?) »
Here is the second half of the Iron Chef interviews from Black Hat 2008. This interview is with Sean Fay, Fortify’s chief architect. I should point out that we interviewed Charlie and Sean separately, so they answered without being able to hear the other person’s answers first. The fact that they both talk about cycling and hamburger helper just adds to the mystery of the cosmos.

Charlie hates Apple. What do you hate?

I guess if Charlie hates Apple, I have to go with Microsoft. It’s nothing personal really. It’s just that I find it frustrating that no matter what my job title is, I seem to spend a fixed percentage of my time rebooting Windows machines.

You did Iron Chef last year too. Any advice for Charlie?

An hour goes a lot quicker than you might think. If you’ve invented some kind of machine to slow time down, now would be a good time to deploy it.

Can people build their own static analysis tools? Should they? Any advice for a tool builder who’s just getting started?

There are lots of cases out there in the software world where some custom static analysis can be really useful. But building a static analysis tool is a lot of work! As with most things, it’s better to build on top of someone else’s work to achieve your objectives. Both commercial and open source static analysis tools tend to be designed to support customization and extension.

Why aren’t there better open source static analysis tools?

Building a static analysis tool is a lot of work! There actually are some great open source static analysis tools out there - like FindBugs – but they tend to be domain and language specific.

Even a great static analysis tool by itself isn’t that useful. A tool needs a set of rules that describe the behavior of libraries and define the problems that the tool should look for. It’s a lot of stuff to pull together, and right now there’s no good standard for describing checks or characterizing libraries.

What’s wrong with fuzzing?

Fuzzing is a great technique for finding vulnerabilities, but it has two fatal flaws:

The first is that it’s skin-deep. The deeper and more involved the bug, the harder it is to uncover with fuzzing. The person fuzzing the app doesn’t have much of an advantage over an attacker. That means you have to hope that the attacker just isn’t going to try harder than you did.

The second is that it requires someone with very specialized skills and understanding. This makes it a hard technique to scale in an environment where lots of software is being produced.

People say static analysis produces too many false positives. Are they right?

No, it’s just that static analysis tools are complicated to use. Most people forget to turn on the switch to disable false positives before they run their tool.

Seriously though, false positives are a fact of life with static analysis, but a good toolset gives you easy ways to manage them and quickly sort out what is relevant and from what isn’t.

Charlie wrote a book about fuzzing. If static analysis is so cool, why haven’t you written a book about it?

I tried writing a book but I couldn’t get the first chapter to compile.

The static analysis concept has been around for a long time, but it seems like it’s gained popularity lately. Why?

I think that’s a combination of a lot of different factors. The tools are getting friendlier and more powerful. At the same time, a growing awareness about security is making their value more apparent.

When you meet women, how do you explain your job?

Well, before that Adam Sandler movie came out I used to explain that I was secretly a Mossad agent and this was just my cover. That hasn’t been working out so well for me lately.

What’s the biggest mistake people make when they use static analysis?

Lack of preparation. Static analysis is a means to an end. If that end is making your application secure, you need to spend time thinking about the architecture of your application and the assumptions that are being made about trusted and untrusted data.

A security-oriented static analysis tool will tell you a lot about where untrusted data is used within your application. But it’s very difficult to interpret that data unless you’ve already made some decisions about where validation is supposed to happen and where untrusted data is allowed to go.

What do you expect the fuzzing results will be like?

Hard to predict since I don’t know what the application is that we’ll be looking at. These guys are good at what they do, so I’ll bet that at the end they’re going to have something pretty interesting to show us. But with the limited time, we probably won’t see a very broad analysis of the application.

Why do you think you’re going to win?

I’ve been learning about competition from watching “Le Tour”. In preparation for Iron Chef, I’ve been doping with EPO for weeks. My red blood cell count is off the charts.

What's your favorite vulnerability or security incident from the last year?

That has to be Mark Dowd’s flash exploit.

What other disciplines do you take inspiration from?

Besides professional cycling? I guess online poker.

Where did you grow up?

I grew up in a small town called Ipswich in Massachusetts. It’s famous for clams and old houses.

If this were the original Iron Chef, what would you cook?

Well, I’ve been vegetarian for 7 years, but tofu just isn’t a crowd pleaser. I’m pretty sure I can still make a mean hamburger.

Posted by bchess at 1:18 PM in Fortify

 

[Trackback URL for this entry]

Your comment:

 
Generate another code
SCode

Please enter the code as seen in the image above to post your comment.
 
 

Live Comment Preview: