Seven Signs You’re Not Ready to Run a Web Vulnerability Scan

Looking to hop aboard the Web vulnerability scanning bandwagon to see just how vulnerable your Web site or application really is? Well, not so fast. Here are some signs you’re not ready to begin just yet:

1. You don’t have any desired outcomes from your scanning other than a PDF report you can share with management. Put nothing into your scans and you’ll get exactly that.
2. You’re using an outdated, unproven, “free” scanner because people on the Internet said it was good. In terms of learning curve, finding the issues that matter, and reporting, a free scanner is often the costliest tool of all.
3. You haven’t bothered to at least read the included documentation to learn the basics on how to use the scanner. Entering a URL and blindly clicking Go is a surefire way to not only get very little out of what you’re doing but to also create a false sense of security that all’s well if nothing is found.
4. You’re doing it to please someone else – or shut someone else up – and aren’t going to take any real action on the findings. Creating the facade that you’re doing the right thing in the name of “audit” or “compliance” creates more risks than it mitigates.
5. You’ve gotten the impression that all you have to do is look for Web security issues that match the popular top Web vulnerability lists available on the Internet. Just because a certain set of vulnerabilities happen to be the most common doesn’t mean you’ll have them nor does it mean you won’t have extensive issues beyond them.
6. You’re prepared to announce to management that the sky’s falling and the plug needs to be pulled on your business’s Web presence simply because it appears a huge flaw is present. Making a big deal out of everything without determining the actual impact to your business is a great way to lose your credibility and put an end to any vulnerability assessment program you’re trying to build.
7. You’ve been instructed to just run a quick scan from the Internet for now. Not looking at an application from every reasonable perspective – both with and without authentication – will rarely serve to give you what you need.

In our world of information security, when it comes to scanning Web systems for vulnerabilities, “good enough” hardly ever is. If your true goal is to minimize business risks then you might as well go about running your Web vulnerability scans the right way. By doing so, you’ll get more out of your money and your efforts, you’ll find security flaws that matter in your environment, and you won’t be surprised when you find out someone else discovered a flaw that you missed.

Go into this with the proper mindset and you’ll do just fine. Jump in headfirst without thinking and you’re setting yourself – and your business – up for failure.

Share this post
  • I understand the point of the article, but it has such a negative tone…on the edge of offensive. You advise, “go about running your scans the right way” but after an entire article telling the reader we’re doing it wrong, there is no solution or guidance offered as to what the right way is.

  • Thanks for your feedback Kara. Sadly I see these issues all the time hence my approach. Running scans the right way is to *not* run them in the ways I list in the seven steps above.

    If you’re looking to learn more, there are some resources to help you out including:
    #This Acunetix blog
    #The OWASP site (www.owasp.org)
    #The Open Source Security Testing Methodology Manual (http://www.isecom.org/osstmm)
    #My book Hacking For Dummies (currently in its 3rd edition)

    Best of luck.

  • Hmm the article tone is a little off I have to agree.

    But as a poor developer who wears the security hat I have to say:

    You know the problem isnt usually us, its management. My manager WANTS a pretty all green ticks PDF. He wants me to concentrate on the “top ten web threats” and not on the applications specific flaws. He wants to look good to his seniors and thats what they want. We don’t want or need security, we need compliance (PCI) but we certainly don’t want it. It’s just a cost! It raise’s my bottom line! We have been online 10 years and we have not been hacked into (sic) so I can justify that the cost outweighs the benefit.

    I try, I really try hard to get them to understand the correct mindset. But when business only does security for compliance, you probably shouldnt dump on use poor dev’s. You need to be addressing managment, not us. WE get it. THEY don’t and thats the problem.

    So perhaps you could offer us some tip’s on how we get to the state of being ready? I know how to do a proper web app security assesment. How do I persuade the powers that be that we need to do so and for the good of the company and not just for compliance?

    Any tips greatly appreciated!

  • Stefan,

    Thanks for your feedback. You’ve made some very good points. I have a forthcoming post on getting developers on board with security where I talk about the underlying problem with management and others not buying into application security. Be on the lookout for it in the next few days.

    In the meantime, check out these links for articles I’ve written on selling security, getting others on your side, and playing the political game in IT to your benefit:

    http://www.principlelogic.com/careers.html

    http://www.principlelogic.com/management.html
    [the “Building credibility and getting others on your side”, “How to get – and keep – user support with security”, “How to get management on board with Web 2.0 security issues” and “Selling security to upper management” articles]

  • Thanks for the reply Kevin, most appreciated.

    Some interesting reading on topics I have been looking for. Cheers.

  • I’m still amazed at how security is developed after the application, like it can be easily saddle stitched in.

    I also see the same developers make the same security mistakes over and over again-You’d think they’d work from a checklist.

    I also see that if I expose a security threat on one input form that developers dont traverse the other input forms and apply the fix. As a tester I have to expose and “bug” each occurance then verify across the board. If I miss one form in my initial bug report I know it will be not be fixed by developer due diligence.

    I’m off to try the free v7 version 🙂

  • Thanks for the feedback Kevy…well put. These are interesting issues indeed.

  • Leave a Reply

    Your email address will not be published.