Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics

Bridging the Patch Gap

With patch times stretching to a week or more, enterprises struggle to put bars on an ever smaller window of attack

It takes about two days, sometimes less, for attackers to develop exploits that take advantage of a newly-announced vulnerability.

On average, it takes an IT department about a week, sometimes more, to deploy the software patches required to eradicate that new vulnerability.

Is your enterprise at risk? You do the math.

The situation is simple, experts say: Black hats are getting better -- and faster -- at writing viable exploits. IT security people, on the other hand, are faced with an increasing number of patches to deploy, yet they are hamstrung by a shortage of skills, people, and financial resources. And the time gap between the introduction of an exploit and the deployment of the "cure" is, in at least some cases, getting wider.

"Even with automated patch management tools such as ours in place, we find that it takes users about a week to roll out a new patch," says Don Leatham, director of solutions and strategy at Patchlink. Across the industry, the average time to patch is still around 30 days, he says.

Contrast those estimates with the speed of security researcher HD Moore, who last week saw Microsoft's critical MS06-040 vulnerability on Tuesday afternoon and published a verified denial of service exploit by Thursday. (See Exploits Emerge for Microsoft Vulnerability.)

"The interval between patch release and patch deployment is the attacker's best window of opportunity, and even though there are some pretty good tools out there, it's not closing," says Scott Crawford, senior analyst at Enterprise Management Associates, a management and security consulting firm.

For years, vendors and analysts have told enterprises that the best way to handle a new vulnerability was to deploy the patch as swiftly and efficiently as possible. That's still the goal, but it's time for IT and corporate management to concede that there will frequently be a time lag between the emergence of an exploit and the deployment of a patch, and enterprises need to have a strategy for managing security during this interim period, observers say.

"There are a lot of enterprises out there that have strict policies that say all critical patches have to be deployed within 24 to 48 hours," notes Leatham. "But particularly in distributed organizations, that's just not realistic, and security people are forced to come up with their own policies because the corporate policy doesn't work."

While there are some highly centralized, well-connected organizations that can deploy an emergency security patch in a matter of hours, most enterprises take longer, experts agree.

"Each patch must be tested to make sure that it is working properly and does not conflict with other existing applications in the system," says Hasan Cavusoglu, assistant professor at the Sauder School of Business at the University of British Columbia. Along with two other professors at another university, Cavusoglu authored a paper called "The Economics of Security Patch Management" last year.

This testing process, along with the time required to analyze the threat and physically install and validate the patch software, virtually guarantees that the patching process will take at least a few days, if not longer, experts say. In the case of non-critical patches, many organizations put together a bundle of patches and do the testing all at once, often on a monthly basis, Cavusoglu notes.

The takeaway: While patch deployment and management technology continues to improve, there will always be a time gap between the exposure of a vulnerability, the development of a patch, and the deployment of the software update. While vendors frequently say the "solution" to a vulnerability is to deploy a patch as quickly as possible, they generally offer no help in protecting the network during the patch testing/deployment process.

So what can enterprises do while they lay exposed, waiting for the patches to be deployed? An intrusion detection or prevention system can help, Leatham says. An IDS can sometimes protect the network against a known exploit, even if it hasn't been patched, he observes.

In extreme cases, an enterprise may choose to simply shut down the vulnerable services, experts say. "The MS06-040 vulnerability, for example, affects ports 139 and 445, so you may choose to shut off those ports or restrict them until the patches are in place. But that's going to affect your business, so it's a radical step," Leatham concedes.

Down the road, enterprises may be able to integrate security systems and configuration management systems, so if a vulnerability remains unpatched, the IT department can change the network's configuration to reduce the exposure, Crawford says. A few companies, such as Blue Lane, are already experimenting with this concept of "security virtualization," he notes.

— Tim Wilson, Site Editor, Dark Reading

  • Blue Lane Technologies Inc.
  • Microsoft Corp. (Nasdaq: MSFT)
  • PatchLink Corp.

    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
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    US Turning Up the Heat on North Korea's Cyber Threat Operations
    Jai Vijayan, Contributing Writer,  9/16/2019
    Preventing PTSD and Burnout for Cybersecurity Professionals
    Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
    NetCAT Vulnerability Is Out of the Bag
    Dark Reading Staff 9/12/2019
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Current Issue
    7 Threats & Disruptive Forces Changing the Face of Cybersecurity
    This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
    Flash Poll
    The State of IT Operations and Cybersecurity Operations
    The State of IT Operations and Cybersecurity Operations
    Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2019-3738
    PUBLISHED: 2019-09-18
    RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
    CVE-2019-3739
    PUBLISHED: 2019-09-18
    RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
    CVE-2019-3740
    PUBLISHED: 2019-09-18
    RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
    CVE-2019-3756
    PUBLISHED: 2019-09-18
    RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.
    CVE-2019-3758
    PUBLISHED: 2019-09-18
    RSA Archer, versions prior to 6.6 P2 (6.6.0.2), contain an improper authentication vulnerability. The vulnerability allows sysadmins to create user accounts with insufficient credentials. Unauthenticated attackers could gain unauthorized access to the system using those accounts.