In this Part 3 of a series examining Zero Trust in more detail, John provides an in-depth view of the fourth and fifth steps in implementing Zero Trust architecture — creating policy and monitoring and maintaining the environment.
Ultimately, Zero Trust is instantiated as a Layer 7 Policy statement. Therefore, you must craft policy statements that are limited and coherent to decrease the chances of a successful malicious attack. We know that malicious actors constantly target your unmanageable applications because, as unmanageable, they’re invisible to you. It’s easier to inject a malicious payload into your environment through a vector you’re not looking at. Zero Trust policy is written for granular enforcement, only allowing known, approved traffic and application communication.
All policy is binary. You can either allow or deny; there are no other options. You can use many criteria to determine that policy, but the end result will be to allow or deny traffic. The fundamental flaw in our legacy approach to policy is that we will allow an amazing amount of useless or malicious traffic because we are afraid we might stop some “good” traffic. This practice must end.
In Zero Trust, we start with a default deny. Fifty percent of your decision-making is eliminated this way. You will use multiple data inputs to make that determination, but the policy statement is still binary. You’re going to enable access to a resource according to a need-to-know basis. Everything should be denied unless there is a business case to allow it.
In the worst-case scenario, someone cannot access something they need. They put in a support request, and, if it’s appropriate, they’re granted access. Easy enough.
Organizations that don’t create granular access allow-only rules run the risk of authenticated users accessing sensitive data they should never have had access to in the first place. Just because a user is authenticated into the system doesn’t mean they should have access to every resource on the system. The obvious example here is Edward Snowden, who exploited the NSA’s trust model. All Snowden had to do was authenticate into the system. No one paid attention to how he used the system, what packets were being generated, or the applications he was using.
We typically give too much access to too many users and don’t monitor what they’re doing. Controlling access on a “need-to-know” basis is extremely challenging for nonfederated, or unmanageable applications (which lack support for modern identity standards like SAML).
You can’t manage these applications in your identity provider, so access has to be managed locally in the app. This only compounds the problem and makes it even more difficult to identify when access is too broad.
Zero Trust only provides access on a “need-to-know” basis, limiting the ability of users to perform malicious actions. It forces organizations to look at who has access and ask themselves: “Who should have access?” As soon as you write policy, applications can move from the realm of unmanageable to managed. A policy statement in a Zero Trust environment is called a Kipling Method Policy (KMP).
I was looking for a technique that would resonate globally with every country, culture, and language. I call it the Kipling Method as a personal homage to the writer Rudyard Kipling, who gave us the idea of “Who, What, Where, When, Why, and How” to the modern world in 1902. Everyone in the world understands the concept and by relating it to cybersecurity, we’re making Zero Trust completely accessible and straightforward. Viewed through this lens, policy is easy to write, read, and audit.
We use the Kipling Method Policy to decide what traffic can transit in and out of the Microperimeter. A Microperimeter exists when a segmentation gateway connects to a Protect Surface and a Layer 7 Kipling Method Policy is deployed. Only approved users will have access to your Protect Surface, preventing sensitive data from falling into the wrong hands.
Using the Kipling Method, you can create Zero Trust policy for an unmanageable application by answering these questions:
When all the above statements are true and defined, you can allow access. Kipling Method Policy also makes it easy for auditors, who otherwise may get confused with certain languages and terminology, to consume policy.
The fifth and final step of Zero Trust is ongoing. With all the telemetry you’ve done from the previous steps, you create a feedback loop in the system. This feedback loop reinjects your learnings and informs you where you need to make any adjustments. Since this is done in a continuous loop, you can constantly update your policies.
Telemetry from every single control in the protection chain is captured, analyzed, and used to stop real-time attacks. Not only does this help prevent significant cybersecurity attacks, but it provides security improvement insights over the long term.
Inspect and log any configuration changes, network traffic, and access levels. All traffic going to and from the Protect Surface must be documented. This should be done all the way through Layer 7 or the “application” layer.
The more you learn about your environment through this constant monitoring and maintenance, the stronger the security around your Protect Surfaces becomes. For example, you might notice that you need to tighten your understanding of a Protect Surface. Or you may discover transaction flows you didn’t know existed and need to add additional controls. In a best-case scenario, alerts and analysis are automated. Now, you’ve set up an antifragile system.
The book, Antifragile: Things That Gain From Disorder by Nassim Nicholas Taleb, gave me the vocabulary to articulate what I was trying to create in Zero Trust: an Antifragile system!
Taleb views the world as having three different types of systems instead of the universally accepted two. The two common systems we think about are Fragile, like a piece of glass, and Robust, like a heavy paperweight. If I were to throw the paperweight at the glass, the glass would shatter, but the paperweight would still be intact. People usually view the world through the lens of these two extremes: Fragile vs. Robust. Taleb brings up a third state, antifragility.
Antifragile systems get stronger and more robust over time as stressors are added. Take the human body, for example. As people exercise, whether that be a Zumba class or weightlifting, they’re stressing their bodies out. The body adapts to that stress by getting stronger, making your body an antifragile system.
Cerby’s platform makes it easy to implement Zero Trust and therefore build an antifragile system, even when nonfederated applications are involved. I joined Cerby because they are the only platform that brings these applications into the Zero Trust world by allowing us to create a Protect Surface around them. By doing so, Cerby is making the unmanageable easily manageable and secure.