Patch Tuesday Prioritization for a Large Enterprise

Patch Tuesday comes around and typically Microsoft releases a handful of patches to the world. Some may have critical security implications, while others may not be as critical. For many small- to medium-size businesses, the patches are applied quickly via Microsoft's SMS or SUS services. Most of these corporations with fairly simple and uniform computing environments have the ability to trust patch stability to the point of not having to pre-test the patches with existing workstation and server configurations.

However, how are the systems of large enterprises positioned to handle an onslaught of patches? It's unfortunately not nearly so simple. Many enterprises run internal applications or services that may be damaged from standard Microsoft updates -- updates that were not tested with technologies from locations other than Redmond. Also, the rollout of an average of four to five patches to 20,000 or more nodes is not an easy or quickly accomplished task. Nonetheless, patches must be implemented. But not all patches are created equal.

Patch Prioritization
It is imperative that the first step toward patching in an enterprise should be the immediate analysis of patches by the security team. Depending on the security resources available, the analysis activities may range between advisory review and CVE cross-referencing, all the way to dissecting the patches via reverse engineering to find the flawed code. The patches should be prioritized, and at the top of the queue should be the most "wormable" flaw: the flaw that has the most potential for disruption or destruction of a network if attacked. This will usually be a vulnerability that allows remote execution of arbitrary code on a service that is running by default, and that is not filtered for most platforms.

During this process, the security team should also keep their ears to the ground of the security community in case any exploits for a particular flaw have been released. Those flaws with exploits should move to the top of the priority list, as many attackers may have access to the attack code.

Asset Identification
Following the analysis of the vulnerabilities, the affected assets of the enterprise should be cross-referenced with the available patches. This requires a strong inventory of assets and their systems and properties, which an asset discovery tool can help create. Direct correlation of patches to systems and the services they run is imperative. For instance, if a web server patch is the highest priority, the web servers of the enterprise should be first in line to receive their patches. The affected system and service information is best found by reviewing the "Executive Summary" or FAQ of a Microsoft Security Bulletin. The security team should now group the assets based on patch analysis and asset properties.

Attack Probability Analysis
Next, it is important to understand that even with the most critical flaw, not all unpatched machines pose the same risk for attack. A good vulnerability assessment scanner will provide two types of checks for these critical flaws: the first and most common audit is that of patch existence -- is the vulnerable DLL updated to the right version, is the registry configured properly, etc. These types of checks are usually not from the "vision of an attacker" because they require credentials on the machine being scanned. The second and less common type of audit goes to the byte level of the process being attacked and does not require user credentials on the scanned machine. Depending on the configuration of a particular machine, it may not appear vulnerable to a non-credentialed user; however, it if does appear vulnerable, it assumes that it will be easier for an outside attacker to identify the flaw. Because of this increased risk, the machine should be prioritized for patching accordingly.

Exposure Analysis
Following asset identification and attack probability, exposure becomes the main issue. Which assets are Internet-facing and accessible from the outside, and which assets are inward-facing? To continue with the previous example, web servers for a corporation's website are going to be much more exposed than those used for internal applications. Strategically positioning vulnerability scanners can assist with identifying exposure. If report data from a scanner installed outside of a firewall shows assets as vulnerable, these are exposed and need to be patched immediately (plus the exposure is more critical if the specific vulnerability allows for a remote attack). Generally, the exposure analysis should be conducted at a network conductivity level to determine if an attacker get close enough to launch an attack on a given asset.

Mitigating Factor Analysis
A basic framework for what systems need to be patched immediately now exists. But, there are always mitigating factors for each vulnerability -- ways that risk for attack can be lessened or avoided even if the patch is not installed. These can be simple instructions like "firewall the port" as described in many Microsoft Security Bulletins, or they can be more intricate solutions such as having host-based kernel protection software installed. In our example, if some of the outward-facing web servers are running custom IIS filters or software that has proven to prevent the attack, those servers should be lower in priority for patches than those without. The same goes for workstations; those with host-based intrusion prevention software installed can be placed lower down in the patching queue than those without a host-based security application.

The Patch Rollout Process
After the basic analysis and enumeration processes, priority is typically moved from the security team to the operations team for immediate patching of those assets with the highest criticality and exposure. If time allows, sometimes only after the "perimeter is secured", a basic test of one system should be conducted before patching all similar systems. Thorough testing of enterprise applications and services should confirm that patches would not disrupt any service or break other functionality. Once the testing is finished, patches should be rolled out in the order of priority based on the previous analysis.

Conclusion
The main benefit of patch prioritization is that the large enterprise will better maintain its security posture in the critical time between patch release and patch application. Once a plan is executed a few times, it will become much more efficient. Efficiency and organization provides a second benefit -- time. Avoiding the "panic patching" syndrome can save an organization money and headache. Centralized vulnerability and asset management software can be a central part of any patching process by helping coordinate the patch rollout as well as provide top-level reporting capabilities on patch progress.

