I have been meaning to write my thoughts on the Spectre and Meltdown vulnerabilities, but held back until now. I wanted the proverbial dust of noise from the “ambulance chasing security vendors” to settle down. Now that it has, to some extent, let me express my thoughts on the two vulnerabilities. These are the real lessons learned, at least in the context of containers and containerized applications.
First, Layered Insight’s solutions couldn’t have protected against the attacks that exploited the Spectre and Meltdown vulnerabilities. As a simple analogy, a car manufacturer builds safety and security features in a car with base assumptions. In this case, the manufacturer assumes that the car will be driven on a surface with gravity. If such a fundamental assumption is mucked with, or is proven wrong, no amount of safety or security features would keep the passengers of the car safe. Actually, none of the security vendors’ solutions could have protected any enterprise application from those attacks. Anyone claiming, or trying to convince otherwise, is just lying. Of course, for further clarification, the keyword in my claim is ‘protection’. Many security vendors have built ‘detection’ capabilities — after the fact — in their solutions to detect if the kernel, and thus applications, could be vulnerable to those attacks.
Could Containers Have Helped?
Quite a few container enthusiasts have claimed that if the applications were to be containerized, they would have been immune to such attacks. The short response to such claims is ‘No’. As I mentioned above, neither virtual machines nor containers, and not bare metal operating systems, could have protected the applications from those attacks. Without getting into too many technical details, any application container that was compromised could have been used to access sensitive information from the underlying kernel and from other application containers. So no, containers couldn’t have protected the applications from those attacks.
However, containers could have definitely made the application patching — to address the vulnerabilities — and the rollout much easier. Especially, when coupled with automated CI/CD pipelines.
How About Immutable Infrastructure?
The portability aspect of containers have lead to the adoption of ‘Immutable Infrastructure’. By bundling anything and everything that an application needs, the resulting impact on the underlying infrastructure is that it can be very thin and simple, hence ‘immutable’. Containers are accelerating this adoption. Most container operating systems are highly optimized, including just the kernel to facilitate the execution of containers.
Immutable infrastructure couldn’t have helped protect the applications — containerized or otherwise — from the attacks either. However, patching the underlying infrastructure would have been much simpler. Just ‘rip and replace’ the infrastructure layer with a new one that has the fix in it.
Hindsight is Always 20/20
Now that the vulnerabilities are well known, a useful tool would be one that would help enterprises evaluate if their application and/or the infrastructure needs to be patched. We’ll leave this to the traditional security vendors.
The takeaway for me is that, once in a long while, things are discovered that challenge our fundamental assumptions. It forces us to relook at the parameters under which our designed solutions work. We tend to forget those parameters or limitations by re-implementing the same approaches until vulnerabilities like Spectre and Meltdown shake that foundation. The same is true for containers and immutable infrastructure. Granting root privileges and tying security solutions to the host is not the future of container security. What’s the next vulnerability, like Spectre and Meltdown, that shakes that complacency?