Thoughts On Zero Trust

This is an extract from a larger piece of work that I have not finished yet but I thought it might be worth sharing at this point to draw attention to this subject. The subject on Zero Trust has been occupying my thoughts for a long, long time. Only recently, I have managed to put this philosophy in a practical context. While I cannot reveal what I am working on, I can share some of the thinking behind it.

I believe that fundamentally Information Security is about trust; whether we are referring to the more intuitive kind of trust such as when giving access to systems, to the more convoluted trust models built into the layers of abstraction from the code running in the fundamental microcontrollers and hardware components, all the way to the actual software which runs on top of the OS. Trust is about the belief in the reliability, truth, or ability of someone or something to demonstrate a certain behavior. In other words, it is about assumptions. Security problems arise when these assumptions are questioned and ultimately broken.

Thus, the practice of Zero Trust (no trust) is the ultimate tool for thinking in terms of Information Security and the only way to create resilient security systems. Zero Trust (ZTS) is not a framework or a tool but a mental model that has a lot of practical manifestations of its values and principles. Experience has taught me that organizations that are built with Zero Trust in mind thrive in the digital world. Organizations that fail to understand and implement Zero Trust fundamentally fail in the long-run or incur significant penalties in terms of arising technical debt, uncomfortable levels of risk, and other negative side-effects. It is essential to point out that Zero Trust is not about creating a culture of mistrust among partners and employees. That is not the goal. Zero Trust is the philosophy of thinking about security and system design from first principles.

The best way I figured that describes Zero Trust is with the following simple analogy. Let's imagine that we need to set up a brand new company, except that we cannot afford an office and thus we need to work from the local Coffee Shop network. Assuming that this network is already hostile, as we don't know who else might be using it, the kind of decision we will make in terms of security and resilience will be very different from the decisions we will make if we are to work from a traditional office environment where access is strictly governed. In the first scenario our assumptions are that everything is compromised thus we need extra assurances. In the second scenario, we base our decisions on the flawed assumption that our design is safe and secure. The problems arise when these basic assumptions are fundamentally broken.

There are a number of organizations and wide-spread technologies that are built on top of Zero Trust as a fundamental building block. Needless to say, such entities demonstrate a high degree of resilience with a proven, long-term track record. It is important to state that the ZTS design is not uncommon. Ultimately any SaaS product exercises ZTS design in the context of the larger ecosystem (The Internet). Google GSuite, Amazon AWS, Slack, and other popular software vendors have their own authentication, authorization systems, completely independent from each other. These products are designed by different companies with different development teams under entirely different constraints and objectives with the assumption that they will exist in a hostile world. An adverse security event occurring at Google GSuite, while may have some ripple effects in its vicinity, is unlikely to affect Amazon AWS. Surely there is a level of fragility in the overall system but ultimately systems designed to be used exclusively on The Internet are designed with Zero Trust in mind as far as their public interfaces are concerned.

There are even some companies that have extended the principles of Zero Trust beyond software security. Amazon is one such organization that currently develops one of the most advanced and well-engineered cloud platforms the world has seen and that is mainly due to internalizing ZTS as part of their engineering culture. Amazon AWS came to be due to a fundamental change in the way Amazon started building its software. Jeff Bezos defined the principle of Zero Trus at the start of AWS with the following key points: 1) all teams will expose their data and functions through service interfaces 2) teams must communicate with each other through these service interfaces 3) no other communication mechanism is allowed 4) it doesn’t matter what technology is used 5) all services must be designed to be extensible. With Zero Trust in mind, Amazon ultimately paved the road to the behemoth that AWS is today. By creating an opaque engineering culture, individual teams in Amazon are ultimately responsible for the security, resilience, and functionalities of their own creations.

With the exception of a few notable examples, a few engineering organizations fully internalize the principles of Zero Trust in their technology DNA. Most engineering organizations begin the struggle with too much trust early on when not enough time is dedicated to planning and focus and high-pace delivery ultimately takes all the energy. While this is an understandable strategy for young aspiring startups, technical debt accumulated over time eventually brings the organization of its knees with slower than ever delivery cycles, diminishing innovation, and security posture beyond acceptable comfort levels.

I strongly believe that regardless of our level of technology and security maturity, every decision must be tested by removing all assumptions and thinking in terms of first principles. In other words, before we take an action we must test our assumptions first. Only then, once we face the ultimate and indisputable truth, we are safe to proceed.

https://www.linkedin.com/pulse/thoughts-zero-trust-petko-d-petkov