<< Continued from Ariel View, part 1
Get buy-in from the owners of the scanned systems if you're considering automated scanning tools. There's always the chance that scanning might impact a system in an unanticipated way and lead to downtime. And the goal of VM is to minimize -- not increase -- downtime.
Set up governance and assign accountable owners of the data and processes in the system. Most systems within the enterprise are interdependent peers, but control of those systems is likely to be stove-piped and hierarchical. Decide ahead of time how the system will account for centralization, distribution and delegation of control. Individual business units, for example, might be resistant to a centralized system if they have limited visibility into the system or say about how decisions are made. Remember: the time to get buy-in is before any products are purchased. Without governance, clearly defined duties and buy-in, vulnerability management frameworks are just extra overhead.
Plan VM data and how it will be used from the very early stages. Decide, for example, how to handle triage in the event of an incident. A well-defined prioritization strategy is the difference between panic and strategic action when thousands of machines are at risk. Prioritize based on dollar value of the device, Internet Protocol on the device, PR value, business costs associated with downtime, or amount of time required to remediate.
Make assessments on environmental, architectural, technical and operational requirements. You need to determine, for example, whether high availability is a requirement, knowing what can be reused, how metrics can be used, what constitutes success, and who owns what portions of the system.
Remember that any type of scanning will introduce some performance overhead. In general, the more detailed the data collected, the higher the overhead will be. For example, a ping sweep has a very minimal impact on the network and the scanned hosts, but it provides very limited data. On the other hand, numerous agents that send back highly detailed information provide more granular information but have larger impact on the network and the hosts themselves. Some techniques, such as credentialed scanning and active vulnerability exploitation, can even cause systems to crash under certain conditions.
Pick a product flexible enough to accommodate the unique workflow of the enterprise. If the tools are not flexible enough to support your workflow, accountability might be assigned to the wrong group or black holes of untracked activity might appear in the audit trail. For example, if there's a process in place where OS patches are tested in the QA lab before being deployed across the enterprise, a tool sending "100 percent vulnerable" alerts while the patch is in QA will skew metrics and create useless noise.
Consider the metrics VM tools might give you. Metrics help track the security posture of the enterprise over time. You can watch, for example, the degree to which hosts maintain compliance with configuration policy, the number of vulnerable systems that exist on your network, and the amount of time required to remediate threats. Metrics are also extremely useful as a proof point in budget negotiations, allowing you to quantify the ROI of the system itself and provide hard data to back up resource allocation. Remember, though, that there's nothing magical about metrics. They provide specific information about what's happening in the environment. They also tell us what the environment is and how it changes over time. But in order to be useful, be careful to make sure what is tracked is useful and relevant to what is known.
Leverage existing technology whenever possible. This saves time and can increase the efficiency of the overall solution. Existing inventory-tracking systems can feed the initial asset map, procurement systems can keep inventory updated, and software distribution tools can provide up-to-the-minute data on what software hosts have installed. Incorporating existing workflows ensures VM stays current and maximizes data coming out of the system. For example, VM can initiate patch deployment workflows when needed, and can kick off incident response procedures at the first sign of trouble.
Set up mechanisms internally to gauge the effectiveness of the solution over time. Use realistic metrics tracks whether or not the system is performing as expected. Concentrate on metrics that provide information about what is happening in the environment, such as percentage of devices in compliance with policy or percentage of devices at optimal patch level. To help refine the system, also include metrics that reflect process efficiency such as how quickly machines are remediated. Evaluate them on a periodic basis to help drive improvements. Distill metrics down to high-level dashboard numbers to allow executive reporting.
There is no magic bullet solution that does it all. Rather, vendors favor technologies that solve individual components--asset identification, correlation, validation and remediation--of the vulnerability management equation. Each portion is crucial, though. An enterprise that doesn't know what's deployed (through asset identification) and can't track what state devices are in (through correlation) will almost certainly make mistakes in validation. Mistakes cost your business money and put it at risk. Combining multiple technologies intelligently to satisfy individual VM goals helps meet complex enterprise requirements.
The key to success with vulnerability management is starting from a strong foundation and building upward. Policies, procedures, prioritization and governance are all foundational components that VM should build on rather than replace.
About the authors
Diana Kelley is a senior analyst in the Security and Risk Management Service for the Burton Group and a founding advisor for Security Curve, an information security services and consulting company, based in Amherst, NH.
Ed Moyle is a founding partner for Security Curve.
