Published: 07 Jan 2005
You're just plugging holes if you don't have the right processes and policies.
Scan, patch and scan again: It's a common process for finding and plugging security vulnerabilities. But, if this is your idea of vulnerability management, it's costing your company time and money without improving your security. Clearly, you need to implement a well-defined, repeatable process that gets the most out of your staff and protects critical business assets and applications.
An efficient vulnerability management process can't be implemented without a solid foundation of essential resources, mechanisms, expectations and security policies. How do you determine where to focus your limited resources? Are your most critical assets also the most vulnerable? If you don't know the answers, you're not efficiently managing vulnerabilities--you're simply trying to plug holes as they appear. Without this foundation, you're doomed to work in reactive mode, with no way to validate budgets or measure performance, effectiveness or exposure to threats and risk.
The following are seven must-have elements of a successful vulnerability management program. They're not about scanning or applying patches; they're the essentials that will enable you to efficiently and effectively find and remediate vulnerabilities.
1. Define Roles and Responsibilities
The chaos of an attack or a rapidly spreading worm isn't the time to figure out who's supposed to do what and when. All of the best vulnerability management practices, checklists and procedures are useless if individuals aren't appropriately tasked with the responsibilities to build and execute a sound program. Defined roles, assigned responsibilities and enforcement procedures--backed by authority--are critical to your enterprise's security. Expensive, cutting-edge security technology is of little use without them.
At an operational level, individuals within the IT department may be responsible for identifying the company's assets, carrying out vulnerability assessments and penetration testing, and participating in the incident response team. These responsibilities may be assigned by business unit for particular sets of servers, depending on the size and complexity of your organization.
Roles and responsibilities should be documented, with flowcharts showing each team member's or department's involvement at each stage. This should include the creation of an escalation process to ensure that the right people are dealing with the more critical and complex issues.
Reinforce these assignments by integrating the responsibilities into job descriptions and performance reviews, and chart the performance of each security team by asset category, such as e-commerce servers, critical databases, nonproduction servers, financial systems and desktops PCs.
2. Take Stock
Fewer than 35 percent of companies have an accurate accounting of their IT assets. You can't prioritize your vulnerability assessment and remediation procedures if you don't know what you're defending.
This isn't easy. Important data is usually held in different locations throughout a company's network, and networks themselves tend to grow organically without proper documentation.
The security and network teams should conduct a complete inventory of the enterprise's operating systems, applications, hardware and firmware, including versions and any patches or upgrades that have been applied. If there's a newly disclosed vulnerability in Apache HTTP Server 1.3, should you care? It's not enough to know that you use Apache; you need to know what versions and on what machines.
Follow these basic steps:
- Assign responsibility for asset identification, management and documentation procedures.
- Determine and implement these tools and methods: scanners, inventory management software, manual examinations, etc.
- Identify all assets, versions, software, patches and configurations. Make sure to include all remote and transient devices in your inventory.
- Update and maintain information on all assets through their lifecycles, from procurement to disposal.
3. Evaluate Assets
Simply identifying individual assets isn't enough, since not all assets are created equal. The database that holds customer credit card information is more important than the nonproduction server that contains routine files. Assigning a value to assets is the foundation for prioritizing your vulnerability management efforts.
Analyze and document the role each asset plays in your business and the consequences of a successful attack; determine the effect on the company's productivity, operations and business continuity. Ask yourself: If a particular asset is compromised, what would be the impact on your corporate revenue stream, reputation and relationship with customers and business partners? It's critical to know which systems should be protected first.
It's relatively easy to gather this information from the company's business continuity team--if you have one.
If not, work with management to task the business units with conducting this analysis. The resulting intelligence is beneficial for security/vulnerability management, as well as disaster recovery/business continuity planning.
4. Develop Metrics
Metrics are the means to quantify security policy compliance, evaluate countermeasure effectiveness, carry out historical analysis and demonstrate security ROI. Measuring performance allows you to quantitatively assess your vulnerability management processes, deficiencies and controls.
There are no industry standard security metrics, so where do these metrics come from? Often, it's a matter defining what your goals are, what variables comprise these goals and how to use those variables to establish baselines and measure progress. (For further guidance on the development and implementation of internal security metrics, review http://csrc.nist.gov/publica tions/nistpubs/800-55/sp800-55.pdf)
In the absence of standard metrics, some enterprises have used those included in vulnerability management products, such as McAfee's Foundstone 1000 appliance and NetIQ's Vulnerability Manager. These and other products generate statistics on the number of vulnerabilities found, the severity of vulnerabilities and the time to remediation. They won't provide a complete picture, but they will give you useable intelligence.
At minimum, the following metrics should be defined and integrated into the vulnerability management framework:
- Maximum tolerable downtime values for critical assets based on, for instance, the loss of revenue per hour.
- Estimate of potential monetary losses per asset and compromise type, computed by this basic formula: (asset value) x (% of potential damage) x (estimated frequency of compromise) = (annualized loss expectancy).
- Number of security incidents per month (e.g., virus infection, successful penetration attempts from the Internet, unauthorized access attempts by internal employees, Trojan downloads).
- Recovery costs, in staff hours, to remediate these incidents.
- Number of noncompliant systems, by department.
- Percentage of vulnerabilities mitigated over cycles of 30 days, and percentage of vulnerabilities that extend past 60, 90 and 180 days.
- How much the vulnerability management products and processes are really worth to your company. For example, if a $60,000 network vulnerability management product reduces your potential loss from $400,000 to $200,000, its real value is $140,000.
5. Determine Acceptable Risk
Every organization needs to establish how much risk its stakeholders--management, investors, the board, customers--are willing to accept. It's the key to creating corporate security policies and balancing functionality, security requirements and available funding. Your valuation of assets is critical in determining your tolerance for impaired performance or downtime, prioritizing your efforts or setting guidelines for remediation.
Risk level is usually represented and communicated in an abstract manner and needs to be quantified.
The quantified values are baselines (minimum level of required security) and the deviation from these baselines. The CISO usually establishes the baselines, and the risk and vulnerability management teams are responsible for maintaining them.
For example, the baseline of the cost of recovery from incidents needs to be reduced by 10 percent every six months. In this case, the metric is the average cost of recovery from incidents every six months. Or, you might establish a baseline for regulatory compliance that says penalties due to noncompliance should occur less than once every three years; the metric is the number of penalties per three years.
6. Classify Threats
Create a classification scheme that categorizes vulnerabilities, threats and compromises by their probable degree of success and potential level of damage. The classification scheme should also include the targeted assets and the business impact of these types of attacks.
Creating a severity rating system provides a simple, powerful way to convey warnings about new vulnerabilities and circumvents the quagmire of disparate vendor ratings. A vulnerability's threat level needs should be correlated to the company's risk tolerance, which is only understood once you've completed the previous steps.
The first, obvious criterion is whether the new vulnerability applies to your environment based on your asset inventory. If your Windows machines all have the latest version of IE, for example, you needn't worry about a vulnerability that affects only older versions.
If you do have vulnerable systems, calculate the impact of a successful compromise. Critical systems, such as an Internet-facing Web server that accesses a customer database, require immediate remediation. The potential business impact--compromised customer data, downtime, loss of revenue--is a critical factor.
Finally, consider the likelihood of a breach. The risk is greater if the vulnerability can be exploited remotely and requires minimal skill level (e.g., a tool used by script-kiddies). Conversely, a database vulnerability that sits deep in the network and requires trusted access is much more difficult to breach and would have a lower likelihood of compromise.
7. Control the Flow of Information
The sheer volume of information on new vulnerabilities and threats can easily overwhelm network and security staffs--it's not just about keeping current with Microsoft's monthly vulnerability disclosures. Many types of vulnerabilities in various products and OSes are reported every week.
Your vulnerability management team needs to know about vulnerabilities that affect your enterprise's environment; all other alerts are ignorable. Designate people to collect, investigate and disseminate vulnerability data; they'll be able to determine the threat severity based on your asset inventory and valuation, and threat classification.
Vulnerability alert subscription services, such as the META Security Group, Cybertrust's IntelliShield Early Warning System, Computer Associate's eTrust Managed Vulnerability Service, Symantec's DeepSight Alert Service and iDEFENSE's iALERT, can provide current, tailored threat information.
Formula for Success
There are no shortcuts to effective vulnerability management. You have to invest significant time and effort to inventory and document your environment, and put the right people and procedures in place. This framework enables you to manage vulnerabilities in an efficient, repeatable process that maximizes your resources and minimizes risk. Without it, the only thing that's repeatable is inefficiency and failure.
The vulnerability management lifecycle will flow as smoothly as an operational practice--scanning for new vulnerabilities and undocumented devices, analyzing the risk to your business and plugging holes before your key systems are compromised.
And, it will give you the opportunity to reinforce security controls. Instead of scrambling to catch up to address new threats, you'll learn from past mistakes and improve your security with each cycle.