Alerts started firing from a system server sitting in the DMZ at a remote site of an oil producer. Analysts concluded that a vulnerability scanner had identified a significant security hole. Several e-mails, a few phone calls, and within a few minutes the organization had the information it needed.

The facts: The system in question was responsible for forwarding reports, which would be double-checked using other methods. It wasn’t tied into any critical operations, it was relatively isolated, it didn’t contain overly sensitive information, and exposure wouldn’t affect nearby systems. And it was very remote. Patching would mean putting an IT person on a plane. The company decided that flying an IT administrator out to immediately patch wasn’t worth the trouble or expense. The alert was noted and scheduled to be handled the next time someone did routine maintenance on the server.

The lesson here: For effective vulnerability management, apply risk management principles and logic relative to the business value.
Today’s vulnerability landscape is mined with custom application exposures, infrastructure deficiencies like improperly secured wireless networks, and desktop- and end-user-centric attack methods. As recent breaches have illustrated, a criminal element has moved us from a world of chatty and poorly developed worms to one of stealthy, professionally developed, targeted malware.

IT must work with business units to determine a company-wide security posture that is within acceptable risk tolerance levels, create operational processes that address the computing environment as a whole, and select the right technology platforms to bolster those processes.

A Working Process
Effective vulnerability management programs require the right balance of technology, business intelligence, and process.
Necessary technology includes vulnerability scanners, such as McAfee’s FoundScan, Qualys’ QualysScan, or Tenable Network Security’s Nessus; application scanners, such as Hewlett-Packard’s WebInspect and IBM’s AppScan; and configuration and patch management tools. However, without several critical vulnerability management processes, these tools won’t be as effective.

One vital process is reducing the exposure a company presents to adversaries—sometimes called “attack surface reduction.” The term “attack surface” can refer to a program’s susceptibility to various avenues of attack or to systems as a whole. Companies often use a combination of network design exercises, access management, and configuration management to reduce attack surfaces. For example, a system’s attack surface can be reduced by exposing only required services to the network, disabling or removing unnecessary software, or limiting the number of users authorized to log on to a system.

An effective vulnerability management program also can help manage a company’s overall security posture and risk tolerance. By aggregating vulnerability and incident data, IT can improve security. Trending and data correlation help show how internal activities and external events affect a company’s risk profile. This analysis helps gauge the success of projects, such as patching and system maintenance, while identifying areas where more investment is needed.

Another benefit to vulnerability management programs is they that can help achieve compliance objectives. Technical standards, operational frameworks, regulations such as Sarbanes-Oxley, and industry-specific frameworks such as HIPAA and PCI have spurred companies to implement controls and report on their success. An effective vulnerability management program can help demonstrate compliance with established controls, as well as alert management to compliance problems. Tools and data correlation within a mature vulnerability management program can extract stats about default password length, expiration, and complexity requirements, and pull them into compliance reports.

Nevertheless, we’ve watched organizations sink a lot of money into security tools and elaborate scanning deployments, only to see teams stuck reviewing similar results, report after report, month after month, year after year. The monthly patch cycle is a necessary but relatively well-understood evil that likely won’t end anytime soon. However, most companies regularly find problems in homegrown apps, missing patches that are quite a bit older than 30 days, and devices that aren’t compliant with approved standards. Many of the failures leading to these findings are systemic in nature, and the ability to address root causes is often what separates an effective vulnerability management program from an ineffective one.
So how do we break the cycle of ineffectiveness? A few steps are critical.

Step 1: Integrate Data Collection
The effectiveness of a vulnerability management program is highly dependent not just on the technologies used but on the integration among components. Vulnerability identification systems, such as vulnerability scanners and system policy and device configuration audit tools, provide a basis for gathering data, but tight integration with change management software also is needed.
Configuration management, patch management, and identity and access management tools automate system maintenance and provide a real-time view of system and device state. Integrating these products with vulnerability identification tools gives a company a holistic picture of vulnerabilities and risks in its environment. That said, integrating maintenance and vulnerability identification systems is easier said than done.

The key is to identify which elements are crucial to the program. We recommend taking a top-down approach. For example, companies should take inventory of the systems and data they have in production. Key stakeholders should review the state of those systems, evaluate the organization’s operational capacity to implement changes, and ask high-level questions that support a higher security posture. How many Windows systems do we have in a given region? What is our exposure to Apache problems? As IT teams compile the answers, they should gather the information needed to act as well. If there are 100 Windows systems in Europe, is that enough information? Do I need to know MAC addresses? Asset owners?
Additional technology should only be considered once these questions have been answered.

Step 2: Prioritize
Prioritization is always crucial in IT, but its importance is only amplified in challenging times. Clearly, vulnerability management must be deployed in a way that allows for easy prioritization. This typically means establishing groups of assets, to improve data collection effectiveness; and groups of owners, to facilitate relevant and actionable reporting. Groups often are built along regional, operational (accounting, facilities), or technological boundaries (desktop group, Unix team). When determining security posture, asset groups should be aligned with business functions. Groups must be a manageable size, with clearly defined responsibilities.

In the case of attack surface reduction, ownership groups include IT managers, data center owners, and others responsible for maintaining the security and integrity of systems. When addressing company-wide security, ownership groups typically include members of the security organization, internal auditors, and, potentially, business units. Compliance-oriented ownership groups should be aligned with individuals responsible for enforcing and reporting on compliance.

Step 3: Continue to Refine
Part of continuous improvement includes understanding how individual characteristics affect vulnerability management program objectives. The table above outlines the way seven characteristics relate to the objectives of vulnerability management.

When determining security posture or compliance level, quality data is paramount. Missed vulnerabilities will create a false sense of security, and poor data can generate “false positives”—nonexistent vulnerabilities. Data should be collected frequently when reducing attack surface is the top priority, but is not critical for determining security posture. The frequency of data collection for compliance initiatives will be specific to individual compliance requirements.

Trending is most useful for understanding security posture, success of vulnerability reduction efforts, and compliance-related activities. Trending information will show how an organization’s risk profile changes over time and how external events, such as vulnerabilities and patch releases, impact enterprise-wide security posture.
False positives often erroneously show vulnerabilities and configuration errors where none exist. Trending can reduce false positives, but they can still have a significant impact on compliance activities, because an accurate picture of vulnerabilities is vital for compliance reporting.