Traditionally—if such a word can apply to the rapidly morphing digital world—companies have secured their web applications by guarding the perimeter with Web firewalls. However, the ever-growing realization is that the real vulnerability lies in the Web applications themselves, which often contain easily exploited security flaws. According to consultancy Gartner, 90 percent of externally accessible applications today are Web-enabled, and two-thirds of them have exploitable vulnerabilities.
That’s where Web application penetration testing tools and services come in. Diana Kelley, VP and service director at Burton Group, says these tools and services conduct automated scans of Web applications that are either in production or just prior to going live, applying threat models and misuse cases to unearth common vulnerabilities. Some of the top 10 flaws defined by the Open Web Application Security Project (OWASP), including SQL injection, cross-site scripting and improper error handling, were until quite recently alien concepts to a lot of people, including developers. In some cases, the tools provide suggested parameters for how to fix these types of problems.
Today, Web penetration testing is considered a key component in ensuring application security, which has become an essential part of enterprise risk management, Kelley says. Or as Joseph Fieman, analyst at Gartner, puts it, “It’s coming down to a race between you and the hackers. Either you use [penetration testing] or the hackers will do it for you.”
According to Gartner, enterprises considering these tools and services should expect substantial market and product consolidation. Acquisitions are likely among the major software development lifecycle (SDLC) platform providers and security vendors, Fieman says. Already the quality-assurance divisions of two heavyweights, Hewlett-Packard and IBM, have bought into the market (acquiring SPI Dynamics and Watchfire, respectively).
Here is advice from CISOs and analysts on how to evaluate and use these tools and services.
Key Decisions
1) Who’s going to use it? Assigning responsibility for securing Web applications isn’t always a straightforward task. It’s a new concept for development groups and QA teams, and security groups are more accustomed to network issues than application issues. So who does the job? According to Fieman, it’s awkward for security specialists to scan the application and forward the results to developers. But that’s exactly what many companies do, at least until the developers accept the idea of using the tools.
Phil Heneghan, chief information security officer at USAID, for instance, has shouldered the responsibility for Web application security, believing it’s ultimately his job to secure the enterprise and that it’s better to have someone other than the application creators assess its vulnerabilities. “You could end up with a rose-colored picture if the developer says, Don’t worry; I checked it, and it’s fine,” he says.
Similarly, Andre Hiotis, technology security officer at NAV Canada, purchased IBM’s Rational AppScan [editor’s note: corrected] more than a year ago and is only now putting it on developers’ desktops to use themselves, at their request. If he’d given it to them at the get-go, he says, they would have been overwhelmed by all the information it produced. As it is, his team has had time to learn the tool and can now provide assistance to the developers when they use it. Security staff is also better equipped to prioritize and edit the tool’s voluminous reports and will continue to provide that service. “If the developers saw 100 things needed to be fixed, they couldn’t judge which were high, medium or low risk,” Hiotis says.
2) Service or tool (or both)? You can buy the tool and dedicate resources to building a robust testing capability, or have a vendor scan your Web applications remotely, validate the findings and produce a focused report. Most leading vendors now offer both options, except WhiteHat, which offers only a service-based solution. “Many companies wish to perform their own testing in-house, for control, management and privacy purposes, but there’s a large and growing market for scanning services,” Kelley says.
And some organizations are choosing to use both. The manager of information security at a large healthcare organization (who declined to be identified), for instance, temporarily halted the use of WebInspect when he found he didn’t have the staff resources to manage the volumes of data it produced. “You need human intelligence to eliminate the false positives and get a complete analysis of where the vulnerabilities lie,” he says. He turned to WhiteHat for help interpreting the results and working with developers to fix problems.
After a year of becoming accustomed to the service, he’s now expanding the use of his original tool and is planning to take a three-tiered approach. Developers will test coding and compilations on the fly with WebInspect, and then security staff will run a second scan with that tool. On the third pass, they’ll push the application out to the Internet and have WhiteHat run a test.
3) How will you integrate? These tools operate best when they are integrated—either natively or through an application programming interface (API)—with other systems used by developers and the QA team. These include QA and testing tools, as well as content management, project management and
scheduling tools, so the scan results can be tracked and fixed like any other code defect. They should also tightly integrate with SDLC platforms such as Microsoft Visual Studio, so that, ideally, developers could run a scan from their desktop, using an interface similar to their development tool’s.
It’s also optimal for the tool or service to export results directly to a static source code scanning tool. That’s because while Web application testing tools can tell you what kind of vulnerability you have, they don’t pinpoint the exact location in the code where the problem lies. “Detecting vulnerability is 50 percent of the job,” Fieman says. “You have to close the loop.”
Evaluation Criteria
According to Gartner, there are almost no dramatic differences between vendors’ scanning technology principles; differentiation lies among vendors’ ability to do the following:
Dos and Don’ts
DO make sure your company is ready to make a real investment not just in the tool, but also in training, staffing and developing robust processes around finding and fixing vulnerabilities. “The main weakness I see is companies that feel they can take the product, point it at their applications and get the same wealth of information they could get if they did manual or highly assisted testing,” Kelley says. “You have to educate your testers on how to test, and they need time to work with and configure and use some of the add-ons provided to assist the process.”
DON’T expect developers to love the tool right away. Many developers have been blissfully ignorant of Web application security elements and are either embarrassed, insulted or just not interested in what these tools reveal. “One of the biggest pain points was getting people to accept the seriousness involved with this,” says the security manager at the healthcare organization. It took his organization a year and a half to get developers to adopt the tools.
DO realize the limitations of these tools. Some people want to believe that if the tools don’t find a problem, they’re home free, says Gary McGraw, CTO at security consultancy Cigital. “But the only thing it can tell you is you don’t have these [specific] problems,” he says. “If they had a list of all possible security problems ever in the history and future of the planet, that would be a great thing, but that’s impossible.” That’s why McGraw famously called these tools “badness-ometers”—they can tell you when your code is bad, but they can’t tell you that your code is lock-tight secure. Not that the tools don’t have value, McGraw says; they do shorten the testing cycle considerably, but humans are often needed to validate that a problem exists.
DON’T think one tool will find every problem. At the healthcare organization, “We’ve found vulnerabilities with SPI that WhiteHat didn’t and vice versa,” the manager says.
DO realize that security is not a one-time event. Because Web applications are ever-changing, they must be tested continuously to ensure no new vulnerabilities have been introduced, Burton Group’s Kelley says. Even OWASP continuously changes its top 10 guidelines. Heneghan scans his organization’s Web applications once a month. The healthcare organization security manager warns it can take one or two days to crawl through all his firm’s applications and produce an analysis.
This article appeared in CSO Magazine as “Patching the Holes in Web Application Security”. Mary Brandel is a freelance writer. Send feedback to csoletters@cxo.com.