The Zero Trust Hub

My friend George Finney, CISO for The University of Texas System, likes to tell a room of security leaders that their CEO could help write security policies. It always gets a laugh.  

Then he asks six questions about one application: who needs access, to what, from where, when, why, and how it should be protected. The answers come back fast and in plain English, and the laughing stops, because those answers are the security policy.

I’ve done the same in boardrooms around the world, with the same result. Business leaders can describe the access their company needs in one sentence. Engineers turn that sentence into rules between addresses and ports.

Something gets lost in that translation. The rule that ends up in the firewall might record an address, a port, and a permission. It doesn’t record who asked for the access, what the business needed it for, or when it should stop.

That creates a major security gap. A contractor gets access to a finance application for a six-month project, written as an allow rule between two address ranges. The project ends and the rule stays, because nothing about it points back to the contract that justified it.  

Repeat that for a decade, and nobody can say which access the business would still approve.

Zero Trust closes the gap by keeping policy in business language and letting technology carry it out. Answer those six questions about a resource, and you get a policy an executive can read, an engineer can enforce, an auditor can trace — and someone in the future can update.

Every allow rule was somebody’s decision

I say it often: all bad things happen inside of an allow rule.  

Attackers rarely break your controls. Instead, they use the permissions you already granted. It’s why lateral movement works so well, even in environments that pass every audit they’re given.

Rule bases grow because granting access solves today’s problem, while removing it can start tomorrow’s argument. No one wants to be the person who deleted a rule and caused operations to halt. This lets permissions — and security gaps — pile up year after year.  

Six questions that turn intent into policy

The Kipling Method fixes that. Named for the six honest serving-men in Rudyard Kipling’s poem — who, what, where, when, why, and how — it writes the decision down in words the whole business understands: who needs access, to what, from where, when, why, and how the connection should be protected. The answers to those six questions are the security policy.

A finished policy statement using the Kipling Method reads like this: the payroll team may reach the payroll application from managed devices during business hours to run payroll, with phishing-resistant MFA and inspection at the enforcement point.

Anyone in the company can read that sentence and say whether it’s still true. Ports and protocols still do the enforcing, but the sentence is stored with the rule, so the reason for the access travels with it. When someone asks why a path exists, the answer is attached to the rule instead of living in one person’s memory.

Machines need a business justification, too

Service accounts, API keys, and AI agents already outnumber your employees, and most hold standing access that renews itself forever. They deserve the same six questions:

• Who is this agent?  
• What can it touch?  
• How long should it live?  
• Why does it exist at all?
• And which controls hold it in place if its instructions get rewritten by a document it was asked to read?

Zero Trust is the architecture that asks you to answer those questions. Microsegmentation is how the answers get enforced between workloads. And least-privilege access is the principle undergirding both.

Start with “why”

Five of the six questions can be reconstructed from a good rule set. “Why” can’t. It lives in the memory of whoever approved the access, and memory walks out at the exit interview.

So start with why. Pick one protect surface — a single application, dataset, or service you can name — and list everything that can reach it today. Then ask what business purpose each path serves.

If the answer is “we’ve always had it that way,” you’ve found a permission nobody owns. Start there. Either someone can name the business reason it still exists, or the path comes out.

Why Zero Trust policy can’t wait for your next planning cycle

Every quarter you wait, your rule base absorbs another wave of automation that was never part of the original design. Agents ship in weeks and inherit permissions written for humans who work business hours from a managed laptop.  

Trust is a vulnerability that has to be mitigated, and an unexamined allow rule is a vulnerability in its most durable form. Pick one protect surface this quarter and write its six answers from scratch. Make a plan to review them regularly.

The distance between what you meant to allow and what you’re actually allowing is where Zero Trust starts being a practical, real-life control in your environment.