A practitioner’s guide to software security

Software security guru Gary McGraw talks with John Dix, Network World editor-in-chief.

Software security guru Gary McGraw is back with a new book, Software Security: Building Security In,which is the third in a series and described as a practitioner’s handbook. Network World Editor-in-Chief John Dix caught up with McGraw to talk about the book, the state of software security and the approaches he recommends for doing it better. (McGraw was interviewed in 2004 about his book Exploiting Software: How to Break Code.)

You organize your new book, in part, around what you call touchpoints. What’s that all about?

One of the things you need to know about software developers is they have different religions when it comes to their methodology. So there will be people who do something called extreme programming, and people who do the Capability Maturity Model, people who do Spiral Model. And when you go to a developer and say, ‘Let’s talk about how you develop software,’ they’re always excited about their own methodology. So the last thing I wanted to do was invent another methodology.

So the idea behind the touchpoints is to create some lightweight security best practices that can be used no matter what your methodology religion is.

The idea came about because I was thinking: What do all these software methodologies have in common? They have in common a set of artifacts. Code is an artifact that you create when you’re making software. Or architecture documentation, or test plans and test results. So these artifacts are produced no matter which methodology you’re following.

And the touchpoints are about each artifact. There’s a picture in the book that shows how the touchpoints align with the artifacts. So the artifacts along the bottom are things like architecture and design, test plans, code, test results and feedback from the field. Those are the things you pile up when you’re building software.

And once you have those, you can talk about particular best practices. With code, for example, I can do code review using a static-analysis tool to look for bugs. Given architecture, I can do risk analysis.

So those are some examples of the touchpoints. Out of all of the touchpoints I’d say the two you should absolutely do are code review with a tool and architectural risk analysis. And the reason for that is software problems come in two flavors. They come as bugs, like a buffer overflow on line 47, and as flaws, like you didn’t do your error handling consistently among all these gazillions of classes. So you want to be able to cover both of those since they’re divided roughly 50/50. And that’s why the first two touchpoints are what they are.

Is your book aimed at individual developers or teams of developers?

Both. The middle section is a bunch of chapters about the touchpoints. So there’s one chapter for each point, which is great for individual developers and software security analysts and people who run projects. Part 3 of the book is called “Software Security Grows Up,” and it’s about how to take a large organization and try to instantiate the touchpoints.

Do you think software security is more important than perimeter security?

We’ve spent a bunch of years building reactive but useful technologies – firewalls and intrusion-detection systems and anti-virus stuff. But then you step back and say, ‘Well, why are our systems vulnerable today?’ The root cause of these problems is bad software. And computers aren’t just on our network anymore. We have things like cell phones and PDAs, and the common vulnerability all of these things have is software. So my belief is the only way to really address the problem in a proactive fashion is to do software security.

The challenge is if you go to software guys and say ‘security’, they say ‘Yeah, yeah, yeah, that’s what those network guys do.’ And if you go to the network guys and you say, ‘Wow, software bad’, they all go, ‘Yeah, software bad. Our beautiful network’s screwed up by software every day.’ So everybody’s sort of pointing at the other guys. The real way to solve it is to better manage software quality, software reliability, software security.

Powerful hardware allows for sloppy, bloated software. Will it be hard to get them to own up to the task?

Software developers are not inherently lazy. All this hardware is more complicated. Imagine the software that has to control it. Software is way more complicated than it used to be. Windows 3.1 in 1990 was 2½ million lines of code. XP is 40 million lines. And here’s a really simple truism for software; the more code you’ve got, the more bugs you’ve got. No matter how you slice it, even if your defect density is dropping over time, the code pile is getting bigger faster than that defect density is dropping.

I put a question to my technical advisory board, which includes some luminaries in the field of security, asking if they think developers are getting better or worse? We came to the conclusion that software developers are in fact getting better. They’re way better then they used to be, but the problem is getting harder. And one issue may be that the problem is getting harder faster than they’re getting better. We’re always sort of right at the edge of our competency.

