“Our recent initiative was the result of LOG4SHELL, which I think made a lot of organizations take a hard look at what they could and could not do in dealing with post-exploitation detection with IDS / IPS in our public clouds.”
– Financial Services Customer
In my role as VP of Product at Valtix, I talk with end-user organizations every day. Over the last two months, it’s been wild to watch the change in sentiment since the Log4Shell vulnerability emerged back in December. For more than a few organizations, Log4Shell was a tipping point and realization that living without the same levels of security visibility and control in the cloud as they have on prem was no longer an option.
One of the biggest changes I’ve noticed in customer requirements is that Cloud IDS / IPS for exploit prevention has quickly risen to the top of every enterprise’s list of critical capabilities. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) have (of course) been around for many years. IDS / IPS serves a critical function in the data center by flagging malicious activity based on either known signatures or pattern-based heuristics. One of the primary use cases for network-based IDS / IPS is to alert on or block activity that might indicate exploitation of a network-accessible vulnerability (such as an unpatched Log4J library).
According to the Verizon Data Breach Investigations Report (DBIR) 2021, vulnerabilities and attacks on “external cloud assets were more common than on-premises assets in both incidents and breaches” (page 20, Verizon DBIR). It would seem that post-exploitation detection would be critical in the cloud as a result, but it has not been that way. Until recently, network-based IDS / IPS was largely ignored for protecting cloud workloads outside of compliance-sensitive organizations.
Perhaps the reason why many skipped this critical capability for defense in depth was there weren’t a lot of options from the cloud providers. AWS has GuardDuty, but it’s purely IDS, doesn’t support deep packet inspection, and only enables detection of external threats. Kudos to Microsoft, their Azure Firewall Premium has included IPS, however, it’s only for Azure. And then there’s GCP, who released an integration of Palo Alto Networks as a GCP IDS, but it comes with some major limitations. It’s also visibility only and not prevention.
Valtix is really the only full-featured and multi-cloud IDS / IPS in the world. So it’s maybe not surprising that almost daily, I’m having discussions with enterprises about why they believe IDS / IPS is essential to security in the cloud.
In this blog, I wanted to document some of the themes as I’m hearing them and my perspective on what it means.
Theme #1: While Visibility of Vulnerabilities Has Improved, Visibility to Exploitation is Limited
I’m paraphrasing a healthcare customer here: Our application sprawl in public clouds has grown, across many cloud accounts and VPCs, leveraging many 10s of cloud services. Doing vulnerability scans is not telling me if we’ve been compromised.
Observation: Monitoring and posture management tools will give some indicators of compromise (IoCs) but without inline traffic inspection and protections, you cannot get far. What is needed is traffic inspection of encrypted traffic with automated packet captures of attacks when they happen, not logs alone.
Theme #2: Supply Chain Attacks Will Persist
Year after year, the Verizon DBIR has shown that older vulnerabilities still persist years after the initial discovery. This is clearly driven by the current application development process that leverages hundreds of third-party and open-source software libraries in an agile process.
Observation: Attackers are clearly cognizant of the issue we all now recognize, many open source libraries don’t have sufficient resources for code reviews, vulnerability scans, and maintenance.
Theme #3: Patching is Hard and Usually Slower Than What’s Required of Security
Weeks after the Log4J vulnerability was announced we noticed a sense of exasperation from some customers who almost were sure they had found critical production systems that might be affected, but were unsure about the “pockets” out there that might be connected to the critical systems.
Observation: No real insight here, but the plain reality: it’s a lot of grunt work to find the vulnerable systems, test the patches in staging for compatibility, stability, and performance, and then roll them out in a maintenance window. And, perhaps redoing this multiple times as new updates occur – as was the case with Log4J.
In some ways, there is no big revelation here. The two most significant security approaches of the day, zero trust and defense in depth, emphasize least privilege and the application of a layered set of dynamic security controls – to which we think the addition of contextual visibility of anomalous behavior is critical. What’s news is that we’ve all finally woken up and said we have to do this in public clouds as well.
At Valtix we have built a robust, multi-cloud IDS / IPS that can be simply configured as policy and associated with cloud-native workload identities like tags. We’ve also consistently delivered mitigations across multiple emerging cloud vulnerabilities as they were divulged. For example, we delivered a virtual patch for Log4Shell within a day of when the vulnerability was made public (and as all the new variations emerged). And prior to that, Valtix provided effective mitigations for Omigod in Azure. It’s inevitable that there will be additional vulnerabilities and whether they are open-source libraries or issues in the CSPs themselves, Valtix stands ready to do everything we can to help protect customers when they do.
