"Sophos research shows that connecting an unprotected, unpatched computer running Windows XP (without SP2) to the Internet leads to a 40% risk of infection from an Internet worm within about 10 minutes, rising to a 94% chance after 60 minutes." Self-propagating worms and viruses typically appear days after the public announcement of vulnerabilities. The risk of not patching your systems in short order could have serious implications due to the speed and fury of virus outbreaks in recent months. For example, in 2005, Zotob took five days to hit after the patch was released; in 2000, Nimda struck systems a year after the vulnerability was announced. Notice the precipitous decline in the time frame to patch.
Patch management is not an easy path to navigate in any company. The common complaints about patching include:
§ Patches cause instability in systems and must be sufficiently tested prior to their release into production. Administrators or security personnel often get the blame for any system woes after a patch is deployed.
§ Most patches require system reboot, which adds to the instability factor and causes downtime to business functions. Closely tied to this is the issue of identifying a maintenance window for patching.
§ Patching affects every system. Due to its wide ranging impact at the server, workstation, and laptop levels, patching requires significant coordination and buy-in from a large number of stakeholders. Not only do administrators need to take into consideration the variants of operating systems, database systems, and network devices, but in many cases they also need to consider the applications or processes running on each component.
§ There are too many patches, many of which are irrelevant to any given environment. SC Magazine reported a total of 3,780 patches in the first two quarters of 2005.7
To counter the stigma associated with patching, focus on building an effective patch management process (PMP) with these practical guidelines:
§ Publicize the objectives of your PMP to executives and management. The key message to carry across is that patching is a necessity that every company faces. Because there are no options not to patch, the goal of the PMP is to make patching a predictable, reliable, and efficient process. Predictability is realized by adhering to a set patching schedule. Reliability is achieved by having the proper testing processes as well as the right staff on hand after the patch has been deployed to validate the system processes and to support any potential issues that may arise. Efficiency is gained by tuning the PMP with each iterative cycle to make it more seamless and less disruptive to the business. When faced with resistance, emphasize that a planned downtime with reliable personnel on staff to bring the systems back up (as well as contingency plans) is more desirable than an unplanned downtime and potential loss of systems or data caused by a security breach.
§ Establish the roles and responsibilities of all the parties involved in the PMP. Your patching should cover servers, workstations, and laptops and include network devices as well. Gather key representatives from each group to form a patch management committee (PMC) that makes joint decisions on patching strategies and contributes to the continual improvement of the PMP.
§ Create contingency plans for patching. Work with the PMC to formulate rollback and communications plans in the event that the patch proves problematic. What we have found in most organizations is that patches are often the culprit of a system failure. A patch, however, may root out a deficiency in the way an application communicates with the kernel causing it to choke. Set the right expectations with the appropriate parties to work on improving problematic systems rather than reverse the patch application.
§ Establish a regular maintenance window for patching following the week of Microsoft's Patch Tuesday (regular patching cycle). Virus writers are moving at unprecedented speed to produce malware as soon as five days after the patch is released; the term "zero-day" exploit has ceased to be as theoretical as it once was. Allocate testing for the four days following Patch Tuesday and set the target of patching production over that weekend.
§ Involve your change management committee or board. Patching requires the appropriate approvals because it has a wide-ranging impact to all systems in the enterprise. Ensure that you embed the PMP into the monthly routine of the change control meetings.
§ Create an exception procedure. There will be business or IT managers whose initiatives will result in your inability to patch their systems. Put the onus on them to inform the PMC at the change control meetings. Review and grant these exceptions accordingly. Set a cutoff date for the list of systems to be exempt and set expectations of the requestor as to when the systems on the exception list will be patched.
§ Include an emergency PMP (EPMP). There will be critical patches that must be applied sooner rather than later due to impending attacks. In those cases, evoke the EPMP and rush the patching through in no more than two days.
A successful PMP saves you from significant hours of downtime and damage control.
A zero-day virus is malware that infects computers before a protection (i.e., signature-based antivirus update) against it is known. Preventing your normal end users from being local administrators on their work computers is probably your least expensive defense against zero-day viruses. Most malware relies on the user's administrative privilege to write or install malicious programs to the system folder or registry. By giving the user a nonprivileged account, a variety of malware would fail to infect the host computer.
Removing local administrative rights has other security benefits, such as preventing users from installing nonapproved software or devices. Users would need to get the appropriate approvals to have company-licensed software pushed out to them. However, this may also be a source of contention due to the limitation of printer or other types of installations that require administrative rights. Users who are used to getting their way are not going to welcome this change in policy. Be sure to get the proper executive support, especially from the business side, to push such an initiative. Provide alternatives to approved installations by creating scripts that allow users to run as administrators while they are logged in as a nonprivileged account.
Other solutions allow you to right-click and send installation files to an administrator stand-in application to facilitate the installation. This method allows you to present a warning banner to inform the users of their responsibilities. Both administrator substitute options require you to provide end users with an administrative password. To ensure the proper safeguarding of this privilege, change the password on a regular basis and communicate that to your end-user support teams.
No comments:
Post a Comment