As many security professionals may already know, Docker has the potential to have a significant impact on an enterprise. Among numerous potential advantages, it can increase data center allocation density, the speed of development, it can enable new deployment models for cloud, and increase the efficiency of technical operations.
From a security point of view, it can have significant impacts as well, both potentially positive and negative. One the one hand, for some it will re-open security issues that we struggled with in the past: sprawl, “stale” (i.e. out of date) images, unexpected migration of images/containers, etc. On the other hand, if approached in a controlled and disciplined way, it has the potential to bolster security: by making it easier to package and roll out security controls/updates, by allowing better management of applications (e.g. dynamically relocating where applications live in response to threats or in response to a natural disaster), and potentially making it easier to manage configuration.
Given these things, it can be advantageous for security pros to start now in preparing their security program even if your organization isn’t actively embracing it yet. It may seem counter-intuitive to start preparing for a technology before you’re actually using it, but keep in mind how rapidly technologies like cloud, mobile, or even virtualization proliferated in the past. If Docker is as likely to take off as many think it is, we don’t want to learn about usage when we’re up to our waist in it (which isn’t the optimal time to begin preparations to secure it). Instead, by taking a few steps now, we can make sure our security programs are ready so we’re not left holding the bag later.
To do that, we’ve called out a few critical things that organizations can do now to help lay the groundwork. Note that these aren’t the only things that organizations can do to prepare for and secure Docker… in other words, this isn’t intended to be an exhaustive list of everything you can do to secure it. Instead, we’ve focused on things that have a benefit regardless of whether or not the organization ultimately embraces Docker; if it starts getting traction the organization, the security team has a leg up. If not, that’s fine too: the organization is no worse off, time/resources aren’t wasted, and security goals are still moved ahead.
Step 1: Shore up Inventorying and Inventorying Tools
As most organizations know, keeping a healthy and accurate record of what’s in their environments isn’t easy. Virtualization in the datacenter has served to make inventories more “dynamic”: the ability to create VM clones and the ability to dynamically relocate workloads means inventories need to be refreshed much more often to stay accurate. Add cloud (particularly IaaS) to the mix and this situation becomes even more complicated. Add Docker, and the complexity is increased again.
To see what I mean here, keep in mind that Docker containers can reside anywhere on virtual or physical hosts: you might for example have a virtual machine in an off-premise IaaS cloud provider running the Docker engine and hosting applications or you might have it running in an on-premise physical or virtual datacenter. Since both virtual hosts and the containers themselves can be rapidly relocated, can be easily cloned, and can “burst” into different environments in response to demand, inventories need to account for this.
Organizations might start shoring up their inventorying methodology by taking a critical look at the tools and processes that they have in place and thinking through what changes might be required to account for application containers. This might mean changes to the tools or processes used, better/more plug-ins to existing automated inventorying techniques, potentially different processes, and additional data to collect. For those shops that do move to Docker, the security team will know from the get-go what they need to do to adapt; for those that don’t, they’ve bolstered their asset management capability regardless. For those in the mid-market that aren’t using inventorying tools, they might consider looking at free alternatives like SpiceWorks or open source alternatives like Fusion Inventory – they’re useful in any environment, but become particularly so if Docker gains momentum in their technology ecosystem.
Step 2: Development Integration
We all know that security can’t live in a bubble. Working closely with business teams, technology peers, auditors, compliance, legal and other stakeholders is a key part of ensuring security is in the loop. So having solid relationships is always a good idea. That said, as Docker gains momentum, it might be a particularly good idea to cement relationships with development teams specifically. Why? Because having a communication path with them will make sure you know about usage early and can lay the groundwork for security measures you might implement.
Keep in mind that developers realize value quickly and directly from Docker. The portability of containers enables them to move code quickly between environments (e.g., QA, staging, and ultimately production) while the configurability means less time spent tweaking each environment and more time focused on business logic and functionality. Couple the appeal Docker has with the ease of deployment, and development is one of the likely areas where shadow usage will likely develop.
Establishing a bi-directional line of communication with development teams now can help you stay alert should those teams start experimenting with Docker. Early knowledge means you have more time to prepare solutions and controls to meet expanding usage. If the organization doesn’t adopt, this relationship is still useful: it can help with DevOps initiatives, can help you accomplish application security goals (like developer training, code review, scanning, etc.), and can give you visibility into new projects you might not otherwise have.
Step 3: Application (or vulnerability) Scanning
Scanning for vulnerabilities in any environment is always a good practice, whether you’re looking at individual hosts to enumerate services and find issues or whether you’re looking at applications utilizing dynamic application security testing or static application security testing (DAST and SAST). However, there can be additional advantages in a Docker context.
Specifically, one of the challenges organizations face is that Docker can increase the likelihood that the same application exists in multiple places – sometimes with differing configuration (different versions of underlying components or different versions of the codebase). For example, you might have a version of an application and supporting components in a staging environment, a different version of that same application at a cloud provider, and another in a DR environment. Because containers are relatively easy to configure, supporting components like libraries or supporting components might be different, the code itself might be different, etc. This can create security and management challenges.
Leveraging vulnerability scanning tools can help you find these so that containers can be standardized to the most robust option. Granted, scanning tools aren’t necessarily going to flag on these using “out of the box” configuration, but they can be used to alert you to changes and issues, potentially flagging problematic software or supporting components along the way. Since this is a useful activity to conduct regardless of Docker/no-Docker, bolstering your capabilities in this area can be helpful even if your organization doesn’t embrace for some time.
The point is, thinking about Docker now can be advantageous. By thinking through how you’re doing inventorying, how you’re interfacing with development teams, and by leveraging vulnerability and application scanning tools, you can both keep alert for shadow usage of Docker in your organization and also start to lay the foundation for the tools and techniques you’ll use to secure it when it potentially becomes more prevalent.
Ed Moyle is Director of Emerging Business and Technology for ISACA. Prior to joining ISACA, Ed was a founding partner of the analyst firm Security Curve. In his more than 15 years in information security, Ed has held numerous practitioner and analyst positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech. Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the Information Security industry as author, public speaker, and analyst.