The key to accurate and insightful Web security scans

You've likely found that Web vulnerability scanners aren't just point-and-click. Maybe so for relatively simplistic marketing websites but not for complex applications. In fact, one of the greatest ways to get a grand false sense of security is to turn a Web vulnerability scanner loose on your site/application and assume everything of consequence has been discovered and audited.

The thing is we're now seeing an entirely new set of Web applications that just aren't that simple to assess with an automated tool. Be it an online survey, e-signing application, or e-commerce system if the scanner doesn't know where to go (or client-side Web 2.0 code trips it up) you're going to get a whole lot of nothing in the results column.

Making the problem worse is the fact every application is different...often vastly different. Not just the platform and the coding but the logic and the workflow. It's all those manual clicks in/around the app combined with tons of Ajax, Flash, and other code that's almost impossible for a scanner to traverse that really complicates things. And it's a problem that's not going away.

There's one Web vulnerability scanner that has always helped to take the pain out of this process - at least as long as I can remember. That scanner is HP's WebInspect. Performing a manual scan using WebInspect is very simple: you load up a new scan, tell it you want to perform a "Manual Crawl" as shown in the following screenshot and you're good to go.






















Once you kick the scan off, WebInspect automatically loads Internet Explorer for you to step through the application. Meanwhile, in the background, the scanner captures every page you browse to, every input you provide (login credentials included), and every script that's run. Once you're done you simply close out Internet Explorer and WebInspect should complete its crawl (you may have to click Finish). If the application logs the scanner out, WebInspect will automatically log itself back in.

[Side note: This assumes that Default Audit Mode under Edit/Application Settings/Step Mode is set to Manual Audit (which I prefer). Otherwise the audit will have already started during the crawl phase and may complete (you sometimes have to pause the scan and restart for it to complete)].

Once that's done, you'll then click the red Audit button, select the audit policy you want to use, and WebInspect will continue on testing the pages it crawled for vulnerabilities. That's it.

It's still up to you to know and understand the logic and workflow of the application you're assessing. If you don't step through the application in the right ways or overlook critical parts of it, you can't blame the scanner for not providing good results. It will if it knows where to look and what to look for.

Bottom line: you absolutely cannot rely on the results of a basic Web "scan" in the name of PCI DSS compliance or whatever. You have to use a good scanner...in all the right ways. No one ever said it was easy. But done right, the payoffs are worthwhile.

Securing and hacking Windows go hand in hand

Computer hacking concepts extend to every nook and cranny of what we work with on a daily basis. Front and center are Windows-based servers. A large part of what I do in my work performing internal security vulnerability assessments - a.k.a. pen tests and audits - involves Windows servers. There's so much you can do to build up Windows server security and so much you can take to bring it down. I recommend both approaches. Here are two pieces I've written that cover each:

The very best Sysinternals tools for Windows server security

Step-by-step guide: Hacking Windows file servers

Crunch risk numbers or fix the obvious?

My colleague Ben Rothke (@benrothke) recently wrote a good piece on basing information security decisions on good data. I like his approach - it'll make you think. It's true we do need good data so we can make better decisions. Sadly, we often don't have the data or, if we do, we're not qualified to interpret it.

Maybe it's just me but I don't believe my degrees in computer engineering and management of technology qualify for "enterprise statistician". That still doesn't make information security oversights okay. The dilemma reminds of something that Gilbert Arland once said: "Failure to hit the bullseye is never the fault of the target." We do need good data. It's just not that simple in the world of information security.

The problem is similar to the underlying principle of goal setting and leadership: how are you going to know where to go if you don't know where you're going, much less how to get there?

The reality is, we're never - at least for the foreseeable future - going to have all the right data to make good information security decisions. We have to do the best with what we've got. But that shouldn't keep us from focusing on what's obviously important. Case in point I can say based on experience that the majority of organizations I've seen (both small and large) haven't even addressed the basics of information security. Why burden ourselves with complex risk calculations when the bleeding and the cure are right before our eyes?

Don't get me wrong. Quantifiable risk calculations have their place in our industry. But unless and until we get the basic stuff under control, what's the point of making things even more complicated? I'm just saying.

Staying tuned for Part 2 of Ben's article...

The case for zero-day testing

Here's a good piece by David Maynor regarding penetration testing and whether or not zero day exploits should be used. I agree with David. With penetration testing, ethical hacking, vulnerability assessments - whatever you want to call them - anything should be fair game. That is if you want a real-world view of what's at risk. Limiting your tests could skew the results and you'll end up with a false sense of security when nothing big turns up.