informa
/
Risk
News

The Worst Reason to Buy a Scanner

Application scanning can speed the discovery of vulnerabilities, but it's no substitute for good app development

4:21 PM -- I've recently been on a bit of a kick, reviewing scanners and working with scanning companies. I've been a long-spoken advocate of doing manual assessments as well, but there are obvious reasons why scanners make more sense for certain time-consuming tasks.

On February 11 I'll be giving a speech to the Minnesota OWASP chapter (where Bruce Schneier spoke last) on the topic of scanners.

At first, I thought it would be hard to fill 10 minutes with a talk on scanners, let alone two hours. Then I got to writing -- and as five slides turned into 30 I realized I have a lot more to say about scanners than I originally thought I did. It shouldn't be hard to fill two hours with my own special sort of ranting.

But one thing in particular occurred to me as I was writing my speech -- a bizarre way of thinking that I haven't even considered in years. Once upon a time, I too was a developer, and I had lazy days just like everyone else. In fact, I sometimes tell people I'm the worst programmer ever -- it was never about making the best code in the world. Just like now, back then everything in my world was a hack.

But when I heard one of the reasons people wanted to hear my speech, I almost fell over backwards: Some people believe using a Web application security scanner is a good alternative to building secure applications. Wow.

It's one thing to build an app with known risks built into it, and it's another to not have any idea that your code could be vulnerable. But it's completely irresponsible to intentionally forgo any security training or coaching and simply assume that any problems will be fixed by a scanner.

Let me spell out the harsh realities here, because I really think that at this point, this has gone too far. Scanners aren't an insurance policy. They miss stuff! Scanners are a useful tool in an arsenal that security pros call "layered security" or "defense in depth." Defense in depth not only works, it's critical -- unless you really like vulnerabilities or turning off the power to your data center.

Secure app development starts with training, peer reviews, code auditing, and QA (including regression and vulnerability scanning). If that's not working, tie vulnerabilities to your staff's bonus structure -- believe me, that'll get them thinking about security. Your deployment strategy should include good logging, multiple layers of risk mitigating tools (if you can afford them), and regular external penetration testing (both manual and automated). This is especially true if you deal with credit cards or sensitive information.

If your stomach isn't churning right now, then either you aren't in charge of anything important, you didn't read that last paragraph, or you're doing things the right way. Even after you implement these best practices for development, you'll still have vulnerabilities -- it's almost a foregone conclusion.

But imagine how much worse off you'd be if you just used a scanner.

– RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading

Recommended Reading:
Editors' Choice
Kirsten Powell, Senior Manager for Security & Risk Management at Adobe
Joshua Goldfarb, Director of Product Management at F5