How things break: Securing your software |
 |
By Jennette Mullaney, Assistant Editor
14 Jun 2006 | SearchAppSecurity.com |
|
|
BALTIMORE -- Only by thinking like a bad guy can you defeat the bad guy.
"So, let's put on our black hats," Gary McGraw, PhD, told his packed audience at last week's Software Security Summit.
With hats in place, McGraw, chief technology officer at Cigital, drove home the message that developers need to know how to break code if they want to be able to make it secure.
"Surely the world needs to know how to build stuff better," McGraw said in a booming voice. But until then, he will "bamboozle people into building better by talking about how things break."
What software security is not
Software security is not application security tools. Those tools are "badness-ometers," McGraw said, which at best reveal that your software is riddled with holes, and at worst lull you into a false sense of security. "What [these tools] don't tell you," he instructed his audience several times, "is how secure your software is."
|
|
|
|
|
What [application security tools] don't tell you is how secure your software is.
Gary McGraw
CTO, Cigital
|
|
|
|
|
|
|
|
|
|
Security features may not help you either. "Software security is not about security features," McGraw said. Cryptography, patches, firewalls -- attackers get past these. In some instances, hackers can even use these features to their advantage.
Patches, for instance, serve as "attack maps," according to McGraw, guiding malicious users to security holes. Those patches often arrive too late anyway. To emphasize his point, McGraw showed a graph in which intrusions increase drastically after the introduction of a patch, eventually tapering off as hackers waited "for the next Patch Tuesday," he said.
As for cryptography, "real attackers don't go after cryptography because it's too hard," McGraw said. Instead, an attacker can search for vulnerabilities on Google -- "the number one hacking tool," he said.
Complicating this situation is the yawning gulf between builders and operators. "Security means different things to different people," according to McGraw. If security means very different things to two departments within the same company -- two departments that are supposed to be working to build a more secure product -- their miscommunication may derail security.
Or, as McGraw put it, "The operations people go to the developers and say, 'Your baby is ugly' and then beat them with a stick and don't tell them why."
Know the enemy
McGraw made an obvious but important point. He asked the audience, "How many holes do you have to find to exploit software?" They responded, almost in unison, "one."
He then asked the crowd, "How many holes do you have to find to secure software?" to which they replied, after a beat, "all of them."
Finding and eliminating all of the holes in your software may sound grueling or, given your budget and time frame, impossible. But if hackers are going straight for the bugs and flaws in software, then that's the best place to start implementing security.
Examine your code, suggested McGraw. Use automated tools to search for bugs. Do architectural analysis to hunt for flaws. Rather than throwing up a firewall, go straight to the source of the insecurities in your software.
After all, that's what an attacker would do.
|
|
|
|
