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.

Risk

4 Steps For Trimming Patch Management Time

The heat is on to protect your systems from the newest exploits; here's a look at how to speed up patching without causing problems

3. Know who needs to know and who signs off.

Approval paths can be time drains down which patch promptness can all too easily drown. Because even the most efficient patch deployments can cause downtime, it's important both to make technical issues clear to nontechnical staff who must sign off on the patch, and to ensure IT understands the business implications of the patch. Communicating clearly in advance that you need to add extra time to the email server's scheduled maintenance, for instance, takes less time than explaining during the downtime why it's taking so long.

"Preapproval of patch deployment authorities is not only an important aspect of an organization's emergency plan," says Andrew Bosch, product manager at Symantec, "[but] it can save vital time and anxiety in critical situations."

With the right people identified in advance, especially in relation to critical systems, "You're not going to be chasing people in the middle of the night to find out when you can patch a critical server," Bosch says.

This one should be among the simplest and most straightforward steps, but bear in mind it involves people, authority, and almost undoubtedly politics, each of which could add to the time required to get sign-off on the sign-off list.

Time-saver: Create and maintain a comprehensive patch deployment approval and sign-off path along with your systems inventory, including emergency and off-hour contact information for all personnel on the list.

4. Take time to test patches before going operational.

Even the most critical and time-sensitive patches, such as those that seal holes that are being actively and aggressively exploited in the wild, must be thoroughly tested before deployment. In fact, those critical and often rushed-to-distribution patches could require more testing before you unleash them on your systems.

So it's crucial that your test platforms and procedures related to them be established and in place constantly, not just assembled on an ad-hoc basis the day of a patch release.

Symantec's Bosch recommends building one day of test time into your planned deployment schedules.

Pay attention as well to patch-testing with new and emergent technologies your organization is using, and with an eye toward easily overlooked things. Don't forget virtualization software and virtual machines, for example.

The initial time investment required to include and establish all systems in your ongoing test platform, and especially the time required to add new systems and applications as soon as they are introduced, will be offset by the time savings achieved by your familiarity with those systems when patches for them are released.

"Patch testing shouldn't be an adventure every time," Bosch says.

Time-saver: Establish comprehensive patch test platforms, including platforms for new technologies and configurations ahead of time, and make their maintenance, readiness, and upgrades an ongoing part of your operations overhead and budget. Build a day of patch-test time into your patch deployment schedule.

Meanwhile, patches, both scheduled and emergency, require planning and time allocation.

You must address in advance the time required to prioritize, schedule, authorize, and test both the patches themselves and your organization's ability to manage patch deployment -- in both technical and business operations contexts. That's the only way to ensure a relatively painless patch process.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.