SBN

Threat Stack Announces General Availability of Its Docker Containerized Agent

Last month we announced that a containerized version of the Threat Stack Agent was coming soon for customers who are using containers to deploy cloud workloads. Today, we are excited to announce that our Docker Containerized Agent is now generally available. As cloud infrastructure shifts more heavily towards containers, we are pleased to bring this option to market as a way to gain unmatched visibility into the entire infrastructure — hosts, containers, and the control plane — to ensure that our customers have the best cloud security monitoring and alerting in place across all their assets.

Containerizing cloud infrastructure has become the hot new thing to do — and for good reason. Containers bring a large number of benefits to DevOps teams that want the ability to move quickly and deploy as efficiently and effectively as possible. Easier write-test-deploy cycles, flexibility to explore new frameworks, and simpler workflows for updating resources are just a few of the reasons teams are moving towards containerization.

According to Data Dog, Docker usage drastically increased among adopters in 2018, and the average lifetime of a Docker container in an orchestrated infrastructure is just 12 hours. Increased usage with short container lifetime means that teams are spinning up and breaking down containers every single day. So as the shift to more ephemeral infrastructure becomes a reality in the cloud, it is critical that security tools be able to move just as flexibly while enabling a stronger security posture across your entire infrastructure.

However, the question of the “best” way to secure the containers themselves remains up to debate.

At one end of the spectrum, you have tools that stay outside the containers completely and just monitor container activity from the host itself. The issue here is that, as teams shift the balance of hosts and containers more heavily towards containers, they can lose visibility into what’s going on in the containerized part of the infrastructure, unless they make special considerations for the host-based tools as part of their build process. Also, if you’re leveraging an orchestration tool like Kubernetes, your security tool cannot deploy in the same workflows as your containers, and you suddenly have gaps in visibility.

On the other end of the spectrum, you have container security tools that require code to be deployed in each individual container. Now you have the reverse problem of host-only tools and lose visibility into what’s going on at the host level. Again, you’re presented with the scary possibility of a malicious actor crossing the container boundary and bouncing around your hosts or leveraging other cloud provider services without your knowledge. While the bulk of your infrastructure may lie in those containers, it’s still crucial to have an eye on exactly what else is going on across all of your cloud resources.

The Goldilocks Principle

Each of these viewpoints has its benefits, but also some critical pitfalls. Somewhere in between these viewpoints, you want an approach that is flexible enough but still provides the security coverage you need — in other words, you want one that is “just right.” In practical terms, you want a security tool that can do two things equally well.

First, you want a tool that grants visibility into your entire infrastructure so you can efficiently investigate an incident by seeing movement between containers, into hosts, and on the infrastructure control plane level in order to understand exactly what the malicious actor did, where they were, and what they touched.

Second, you want to be sure you can deploy the solution in an efficient way that doesn’t create more burden on your dev and ops teams. This means both deploying as an independent container or pod within each node and doing so via deployment options like Kubernetes daemonsets. Doing so ensures maximum security visibility into each container and any underlying hosts without sacrificing speed or efficiency.

To help illustrate these points, Enterprise Strategy Group (ESG) recently published a survey stating that customers should consider whether they will require a security implementation that is as portable as the application containers they are intended to secure. This point and the survey in general, are tightly aligned with the release strategy for our Docker Containerized Agent to ensure that customers have the most flexible deployment options that operate with their existing CI/CD workflows.

In the march to general availability of this containerized agent release, we have been working with a number of beta customers to ensure that we are delivering on these release goals. In every case, customers reported on their ability to deploy through Kubernetes daemonsets as well as noticeable increases in efficiency across the board while maintaining the same level of visibility into user, file, and network level activity — even when there were dozens of pods in each node. In each of these scenarios, customers saw how easily they were able to visualize user behavior across the container, host, and AWS control plane with Threat Stack CloudTrail activity monitoring in order to gain full visibility into malicious behavior. These customers were able to accomplish this by implementing the Threat Stack Cloud Security Platform®  into their existing build process — without having to alter their current development processes.

To learn how Threat Stack can be seamlessly integrated into your build pipeline or to learn more about how we can help you secure your evolving infrastructure, feel free to request a demo with one of our engineers.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Hank Schless. Read the original post at: https://www.threatstack.com/blog/threat-stack-announces-general-availability-of-its-docker-containerized-agent