Software Development
Last month, we introduced our first principle for building secure software: Secure the weakest link. This month, we discuss the concept of practicing defense in depth. Over the next several months, we'll cover each of our 10 security principles in turn, putting some flesh on the bones of our tenets.
To practice defense in depth is to manage risk with diverse defensive strategies, so that if one layer of defense turns out to be inadequate, another layer will prevent a full breach. This doesn't apply only to security—it's also a tenet for programming language design proposed by Bruce MacLennan in his Principles of Programming Languages (Holt Rinehart, Winston, 1983, 1st ed.).
The Value of Redundancy
The defense-in-depth principle may seem contradictory to the secure-the-weakest-link
principle. There is no contradiction, however; "secure the weakest link"
applies when security functionality does not overlap. But when it comes to redundant
security measures, it's indeed possible that the sum protection offered is far
greater than the protection offered by any single component.
|
Principles to Build By
—G. McGraw and J. Viega
|
A good real-world example in which defense in depth can be useful, but is rarely applied, is in the protection of data that travels between various server components in enterprise systems. Most companies, assuming that a corporate-wide firewall is sufficient security, will erect one and let their application server talk to their database in the clear. However, if an attacker manages to penetrate the firewall, if the data is also encrypted, the attacker won't be able to get at it without breaking the encryption, or (more likely) breaking into one of the servers that stores the data in an unencrypted form. If we put up another firewall, around just the application this time, we can protect ourselves from people who get inside the corporate firewall. Now they'd have to find a flaw in some service that our application's subnetwork explicitly exposes—a situation that we can easily control.
When designing and building a piece of software, treat it as a complicated system that requires multiple lines of defense. Use both passwords and physical tokens to authenticate users; double-check that the operating system is enforcing access control in a reasonable way; make use of advanced sandboxing technologies in your design; and, by all means, monitor your software automatically as it runs.
Protecting the Organization
Defense in depth can also be applied at an organizational level. Try to avoid
having the same people design and analyze a system. It's all too easy to overlook
problems in a system that you've designed.
By the same token, make sure your software development process manages risks at both the architecture level and the implementation level. Using a code scanner is a great idea, but no substitute for an architectural analysis. Finally, you'll find defense in depth to be an especially powerful concept when each layer works in concert with the others.
Watch for next month's column, "Fail Securely." Failure is unavoidable. What can be avoided are security problems related to failure.
|
What Goes Wrong Some organizations do acceptance testing for functionality, but never test for security. This is a common oversight, especially in today's fast-paced software development world. The problem is that attackers don't do what they're supposed to—they do precisely what they're not supposed to! The art of exploiting software is about revealing assumptions made by designers—and then undermining those assumptions. Exacerbating the security-testing problem is the fact that standard-issue QA people can't really do security testing without some expert guidance. Any such testing must be done with the help of people who understand how software is exploited in the real world. Finally, a solid and thorough risk analysis must inform the testing process. |
Gary McGraw, Ph.D., is CTO of Cigital and coauthor of Building Secure Software (Addison-Wesley, 2001). He is the author of Java Security (Wiley, 1996) and Software Fault Injection (Wiley, 1999). Reach him at [email protected]. John Viega is Chief Scientist at Secure Software, author of Network Security with Open SSL (O'Reilly, 2002) and coauthor of Building Secure Software. Reach him at [email protected].
