In my 12 years of working in various roles information security, I have developed a strong bias towards implementing security that is very close to the thing you’re trying to protect. You either need to build security in before you ship something, or completely trust the security that you’re going to end up depending on. As more organizations move aggressively to the cloud and accelerate their adoption of speed-enabling technologies like containers and microservices, this becomes even more important as perimeter- and controls-based security models are turned upside down. With these seismic shifts in IT, teams can no longer depend on the infrastructure or the network to protect their assets, because they no longer control it. When I first met the Aporeto team, it was immediately clear that this team understood what a zero-trust environment is. The instinct to put strong security very close to what you’re protecting is at the very core of the company and the technologies that we have built. The more I learned about them, the more I understood how disruptive the Aporeto security model will be.
My introduction to security was into the application security domain when I joined SPI Dynamics in 2005, one of the early pioneers of application security testing to find and fix security vulnerabilities in software before attackers can exploit them. What I liked about application security then and even now is that it is based on the premise that production applications are only as secure as the code they’re built with. When web apps get deployed or software is released to the public and they’re available for the world to use, they’re on their own to protect themselves. In my first weeks in application security, I learned how easy it is to execute a SQL injection on a live production app (not that I actually tried!), that was ostensibly protected by millions of dollars of network security. It’s even more frightening to learn how easy it is to discover vulnerable websites using search engines and scripts. I went on to spend more than 10 years in application security, including running the market-leading Fortify business for the last four years. As a result, I have spent my formative years in security reinforcing a strong belief that an application cannot depend on its environment for security. It has to either be hardened to perfection or have a security policy and control framework built into it so that it’s secure no matter where it runs.
Furthermore, for more than 10 years now, security vendors and security professionals alike have been saying with some conviction that there is no perimeter and that perimeter security is largely ineffective. Yet industry analysts estimate that businesses are spending billions of dollars per year on perimeter defenses. Perimeter security solutions are certainly necessary for certain types of attacks, they’re simply just not enough or advanced, for even moderately sophisticated attacks. Nevertheless, security teams are voting with their dollars and they’re continuing to double down on perimeter security. And the breaches keep rolling in as sensitive data flows out.
It’s time for security to be an integral part of the applications, services and APIs that we deploy, not an afterthought or an attribute of the computing environment. Security needs to get much closer to the workloads that we’re trying to protect, but it must operate with context and intelligence about the workload that it’s close to. We know a lot about how ineffective perimeter security can be when it is ignorant of the semantics and patterns of what it’s trying to protect; it’s relatively blind and relies on patterns and heuristics, and to some degree machine learning, to make intelligent guesses. Now virtualizing marginally effective perimeter security and moving it closer to the workload might make it more contextual, but it also makes it dramatically harder to manage. Many organizations struggle with managing complex network segmentation and firewall rules with a centralized network management infrastructure today. Miniaturizing firewalls and WAFs and other network controls and managing massive tangles of endpoints and IP addresses might give more granular control but feels like a step backward in terms of scalability.
The most powerful element of the Aporeto security model that attracted me is the intersection of identity, encryption and policy. We give a cryptographic identity to every service or process in your protected environment – cloud, legacy, container, process, microservice, whatever. We authenticate and authorize it for everything that it attempts to do so that it can’t get into trouble or be misused. It’s not allowed to talk to or even respond to something you don’t want it to talk to. We provide visibility into everything it and every other process, service or container does. We control what these things are allowed to do if they are known to be vulnerable. And we control it all by a distributed policy framework. The identities are automatically created and securely managed, and the policy framework is automatically created as you onboard new services or processes. This all works for containers, microservices and Linux services today, with no dependence on kernel level controls or IP addresses.
Aporeto stands alone in offering security that spans containers, microservices, cloud and legacy applications, untethered from network and infrastructure complexities. That’s why I joined Aporeto.