Five Secrets and Two Common
“Gotchas” of Vulnerability Scanning
An Insider’s Guide to Best Practices
Tips from Ed Bellis, Former Orbitz CISO & Founder of Risk I/O
IT security professionals are the unsung heroes of each organization. I know, I used to be one. When I ran Security at
Orbitz, it was absolutely critical that my team and I stayed on top of threats, attacks and potential exploits. And we had to ensure that our execution was flawless, every day, despite the fact that the influx of new data and threats was never ending. Any slip up could put the company at risk of a breach.
While in the trenches, we developed a series of best practices for working with vulnerability scanners such as Qualys, Nessus, Rapid7 and the rest. I found that following these practices dramatically improved our company’s security posture, and helped all of us sleep a lot better at night.
Here’s what we learned:
1. CVSS is great. But it’s only part of the picture.
CVSS is table stakes these days when examining vulnerability scan results, but you need to be careful to not place too much reliance on CVSS when prioritizing your remediation tasks. CVSS has the ability to add temporal data in the effort to account for changing threats; however, temporal scores can only lower and not raise the actual score. So if you look at CVSS and only focus on the 8’s, 9’s and 10’s, you may be missing the actual dangers.
Let me give you a hot button, commonly referenced example: the Heartbleed vulnerability exposed the majority of web servers running over SSL on the Internet and allowed for the leaking of data (including the very encryption keys that protected them). But how did CVSS rate
Heartbleed? It scored at only a five.
Why did CVSS misread Heartbleed so badly? The scoring system doesn’t allow for a high score on a vulnerability whose impact is “information leakage,” even though in this case the information being leaked could have been—and was—highly sensitive. You have to take into account an ever-shifting threat landscape and model, asset priorities, and mitigating controls in order to take a holistic approach to prioritized remediation.
2. Authenticated scans are your friend.
One of the common complaints of vulnerability scan results is false positives. While not foolproof, running authenticated scans can go a long way to removing false positives and has the added benefit in many cases of providing a CPE fingerprint.
If you’re not familiar with the acronym, CPE stands for Common Platform Enumeration. The
CPE fingerprint is a machine-readable representation of what is running on a particular asset down to the exact version. This will give you the ability to track assets, and it can serve as a poor man’s asset management system. One quick security benefit of knowing what your assets are running is knowing when new vulnerabilities come out and what assets they affect without running a scan. You can find more about CPE here: https://cpe.mitre.org/
Of course, authenticated scans apply to your web application scans as well. Authenticated web application scans allow for detection of vulnerabilities to the protected areas of your application, which is likely where the valuables are stored and processed. I’m still surprised to see many organizations scanning their publicly facing web applications, but not setting up authenticated scans.
One note here: authenticated scans will produce a greater volume of results. This means, of course, that you must be mindful and test these scans on non-production systems prior to rolling out.
For more vulnerability scanning best practices: visit www.risk.io
Five Secrets and Two Common “Gotchas” of Vulnerability Scanning
2
3. Remember the OSI stack has 7 layers.
As mentioned above, you can’t forget about your applications. I see an amazing number of organizations that are far along in their network vulnerability scanning programs, yet they aren’t doing anything with their applications. Scanning your
