I'm often on my soapbox talking about how good security testing tools are required for information security success. This is especially true for the in-depth operating system, Web application and database vulnerability scanners.
Security testing tools are fast and efficient and they can root out security weaknesses in your operating systems (OSes) and applications that would take even the best security expert days or weeks to find (if they can find them at all). Simply put, good vulnerability scanners take the pain out of performing your ongoing security assessments and are a must-have in order to stop yourself from going crazy trying to keep up. But you've got to take what they find and what they rank as vulnerabilities with a considerable grain of salt.
What our vulnerability scanners find isn't always reality. Vulnerability scanners return information that the vendors think is important. The problem is that many of the vulnerabilities found and ranked as high, medium or low priority don't really apply to your environment at all.
There's also a chance bias or conflict of interest when an IT auditor looks for something -- anything -- to flag as a problem. The same goes for external experts you may hire to perform independent assessments. A fancy report containing tons of security vulnerabilities looks good for them but it is likely not in your organization's best interest.
In the security vendors' defense, they're likely erring on the side of too much information rather than not enough. I'd rather it be that way, but it does require some work to sift through the noise.
In reports, I often come across vulnerabilities that are flagged as a considerable security problem --
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
oftentimes "Level 5" or "High Priority" -- that really have no bearing in the environment I'm testing. They may include:
Differentiating the fact from fluff is all about context -- what was being tested at the time, where it was being tested from, how it was being tested, who you were logged in as, why the vulnerability is exploitable and whether or not there's a fix.
This is where you can educate others (including your boss or project sponsor) on the fact that you can't lock everything down completely. There will always be a certain level of security issues that must be accepted.
There are six takeaways from this:
No matter how sophisticated your security scanning tools are and no matter what the vendors say, you're still going to need to get involved and use your knowledge of your network, your scanner(s) and information security in general to determine which issues need to be addressed and which ones don't apply. You need good tools, but in the end, there's no replacement for the human element and good old-fashioned experience.
About the author: Kevin Beaver, an independent information security consultant and expert witness with Atlanta-based Principle Logic, LLC,has spent six long years obtaining his degree in computer engineering that included Blue Pill like bit and byte manipulation. He has more than 18 years of experience in IT and specializes in performing information security assessments for compliance and IT governance. He has written six books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at kbeaver@principlelogic.com.
