Back
What Happened to Vulnerability Management?
A recent spate of data breaches has highlighted the fact that, even in 2011, many organizations still have not managed to grasp the concepts of vulnerability management. It is certainly the case that no organization, no matter what sort of controls are in place, can eliminate risk completely. However, the apparent ease with which some of these attacks have been carried out makes one wonder what sort of vulnerability management practices, if any, these organizations had in place. At the most basic, vulnerability management should be a cyclical process that involves the identification, analysis, reporting, and remediation of weaknesses in system configurations and software. Before vulnerability identification can begin, though, it is necessary for an organization to have an understanding of what assets (i.e., systems and data) exist and where they live. This, of course, is itself an ongoing process, as few IT environments are very static. Vulnerability identification is, believe it or not, often one of the easier steps in the vulnerability management process. There are numerous options available to assist organizations in identifying weaknesses in their environments, including automated scanners, patch and configuration management utilities, and assessment service providers. Regardless of the sources of this information, it should provide insight into vulnerabilities in system and software configuration, patch levels, and application code. Analysis of the identified vulnerabilities should include prioritization based on risk to the organization’s assets. Information such as CVSS score can be helpful in this regard. Also, categorization based on vulnerability type, infrastructure area, and business unit may also be beneficial, particularly in larger or decentralized organizations. Internal reporting of vulnerabilities sounds simple but, in larger IT groups, can actually be surprisingly complex. A process needs to exist to ensure that vulnerability information is distributed to the proper individuals in a timely and organized fashion. Ticketing systems can be a useful tool in this regard, particularly if your vulnerability assessment, analysis, or correlation tool can integrate directly with the system. Finally, identified vulnerabilities should be remediated. In the ideal scenario, this simply means applying a patch or changing a configuration setting. However, it is not uncommon for this to be a sticking point. Whether due to patch incompatibility or a business need for particular features or configurations to exist, it is all too common for identified vulnerabilities to go unmitigated for long periods of time. This is somewhat understandable and sometimes risks do need to be accepted but, often, the business impact of a vulnerability is not fully understood by the risk owners. Ultimately, risk owners need to realize the implications on the entire environment if they choose to allow vulnerabilities to persist (see Scott Sutherland and Antti Rantasaari’s “When Databases Attack” presentation for some great examples). Ultimately, vulnerability management does have some complexities but it is an absolutely critical component of a comprehensive and effective information security program. Security can never be a sure thing and threats will always exist. However, in this day and age, there is really no excuse for organizations to lack a formal approach to identifying and treating vulnerabilities, particularly in their Internet-facing infrastructure.
