StackRox And The Reinvention Of Security For Microservices
At Sequoia, we have been very selective in our cyber security investments. Years ago, Palo Alto Networks and FireEye incubated in our offices. We’ve since partnered with a handful of companies, including Barracuda, Carbon Black, Okta, OpenDNS, and Skyhigh. But we have not accelerated our security investments in line with the market. According to CB Insights, in the last five years alone, $13.2 billion has been invested in security-related private companies, spread across 829 financings. There’s clearly a need, as shown by constant breaches and ransomware attacks. Our challenge is that it’s very hard to build an enduring security company -- it takes a unique combination of market, technology, and team.
We believe that rare blend exists in StackRox, which is today talking publicly about its product for the first time.
StackRox is capitalizing on a shift in application architecture. We have seen these kinds of shifts create large security companies in the past. It's virtualization that enables FireEye and the cloud that drives demand for Okta and Skyhigh. For StackRox, the change is that developers have moved en masse from closed, secure virtual machines to the more open, vulnerable world of containers. As a result, applications are built and deployed in a different way, which creates a new attack surface for hackers to exploit. For example, a bad actor might insert a rogue container which exfiltrates data.
StackRox helps CISOs (Chief Information Security Officers) protect against these kinds of threats, and that in itself has great value. But it also has the opportunity to do much more. That’s because, unlike other architectural shifts, this one also creates a massive opportunity to reinvent application security.
It’s a truism that developers will not change the way they write code to improve security. So security products create "control points”, where security policies can be applied. For Palo Alto, it’s network traffic; for Okta, it’s identity; for Skyhigh, it's cloud traffic.What’s different today is that applications are being written as “microservices", meaning small, loosely-coupled autonomous units which are wrapped in containers, rather than as large, monolithic bodies of code.
That means, for the first time, it’s possible to move that control point to the application itself. By collecting data upfront -- system calls from containers, Docker event data, etc. -- it’s now possible for security teams to get much greater visibility and control inside applications than was ever possible before. In a sense, security teams can now build security into the application environment by monitoring and regulating the flow of information between application components. If done right, it would take away the need for other control points — why have web application firewalls (WAFs) or intrusion detection systems (IDS), if you can layer security into the core of the application itself?
With the StackRox team in early 2016
That’s the larger opportunity for StackRox. It's part of the macro trend which Gartner describes as "adaptive security", meaning a move from one-off assessments to real-time, continuous monitoring. And it’s what Sameer and Ali explained when we first met them at the seed stage in 2015 (thank you, Mike Dauber, for introducing us!). We were immediately struck by their clarity of vision, which aligns with our own, about the future of security. As we got to know each other, and they shared more about their plans, we were impressed by the depth of the technology, and the immensely talented technical team that they had assembled. It’s why we are so excited to partner with them in their series A, and together take the long, multi-year journey to reinvent security from the inside, out.
Having written a number of applications some with centralized event, data and status logs from different parts of the application and some with more decentralized approaches the amount of processing, I/O and for millions of calls is impressive and will slow down a supercomputer. VMs of course, can take large amounts of overhead with containers being light to very light VMs with either a two port or multi-port data flows between program components. Instantiating 10 to 100 of thousands of containers or clusters of containers in a Cloud would seem to overwhelm this approach. My other conceptual issue is, how to identify an bad actor container or sub thread in the system or larger app whose task is nefarious when it does the same function as the running app that it is hooked in with. Yes I am sending a data stream out on the network, which in reality is data exfiltration that this level of monitoring does not have the context to understand.