Application Security

Three Pillars of Intent-Based Security for Containers

Recently, you may have come across other articles that feature me talking about Intent-Based Security, (like this podcast), but in today’s post I’d like to clearly define the key pillars of the concept.

First, a reminder: The concept of intent-based security is a new way of looking at applications, specifically those in a containerized environment, down to the application level and adding in extra security. It uses the power of the developer in order to produce a more predictable and secure environment that can be enforced.

To elaborate, today there is more information flowing from the developer. Historically, when developers wrote their code, if you asked them which processes are running in the operating system where their code is running, they would have no idea. They would probably know the process name of their code and that’s about it. Conversely, if they develop a container-based application, they know exactly which processes are running. Developers are trying to create micro workloads and must be able to tell the system what these workloads need to do in order for them to run. Everything needs to be more automated and it needs to be delivered in small pieces where developers understand what’s contained.

When it comes to DevOps and containers, the unique nature of the process and technology allows the intent-based security model to capitalize on three pillars:

Containers are declarative. When a developer writes the code, he/she does not just write the code, he/she writes a manifest that describes how this code should work and how it should interact with its environment. While the developer does not provide you with a real security manifest, you can translate the extra information that you have and try to create a security profile. With containers you have a Docker file, you might have a pod, and you might have an application group if you’re running on top of mesosphere. There is a lot of information in the system that you could use in order to understand what is supposed to happen.

Containers are predictable. When you look at containers, they contain less specific logic and more common building blocks because containers are typically made out of downloadable layers that someone else created. For example, if you’re creating a container, you don’t write the OS from scratch, you take an Ubuntu. If you’re using MySQL, then you’ll just take a MySQL layer and put it in your container. And then if, on top of that, it’s just a database and you want to add a thin layer of configuration, you’ve got Ubuntu, MySQL and on top of that a little bit of configuration. That’s a pretty predictable piece of software. It’s very minimalistic, there’s not a lot of logic in it and it’s built out of common building blocks. So you could basically assume what that piece is supposed to do. But even if it wasn’t just configuration and there was some logic in it, it would contain less logic than a virtual machine would because it’s a microservice. Baselining behavior based on a more minimalistic microservice is much easier than it was in the case of virtual machines.

Containers are immutable. In the past, it was hard to understand if something happening with the application was really an attack or not. In the case of containers, whenever you patch a container or change its real intent, it should not happen in real time. What happens is the developer changes things and then he/she pushes in a new version. He patches the OS or adds new functionality and then pushes in a new container and scratches the old one. This gives you a lot of power from a security standpoint because, for the first time ever, if you see a polymorphic change in the behavior of the application (if it starts behaving differently) it’s either a configuration drift, which is bad, or a real attack.

Leveraging these three pillars, there is a powerful opportunity to use whitelisting, for example, to approve known good processes. In combination with application intent analysis, enforcement measures help to support the intent-based security model and preserve the original intent of the application. For more information on intent-based security and Twistlock products in general, subscribe to our newsletter or email us at contact@twistlock.com.

Ben Bernstein co-founded Twistlock, Inc. in 2015, and serves as its Chief Executive Officer. Ben has 14+ years of experience in enterprise security and operating systems. He is a Microsoft veteran with extensive experiences in both software development and product management. Ben is a veteran of the Israeli Intelligence Corps. He has a B.A cum laude in Computer Science from the Technion in Israel and an MBA with a scholarship of excellence from the Interdisciplinary Center in Israel. Ben hates writing about himself in third person.