|
Many organizations have at least some vulnerability management products. In many cases, however, they are point solutions that only partially solve the vulnerability management problem. This often results from an incomplete understanding of the full range of vulnerability management issues, as well as the relatively new market for commercial enterprise-class vulnerability management products, which has developed only in the last few years. Attempting to integrate point solutions into a comprehensive whole or using administrative guidelines poses its own challenges. However, these challenges are much easier to solve when you understand the problems you face and you have a proven methodology to follow.
The Problem
To understand solutions and methodologies that facilitate an enterprise’s vulnerability management program, you must first comprehend the problems faced and the challenges in implementing the solutions. A good starting place is with the typical vulnerability lifecycle. The cycle below depicts a typical remotely exploitable “zero day” vulnerability disclosed publicly before a patch is available. Be forewarned though, not all steps will occur for all vulnerabilities, and not always in the order presented.
- A vulnerability is created
- often unintentionally when computer code is written or updated
- or when a system is misconfigured
- The vulnerability is discovered -- often by a “hacker” or security researcher
- The vulnerability is published and disclosed -- either publicly or privately
- Proof of concept exploit code is created, usually performing an innocuous task
- A configuration-based fix is published
- An actual exploit or virus is created
- A vendor patch is created, tested and made available
- The patch is tested by the customer and then deployed
|
This highlights the major problem facing security managers today: the notion of minimizing the “vulnerability window.” This window opens when the vulnerability is disclosed, and closes when the end user fixes or mitigates the vulnerability. Regardless of the type of remediation, as long as the window is open, the system is vulnerable. And once a system is compromised, it is often used as the new attack vector to reach and infect other systems.
Figure 1 – Prototypical Vulnerability Window
151
180
Blaster
Welchia/ Nachi
Nimda
25
SQL Slammer
When previously published vulnerabilities are compared to the vulnerability cycle described above, one can begin to predict future events. For instance, if a proof of concept exploit is made available the same day the vulnerability is published (i.e. zero day exploit), and a patch is not yet available, a virus or a worm likely will be created from this vulnerability. Such predictability enables security and IT staff to prioritize high-risk vulnerabilities for remediation. However, if the vulnerability is not remotely exploitable, the likelihood of a virus based on the vulnerability alone is minimized. The amount of time it takes to create an exploit also will vary, as the graphic below illustrates with respect to some recent major vulnerabilities.
Number of days it took to create an exploit
It also helps to understand the primary motivation behind the creation of exploits, viruses and other malicious code – monetary gain. In a typical zero-day scenario like the one above, some vulnerability research firms offer as much as $10,000 to the person for exclusive rights to publish the disclosure. The research firms gain notoriety and increase the perceived value of their products. Another disturbing recent trend involves remotely exploitable, zero-day vulnerabilities used to create tens of thousands “zombie” PCs to unwittingly send out countless spam emails or to distribute ad-ware. In these scenarios, there is much more money to be gained in the underground international economy.
However, understanding the source of a vulnerability and knowing that it exists is not enough. Real-time, updated information is necessary to translate this knowledge into good business decisions. Using a standard vulnerability management methodology will help.
The Methodology
According to Gartner, vulnerability management is a process that should include the following steps:
1 Policy definition, including defining the desired state for device configurations, user identity and resource access.
2 Baseline your environment to identify vulnerabilities and policy compliance.
3 Prioritize mitigation activities based on external threat information, internal security posture and asset classification.
4 Shield the environment, prior to eliminating the vulnerability, through desktop and network security tools.
5 Mitigate the vulnerability and eliminate root causes.
6 Maintain and continually monitor the environment for deviations from policy and to identify new vulnerabilities.
Expanding upon these high-level processes creates a continuous vulnerability management cycle:
?
The nine steps described in the graphic above represent commonly accepted industry best practices, regardless of the tools or solutions implemented. The steps do not represent a starting and ending point, but rather a constantly repeating cycle.
The Solution
With an understanding of the vulnerability management problem and a methodology for solving it, you can begin to examine solutions. Some important factors to consider are:
1 People: Because responsibilities for the process steps above tend to fall under different departments within an enterprise, a successful program requires that the people with these responsibilities understand and accept their role in the process, even when doing so may conflict with their perceived primary job functions.
2 Process: Develop, document and communicate a coordinated workflow for all steps in the process.
3 Product: Implement, integrate and automate products that bind people and processes to the final solution.
There are many different vulnerability management functions, and even more potential vendor solutions. Indeed, many existing products can assist with vulnerability management functions. While more complicated than an integrated vulnerability management suite, existing point solutions can be used effectively by ensuring interoperation. The following simple example of combining point solutions occurs in many enterprises today. Support engineers export a list of machines under their care from their asset management or help desk systems’ inventory section. The vulnerability scanning team then can create a scan of those addresses. This ensures that the reports received from the scanning team are pertinent to their area of operations, rather than data mining a full enterprise report. While a simplistic integration, it improves the effectiveness of both teams.
In many situations, however, integration is not as easy as providing a list of machines to another department. Even when a loosely coupled integration is possible, many key data elements may be left out. For example, some solutions that import vulnerability scan information will process the data to create patch-based remediations, but not have the capability to perform configuration-based fixes. When choosing point solutions, interoperability with existing systems is crucial to maximizing current investments while retaining all desired functionality. Vulnerability management suites are designed to solve many of these issues through much tighter integration with all vulnerability management functions.
Vulnerability Management Ecosystem
The vulnerability management industry has begun to see the advantages of both integration and feature expansion. Many vendors are beginning to add features into existing products in lieu of integration. For example, asset management packages are supporting patch management, vulnerability scanners are beginning to remediate the vulnerabilities that they detect, and patch management vendors are creating policy solutions. Other product vendors produce full vulnerability management suites covering all aspects of the vulnerability management process. When making product choices, it is important to ensure that products with multiple feature sets interoperate with existing solutions, even if the new product features duplicate some already existing.
Compare the previous example of vulnerability scanning exports with a system that scans for vulnerabilities and sends point-and-click remediation events to the person responsible for fixing it. Include the ability for the vulnerability scanning team to be notified automatically when a remediation is complete so they can re-scan to verify the remediation, and the value of shared (i.e. a vulnerability management suite) or tightly integrated systems becomes apparent.
The portability of XML integration lends itself well to integrating many vulnerability management systems. Products supporting web services integration provide the most promise. Products with a such architecture provide the ability to automate and govern the interaction between their services and different vendors’ products. A good example of integration with web services can be found between a SIM/SEM (security incident management/security event management) product, a vulnerability scanning product, and a help desk system. Assuming that all three support web services interact, a possible scenario could look like the following:
1 A SEM product receives notification of a possible attack on a web server for a vulnerability in the Linux awstats package via the web servers’ access log.
2 The SIM sends a web services request to a vulnerability scanner to scan the web server to assess vulnerability to the attack.
3 The vulnerability scanner detects that the web server does, in fact, have a vulnerable version of the awstats package and issues, via web services, an emergency trouble ticket to the help desk system for remediation of the vulnerability.
Another key feature of integration is the ability to automate many of the workflow steps. IT faces constant pressure to do more work with fewer resources. Automating the workflow routing tasks is one great place to start. Vulnerability management suites, with their tightly coupled nature, usually provide the best automation capabilities. Integrated solutions that provide web services-oriented architectures come in a close second. With either solution, the nine-step vulnerability management process helps define automation needs.
Why Converge?
When examining the question of why to converge, it helps to look at your vulnerability management methodology and solutions from a business process management and business activity monitoring perspective. Integration will facilitate incorporating the constantly changing aspects of vulnerability management with existing and future BPM efforts. Experience in vulnerability management has shown that you will integrate vulnerability management into your enterprise in ways you can’t always anticipate.
In the past, many security professionals based security technology purchases and convergence projects primarily upon fear. The old argument of “if we don’t buy system X right now, a major security event could cripple the company” has ceased to become an effective business motivator. What has proven effective is using regulatory compliance and process automation as motivators. Producing more results, with fewer people, targeted to regulatory policies, is a business case that can be proven at all levels of the enterprise.
About the Author:
Scott Carpenter is the Director of the C5 Security Labs for Secure Elements, Inc.
Go Back
|
