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

August 17, 2017

Mobile SDKs (software developments kits); love them or hate them, they're here to stay. They provide our apps with all sorts of functionality that would be incredibly time consuming to build, and they give us another means to monetize our apps. While it would be difficult to argue that SDKs aren’t useful, it’s also hard for developers to get a good idea of the amount of resources used by each SDK once the app is in production ...

August 15, 2017

A common belief within DevOps circles is that automation not only enables greater frequency of delivery and deployment, but improves its overall success rate. Whenever manual intervention is required, the chances of errors creeping in increases. Human error is a significant factor in many an outage, after all ...

August 14, 2017

DevOps and NetOps are both far more generous in their opinion of the other with respect to prioritization of efforts than traditional archetypes purport them to be, and they have a lot in common – even though they may disagree on details – according to a new survey by F5 ...

August 10, 2017

Only 12 percent of organizations can claim that their whole organization is on the path to business agility even though more than two thirds of survey participants agreed that agile organizations are better able to quickly respond to dynamic business conditions, according to a new survey from CA Technologies ...

August 09, 2017

Alongside its clear benefits, DevOps brings unique challenges when developing and operating a mobile environment. Mobile app developers and development teams face a unique set of requirements relating to collaboration, testing, and release. Technology fragmentation, disparate back-end systems, updates that require user action, and poor instrumentation can impede the DevOps process and become critical roadblocks to agile mobile development, ultimately impacting app retention and the bottom line ...

August 07, 2017

A crashing app might be a deal breaker, no matter how heavy the load that an alternative website entry point can handle would be. It is all about quickly verifying compliance against key functional and non-functional requirements in order to meet aggressive release schedules as part of the Go-to-market strategy. This means positioning unit testing, UI testing, API testing, and, of course, performance and load testing — as pillars of SDLC ...

August 03, 2017

Most software developers make themselves easy targets for hackers, even when they are behind a corporate firewall, according to a new survey from Netsparker Ltd. ...

August 01, 2017

Your top priority is to improve application development agility, but you may run into roadblocks put up by a security team that (mistakenly) believes speed is the enemy of effective cybersecurity. A new survey finds a majority of enterprises are working to overcome those roadblocks by integrating security into their existing DevOps methodology ...

July 31, 2017

Agile development compresses software testing cycles, jeopardizing risk coverage and opening the door for software failures. Here's what you can do ...

July 27, 2017

While 75 percent of organizations highlight continuous testing as critical or important, only a minority of survey respondents have made exceptional progress acquiring the necessary knowledge and key enablers to drive digital transformation, according to a global study by CA Technologies ...

Share this