3 Pillars of Intent-Based Security for Containers
February 01, 2017

Ben Bernstein
Twistlock

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. Conversely, if they develop a container-based application, they know exactly which processes are running, because they produced the entire container stack top to bottom. Developers must be able to describe the entire OS stack in order for their containers to run. This enables everything to be more automated and it typically results in everything being delivered in small frequent pieces and updates.

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:

1. 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 dockerfile, you might have a pod, 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.

2. 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 layers you download 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.

3. 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. And depending on the other indicators, you can understand if you're seeing an event that looks like an attack or not.

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.

Ben Bernstein is CEO and Co-Founder of Twistlock.

The Latest

March 23, 2017

Mature development organizations ensure automated security is woven into their DevOps practice, early, everywhere, and at scale, according to Sonatype's 2017 DevSecOps Community Survey ...

March 21, 2017

When it comes to food, we all know what's considered "good" and what's "bad". We can all understand this simple rule when eating. But for many, when it comes to software development, simple rules and advice from nutritional labels aren't always there for us ...

March 20, 2017

Monitoring and understanding what software is really doing, and maintaining good levels of software quality is increasingly important to software vendors today. Even a minor bug is capable of shutting down whole systems, and there is a real risk that development cycle pressure competes with quality assurance best practices ...

March 16, 2017

More than half (54 percent) of IT professionals surveyed indicate they have no access to self-service infrastructure, according to a new DevOps survey of 2,000 IT industry executives by Quali.This means that more than half of respondents take a ticket-based approach to infrastructure delivery, impacting productivity and increasing time to market ...

March 15, 2017

Driven by the adoption of cloud and modernization of application architectures, DevOps practices are fast gaining ground in companies that are interested in moving fast – with software eating everything - between "write code and throw it across the wall" to creating more pragmatic mechanisms that induce and maintain operational rigor. The intent behind DevOps (and DevSecOps) is quite noble and excellent in theory. Where it breaks down is in practice ...

March 13, 2017

There might be many people across organizations who claim that they’re using a DevOps approach, but often times, the “best practices” they’re using don’t align with DevOps methodologies. They can say what they do is “DevOps”, but what we’ve found is that many are actually not following basic agile methodology principles, and that’s not DevOps ...

March 09, 2017

The velocity and complexity of software delivery continues to increase as businesses adapt to new economic conditions. Optimizing and automating your deployment pipelines will dramatically reduce your lead times and enable you to deliver software faster and with better quality. Here are three more most common areas that generate the longest lead times ...

March 08, 2017

Every enterprise IT organization is unique in that it will have different bottlenecks and constraints in its deployment pipelines. With that being said, there are some common problem areas that typically produce the longest lead times in your software delivery process. Here are the most common areas that generate the longest lead times ...

March 06, 2017

The findings of an independent survey of IT leaders, application developers and database administrators, conducted by IDG Research for Datical, indicate that database administrators are unable to keep up with the pace and frequency of database changes caused by the accelerated pace of application releases, thus creating a bottleneck and delaying digital transformation initiatives. An overwhelming number of databases administrators (91 percent) and application development managers (90 percent) cited database updates as the cause for application release delays ...

March 02, 2017

A "Boost Caboose" is a secondary engine pulled on a trailer for the explicit purpose of increasing the output of the primary engine. In many ways, DevOps is its own form of Boost Caboose for application of agile methodologies within the modern software factory and SDLC/ADLC processes ...

Share this