This is not to say that the patch process can be delayed, but companies can definitely buy themselves some extra time to patch all of the systems if they have paid close enough attention to the mitigating factors, the effect of the vulnerabilities, and the possible resulting attacks on their assets.

Source: Andre Derek Protas, Research Engineer, eEye Digital Security

Red Herring: Security Threats Rise 22%
"So far this year, companies reported 862 incidents, up 22.4 percent from 704 during the same period in 2004, according to an annual study released by IDG and PricewaterhouseCoopers. Cyber crime seems to be on the upswing, with 22 percent of companies surveyed reporting financial losses from attacks on their systems, up from only 7 percent in 2004." Full Article

ADTmag.com: Security, Computer Crimes Still Bane of IT
"Robert Richardson is the editorial director of the Computer Security Institute, which provides training to computer, information and network security professionals. During an interview with ADT, Richardson examines how companies are tackling these issues." Full Article

NewsFactor: Apple Plugs Critical OS X Vulnerabilities
"Apple Computer has issued fixes for 10 security holes that have been rated as 'critical' by security firms. With the vulnerabilities, machines running the affected systems could be targets for remote attack, which could be done with images sent through e-mail, Apple has noted." Full Article

Q: If I own a host-based intrusion prevention product, do I still need a network-level vulnerability assessment product?

A: When considering host-based products for a subset of your networked devices, the concept you should understand is that of "managed" vs. "non-managed" devices. If you were to place security agents on each and every device on your network (a difficult, "boiling the ocean" undertaking), they would all become managed devices, meaning you have some form of control over them, and can verify that they are online and protected.

Most security administrators will tell you, however, it's not the devices that they know about that keep them up at night, it's the devices they don't know about that are exposed to an attack. For example: the contractor who is plugging a laptop into the network, with an untold number of vulnerabilities on their system; the QA engineer who has re-imaged a networked machine with a superceded operating system for the sake of testing; and even a vulnerable device such as a router or printer that cannot be managed at the host level. The list of scenarios that outline how a non-managed device can wreak havoc on your network goes on.

This clearly demonstrates the need for a vulnerability assessment solution with comprehensive discovery capapbilties. In the end, all security plans should include a healthy mix of network-based vulnerability assessment and host-based intrusion prevention for critical devices.

Have a question you would like answered? Send it to versa@eEye.com, and win an eEye t-shirt if we select your question for an upcoming newsletter.

Blink® Named as Windows IT Pro Readers' Choice Award Winner
eEye's Blink End-Point Vulnerability Prevention
software was named as the winner in the Security Intrusion Detection and Prevention Software category of the 2005 Windows IT Pro Readers' Choice Awards fourth annual contest. More than 1,700 readers chose the best among more than 750 products and services. Full Article

Event: October "Patch Tuesday" Vulnerability Expert Forum
After a quiet Patch Tuesday in September, eEye expects a torrent of vulnerabilities to be announced by Microsoft in October. Join eEye security experts for an online seminar focusing on the critical vulnerabilities and the actions organizations need to take to protect from attacks. Full Article

Online Presentation: End-Point Security
Listen to a free recorded e-session entitled "End-Point Security: Strengthening The Weakest Link - Bring E-Mail Policy Enforcement, Patch Management, Mobile and Wireless Protection to Your Endpoints". The discussion features a panel of security experts including eEye's own Steve Manzuik. Full Article

NSA Granted Net Location-Tracking Patent
The National Security Agency has obtained a patent on a method of figuring out an Internet user's geographic location. Patent 6,947,978, granted Tuesday, describes a way to discover someone's physical location by comparing it to a "map" of Internet addresses with known locations. More

The Buzz About Fuzzers
A fuzzer is a software program or script designed to look for possible errors in a piece of programming code or script. The ultimate fuzzer would look for every input variable and try every possible allowable combination of input, hoping to find buffer overflows and unhandled coding errors. Fuzzers find most of the buffer overflows these days, and white- and black-hat hackers alike use them. More

HOW TO SUBSCRIBE
To subscribe to this and other eEye newsletters, please visit: http://www.eeye.com/html/resources/newsletters/subscribe.html

FEEDBACK
The eEye newsletter staff welcomes any comments, questions or suggestions from our readers. We hope that you will not hesitate to contact us with any feedback you may have. Send all feedback to versa@eeye.com.

DISCLAIMER
The information within this newsletter may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

NOTICE
Permission is hereby granted for the redistribution of this newsletter electronically. It is not to be edited in any way without the express consent of eEye. If you wish to reprint the whole or any part of this newsletter in any other medium excluding electronic medium, please email versa@eeye.com for permission.