Q&A: Programming Secure Systems in an Insecure World

REDMOND, Wash., Jan. 24, 2002 — Computer systems today live in a largely unseen, hostile world. A new Web server set up on the Internet is typically discovered and attacked within a matter of days. As technology evolves and grows smarter, so do those who seek to exploit its vulnerabilities. Today, computer users cant quite depend on their systems to always be available and secure the way they depend on other utilities such as electricity, water service and telephony. Computing isn’t yet inherently trustworthy — but it should be.

In a recent memo to employees, Microsoft Chairman and Chief Software Architect Bill Gates spoke of the need to deliver what Microsoft calls “Trustworthy Computing.” In it, he says that Microsoft software “should be so fundamentally secure that customers never even worry about it.” Also in the memo, Gates mentions the book “Writing Secure Code,” recently published by Microsoft Press, which is being used to help train thousands of Microsoft developers, testers and designers in the latest techniques for delivering secure products.

PressPass spoke with the co-authors of “Writing Secure Code,” Microsoft security experts Michael Howard and David LeBlanc, to discuss these techniques, the challenges developers face in today’s increasingly hostile technology environment, and what is necessary to provide for secure systems in the future.

PressPass: What compelled you to write this book?

Howard: We wanted to make our jobs easier! On a daily basis, Dave and I review designs, code and test plans with both internal and external product groups Quite frankly, we see many of the same programming mistakes made throughout the industry — the same mistakes made over and over and over again — and it consumes a lot of time to go over those. Our time can be better spent working on the really difficult problems So we got together and said, “Let’s document all the things that we’ve learned over the last 10 years, so that when people ask a typical question — even some of the hard ones — we can just direct them to the book.”

Many of the things we’re doing in our respective groups are not really visible to the outside world. Our jobs are ultimately to improve the security of our products, through tactical and also strategic means. This book is documentation that is being used to back up what we’re doing — and it’s mandatory reading for the entire Windows division.

LeBlanc: People want to do the right thing. That applies to almost anything in life. And most programmers certainly want to do the right thing, but they don’t always know what the right thing is. They know what mistakes in design or coding lead to performance problems; there are semester-long classes taught in most computer-science programs that deal with exactly those types of issues. In school, they’re taught all these different aspects of programming, but one of the things that’s typically not taught is how to make applications secure. And that’s one of the main motivations behind this book: that people need to be taught how to make things secure because they don’t always know in the beginning what a security mistake looks like. And once they’re shown what’s a mistake and why, then they say, “Oh, I definitely don’t want to do that,” and they learn from it.

One of our hopes is that maybe people will start using it as a textbook. We want to teach people to do it right in the first place.

PressPass: How has the environment in which programs are being run today changed?

LeBlanc: We’ve moved from two very different computing scenarios to what we have today. At one point in the past, if somebody was on my corporate network, then odds were I let them in the front door, and if I didn’t like the way they were behaving on my network, then I could very easily throw them back out and ask them not to return. There was nothing over the corporate LAN (local area network) except for maybe a remote office, and that was usually over a dedicated link. At the same time, the Internet was largely made up of a bunch of geeks and academics — it was essentially like a small town.

So we took those two things and glued them together, and instead of a small town, we’ve now got a huge, global city made up of millions and millions of people, and not all of them are very nice. The very high level of connectivity and availability that people have to each other has some pretty extreme security implications. The environment’s changed, so we have to look at things a different way.

PressPass: Why should developers or companies care about security?

LeBlanc: It doesn’t make sense not to care about security. The industry spends a lot of money shipping security patches; it’s tremendously expensive and it’s disruptive to the development process. We have entire teams that do nothing but deal with incoming security bugs. Those resources cost money. And it’s even more expensive and disruptive for our customers.

Another thing is that customers are coming to value security more and more all the time. So if a customer perceives a lack of security, they’ll be more reluctant to buy your product. It’s what’s called a deployment blocker. The last thing you want to do is discourage a customer. I always want to ship software that, as Steve Ballmer puts it, “delights the customer.” I’ve never seen anyone delighted at running around deploying patches.

