When Good Infrastructure Goes Bad: Vulnerabilities Drive The Case For Zero-Trust Models

When Good Infrastructure Goes Bad: Vulnerabilities Drive The Case For Zero-Trust Models

The past few weeks have seen a spate of infrastructure-related cybersecurity vulnerabilities.

On March 8th,  Apache released a critical vulnerability alert (CVE) regarding a significant vulnerability in its Struts 2.0 opensource enterprise Java framework, which is widely used in enterprise deployments.  The vulnerability permits remote code execution (RCE) in the framework; recommended mitigation strategies include upgrading the framework or changing implementations.

Recent vulnerabilities in major vendors and open-source providers

On March 17, Cisco Systems acknowledged that a vulnerability related to cluster management protocol (CMP) afflicted more than 300 of its devices. The vulnerability was first revealed by Wikileaks, and there are no workarounds to date.
On March 22, Google Project Zero researcher Travis Ormandy announced three vulnerabilities in password management provider LastPass, which were fixed on the same date. The vulnerabilities included an RCE vulnerability that could have enabled the proxying of internal Remote Procedure Call (RPC) commands.

And on March 28, Apple announced it fixed 223 bugs across IOS, macOS Sierra, Safari, watchOS, and tvOS. The vulnerabilities,  discovered by a range of researchers, including Google Project Zero researcher Ian Beer and Jung Hoon Lee, again could have led to RCE, often with root privileges. (Note: this has nothing to do with the supposed iCloud ransomware attack, which Apple has denied is real.)

The onslaught continues, with vulnerabilities recently discovered in Samsung’s Tizen Android operating system and Huawei’s Fusion storage among others.

What’s the message here? Should enterprise technologists take option A and avoid using products from Apache, Cisco, LastPass, Apple, Samsung, and Huawei?

Well, maybe, if that’s what flips your bits. If you harbor a particular dislike for these providers, or have other reasons to avoid buying from them or using their tools, don’t let me stand in the way.

But don’t do it on the grounds of known security vulnerabilities, because virtually all major providers (both commercial and open-source) have had significant vulnerabilities in the past few years.  This just happens to be the group that was hit over the past couple of weeks–I selected them to make a bigger point.

Option B–hiding your head in the sand–is the option that most of the security professionals I work with have chosen.

Essentially, the argument goes like this: If I buy from major vendors (or use widely-deployed open-source provider), if my company gets breached it’s not my fault, it’s the providers’. So I’m less likely to get fired.

That’s true enough, so far as it goes, but it has one major problem: You’re still liable to get breached.

Option C is to adopt a zero trust model, as Google has done. In a zero trust model, the assumption is that any device, application, or data store could be breached at any time. The idea is to limit the damage that any single breach can cause by embedding security within the devices, applications, and data store using techniques like segmentation, microsegmentation, and containerization.

This all sounds good–but it upends most of the assumptions that security professionals have made throughout their careers. For instance, the notion of a firewall-protected perimeter becomes obsolete (a concept that strikes fear into the hearts of many network security professionals). And advanced endpoint security (AES) is no longer an option, but table stakes. Finally, zero-trust is impossible to implement unless you have a solid–and automated–data classification scheme in place.

We’ll talk more about the practical implications of zero-trust models in our upcoming research.  Meantime, today’s takeaway should be: assume your infrastructure is already compromised. Because it more than likely is.