Zero Trust part three: policy and monitoring
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.
Step Four: Create Zero Trust policy
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.
Policy is always binary
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.
Control access on a “need-to-know” basis
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).
What is the Kipling Method?
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.
Applying Kipling Method Policy to Zero Trust
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:
- Who? Start by asking who should be allowed access to the Protect Surface via what application. You’re defining the validated “asserted identity” here, which is used instead of the source IP Address in a traditional firewall rule.
- What? What application is the asserted identity allowed to access the Protect Surface with? Answering this replaces port and protocol designations found in traditional firewall rules.
- When? When does the asserted identity have permission to access the Protect Surface? In many cases, 24/7 access is given. But rules should be time-limited in instances where validated users don’t need to access the Protect Surface all the time. Otherwise, you open yourself up to attackers who target your system when approved users are away, but the rules are still on.
- Where? Where is the Protect Surface located? If it's a cloud-based application, where some unmanageable applications are, you’ll know how it's being delivered to you, and how it gets injected into the browser. Instead of the destination IP Address in a traditional firewall, you’ll look at your “Where” statement.
- Why? Why are you giving access to the validated asserted identity? You can tag a packet to identify any sensitive data. With the metadata you’ve created from tagging, various controls can be executed to inform or automate policy statements. This encompasses the “why” of the Kipling Method.
- How? How should the traffic be processed as it accesses the Protect Surface? In other words, how are you looking at the packet to determine that it's clean and not malicious? Here, additional controls or inspections are usually applied to a packet.
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.
Step Five: Monitor and maintain the environment
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.
Inspect and log all traffic up to Layer 7
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.
Build 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.
