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.

Edge Articles

02:20 PM
Sara Peters
Sara Peters
Edge Features
Connect Directly

Realistic Patch Management Tips, Post-SolarWinds

Patch management and testing are different, exactly the same, and completely out of hand. Here are tips from the experts on how to wrangle patches in a time of malicious software updates.

{Continued from Previous Page}

  • IT asset management (for example, from companies like ServiceNow)
  • Software asset management (SAM) (Snow, SUMMIT)
  • Application security testing (Veracode, White Hat, Synopsys) 
  • Cybersecurity asset management tools (Axonius)
  • Remote monitoring and management (NinjaRMM)
  • Vulnerability management (Nessus, Rapid7) 
  • Patch management (SolarWinds, ManageEngine)

Franklin says many products on the market will ably perform several of these functions.

But don't assume that all these functions are essentially the same thing. "Vulnerability management systems are notoriously bad at being asset-management systems," for example, Causey cautions. 

Patch management service providers like SolarWinds and ManageEngine vary in many ways. Some questions to consider when selecting one:

  • Is it cloud-based, agent-based, or agentless?
  • What applications and systems does it support?
  • Does it observe third-party applications?
  • Does it have visibility into unsupported devices?
  • Does it conduct testing of patches before deployment?
  • Does it generate audits and reports?
  • Does it integrate with other, similar products? And open-source products?
  • Is it built for a small business, an enterprise, a managed service provider?

Isolate your Testing Environment. 

The Sunburst/Solarigate backdoor was delivered through a software update that had been signed by a trusted vendor; more payloads were then delivered via the backdoor.

Isolating the testing environment protects the live environment from such attacks. In the case of Sunburst, however, it might have eluded notice anyway, since it waited two weeks before making contact with its command server.

In an ideal world, Causey says, testing environments would be kept on their own physical servers. In a realistic situation, though, virtualization and microsegmentation are more feasible options. 

Back Up Before Deployment. 

Romanus Raymond of patch management provider ManageEngine says his firm always advises customers to create versioned backups before updating software, and to conduct those deployments to small groups at a time. This makes it easier to tell if a problem is due to a troublesome update, and gives the organization a recent, safe, known-good version to fall back on.

"We always recommend fragmentation," says Raymond, "so you can easily diagnose problems."

Prioritize Important Patches. But Don't Ignore Any. 

Start with high-priority patches, Causey says.

What qualifies as "high-priority?" Vulnerabilities with known exploits in the wild are on the list. He also advises that organizations pay heed to their threat intelligence and monitoring tools - these will help SOC teams determine which bugs are most critical to their particular environment, regardless of severity rating.  

Certain updates will have to wait patiently, but don't ignore them forever, says Pironti. Some software vendors will not provide support until you update software to a certain level, he says. 

Some Vulns May Never Be Patched. Act Accordingly.

Sometimes the risk assessment will show that the risk of deploying a patch outweighs the risk of the vulnerability itself. This is particularly prevalent in the case of industrial control systems and OT environments, but it may also be the case on pieces of critical enterprise IT infrastructure.  

Franklin says that companies will decide how to handle those cases: "'We know that we're not patching this. We have read the CVE. We know what the CVSS is. So we will bulk up our security infrastructure to try and make sure that that piece of kit never sees the threat that this patch is supposed to guard against.'" 

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio
2 of 2

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
4/6/2021 | 4:38:08 PM
Virtual patching

I am surprised the article is not mentioning the virtual patching solutions. It permits to avoid the risks of running a new software without careful (and therefore long) testing when the security issues are high or critical.

Anyway, we need to consider the concept of always running the latest version. What's the point?
Do we really need to get the latest features? Are we affected by the bugs fixed? Is the version running still supported? Is any serious security vulnerability?
The benefits of an update must be carefully measured. It could appear better to not run the last version, as long there is no security issues or bugs affecting your business.
User Rank: Apprentice
3/8/2021 | 1:42:31 AM
So what do we do?
In my opinion, this article is more about patch management when what we should learn from the SolarWinds incident. We already have patch management and patch systems in stages and following a priority list, thank you very much.

How is a company supposed to protect itself against malicious software updates and patches from vendors we all trusted in the first place? Every month, there is a lot of new software coming into the enterprise. Who will tell me if the binary code is clean or not? I am still looking for an answer myself.

Best regards

Jan Klingel

Cartoon Caption Winner: Magic May
Flash Poll