Insight by Ivanti

Discovery, patching, automation are keys to Log4J – and EO 14028

Discovery of the Log4J vulnerability caused much consternation among chief information security officers and everyone else concerned with agency security. For three good reasons.

One, the logging utility is so ubiquitous and exists in so many instances that IT people weren’t certain where it exists in their systems. Two, few realized that hackers could lodge executable programs in a logger that normally accumulates static data. Three, discovery of instances of Log4j – or any other...

READ MORE

Discovery of the Log4J vulnerability caused much consternation among chief information security officers and everyone else concerned with agency security. For three good reasons.

One, the logging utility is so ubiquitous and exists in so many instances that IT people weren’t certain where it exists in their systems. Two, few realized that hackers could lodge executable programs in a logger that normally accumulates static data. Three, discovery of instances of Log4j – or any other software asset – is complicated by virtualization and containerization of workloads in the cloud computing era. These techniques produce multiple instances of a given workload, often in more than one physical location.

Given the growing ransomware threat, the Log4j vulnerability seemed particularly dangerous. Startling and exotic as it seemed, though, Log4j simply underscored some cybersecurity basics. That’s according to Bill Harrod, the public sector chief technology officer at Ivanti.

Topping that list of basics: Patching, and the need for a fast, responsive mechanism to ensure that known vulnerabilities get buttoned up fast.

“In in 2021 and in 2022, I think we’re still going to see a significant amount of ransomware,” Harrod said. “And almost all of the ransomware is attacking vulnerabilities that have known patches that can be applied.”

Timely patching, of course, has been a government strategy for years now under the policy of continuous monitoring and the continuous diagnostics and mitigation program. The typical software stack, though, makes impossible the manual discovery of what needs patching. Harrod points out that a patching policy requires a continuous asset discovery component. Discovery should cover both software and hardware – especially as remote working and teleworking tends to multiply the endpoints accessing networks, applications and data.

Asset recover itself requires automation, Harrod added.

“Gone are the days where we managed all of that with Excel spreadsheets, for sure. Automation is the key,” he said.

Automation speeds the discovery of assets in such a way that it enables the organization to “prioritize the vulnerability management,” Harrod said. “So that when we test and when we do some penetration testing or when we look for vulnerability, we can then prioritize what is the most serious, what has been weaponized, and what can be remotely executed.” Then “making sure that we patch those things as quickly as we possibly can.”

This process underscores the importance of software bills of material (SBOM), which when obtained and understood, help the IT staff know both what it has and where the patching priorities might lie.

The mobile device management system can also feed the discovery and patch management strategy. In fact, all of what might be called discovery and asset management utilities can work in concert toward better cybersecurity, Harrod said. He called the resulting integration a service management layer.

“All of those things need to be feeding an overall service management,” he said. “And part of that asset inventory and the SBOM is to be able to enrich information that comes directly from the vendors.” He noted that the Homeland Security Department has at this moment a request for proposals on the street for endpoint detection and remediation.

The challenge for agencies, Harrod said, will be to bring together their tools for discovery, asset management, and patching into a cogent whole known as security orchestration and response, or SOAR. He called SOAR “sort of an extended detection and response (EDR) for cloud and cloud computing.”

Harrod said many vendors will submit SOAR or EDR solutions in response to the request for proposals, and agencies risk over-buying.

“But the agencies haven’t been given any strategy or any guidance about how to come up with some sort of a compatibility matrix that allows them to take advantage of best of breed solutions that they already have,” Harrod said. Such guidance would let them do a gap analysis between they have and that they need “and then fill only those gaps.”

Besides SBOMs, the prevailing executive order on cybersecurity, EO 14028, calls for agencies to have zero trust architectures.

“So what we need to do,” Harrod said, “is to take that [zero trust] framework and include the NIST cybersecurity risk management framework and the privacy framework, and use all of those together to figure out what components we need.”

He added, continuous diagnostics and mitigation, and zero trust are two sides of the same coin.

“It’s all about knowing what’s on the network, who’s on the network, what’s happening on the network, and how do we protect the data on the network,” Harrod said. As for the executive order, he said, “We really need to work smarter, not harder. And I think part of that is making sure that we bring the right automation into to help address some of that.”

Featured speakers

  • Bill Harrod

    Public Sector CTO, Ivanti

  • Tom Temin

    Host, The Federal Drive, Federal News Network