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
    Commentary
    Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
    Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
    Edge-DRsplash-10-edge-articles
    7 Powerful Cybersecurity Skills the Energy Sector Needs Most
    Pam Baker, Contributing Writer,  6/22/2021
    News
    Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
    Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon
    Current Issue
    The State of Cybersecurity Incident Response
    In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
    Flash Poll
    How Enterprises are Developing Secure Applications
    How Enterprises are Developing Secure Applications
    Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2021-34390
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
    CVE-2021-34391
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
    CVE-2021-34392
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
    CVE-2021-34393
    PUBLISHED: 2021-06-22
    Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
    CVE-2021-34394
    PUBLISHED: 2021-06-22
    Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.