PressPass: Where are the threats coming from?

LeBlanc: Probably the greatest single threat is the teenage hackers known as “script kiddies.” They attack insecure systems by using scripts written by more knowledgeable attackers. These are the same kids who whack your mailbox with a baseball bat or set something on fire on your porch, those types of pranks. They’re doing similar kinds of activities on the Internet, and there are a lot of them. They have a typically childish approach to the consequences of their behavior. Probably just because there are hordes of them, I would qualify them as a big threat.

On the other hand, they have, in general, pretty limited technical abilities. They’ve got a low level of understanding of what they’re attacking and what they’re after, and are pretty easily thwarted. If you keep up to date on patches, you can pretty well shut down most of the ordinary script kiddies. But they create so much noise that it’s difficult to focus on the guys who are the real problem, the real attackers. There are people out there who see something valuable and want to get at it. When you create banks, you create bank robbers.

PressPass: What are some of the ways in which the technology industry has had to change its approach to creating software, particularly with regard to security issues?

LeBlanc: We’re closely questioning how we design software and how we develop software; we examine exactly what’s appropriate to use and in what types of environments.

Howard: It’s not just about code. It’s also about the problems that we — the industry as a whole — have. The Internet is incredibly hostile, and there are no signs of it getting any less so. More and more machines are hooked up permanently to the Internet, and a lot of attacks can manifest themselves anonymously, or from across the world, and you wouldn’t even know it. So it doesn’t just boil down to the quality of the code. We’re doing some great things to make sure that code quality is better to protect against certain types of common coding mistakes, but we’re also looking at the designs — what features are enabled, how those features work, how they handle certain types of data. Additionally, we’re looking at ways applications are tested. The book goes into all of this, and it doesn’t just apply to Microsoft products. It applies across the industry.

In terms of what we’ve seen over the last few years, the quality of code is definitely getting better. But there’s code out there that can’t be fixed easily. When it’s already out there, the cat’s out of the bag. What we’re trying to do is get people to build systems that, even once they ship, if there are attacks that come out — that you might not even know about — you’re still not susceptible to those kinds of attacks, because you’ve taken appropriate design measures.

PressPass: What are some of these design measures?

Howard: There are two big ones. First, if your feature isn’t required by 90 percent of your user population, then don’t install that feature.

Second, once you have installed the feature, then you should run with the least privilege, which has just enough capability to get the job done. The analogy I draw in the book is, you can use a chainsaw to open a can of baked beans, and it will open the can, but you’ll probably lop off a hand while doing it. A can opener is the right tool for the job. It opens cans, nothing else. It doesn’t cut down trees, it doesn’t lop off hands, it just opens cans. And that’s exactly what we tell people to do. If your application does A, B, and C, then make sure it runs with just enough privilege to only do A, B, and C.

What that means is that a lot of applications, through poor or naive coding techniques, require the code to be executed by an administrator. So basically, if you’re not an admin, the program won’t run for you. But what happens if there’s a vulnerability in the code you’re running? The code that executes will also run as an admin, and admins can do anything they want to the computer system. Now, if you write the code in such a way that you can just be a normal user to run it, then if there’s an exploit or a vulnerability in the code, that exploit code will only run as a user. And a user can’t do very much on a machine — it can’t change the way it works or install new software, for example.

LeBlanc: In layman’s terms: If I run a bad piece of code as an ordinary user, the worst that it can do would be to, say, erase the files that belong to me or maybe even transfer into some mailbox on the Internet or something like that. But that’s really the worst it can do; it’s not going to reformat the hard drive. It’s not going to install a service that attacks a million other machines while I’m not looking. So there are limits to what can happen. Whereas if I’m running at an administrator level, with a high level of privilege, then the sky’s the limit. If something goes wrong, there’s essentially no safety net whatsoever.

