Dr. Dobb's | The Weakest Link | December 01, 2002

The Weakest Link

Security practitioners often point out that security is a chain; just as a chain is only as strong as the weakest link, a software security system is only as secure as its weakest component. Bad guys will attack the weakest parts of your system because they're the parts most likely to be easily broken. (Often, your system's weakest parts will be administrators, users or tech support people who fall prey to social engineering.) It's probably no surprise that attackers tend to go after low-hanging fruit. If hackers target your software, they'll follow the path of least resistance-attacking parts of the system that look the weakest. (Of course, even if they spend an equal effort on all parts of your system, they're far more likely to find exploitable problems in the parts of your system most in need of help.)

December 01, 2002
URL:http://www.drdobbs.com/the-weakest-link/184414929

Read part 1

The Convenience Store Analogy
A similar logic pervades the physical security world. There's generally more money in a bank than a convenience store, but which one is more likely to be held up? The convenience store is a much easier target, because banks tend to have strong security precautions. Of course, the payoff for successfully robbing a convenience store is much lower than knocking off a bank, but it's probably a lot easier to get away from the convenience-store crime scene.

So to extend our analogy, you want to look for and better defend the convenience stores in your software system. Consider cryptography. It's seldom the weakest part of a software system. Even if a system uses SSLv2 with 512-bit RSA keys and 40-bit RC4 keys (which is an incredibly weak system), an attacker can probably find easier ways to break the system than attacking the crypto. Even though this system is breakable through a concerted crypto attack, successfully carrying out the attack requires a large computational effort and some cryptography knowledge.

Let's say the bad guy wants access to secret data being sent from point A to point B over the network (traffic protected by SSLv2). A clever attacker will target an endpoint, try to find a flaw like a buffer overflow, and then look at the data before it gets encrypted or after it gets decrypted, because attacking encrypted data is too much work. Cryptography can't help you if there's an exploitable buffer overflow, and buffer overflows abound in code written in C.

For this reason, while cryptographic key lengths can have an impact on system security, they aren't that important in most systems as deployed, where there exist bigger and more obvious targets. For similar reasons, attackers don't attack a firewall unless it has a well-known vulnerability. Instead, they'll try to break the applications that are visible through the firewall, since these tend to be easier targets. New development tricks and protocols like SOAP, a system for tunneling traffic through port 80, make our observation even more relevant. It's not about the firewall; it's about what's listening on its other side.

Buffer overflows and race conditions are the most common software security problems. However, code-scanning tools can spot exploitable areas if you're using dangerous languages like C or C++. Other common security risks include design errors, access control problems, problems with random numbers, applied crypto mistakes, flawed password systems, database interface problems and input validation problems. Building up knowledge about common software security risks is an excellent way to begin to secure the weakest link.

Identifying a program's weakest component comes directly from good risk analysis. Given good risk analysis data, addressing the most serious risk first, instead of a risk that may be easiest to mitigate, is always prudent. Security resources should be doled out according to risk. Deal with one or two major problems, and move on to the remaining ones in order of severity.

This strategy could be applied forever, since 100 percent security is never attainable. There is a clear need for some stopping point. It's OK to cease addressing risks when all components appear to be within the threshold of acceptable risk—though the notion of acceptability depends on the business proposition.

Sometimes it's not the software that's the weakest link; sometimes it's the surrounding infrastructure. Consider an attack in which the bad guy uses social manipulation. In a typical scenario, a service center will get a call from a sincere-sounding user who talks the service professional out of a password that should never be released. This sort of attack is easy to carry out because customer service representatives don't like to deal with stress. Faced with a furious customer who seems to be unable to get into her account, they may not want to aggravate the situation by asking authentication questions—instead, they may simply change the password.

Good security practice dictates an approach that identifies and strengthens weak links until an acceptable level of risk is achieved. Though no guidelines are foolproof, when properly applied in concert with the other principles, this principle can address many common security problems. In our next column, we'll discuss "defense in depth."

Gary McGraw, Ph.D., is CTO of Cigital and coauthor of Building Secure Software (Addison-Wesley, 2001). Reach him at [email protected]. John Viega is Chief Scientist at Secure Software and coauthor of Building Secure Software. Reach him at [email protected].