This month we are examining vulnerability management tools. This has been an interesting category for several years. The history behind some of these tools, as well as how they have been used, both currently and historically, could be a column all by itself. Briefly, the genre of vulnerability management started with simple vulnerability management.
And that, arguably, started when, back in 1993, Dan Farmer and Wietse Venema wrote "Improving the Security of Your Site by Breaking Into it." Farmer had written SATAN (Security Analysis Tool for Auditing Networks) and many of the functions of SATAN were described in the paper. At some point, someone wrote a version of SATAN called SAINT that did pretty much the same thing - and vulnerability testing was on its way to the mainstream. The idea of this type of security testing was pretty radical for the time and it was by no means embraced universally.
The paradigm at that time was running scripts against the perimeter and the devices on the network with the idea of compromising them and raising privilege levels to root. There was a real distinction made between Vulnerability management and penetration testing. Vulnerability management evolved to vulnerability scanning, and penetration testing remained largely manual for some time. Then a new wrinkle appeared in the form of patch management. Patch management matured into a unique approach with its own tools and processes/procedures/automation. It was inevitable that these three pillars of vulnerability management - a term coined when they converged - would become a mainstay of ensuring security of the enterprise.
Now, let's take a little side trip into the realm of risk. Risk consists, in one combination or another, depending on who you ask, of threats, vulnerabilities and countermeasures. While we tend to think of threats as a synonym for malware, the reality is that malware is just one of many tools used by a threat agent. Manual hacking, denial-of-service attacks, certain types of phishing that do not include malware and, yes, malware - all are tools the bad guys can use to execute a threat against a network. Vulnerabilities are those weaknesses against which the threat actor focuses. What is a vulnerability to a particular strain of malware may not be a vulnerability to a manual hack.
So, when we want to manage vulnerabilities we are, in a sense, managing risk. To do that we need to understand what vulnerabilities are in the enterprise. Those can be unpatched systems, malware waiting calmly to harvest and exfiltrate credit card numbers, a weakness in the network architecture that allows penetration from the perimeter to the internals of the network, or a weak administrator password on a database. So, the whole idea of vulnerability scanning, penetration testing and patch management has become considerably more complicated since the early days of SATAN.
It is that set of challenges that we explore this month. Along the way we encounter some pretty creative tools to untangle this increasingly complicated environment. For example, there still are a few pure-play vulnerability scanners. If we are interested in just the perimeter - an increasingly porous part of the enterprise - scanning is useful as long as the scanner stays current. That is a very big "if," by the way. However, multiple vulnerability studies have concluded that a large percentage of breaches occur because of old, unpatched vulnerabilities - low-hanging fruit, actually. So not becoming low-hanging fruit is one of the reasons to use this kind of scanner.
Manual penetration testing has given way to automated pen testing and there are several tools that facilitate that practice. But, still, a good current knowledge of vulnerabilities is necessary. We can get around that by using passive vulnerability scanning. Passive scanning watches data flows and figures out what should not be happening and what sorts of vulnerabilities - especially misconfigurations - would be at the root of incorrect flows.
Now, we add patch management. At some level, patch management can become very difficult on large enterprises. For that reason it needs to be automated. It also needs to be prioritized. That means that we need to patch the most egregious vulnerabilities first. We want to patch them all, of course, but a triage approach is good also. Therein lies the marriage of vulnerability testing and patch management. Asset criticality is a key issue as well. While just about any device on the enterprise has the potential to be used as a pivot - and therefore needs to be protected - some are more critical than others.
This month we were fortunate enough to see examples of tools that do all of these things and we think you'll enjoy seeing what the current state of the vulnerability management art is.