Gunnar Assmy - Fotolia
Automation: it's the one feature we can't live without in security. We seek to automate patch management, system...
monitoring and alerting, and even certain aspects of incident response and forensics -- it helps us.
I always encourage my clients to automate security tasks where they can, since no one has enough time to do everything manually. If you know an organization that does everything manually, then they've probably already been breached.
There's another important area of security that can be -- and often is -- automated: web vulnerability testing. I've been relying on automated web vulnerability scanners, such as Netsparker and Acunetix Vulnerability Scanner, for many years. I don't know what I would do without such tools, as they can find a lot of relevant web security flaws in a very short period of time.
Personally, I think it's this utility and convenience that gives people a false sense of accomplishment when it comes to running automated web vulnerability scans.
Automating web vulnerability scanners
In terms of web vulnerability and penetration testing, there's absolutely no problem automating much of the process wherever possible. However, with the complexities of today's typical network environment, many IT and security professionals have grown accustomed to being able to click a button and automate all of their web security testing.
I know there are only so many hours in the day, but proper web security testing goes beyond simply pointing a vulnerability scanner at a URL. There are so many nuances to running web vulnerability scans that only an experienced professional is going to know how to properly run them to yield the best results.
I could probably think of a hundred ways that people take web security testing for granted, but I'll focus on one main area: You have to know your scanners and what to expect or you won't get the desired results.
The general assumption is that end users of these tools are supposed to know exactly how to run them right out of the box. Granted, many scanner vendors have done an excellent job fine-tuning the interfaces of their tools, but there's so much more to it.
For example, which scan policy do you use? Do you tell it to look at everything, or do you just have it look for high-risk vulnerabilities? If you just look for high-risk vulnerabilities, then you're probably overlooking a ton of potential opportunities to uncover additional security flaws. But you may not be able or want to run certain comprehensive checks, such as those that can impact a production environment, especially when doing authenticated testing.
Speaking of authenticated testing, do you do it just as an unauthorized outsider or do you do it while logged in as a trusted user of the system? If you want a true picture of where things stand, you have to do both. However, you also need to know which scan policies are good for unauthenticated testing and which ones are good for authenticated testing.
With most vulnerability scanners, I usually select the scan policy that checks for everything as an outsider without authentication. However, given the intricacies and workflows of many applications, combined with the difficulties that many scanners have logging in and staying logged in to the applications being scanned, you often have to perform a less comprehensive scan while doing your authenticated checks. Otherwise, the scanner may just sit and spin for days and never complete its actions; this is something you learn with practice.
Best practices for web vulnerability scanning
Another aspect of web vulnerability scanners is that some are better than others in certain areas of testing. For example, one scanner I use is great at cross-site scripting detection. Another tends to be spot on with SQL injection. Still, there's another popular scanner out there that I have used for years and it never detected SQL injection -- even on applications where one or two other scanners did find it. I have used many different web vulnerability scanners over the years and, in many cases, you actually don't get what you pay for.
Just as challenging, most scanners tend to find their own vulnerabilities. In other words, multiple scanners often find completely different sets of flaws. I learned long ago that you have to run multiple scanners against the web applications you're testing if you're going to get thorough and accurate visibility into where things stand.
There are plenty of other nuances when it comes to running a web vulnerability scanner. Something as seemingly innocuous as scan threads -- the number of concurrent requests the scanner sends to the application -- can impact your test results.
The same goes for running vulnerability scans against applications with contact or similar forms that are not protected with CAPTCHAs. That's a surefire way to create a denial-of-service situation against your production environment -- not to mention ticking off all of the users who have an email account tied to that page.
There are also considerations for testing production versus development environments. If you test production, then you have to be careful not to bring the system down or pollute the database with junk data that the scanner submits. You also have to eventually ensure that flaws don't exist in publicly accessible test systems; if you only run scans against your test environment, then you may not be getting a true reflection of production. These questions and more are often best addressed during the scoping phase of your web security vulnerability and penetration testing.
For a seemingly straightforward security check, there's a lot to learn in terms of web vulnerability scanning. Know your scanners like the back of your hand. Know their limitations. Know that you're going to have to use more than one scanner. And know that you're full of yourself if you simply rely on traditional network vulnerability scanners to do the work and don't use dedicated web vulnerability scanners.
Even with dedicated and automated web vulnerability scanners, you still need a hacker mindset to find the right weaknesses. Web vulnerability scanners aren't going to find everything, but I would say that, on average, the scanners find about 50-60% of the vulnerabilities that I document in any given web security assessment report. Manual analysis with a good old-fashioned web browser, HTTP proxy and similar tools are required to find all the other flaws in any given application.
If you're a CISO, security administrator or a security auditor, how do you reconcile the differences between manual and automated scanning? How can you say -- or not say -- that you have performed reasonable and adequate testing of your web environment and that you truly know where things stand? Unless and until you address some of these hurdles, you simply can't say that.
One thing to keep in mind is that you have to know that there's always more. Don't take web vulnerability and penetration testing for granted, and never assume that simple web vulnerability scans are enough because they're not the same as running scans against network hosts. Even in-depth web vulnerability scans may not provide you with good results because of certain oversights.
Seek out new information, new tools and new techniques. This will help improve your overall security program, while ensuring that web security vulnerabilities don't get your organization into the headlines over a web flaw that could have been prevented.
Read more about beating web app security threats
Discover the differences between security audits and assessments
Find out how Docker APIs can be turned against enterprises