Rolling Review: Cenzic's Hailstorm Enterprise Application Risk Controller

Cenzic's Hailstorm Enterprise Application Risk Controller isn't what we'd call eye candy. Fortunately, this Rolling Review isn't a beauty contest-Ajax apps pose potentially ugly security risks, and we wanted scanners that go beyond finding flaws in conventional Web applications.

Why are Ajax apps so insecure? From an architectural standpoint, an Ajax application might look better and seem faster, but it adds much additional complexity compared with a conventional Web app. While the larger layers of the OS along with the Web server used to be the risk components, their security has been strengthened by decades of scrutiny. Even browsers, under heavy attack recently, have seen a number of security improvements. But programming languages are languishing--where a core team of skilled developers is behind an OS or server, there are orders of magnitude more developers each doing their own applications, often with little understanding of current threats and using frameworks that are only just now beginning to take security seriously.

The answer? Longer term, develop programming language frameworks that simplify the task of coordinating code on both the client and the server, and include out-of-the-box protection for common attacks like SQL injection and XSS. Microsoft's ASP.Net Ajax framework is a good example of one toolkit that is making progress in that area.Shorter term, get yourself a Web application scanner with Ajax capabilities.

Going Under The Hood

In the IDS/IPS world, one topic that splits vendors into two camps is that of open versus closed signatures. While companies like IBM ISS regard their signatures as secret sauce and tie them closely into the flow of traffic through various decoders and detectors, other products, such as in the popular open-source Snort IDS, decouple the signature language from the processing engine so that signatures can easily be understood and modified.

The same conundrum applies to Web application scanners. When using the open-signature approach and a false positive crops up, it's easy to not only see why it occurred, but you can adjust the signature to minimize recurrence of the error. Likewise, a product with an open-signature language allows for creation of new sigs.

Which is best? That depends on the environment. For those who want a hands-off product, the closed-system approach isn't a drawback. But companies with unique needs, and the time and energy to invest in adapting products to their environments, will find an open-signature language crucial.Cenzic has an open-signature format, with all existing signatures visible and written in JavaScript--a language any Web application assessment professional certainly should understand. Hailstorm doesn't have the slick extensions we found in SPI Dynamics' WebInspect 7.0--the first product in this Rolling Review--nor is its interface nearly as usable and pretty. But it was much more accurate in identifying vulnerabilities in our sample applications. It suffered fewer false positives and no false negatives (unless later scanners find new vulnerabilities).

In addition, though Hailstorm couldn't automatically spider our Ajax application, much as WebInspect failed to do, it did learn the site when we manually walked it through the application, a feat WebInspect could not manage.

Unfortunately, Hailstorm found no vulnerabilities after the scan. Is the result of a relatively small application that is simply well-written, or did Hailstorm miss faults? That will be obvious by the end of this Rolling Review series. Stay tuned.

Continue Reading This Story...

Don't Hate Me Because I'm CrampedCosmetic flaws are mainly within the Hailstorm scanning application, rather than in the ARC Web interface. In Hailstorm, activities take a few too many clicks. Starting a new scan, for example, involves creating a job, creating a traversal, dragging the traversal to the job, dragging the smart attacks to the job, then starting the scan. Although the Web interface and the new job wizard make the process much simpler, the steps involved in creating a custom scan feel awkward and nonintuitive. Moreover, the product specs recommend 1,600x1,200 pixel resolution, high for this type of application. The Web interface was certainly usable at lower resolutions, but Hailstorm felt slightly cramped even at 1,280x1,024. Unfortunately, this means that most laptops--especially wide-screens--won't be comfortable platforms for using the scanner.

The ARC Web interface dashboard tries to display at-a-glance the current state of all applications being monitored. On the upside, the product is meant to constantly scan applications and track the overall exposure from each. This Web application vulnerability-management approach is necessary in environments where the application as tested last month isn't the application that's running now due to upgrades, patches or other fixes.

Unfortunately, all that data is displayed by way of an arbitrary "HARM" score. The metric is computed by assigning each application a risk, and computing that value together with a predefined (though customizable) rating for each instance of a discovered vulnerability. The problem with HARM is that it's overly simplistic. Is an application with a 10,000 HARM score at more risk, or more work to fix, than one with a 3,000 HARM score? Maybe, but maybe not. One of our sample applications had a very high HARM score from a single vulnerability type, for example; but if all those vulnerabilities are in the same section of easily patched code, the HARM score would not be a useful metric for overall exposure.

Those are evaluations a human needs to make. Cenzic has the right idea in integrating a dashboard display and trying to present a lot of information in a simple interface. But we're afraid it may lull some IT folks--arbitrary values have a hard time summing up complicated realities, especially without options like being able to scale multiple identical vulnerabilities on a logarithmic scale.

Jordan Wiens is an NWC contributing technology editor and a network security engineer at the University Of Florida, where he works on IDS/IPS, forensics, vulnerability assessment and system security. Write to him at [email protected].