Critical patches are announced at the whim of vendors. Security and operations teams must drop everything to close holes in software before attackers exploit the vulnerability. Even in the best of circumstances, patch management requires close cooperation across operational disciplines that include security, operations, applications, and business units. Patches must be tested to ensure that they don’t affect essential business systems, tracked to ensure that they’ve been deployed, and reported on for executives and auditors who want bottom-line summaries of risk posture and compliance.
Patch management products can provide immediate relief, but a new trend is emerging that folds patch management into a larger security or configuration management system.
Pure-play patch management vendors that don’t respond to this trend will find themselves marginalized, whether by Microsoft and its automated patching systems, or by established software distribution and asset management vendors that are adding patch management to a larger portfolio of security and configuration management features. These systems track changes and remediation efforts and continually monitor the state of the assets to detect machines that fall out of compliance.
To help him answer that question, Hoff has an extensive set of tools at his disposal, including a vulnerability management service from Qualys, a risk analysis system from Skybox Security, and a collection of patch management products, including PatchLink and Microsoft’s Software Update Service (SUS).
Aaron Merriam, a systems service specialist for Hannaford, a New England grocery chain, has his hands full. Before turning to a tool to automate deployment, Merriam created and distributed patches manually. He also likes that BigFix can track the status of the anti-virus clients on the desktops. At this point, Merriam says there’s no clear policy in place that gives one group or another final say over a change. Disputes between himself and the applications group have to be mediated by supervisors, which complicates his ability to deploy patches during regular maintenance windows.
Some products begin from a patch deployment perspective, while others are born from an asset tracking or systems management perspective. What they all have in common is a move away from simple patch automation toward policy-driven monitoring. For instance, with an automated patching tool you associate a patch with a specified group of desktops or servers, and the patch is deployed. Using an agent-based architecture, BigFix lets administrators distribute software, start or shut down specific services, close file shares, track software licenses, and change registry and file settings on host machines.
BMC’s Marimba includes a suite of products, such as OS Management, Application Management, Patch Management, and Configuration Discovery, which can be purchased à la carte or as a set. It also ties into BMC’s popular Remedy ticketing and workflow system so that changes can be managed through normal procedures.
Many organizations find that their IT department’s priorities aren’t set by the staff, but by software vulnerabilities and the attackers who exploit them. “A process is needed so that organizations can identify vulnerabilities and other weaknesses in the environment and fix them before they are exploited or attacked,” says Mark Nicolett, vice president and research director at Gartner, a consulting firm.
While a patch management tool can help, the problem is that the root cause of a vulnerability isn’t always related to a patch. Root causes generally come in two forms: known vulnerabilities (which may or may not have an associated patch), and configuration policies that affect the risk posture of an asset.
Step one of the process is to create policies regarding the secure configuration of assets. This paves the way for assessing the environment to find assets that are out of compliance. Once you have a baseline, you can bring assets back into compliance.
However, because IT resources are limited, you’ll have to set priorities. Priorities will differ from enterprise to enterprise based on the value of the assets, their effect on business processes, the criticality of the vulnerability, and regulatory issues.
On the technical side, the vulnerabilities must be analyzed to determine how critical they are, if an exploit currently exists, whether patches are available, and what other steps can be taken. If patches are available, the organization must decided whether to deploy them immediately or during regular maintenance cycles.
In many organizations, the security staff is tasked with finding and analyzing vulnerabilities, but redressing those vulnerabilities often falls to IT operations, which in turn must answer to application owners and business managers if services are disrupted.
After remediation comes monitoring, in which assets are continually assessed to ensure that previous patches are still in place, that configurations are correct, and that changes haven’t been made that affect an asset’s compliance.
At this point, the process starts all over again, resulting in a process-based cycle that drives the organization, rather than the organization being driven by vulnerabilities, patches, or attackers. They now focus on new capabilities for configuration management, such as dealing with registry and system settings, security policy enforcement, and so on.
The majority of solutions are agent-based and will thus require some deployment effort, though network scanner-based products are also available. Patch management is also most efficient when rolled into a policy-driven security or configuration management system. Such a system requires considerable effort up front to create and deploy across the multiple silos (security, IT operations, application managers, and so on) in today’s network environment.
The most significant risk from a patch deployment system is the potential for a patch to adversely affect the host’s OS or applications.
http://www.securitypipeline.com/160701482