Container Security Automation: Keeping Up With The DevOps Crowd

This article was originally published in InfoWorld.com, New Tech Forum. 

From development to deployment, one of the most distinctive traits of using containers is speed. The development cycle is not only rapid, but divided into multiple, bite-sized components that are constantly updated. At runtime, frequent updates and sometimes ephemeral workloads make it a challenge to lock down any environment.This scenario perfectly exemplifies why speed has always been the enemy of security, but in container-based development environments, there is a way to nip this problem in the bud: automation, automation, and more automation.

In devops environments, automation is par for the course, but traditional security tools and methods were not designed for CI/CD settings, and they are usually ill-suited to address key elements of container security. Simply put, it is not possible to keep up with container image updates, deliver reliable alerts, and detect anomalies if we continue relying on a manual, start-and-stop system.

What needs to be automated? Namely, the discovery of security vulnerabilities during development, and the application of security policies and blocking of suspicious behaviors in production.

During development, security scanning of container images needs to be automated as part of the CI/CD build process. Images should be allowed or disallowed according to a clearly defined policy.

At the same time, automated security testing must be unobtrusive and usable. The solution you choose should be fully integrated into your development workflow and fast enough to withstand the inflow of updated images. It also needs to be continuous, to enable constant checks and validation of overall security posture.

When an unacceptable vulnerability is found, this will fail the build and prevent the image from moving to the next stage (dev to test, test to staging), but then what? Clearly it is equally important to work remediation into the process and not leave the job half-done. It’s imperative to send information back to developers either by opening a ticket (for example, in Jira) or sending messages via a collaboration channel such as Slack. This way, the feedback loop is also automated and leaves nothing to manual scheduling.

2. Automated security policy creation & updates

What about setting the security policy for containers? The challenge is that containers might exhibit different behaviors (resource use, networking, file access) depending on their application payload and the context in which they operate. For example, a database container may need different privileges for an ephemeral internal application than for an external persistent application.

Clearly, taking a cookie-cutter approach for all containers won’t work. Nor will setting a static policy at the time the application is launched, because then updates will not be taken into account, and updates may be quite frequent.

It’s also not possible to rely on developers to define the security parameters manually. Developers possess neither the skills nor the time to do that, certainly not when images are constantly updated. Relying entirely on the declarative metadata in containers provides a limited, and not necessarily accurate, representation of what a container should be doing.

The answer lies in automated profiling of container behavior, using declarative principles as the baseline but looking at actual container behavior to determine legitimate behavior. By employing techniques such as machine learning, you can determine the scope of a container’s normal activity with a high degree of accuracy, and from there it’s easy to detect anomalies. And being automated, this profile can be updated whenever the container is updated or its runtime parameters change.

3. Automated blocking of suspicious activities

Container deployments present a significantly larger attack surface when compared to traditional deployments. This larger attack surface is due to the relatively large amount of third-party code, the sheer number of entities to track, and the speed at which containers can appear and disappear.

The security world in general is moving from detection to automated prevention—both because the flood of alerts makes it impossible to act in a timely fashion and because attacks may be over before a human can react. With containers this shift is even more critical. Knowing that container X has run a privilege-escalation attack and has successfully obtained root privileges on the host is useful only in hindsight. We must prevent that from happening in the first place because after the fact might be too late.

The challenge, of course, is how to avoid false positives. False-positive alerts are annoying, but false-positive blocking can be downright detrimental. However, given the automated profiling of container behavior I outlined above, false positives can be dramatically reduced—even to the point where it is realistic to use automated prevention, delivering real-time defense to container runtime applications.

The same characteristics that make containers an outstanding environment for wide-scale and low-footprint deployments also make them impossible to secure using traditional, manually driven security solutions. If you’re going to adopt containers on a large scale, you should make security automation part of your plan.