Vulnerability assessment is a necessary component of any complete security toolchain, and the most obvious place to start for anyone looking to improve their security. Ironically, starting with vulnerability assessment can actually degrade an organization's overall defense by shifting focus from the cause of most outages and breaches: misconfigurations.
Misconfigurations - Not Very Cool, But Extremely Important
Sophisticated, high-profile attacks get the most attention, in part because they are terrifying and in part, let's admit it, because they are cool. Transmitting a binary across air-gapped systems using fluctuations in temperature caused by CPU usage is cool. Logging into a system where the username and password haven't been changed from the defaults, or are on a post-it note hanging hanging from the monitor, are not cool. One of these vectors is far more likely to happen to you than the other. Given limited resources, you would do better to invest in the far more likely risk.
To put it in everyday terms, skipping configuration integrity to jump straight to vulnerability detection is like taking classes on how to wrestle alligators and driving there with your seatbelt unbuckled. While you might fare much better in an encounter with an alligator, you've increased your overall risk of mortality by missing the fundamentals.
Integrity, Availability, and Confidentiality - Not Just for Campaign Slogans
"Putting the fundamentals of information security front and center provides the means to prioritize competing initiatives and make misconfigurations a top concern."
The significance of configuration integrity and vulnerability assessment should both be measured by their ability to increase information security. The three components of information security are data integrity, availability and confidentiality. A loss of data integrity means it has been corrupted; availability means it can no longer be delivered to the appropriate user; and confidentiality means that it has been made available to an incorrect user. Putting the fundamentals of information security front and center provides the means to prioritize competing initiatives and make misconfigurations a top concern.
Making a List and Checking it Twice
What does vulnerability assessment catch? A software vulnerability means that a particular crafted input to a program can result in a loss of information security, from low severity denial of service attacks to business-rattling data leaks. Vulnerability assessment is one way to improve information security by comparing the software you have to a list of software that is known to have vulnerabilities. (Getting the list and executing the comparison is complex, but at least the idea is straightforward.) The list of vulnerable software grows over time as security researchers experiment with new ways to make programs do something they're not supposed to. Once a program is known to have a vulnerability then the provider issues a patch, users update, and they are no longer subject to that vulnerability.
At least in theory.
Reality Check, Please
Basic patching is a critical activity for infosec, but one that is easier said than done. Patches for zero day vulnerabilities are rushed out to mitigate an urgent risk and may introduce operational problems-- ie, a loss of availability-- due to a limited testing window, limited development resources for open source software, and the permutational complexity of the systems themselves. They also may require additional subsequent patches to address more sophisticated methods of exploiting the same underlying problem. (And some problems may be so fundamental that there is no easy and foolproof solution.)
Vulnerability assessment is, to borrow Gartner's phrase, bimodal. On one hand, organizations want to keep up with whatever the latest exploit is that they're seeing on zdnet. On the other, they are more than likely already way behind on the ever growing list of known vulnerabilities. 99% of vulnerability exploits in 2014 had patches more than a year old. That is to say, you would be 99x better off ignoring whatever is on the front page of the internet and instead fixing something that's been broken for over a year.
Beyond the Seat Belt - Fixing the Car
"Through 2020, 80% of cloud breaches will be due to customer misconfiguration, mismanaged credentials or insider theft, not cloud provider vulnerabilities."
Patches might address vulnerabilities but they also might just address bugs, providing further evidence that good information security practices are on a continuum from out maneuvering clever attackers to avoiding dumb mistakes. If we continue down the continuum past basic patching then we get to misconfigurations. Just as patching has a bigger impact on security than cutting edge vulnerability detection, configuration integrity again has a larger effect on your ability to maintain information security. Numerous studies have found that misconfigurations are responsible for the majority of breaches and outages. According to Gartner, 99% of all firewall breaches will be caused by misconfigurations, not vulnerabilities. Gartner's previous analysis adds that misconfigurations account for some 70% of mobile breaches and 80% of cloud breaches as well. At some point it seems like an abuse of language to blame vulnerabilities when the software itself is badly out of date or even past end of life.
Vulnerability assessment is a valid concern, but one that must come after repeatable, auditable processes for remediating misconfigurations. Not only are misconfigurations more likely to lead to business disruption due to a lapse of information security, it is unlikely you will be able effectively remediate the vulnerabilities themselves without the processes. For the sake of clarity, it is worthwhile to continue to use "vulnerability assessment" to mean the comparison of actual software versions to those on a blacklist. For pragmatic operations and security professionals wondering "am I vulnerable to a loss of integrity, availability, or confidentiality," misconfigurations should be the first things they check.