09:14 PM
Connect Directly
Repost This

A Security Pro's Guide To Patch Management

With so many applications and vulnerabilities, the question is which patches to deploy first

[Excerpted from "Security Pro's Guide To Patch Management," a new, free report posted this week on Dark Reading's Vulnerability Management Tech Center.]

Deployment of critical software updates and patches used to be a relatively simple proposition that didn’t require much thought or strategy. The conventional thinking was that if you simply patched Windows, Internet Explorer, and Office based on Microsoft’s recommendations, you were essentially immune from the most destructive attacks that were propagating in the wild.

That patch management approach presents two increasingly significant problems. First, it leads the vast majority of companies to deploy every critical patch fed to them, without first assessing or testing what those patches might break once deployed. Second, and more important, many applications exist outside the traditional core operating system realm, and those applications often represent an even larger threat vector than Windows or IE.

Consider all the applications on a traditional fat-client PC that supports dynamic code execution: Java, Acrobat Reader, Flash, Shockwave, QuickTime, Windows Media Player, iTunes, RealPlayer ... We could go on, but you get the point. Each of these applications is an independent threat vector whose unique capabilities have been exploited by malware developers.

Further, patch management is no longer just PC-focused. OS and application patches arguably may be the most vulnerable applications in the enterprise, but security professionals also must consider the patches published by email security gateway vendors, firewall vendors, routing/switching vendors, and so on. You also need to factor in mobile devices, along with any key systems located in the Internet cloud.

Given that the threat landscape is vastly more complex than it was just a few years ago, it’s vital that IT managers rethink overly simplistic patch management strategies that address — maybe, if you’re lucky — 25 percent of the problem. For those of us in the trenches, it’s disingenuous to tell our bosses we’re addressing the entire patch management problem when we’re really only deploying Microsoft patches.

With that said, patching every application in your company with every update available isn’t a viable solution, either. The application inventory for the typical large business ranges from the hundreds to the thousands. In a perfect world, IT would have the resources to track, test, and deploy patches for each and every application, but that’s not reality — and often is not even necessary.

Like everything in the security world, effective patch management is all about setting priorities and maintaining balance. In this report, we provide an approach for developing a sustainable patch management strategy that breaks the larger challenge into three more focused disciplines: patch prioritization, patch deployment, and patch quality assurance (QA).

To read this guide on enterprise-class patch management practices and processes, download the full patch management report.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web