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 -- oftentimes "Level 5" or "High Priority" -- that really have no bearing in the environment I'm testing. They may include:
- Windows shares accessible when logged into the network
- OS or network protocol problems that have no known patch or fix
- Default manual pages and other "readme"-type files found on Web servers that are of no value to an attacker
- Cross-site scripting and SQL injection vulnerabilities that don't really exist
- Essential network protocols, such as RPC and ICMP, flagged as enabled when you need them no matter what
- Database tables, log files and other sensitive information that are accessible but only when the sa account is logged in
- Email, FTP and telnet login banners accessible to the public when they've got to be anyway
- Encryption weaknesses related to data in transit that will likely never be exploited. And even if they were, the small amount of information captured would be too little to benefit from.
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:
- Know your network and application environment like the back of your hand. Get involved with how everything on your network (routers, firewalls, workstations, servers, applications and databases) works together. This means creating and maintaining that ever elusive network diagram.
- Pick a good set of vulnerability scanning tools (i.e., one for operating systems, one for Web applications and one for databases). Stick with them, and learn them like nothing else. I've been using some of the same vulnerability scanning tools for more than six years and I still learn new things about how they work and how I should treat the results they supply.
- Always work toward enhancing your technical skills. Read articles and books, listen to webcasts and attend seminars and conferences to keep feeding your mind all the technical intricacies involved with network protocols, OSes, databases and even basic software development concepts -- especially related to Web applications. This education will help you understand what your vulnerability scanners are telling you.
- Focus on the urgent and important vulnerabilities that the scanners discover -- that is, vulnerabilities on your most critical systems that can be exploited with serious consequences right now. Go for your highest payoff tasks.
- Save some vulnerabilities for a rainy day when you've got nothing else to do and time to experiment. For instance, if your tool flags something as a serious issue but it isn't able to exploit anything and you can't glean any information or manually exploit the vulnerability found, then it's probably not urgent or important.
- If you're ever in doubt about a vulnerability, never ever apply the vulnerability scanner's recommended "fix." That can cause a lot more problems than you're trying to solve.
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.
