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

May 25, 2017

DevOps brings Development and Operations together with the sheer objective of ensuring quality and enabling faster time to market. However, what happens to QA in this scenario? How does the Testing team fit in? Let's ponder on this further and understand the role of QA and Testing in the DevOps world ...

May 23, 2017

When organizations adopt containers and microservice style architectures in production, systems become incredibly complex. For operations it's a shock because it means coming to grips with many new container tech nuances - plus letting go of the old monitoring rule book ...

May 22, 2017

Managing application performance today requires analytics. IT Operations Analytics (ITOA) is often used to augment or built into Application Performance Management solutions to process the massive amounts of metrics coming out of today's IT environment. But today ITOA stands at a crossroads as revolutionary technologies and capabilities are emerging to push it into new realms. So where is ITOA going next? With this question in mind, DEVOPSdigest partner site APMdigest asked experts across the industry for their opinions on the next steps for ITOA ...

May 18, 2017

In Part 3 of my Q&A with industry analysts, I ask: What trends will have the biggest impact on the software industry and DevOps in particular this year and beyond? How can enterprises set themselves up to succeed with so many rapid changes occurring in development and delivery? ...

May 16, 2017

See how to turbo-charge the impact of APIs, according to a global study conducted by CA Technologies ...

May 15, 2017

APIs are vital components for business success and thriving in the application economy, according to a global study conducted by CA Technologies ...

May 11, 2017

In Part 2, I'll dive into some findings from CollabNet's outreach to industry analysts. I asked them about the greatest challenges facing enterprises venturing into the world of DevOps and to touch on what lies ahead for the future of the DevOps movement ...

May 09, 2017

DevOps teams bring significant benefits to their organizations. Unfortunately, DevOps teams, like many business programs, tend to believe innovation must come with a detriment to security. Security measures are often seen as obstacles that impact the agility that DevOps teams rely on ...

May 08, 2017

With increased competition, enterprises now require greater agility than ever before, and traditional approaches simply can’t provide the speed enterprises demand. To remain competitive with these new players, companies need to improve their operational agility both in the data center and the WAN ...

May 04, 2017

There is no "right" culture for DevOps, but characteristics such as open communication, high cooperation, collaboration, respect, and trust are essential. If your organization does not have these characteristics, they must be developed. Culture is learned, not inherited. It must be genuinely nurtured by everyone from executive management on down the line. Here are some hacks to help develop a positive DevOps culture ...

Share this