{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.'"