This column is available in a weekly newsletter called IT Best Practices. Click here to subscribe.
A senior executive of one of the world's largest commercial software companies told me they use software containers in their development process to increase agility and bring new products and updates to market more quickly. Their development cycle is now months instead of years.
A software container is simply a very thin package of an application and all the libraries that support the application, which makes it easy to move the application from one operating system to another. A developer can build an entire application and then use a tool to take all the source code and supporting files and basically create something like a zip file so the container can be deployed just about anywhere. It contains everything the application needs to run, including code, runtime, system tools and system libraries.
Unlike a virtual machine that has the whole operating system beneath it in a package, a container is just the application. Containers are smaller, thinner and typically more portable than VMs because you can run them on top of any hypervisor as long as you have the proper host OS running above that hypervisor.
The most popular container technology is Docker.Basedon open standards, Docker containers can run on all major Linux distributions and Microsoft operating systems with support for every infrastructure. They have become very mainstream because of the beneficial impact on organizations to quickly deploy new applications.
Containers are awesome but they have drawbacks. There are some security risks that go along with this new development idea.
For one thing, containers don't keep themselves up to date. There's no mechanism to make sure the components within the container are staying up to date and and addressing security vulnerabilities. For example, it's easy to create a container with a particular version of Java and then deploy the container. Weeks later, when a new release of Java comes out to fix a flaw in the previous version, there's really no easy way to know how many of those out-of-date containers are out there, and no way to simply install an update to the container. Furthermore, unlike VMs, containers typically don’t include anti-malware, IDS/IPS, and other security agents, which puts them at risk of attack.
A development philosophy for containers is to split up applications into micro services. Whereas a traditional application might be divided into, say, three tiers for a web app, the container approach splits the application into many more small containerized components. That three tiered web app might end up with 20 or 30 containers. Having this many entities further complicates the management task of tracking, securing and updating/replacing the containers.
Another complication is that Docker has an all-or-nothing administration model, which makes it difficult to restrict administrative privileges to just those tasks that a person or team needs to perform. This model can be a challenge for companies that want to separate administrative access across different teams, like developers and testers. It's difficult to securely delegate access to just the right level of people throughout the environment.
Startup Twistlock addresses these challenges with security and vulnerability management tools to reduce the risk of using containers. Twistlock's security solution for containerized computing primarily addresses three areas today:
- Vulnerability management, with an integrated intelligence stream of the latest CVEs and security standards
- Security hardening for containers, their contents, and the fabrics they run on
- Advanced authentication and authorization capabilities, including Kerberos support and role based access control
This is not an agent that you install on the host OS, nor is it something you have to install in your container. Taking this approach enables Twistlock to run completely independently of whatever infrastructure you deploy containers on. Anywhere you can deploy a container, Twistlock says it can protect those containers in a consistent way.
For all the places you would be deploying containers in your environment, you have a Twistlock container called a Container Defender deployed on every host you are going to be working with. This ensures that any other application that you add on top of that host is going to be monitored and protected by that Container Defender.
Your developers don't have to do anything for this capability to work; they just start building their application, package it and deploy it as they normally would. They don’t have to change their application, install an agent, build their container with a particular flag, integrate one of Twistlock's libraries, or anything like that. They literally build their app, deploy it like they normally would, and the Container Defender is able to look inside that container and make security decisions.
Some of those security decisions might be about vulnerabilities (CVEs). The Twistlock Security Intelligence Stream provides near real time consolidation of CVEs and recommended configurations from open source, vendor and governmental data sources. Twistlock’s cloud service consumes, parses, validates, and combines all this data into a single feed for Twistlock to send to its customers.
You can set up a scan of your environment to automatically inspect what applications have what binaries in them and what in those containers makes it vulnerable to a particular CVE. Now you have the ability to look inside your containers and understand your risk posture, and then make vulnerability management decisions like whether to replace containers that are high risk.
Another Twistlock capabilitity is security hardening, to make sure the environments you are running your containers on are configured properly to give you the maximum level of defense against risks to your underlying environment. In the Twistlock console, there is a policy user interface where you can select benchmark policies that will control your environment. The selected policies are consistently enforced by the Container Defender wherever you run your containers.
Aside from configuring policies in the Twistlock console, you also can see analytics about your environment, logging information about the configuration, the setup of the hosts, and more. All the information from the console can be sent to your preferred SIEM tools to make it easy to analyze this data in the context of your enterprise risk posture.
Containers are the future of application development but they need to be brought under control. With its security and vulnerability management tools, Twistlock looks like it can provide that control.