1 March 2003

Security may be at the top of the corporate agenda, but programming secure systems is a rare skill. Keith Brown of DevelopMentor discusses the pursuit for perfect protection and the need to design for detection and reaction

The next time you talk to a software developer, ask her what she thinks makes a secure program. You're almost certain to hear about encryption, access control, and maybe if you're lucky, authentication and integrity protection. It's unlikely that you'll hear her tell you why it's so important simply to write robust code. You'll probably hear very little about sanitising user input. And it's almost certain that you'll hear nothing at all about the importance of auditing and alarms. All of these items are important, but why is the average developer only familiar with a few of them?

To learn the answer, look at the computer science curriculum taught to that developer in school. Little, if any, emphasis is placed on security. Then look at the typical framework the developer works with on a day-to-day basis. If the framework pays attention to security at all, it likely focuses almost all of its attention on a few protection countermeasures, including encryption, authentication, and access control. Even if other types of security countermeasures are available, they usually aren't well documented, and the developer is left to try to piece together a secure system without much guidance.

An entire generation of software developers has grown up working on Windows 9X, which has absolutely no security model at all. Many of these developers are eventually asked to work on server-side software running on real operating systems, and in today's tough economic climate, training budgets rarely allow for training in such an obscure area as writing secure software. Even when they move to a real operating system like Windows 2000, most choose to run with administrative privileges while they develop software, simply because they've no idea how to make their systems work if they don't. They produce code that you cannot run unless you also run with administrative privileges. It's enough to make you want to run screaming.

The search for perfect protection I recently had a conversation with a buddy of mine who was doing some consulting on a large software project. The project entailed a multi-tier architecture that exposed a Web service on the Internet. My friend asked me what he could do to prevent a domino effect once the Web server had been compromised by an attacker. You see, the Web server must connect to another machine on the network (perhaps a database) in order to get interesting data to display to its clients. But once an attacker compromises the Web server, what's to keep the attacker from gaining access to the database? The answer of course, is that if the Web server is compromised, the attacker can use the Web server's credentials to access any resource on the network to which the Web server had access previously. If the Web server had privileged access to a database, the attacker now has privileged access to that database. Period.

This upset my colleague. It meant that the components in the distributed system he was building couldn't blindly trust one another, but instead must run with least privilege - this is the practice of granting just enough privilege to each component so that it can do its job. It also meant that he couldn't build a system that provided perfect protection at the perimeter. He instead needed to think about defence in depth. It's frustrating for a software developer to think that his code might be coerced into doing something he didn't intend it to do; that it might actually be used to attack other components of the system. It's so frustrating that many developers simply stop thinking about it. But there is hope.

Three types of countermeasures In his book Secrets and Lies, Bruce Schneier groups security countermeasures into three categories: protection, detection, and response. If you had a system with perfect protection countermeasures, you wouldn't need any detection and response. Sadly, such systems do not exist, but you can design a system with less than perfect protection, if you balance it with good detection and reaction countermeasures.

In the physical world, secure systems are built with this in mind. Protection countermeasures such as padlocked doors, safes, and castle moats are not designed as perfect protection mechanisms, guaranteed to keep attackers at bay while we slumber. But they do work pretty well in conjunction with burglar alarms and armed guards who patrol the premises.

With good detection and reaction countermeasures, protection becomes a means to keep honest people honest, and slow down the determined attacker and perhaps make him more obvious. A deadbolt on your front door ultimately won't keep an attacker out, but it might cause him to either try the house next door, or try to break through the window instead, which will likely arouse the suspicion of any neighbours or passers-by, or better yet, wake up your alarm system or pet pit bull.

Software systems that rely solely on protection countermeasures will ultimately fail to a determined attacker. And the problem is, the system may be under siege for days or months, and nobody will have any idea that an attack is in progress. Eventually the bad guys are going to find a way in.

Call to action: design for detection and reaction If my friend had considered all three types of countermeasures, I believe he'd not have felt nearly as frustrated as he did when he was searching for perfect protection. Once you admit to yourself that you're never going to have perfect protection, you can start to look at protection countermeasures as a way to slow down the attacker. Techniques that once were discarded because they couldn't stave off an attack forever suddenly become viable options. Simple obfuscation that can slow down an external attack can now significantly raise the bar for the bad guys. But this assumes you've got a plan for detection and reaction.

So how can you design detection countermeasures into your system? Perhaps a start is installing an intrusion detection system and hiring a staff of experienced system administrators. During software development, design a mechanism for reporting suspicious activity. It can be as simple as using the Windows event log to record events and having a daemon reading the logs and alerting system administrators to potential problems. It can be as complex as sending messages to a remote secure auditing machine to ensure that the messages aren't tampered with once they are sent. What about a daemon that scans the hard drive checking to make sure that no rogue files show up, and that existing files haven't been altered (hash algorithms are great for this)? If enough people get excited about these types of countermeasures, we may even see support in popular frameworks for implementing them.

What about response? A very important step you and your company can take (if you haven't already) is to pull your collective head out of the sand and assume that you will be successfully attacked some day soon. If you detect an attack in progress, how will you deal with it? Decisions need to be made very quickly, often by system administrators who are on duty at odd hours. Is it possible to shut down one portion of the system that has been compromised without denying service to all your customers? How quickly can you detect the flaw, patch the system, and get up and running again? Have you ever tried doing this in the lab?

Building a secure system isn't easy, but by focusing on a comprehensive set of countermeasures including protection, detection, and reaction, your staff will be better prepared to build one.

Add a comment