Does the adoption of service-oriented architectures (SOA) complicate the picture for software security?

I see SOA as an opportunity, because if people are serious about rearchitecting their software pile in terms of services, they have an opportunity to build security in. I also see it as a potential problem, because some of the early vendors doing SOA security are running down the feature rat hole. They’re saying, “If you just use this or that, name your acronym; everything will be secure.” Or we’ll do security all at once, [and] in some sort of magic now we set the security parameters for everything. And unfortunately that’s not how security works. It’s a system property. It’s a dynamic thing, like quality. You don’t add quality in at the end, or spray-paint it on. Same thing with security. So I’m both worried about SOA from that perspective, and excited about it because if people do start to rearchitect, they can eradicate flaws like there’s no tomorrow.

Companies buy more software than they build these days, so do they still need your book?

We have the Enterprise Software Security Framework in the book on page 256. And you’ll see that the touchpoints really are about building software, but they have analogs in terms of buying software. There are certain things you can ask your vendors to produce as evidence that they’ve done a good job on the software security front, and that’s a critical, critical factor. Because if you just focus on the stuff you’re building you wouldn’t be addressing a majority of the problem. And you do have to address that problem.

So you can use this to help control your vendors and get a handle on the software you’re not producing yourself.

You’d have to be an awfully big company to influence the provider . . .

That’s right. But some companies are big. And if we all demand better software, stop putting up with the, ‘It’s very complicated, and you don’t understand it,’ crap that the vendors promulgate, and start saying, ‘Well, actually we do understand it, and we’d like to see evidence you’ve done code review,’ all of a sudden we’ve changed. We start to write service-level agreements that vendors have to sign that say if there are security problems they are going to pay us money, and you’ll see where the rubber hits the road real quick.

How would you rate the off-the-shelf software suppliers in terms of security?

Not very good. We have a long way to go. By and large, most software people don’t shirk their responsibility. They get it. Everybody sort of goes ‘Yeah, yeah, we really got to work on that’. But some have made more progress than others.

This is your third book on software security. Do they add up as a series?

Building Secure Software came out in 2001, and Exploiting Software came out in 2004, and this book just came out this year. Building Secure Software was a philosophy book. It was about the theory of software security. And this is a practitioner’s book; this is about, ‘OK, you want to know how to do it? Here’s how.’

Together, they make up a boxed set called the Software Security Library, which is the anchor of a series called the Addison-Wesley Software Security Series. Right now there are four books in the series. The three I mentioned and a new book called Root Kits that my co-author from Exploiting Software, Greg Hoglund, wrote – a fantastic book.

How does Exploiting Software fit in?

In that book we didn’t say, ‘Here’s how to build a bomb’; we said, ‘Here’s the way people are building bombs, here’s what they do with the bombs and here’s how you need to protect yourself against bombs like this.’

In closing, tell us about your “badness-ometer.”

(Laughs) There are two major categories of tools out there. There are tools that look at your code for problems, like static analysis tools, and there are application-security testing tools. Those are what I like to call badness-ometers. The idea behind a badness-ometer is you have a black-box set of tests that you run against your system. And if those canned tests find problems, you know you’re in a world of hurt. But if those tests don’t find anything, you really don’t know much. You ran some tests, nothing happened. So badness-ometers measure from deep trouble to who knows? And the important thing to realize about them is they’re not security meters. They’re badness-ometers.

Do we need badness-ometers? You bet, because most people don’t know that they’re in a world of hurt, and they need to stick it on their head and go, ‘Uh-oh, we’re in a world of hurt’.

The one cautionary note for your readers: I don’t think that you can just tool up and solve this problem. So it’s going to take some more serious work in terms of architecture and design and design analysis that might require outside help. It will certainly require some cycles from your software architects. And that’s an important thing for people to know so they don’t think they can just run out and buy tools to solve the problem.