I have been combing though some vulnerability reports and the vast majority of remediation strategies revolve around applying a patch. Simple in concept; install this patch, and the vulnerability is mitigated. The difficulty arises when you have vast quantities of the patch to deploy, are unsure whether the security update breaks any other function or is incompatible, or requires a reboot or other disruption that could cause unwanted downtime. Finding the best remediation strategy for your organization is more than just knowing when to test and deploy a patch. It is a much larger process that starts with how you protect hosts in the first place and ends with applying a patch to correct the vulnerability. Along the way, it is very likely that you will discover that the patch alone is not the only method to mitigate the risk and in some cases introduces other unwarranted risks. Consider the following sample lifecycle of a popular zero-day threat against the Windows Task Scheduler Service used in Stuxnet:
The amount of time between when a vendor publishes a patch for a discovered vulnerability and when a worm or malicious attack takes advantage of such vulnerabilities is shrinking dramatically and has been for years. Organizations that have “no solutions” are exposed to these attacks from the discovery of the exploit and through any malicious intent that criminal organizations may use to compromise hosts. In our example, the Stuxnet malware utilized this vulnerability well before public disclosure on November 10, 2010. Protection begins for most business only when a patch is available and fully deployed (patch solution). For the Microsoft Windows Task Scheduler Service vulnerability, as of this post, no patch is available yet and only mitigation workarounds are present. Environments using only vulnerability scanning solutions (assessment only) can identify which assets are at risk for the exploit once a check is added to their scanning product as either a zero-day audit or at public disclosure. This assumes that the developers and research team supporting your scanning solution maintain a tight SLA for including identification (audits) of new threats within the product. This does not protect you from the threat, it just raises the level of awareness that you could be compromised. Again, for our example, users are only able to scan for this vulnerability using a zero-day audit and have no mitigation strategy until a patch is available unless they take an alternative approach for protection.
eEye customers that use
Retina (or Blink) are protected from this attack from day zero...well before public disclosure. Real-time alerts are sent notifying administrators and security teams of the attack even when no patch is deployed. This entire lifecycle of identification and remediation goes far beyond just identifying a vulnerability and patching a host. Solutions can provide protection when remediation is not possible even when patches do not exist.
In addition to patch management, vulnerability remediation can occur through other controls that protect a host from threats (like protection agents above). Another common method is changing the configuration settings for a host or network. Consider the timeline above is for a popular word processor or document reader. The most common entry points into the network for these documents are through email and internet browsing. Stopping these attachments at the mail server, firewall, or proxy would mitigate the threat until the patch is available (not remediate it). Although this may cause some disruption to the business, there are very few other alternatives when an effective protection solution is not available for the threat. One final course of action which I have seen successfully deployed at several enterprise clients is to prohibit almost all attachments from email. The only way to receive inbound attachments is for the files to be compressed and have a special extension (in lieu of .zip or .rar) coded to the user and company. This stops nearly everything except for a very specific targeted attack and renders virtually all modern bots and worms which have attachment payloads useless. Again, this is a mitigation strategy and does not remediate the threat.
Finally, network access control lists, trusted and banned IP ranges, and proper network segmentation and scoping can be effective counter measures when coordinating remediation actives. These are by no means the best solutions since the threat still exists, but they can reduce the environmental risk to your organization by denying access to systems that are susceptible to the vulnerability. They represent strong mitigation strategies to support any remediation and protection activities.
In conclusion, consider patch management as just one of many tools you have for remediation. Protection technologies can manage the threat when no patch is available, assessment technologies identify when a threat is present, and mitigation occur through patch, protection, and even configuration changes. All of which require you to have more than just patches to manage remediation.
