I have been an advocate of application security for a long time, and it has always been frustrating to me that AppSec is often the least well-funded group within IT security. As an industry, we spend hundreds of millions of dollars on firewalls and AV software every year, but willingly leave vulnerabilities unfixed in our applications, only to be found by enterprising intruders.

We all know that it is better for security to be built in rather than bolted on. Yet, few organizations can truly practice “building security in” because a) developers don’t want to change their processes, b) developers don’t necessarily know what to do in order to build security in, and c) (This is a big one) it is simply not possible to have full stack security in a monolithic application environment.

That is until immutable infrastructure, or containers, burst on the scene and challenged some of the traditional wisdom of application development and deployment.

With containers, a developer can easily specify, for instance, a read-only file system or read-only database, and the runtime system could enforce that. Docker, more specifically, allows developers to specify a variety of run-time application security requirements and Docker would execute those requirements in production. For instance, a developer can specify the execution or I/O priorities of various application pieces, including security.

This offers an interesting opportunity for application security-relevant decisions to be made upstream at development time, which helps free up runtime resources to deal with the truly egregious stuff.

But, we can do even better than that.

With immutable infrastructure, it is now conceivable to determine, statically, what a common system component, such as a database engine or a storage node, might behave in runtime. If we pass this knowledge from development time to production, anything deviating from that behavior is potentially suspect.

That, is game changing.

Imagine, for a moment, that a security layer embedded in the container ecosystem can automatically determine and enforce a container’s run-time behavior, based on a few policy breadcrumbs that the developer seamlessly coded in, caveat emptor. This, is how you truly build security in and ultimately create that force multiplier that IT so desperately needs.

What type system did for language safety, containers will do for application security. If this is not a disruptive opportunity, I don’t know what is.

To truly leverage this disruptive potential, though, you need a security solution that has these properties:

Full stack: What is the point of a container security solution if you can only deal with one layer of the system? The security mechanism must handle Node.js, Ruby, Java, the Linux distribution layer, as well as the container itself. It’s not a solution for containers if you can’t handle the full stack layers.

From dev to production: The only way to allow developers make policy decisions or specify requirements at dev time is to have the policy apparatus extend from development to production. In other words, you need to cover the entire application lifecycle. Sure, there is value in a dev-only capability where developers can use to scan applications and containers before deployment, but who can tell you how many of (and where) your production containers had the “Heartbleed” bug if you don’t have runtime capabilities?

Run anywhere your containers do: This goes to the very heart of the container promise. Containers are extremely agile and portable. The security solution must be as agile and portable as the containers it protects. There is nothing worse if security impedes the agility or productivity premium that is enabled by containers.

As container adoption continues to gather steam, you need to ensure that security technologies are purpose-built for this new environment. Traditional security pivoting for containers, or those that narrowly focused on just one stage of the lifecycle, may just miss the point.

Twistlock is proud to be the pioneer in the container security market. The fact that we are 4 months out of stealth, and we already have 9 beta customers, with 2 more deploying next week, serves as a proof point that customers want purpose-built technologies and a true dev-to-production approach.

I believe that we are just beginning to see the tip of the iceberg on this one. We don’t yet know the full extent of this disruptive opportunity, but I am sure glad that we are part of the journey.

← Back to All Posts Next Post →