5 Questions with StackRox Cofounder and CEO Sameer Bhalotra
1. Since you started StackRox in 2014, how much production use of containers have you seen?
There’s been a substantial increase in the number of Global 2000 enterprises with Docker containers in development and staging, and many of them have been testing the water with deploying containers in production environments. We knew that major enterprises were moving to containers as a way to speed development processes and optimize computing resources across different environments — on-premises, cloud, and hybrid environments. The trend we were seeing was similar to what we saw with the public cloud such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform; container adoption would start with applications in development, staging and testing, and then once organizations gained enough confidence, they’d roll those containers into production.
Of course, security has a significant impact on an organization’s comfort in moving containers to production. Leading Chief Security Officers, such as Alex Stamos of Facebook and John Stewart of Cisco, have been our allies and design partners from the very beginning. They wanted a new type of security solution that’s fully tuned to their environments to safely move containers into production. Today, surveys are showing an uptake of containers in production; a 451 Research study earlier this year found that more than 50% of all enterprises using containers are running them in production.
2. What sort of security issues have your customers faced with respect to their container environments?
We see a mix of common threats, such as web-based attacks, and new types of attack vectors. These include threats such as code injection, privilege escalation, malicious lateral movement, and data exfiltration — because attackers will target applications regardless of how they are deployed. We also see container-specific attack surfaces posing new challenges, with applications being spun up and down rapidly, containers that are ephemeral and microservices distributed across environments.
One interesting type of attack we’ve seen is something we call “ container hijack and kill.” In this type of attack, an attacker compromises a container via code injection or execution, uses the container to gain access to the host, drops a rootkit to the host, and then kills the container, leaving little information behind. Containers are coming up and down so quickly that you might not notice that a container’s gone, and a security team might not have the forensics data it would typically use to understand the attacker’s techniques.
So in this scenario, an attacker can get in, steal files, and cover up his tracks relatively easily, which makes it harder for organizations to respond.
3. Could these security issues have been found with traditional scanning, sniffing, and logging solutions?
No. Unfortunately, existing security solutions aren’t effective in these new container environments. Most existing host-based and network security tools do not have the ability to monitor or capture container activity. Those tools were built to protect single operating systems or traffic between host machines rather than securing the applications running on them, so traditional security solutions cannot see container events, system interactions, and inter-container traffic.
Also, it’s difficult for traditional security methods to keep up with the speed and ephemeral nature of containers. For example, with conventional detection applied to monolithic applications, you look for known signatures. With container environments, application services are constantly scaling, talking programmatically to each other, and exchanging data in distributed environments. Indicators of compromise, indicators of attack, signs or identifiers of threats are distributed and therefore harder to spot. Attack patterns are also changing, shifting away from tools, and focusing on advanced techniques. Traditional detection methodologies are unable to effectively understand these patterns.
My co-founder Ali Golshan and I were recently on the ARCHITECHT Show to discuss this topic, right after our launch out of stealth. It was a lively conversation and great session, thanks to Derrick Harris.
4. How is StackRox deployed and integrated into typical enterprise environments?
StackRox operates as a set of security microservices that runs in containers. These containers are scheduled and deployed across the customer’s environment alongside their existing applications based on integrations with container orchestrators and platforms, such as Google’s Kubernetes, Red Hat OpenShift, Docker Swarm, or Docker Enterprise Edition.
StackRox instruments the customer’s entire container infrastructure — automatically discovering every container across the environment, and mapping out a clear depiction of connections between containers, microservices and applications. It monitors millions of signals, including system calls, network traffic, and Docker events.
With all of this information collected, StackRox analyzes it against very detailed behavior models that we generate, giving enterprises contextual detection that helps security teams understand alerts and their events, not just for a particular container, but across their applications.
StackRox also provides enforcement capabilities. StackRox can isolate, quarantine, and block commands for containers. This gives enterprises a full suite where they can actually prevent or respond to malicious activity. In fact the Department of Homeland Security just announced a contract with StackRox to develop more advanced responses to attacks, and we’re excited to work together with the Government to push the envelope.
5. Where can readers go to learn more about StackRox?
You can learn more about our approach to container security on our website and on our product page. We also just launched our blog, which we hope will become a valuable resource for those seeking a deeper understanding of security for containers and microservices.
Originally published at https://www.linkedin.com on September 5, 2017.