Want secure software? Think like an attacker |
 |
By Colleen Frye, News Writer
21 Feb 2006 | SearchSoftwareQuality.com |
|
|
Automated tools for testing application security can help smart QA people, but those smart QA people need to start thinking like bad guys, according to Michael Gavin, a senior analyst at Forrester Research Inc. in Cambridge, Mass. In his recent report, Trends 2006: Application Security Testing, Gavin recommends using a combination of automated tools and expertise to find and fix vulnerabilities before attackers can exploit them.
"You need to be doing security throughout the application development lifecycle. But if you haven't done it, the best place to start is where the attacker would, so test it for security holes like the attacker does," Gavin said. For example, he said, "They see your application on the Web, so how does it react when I give it something not expected? The QA people need to do this."
Security is one aspect of quality, he said, and "a lot of security vulnerabilities are just bad coding." So in addition to testing an application for features and functionality, QA needs to be looking for any bugs that can be exploited for security purposes, he said.
While ideally the developer would assume more responsibility for security testing, that's just not the reality in today's IT shops, Gavin said. "Developers don't have time -- they're not given time to do it right. They have crazy production cycles. Management has to step up and build time into projects. Teams should be doing code reviews [for security]. That doesn't mean every line of code, but some things are obvious. It would be great if developers ran these tools themselves, but that might be unrealistic," Gavin said.
David Grant, director of product management and marketing, at Watchfire Corp., in Waltham, Mass., agrees that security testing should begin earlier in the software development lifecycle. However, he said, today the users of Watchfire's AppScan application scanning tools are primarily the experts on the security audit team. The problem, he said, is that "the security audit team becomes a bit of a bottleneck, trying to keep up. And what's troubling is the auditors have no way of knowing if developers fixed the problems they identified, because it often doesn't come back to them."
Gavin's recommendations are to bring in hired experts for sensitive applications, teach QA staff to think like attackers, and provide the tools to carry out those attacks.
He divides software security testing tools into three categories.
- Application scanning tools, which are offered by vendors such as Application Security, with AppDetective; Cenzic, with Hailstorm; SPI Dynamics, with WebInspect; Watchfire, with AppScan; and the open source Nitko project.
- Proxy security testing tools, which are offered by vendors such as Immunity, with Spike Proxy; Maven Security Consulting, with Achilles; and the open source Paros Proxy.
- Automated penetration testing tools, which are offered by vendors such Core Security Technologies, with Core Impact; Immunity, with Canvas; and the open source Metasploit.
Additional advanced testing tools include reverse engineering tools such as decompilers, disassemblers, debuggers and hex editors.
Even armed with those tools, organizations still need human expertise. "If you just use a tool, you're only as secure or as good as the tool is," Gavin said.
|
|
|
|
|
If you just use a tool, you're only as secure or as good as the tool is.
Michael Gavin
Senior analyst, Forrester Research Inc.
|
|
|
|
|
|
|
|
|
|
A lot of the automated tools do fuzzing, he said, "which is basically throwing random junk into input fields and seeing what comes back. But what we haven't seen from most is the ability to customize the fuzzing." And even if the tool can be customized, testers need "some knowledge about what the tool is doing and how the software is reacting to it. That enables you to perform a more complete test."
And, he added, "If the tool isn't doing a good job fuzzing, or it just stock tests that don't break the application, then you will get false sense of security. Automation is great, but you need to apply extra knowledge."
Watchfire's Grant agrees. "We're always trying to automate more and more, but we won't tell you we automate 100%. You need some human interaction for security vulnerabilities." And the issues, he said, may not be actual vulnerabilities but, for example, "the funny way you're collecting a password, or maybe you shouldn't be collecting a password at all."
Rolf Moulton, president and CEO of (ISC)2, a security certification consortium, said often the people interaction gets filtered out. You need people to make decisions; you can't rely on technology, he said. "To build the right solution, you need to know the problem and know the business," Moulton said.
Bringing in experts is also appropriate, Grant said, along with the in-house use of automated tools. "We won't replace third-party testing, but applications are always changing, so you can't have someone just once month or a quarter."
The biggest challenge for those testing security, though, is to think like an attacker, and to use the tools like an attacker would, Gavin said. "It's a big change in mindset. It's going from, 'How can I get this cool technology to do this neat feature,' to saying, 'Somebody wrote this really cool program; let's break it.' "
|
|
|
|