PressPass: When in the process of creating software should security be considered?

Howard: Many applications are designed by teams of people who don’t really understand security. Their priorities are meeting schedules, making budget, and sometimes performance and security if there’s any time left. The biggest problem with software has been that code is built without a security process in place. This has to change. Security is a doctrine that is deeply intertwined with every aspect of the design, coding, testing and release of any product.

LeBlanc: Adding any feature, including security, is expensive as an afterthought. Then, if you add it, it might change the application interface, which might break the code that relies on it. Essentially, adding security later is wrapping security around existing features instead of designing with both in mind. Designing with both in mind from the outset leads not only to more secure products, but cheaper products too.

PressPass: What are the various aspects of security?

LeBlanc: Well, let’s say I’m running a Web server. I don’t want people to do things with my Web server that they’re not authorized to do, such as changing content on the site without my permission. I certainly don’t want them to take control of my server and use my bandwidth for their purposes. So that’s one thing; I want to be able to control my resources. The other thing is that I want it to be a useful Web server. So I don’t want it to be vulnerable to denial-of-service attacks. I don’t want somebody to be able to send it four packets, and then I have to come along and reboot it before it’s a useful Web server again.

Now let’s say that I’m exchanging e-mail and I’m trying to get to something really important. My concerns are reliability — I want to make sure my e-mail gets where it needs to go and back again on a regular, consistent basis because I should be able to depend on it as a communication mechanism. But there are other aspects of security that I’m concerned about. There’s privacy. I don’t want somebody sitting in between to be able to read that mail, and I certainly don’t want somebody in between to be able to tamper with the mail. Additionally, there is reputability . I want to be able to know that if a mail claims to be from Michael, it’s really from Michael.

So the things that are valuable to security to some extent depend on the usage scenario.

Howard: There’s another aspect to this that we covered in the book. What David is alluding to is what are called “threats.” Different computer systems — like Web servers, home users, banking systems, military computers — have different threats to which they are susceptible. In the book, we discuss how to determine what threats are likely to your systems, and then make sure that you counter those threats accordingly — with appropriate technology or other mitigation techniques.

PressPass: What are the components of “threat modeling,” as you term it in the book?

Howard: Threat modeling involves thinking through the usage of the technology, who the users are and what the resources are that are being protected by the system. In the example of, say, a hospital health-care system, there are doctors, nurses, and patients who can possibly view things. Resources include things like an operating theater, scheduling doctor’s appointments, patient records, etc. If I can start randomly changing the operating theater schedule, that could result in the loss of human life, as well as a big lawsuit. So then you ask, “Okay, what can I do to keep people from doing this?” Then you come up the different ways you can mitigate these threats; some require technology and others require education.

PressPass: What are the challenges that ISVs (independent software vendors) face today?

Howard: There are two main ones that spring to mind. The first is that there is so much to know. The second, which is the big one, is that the landscape is constantly changing. It changes every week. David and I live and breathe this stuff, so we know the latest exploits, we know the current thinking in the “black hat” community, what the hackers are currently doing.

LeBlanc: For instance, if you write code in C, you can deal with the operating system at a very, very low level, because that’s the language that the operating system was written in, and it’s very powerful and has high performance, but it also can be dangerous. Whereas if you write code using some of the managed code — like the .NET Framework and C# — there is a bit more of a safety net. It makes it a little harder for a programmer to make the same types of mistakes. We try to make it easy for the programmer to do the right thing. It would be better if programmers could spend more of their time worrying about how the stuff ought to work rather than, “If I do it this way or that way, there’ll be some kind of security disaster.”

PressPass: How enduring is the information in the book?

LeBlanc: Unfortunately, a lot of problems stick around for awhile. Buffer overflows were first noted in the 1960s if not before, and we’ve still got new ones showing up frequently. I would bet that five years out, certain sections of the book will have become obsolete. I would also say that we will have found new threats that belong in the book. I anticipate there will be more than one edition.