Security Intent & Zero Trust
As we’ve navigated some of the issues around implementing a Zero Trust strategy, we’ve done three things: explained the difference between Zero Trust and microsegmentation, worked through the need for visibility in order to achieve Zero Trust and discussed the techniques needed to analyze risk.
Up next: Security Intent
You can’t write rules fast enough in Zero Trust
This is important to remember: rapidly evolving systems are needy. Access requests have overwhelming dependencies. Attributes change. These attributes are a taxonomy that goes through real-time mutation, and enforcement points must adapt to the change faster than you completed this sentence.
Enforcement points need rules to work. But the problem is this: in Zero Trust, you’re moving from what could be two dozen enforcement points to thousands. And those thousand-plus enforcement points are constantly changing.
So now it’s less about rules; instead, enterprises adopt a method of security intent and separate that desired goal of security from the specific implementation. This hierarchy allows you to set a single global policy that’s applied to any network resource with all its defining attributes – regardless of mutations in the network.
We stop changing rules and policies for the current state (which never stays current) and design the policy for desired state to ensure security no matter what happens in the Zero Trust environment.
What do you need to achieve security intent?
Glad you asked.
That would be:
- Translation: Take the overall security goal and map it to specific rules, irrespective of enforcement point (e.g. firewall, router, switch, VM, cloud, etc.).
- Automation: Check the design against all possible contingencies, score the risk and, if all cleared, push rules to the enforcement point.
- Network Awareness: Real-time monitoring that pulls data from across the Zero Trust network and gives instant detail about how our intentions are playing out.
- Network adaptation: A change to the network becomes a new input, is tested against the desired state and, if new rules are required, they are deployed instantly…no human required.
All four are essential to make sure security intent can be your norm, but automation might actually be among the most essential. Change management that does not automate the entire rule lifecycle will be useless in Zero Trust, because in Zero Trust, our goal isn’t to undo or redo rules.
If you don’t fully understand the tech specs, no worries. Think about it like this: what’s the biggest complaint you hear from employees about new tech? For many organizations, it’s some variation of “Another thing to manage” or “Doesn’t work with what we already have.”
Now take a look at this visual:
See how we move amongst your desired end state, your current network and your security setup?
If you remember anything, remember that. And in our next and final post in this Zero Trust series, we’ll show you how all this happens without you really having to think much about it (freeing up time for other, more worthy pursuits): orchestration.