Earlier this year, Jerry Chen wrote an interesting blog post that neatly summarized a lot of the trends I’ve seen across customers over the past few years. In it, he uses the term “Developer Defined Infrastructure” which really resonated with me, because it so succinctly describes a common theme I’m seeing as I talk with customers. Specifically, that the degree of both ease of use and sophistication of cloud services are making it more and more accessible for a developer to design and build not only his app, but also much of the supporting infrastructure it runs on.
If you’re a startup today, you’re probably not hiring anyone with a job title of ‘sysadmin’ or ‘IT professional’. Instead, you’re expecting the devops team to use modern cloud services from Amazon, Google, Microsoft, and others to instantiate whatever compute, network, and storage capabilities you need. On the surface, this shift may seem obvious or unremarkable, but it has huge ramifications to the way that we operate and secure systems.
At Twistlock, we’ve been talking a lot recently about how containers can actually make your apps more secure. There are no security silver bullets, but Dockerizing your apps gives you an opportunity to have a declarative security model enforced by development time tasks, either as code itself or as dev-time configurations; this is something that’s extraordinarily difficult to do with traditional monolithic applications and the ever changing infrastructure. With containers, the promise of immutable infrastructure, and technologies like Twistlock, you can now conceivably develop and enforce that declarative security model. We like to think of that as “Developer Defined Security”
We often get questions on why traditional security solutions don’t fit the container ecosystem well. One of the reasons is that most of these solutions have been developed for the traditional stack, in appliances, agents, or tied to a particular infrastructure layer. These dependencies simply do not work well in the container world where things can move from a dev linux workstation to an OpenStack powered cloud or to AWS. Moreover, these technologies are often not accessible to devops teams like the rest of the ‘Developer Defined Infrastructure’ they seek to protect.
If you look at the way we’ve built Twistlock — there are two major architectural imperatives we’re constantly balancing. First, to provide a powerful set of security capabilities that protect against real world threats our customers face. Equally important, though, is to fight these threats without sacrificing all the great benefits that are driving devops and container adoption in the first place.
To achieve the two imperatives, a key part of our approach is Twistlock’s dev-to-production strategy. Almost from the beginning, we decided that as a defined security solution for DevOps, we can’t exclusively be in development time or run time; we need to be in both. On top of that, being in both dev and run time does not mean stitching together two disparate functions and call that an end-to-end solution (God knows how many vendors have done that). We strive to build a defined security framework that carries from dev time to production. For instance, our system retains intelligence for any static container image that we scan. If this container shows up in run time on a server that we are protecting, we would know, with a fairly high confidence level, which processes should be running in the container. With that, we can easily spot an injected process dynamically. This is just an example of a meaningful dev-to-production task, there are many others that we bring together in our product that allows developers to play a much larger role in runtime security policies.
Another key part of our approach is our architecture, which is extensively API-driven. Much like AWS, Google Cloud Platform, and Azure that have comprehensive APIs making their fabrics accessible (and, thus, developer defined infrastructure possible), Twistlock is built around a programmable core that powers the Developer Defined Security approach. Nearly every action you can take with our product, from deployment, to managing access control rules, to scanning images, to runtime defense, is all accessible through a simple REST API. This enables limitless automation scenarios where you can use existing tools like Puppet, Kubernetes, or Mesos to deploy and scale Twistlock in step with your app.
Much as containers and developer defined infrastructure have greatly altered the way we build and operate apps, we think this approach of declarative defined security is going to help our customers protect those apps at scale, throughout the dev lifecycle, and on whatever clouds they run.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Cryptomining Malware Emerges
I have been watching for the spread of malware that, primarily, uses c...
Calling the Twistlock API from PowerShell
The Problem This morning, a colleague was looking for situations where...
What Makes Distributed Security ‘Cloud Native’: Podcast Overview
I caught up with Scott Fulton III on this edition of The New Stack Mak...
Reflections on the 20th Anniversary of Open Source Technology
Exactly twenty years ago in February 1998, the term “open source” ...
Enhanced Syslog Data Streams: 2.3 Deep Dive
In each of our Twistlock releases, we publish some truly remarkable fe...