Zero Trust is all over the news. In the wake of the Colonial Pipeline ransomware attack, the Kaseya catastrophe, and President Biden’s Cybersecurity Executive Order, every product is suddenly a Zero Trust solution, every company is rebranding as a Zero Trust provider, and you can trust all of this about…well…zero.
Despite my cynical introduction, I am a fervent believer in Zero Trust. Zero Trust environments are fundamentally more secure and resilient. What annoys me is the hype. Whenever any technology or technique becomes popular, the marketeers overpromote, overpromise, and overstate the benefits (and understate the challenges).
If you know better, you know that Zero Trust is complex. With that in mind, let’s stick our hands into the Zero Trust hype machine, scrape the marketing goo off the gears, and see what makes Zero Trust really tick.
What is Zero Trust?
While many of you reading this already know what Zero Trust is and do not want to read yet another pandering explanation, indulge me for a moment.
Zero Trust is a ridiculously overhyped word these days that gets slapped on everything including products, features, cloud services, and entire companies. This is where the first problem lies: Zero Trust is not a product, not a service you subscribe to, and definitely not a company.
Zero Trust is an architectural design approach. I prefer the word, Zero Trust Architecture (ZTA). Zero Trust is something baked into every part of your infrastructure and applications.
The alternative to ZTA is Castle Defense Architectures (CDA). CDA was how most of us built corporate networks in the past: strong perimeter, soft interior. This typically manifested with a NGFW at the perimeter, with some internal monitoring inside the trusted zone.
Concisely, CDA explicitly trusts some things, while ZTA trusts nothing. Apple devices are a good hardware example of a ZTA, as are cloud providers like AWS and Azure.
ZTA is inherently more secure because, to state the obvious, nothing is trusted.
Where Zero Trust Comes Unglued
Unfortunately, Zero Trust is difficult to adopt, challenging to maintain, and perpetually locked in a tug-of-war with those pesky humans and their penchant for doing dumb things. In other words, it is like everything else in security.
Furthermore, Zero Trust is different for application environments versus corporate environments. To keep things simple, I am going to focus on application environments. Corporate environments with all their laptops, printers, and other technical detritus face the same challenges, just in a larger scale.
Let’s unpack these three ZTA challenges.
Start Vulnerable
Ever spent time with developers? These are not people who like a lot of restrictions. Developers need freedom, and rightly so. Building apps requires the freedom to tinker and test out multiple designs. This makes it difficult to implement the restrictions necessary for ZTA environment in the middle of development.
Most organizations develop applications in “full-trust” environments that have no access restrictions or security controls. Only after the environment is built, do security and DevOps teams attempt to impose security controls on the environment.
This approach creates a positive inclusion coefficient. That is a fancy sounding way to say it is difficult to find all the holes. This is because the environment starts in a vulnerable state and to get it to a secure state, engineers must locate all the possible vectors of compromise. The number of exploit vectors grows in a non-linear manner (possibly exponentially) with greater complexity.
However, if the devs embrace ZTA and make tuning security controls an integral part of the development process this creates a negative inclusion coefficient. Rather than trying to identify the vast number of ways an environment might be exploited, devs focus on the smaller amount of access rights necessary to keep things running correctly.
However, even if you start with a ZTA you still must maintain it.
Stay Vulnerable
Application environments (as well as corporate networks) are not static. New features, component updates, expanded access, patches, new devices, new employees, additional customers…the list of possible changes is long and dynamic.
This gets us back to that positive inclusion problem. The more things change, the more difficult it becomes to maintain the complex access rights of ZTA. If you have ever managed a corporate perimeter firewall, you know exactly what I mean. You start with everything locked down and secure. Then little by little, over time, access becomes loosened. It starts with some third-party vendor requiring a bunch of weird ports for their crappy software. Next it is an update to some internal system that needs a group of people to have unrestricted admin rights. Then it is the CEO’s pet project that demands a dangerous “any-any” rule. In a brief time, the NGFW is essentially useless.
Oh, and incidentally, this is why breaches happen.
To solve this problem, you must have “custodians” of the environment, who can monitor for issues and maintain the security controls.
Now, scan through all that marketing blather from ZTA companies. Do you see the word “custodian” in any of them? Of course not, because imagine a product pitch that said: Our product will secure your business and give you a tedious job that is profoundly unrewarding, and if you make a mistake, you will be fired and humiliated!
Which drops us into the lap of the third challenge.
Stop Being Human
Humans make mistakes. I do not think that is a remarkably controversial statement. Human error is the Achilles Heel of Zero Trust.
Remember back when AWS was getting all that negative press about S3 buckets being public on the Internet? AWS S3, like most of AWS, is a Zero Trust service. When you setup an S3 bucket, it has no rights. It starts in a secure state. Humans must overtly reconfigure S3 to be public. This happens all the time. This is how S3 buckets become sources of attacks. It is not AWS’s fault. Their service follows ZTA practices. It is the humans operating those services who make mistakes.
Those pesky humans. They create the problems and they also can solve the problems. The answer to this is to require identity validation at every stage, which is great…except when it gets turned off because of all those pesky humans.
The Bigger Picture
If all this feels depressing, then allow me to quote Gale from Raising Arizona, I’d rather light a candle than curse your darkness.* There is a way out of this ZTA muck and it does not require robbing a store or putting a panty on your head.
The answer is frustratingly simple and immensely complex: Zero Trust is a strategic business challenge, not a technical challenge.
The technology of Zero Trust is everywhere, inside everything. If you are making Zero Trust a technology project, then it will probably get watered down and sputter out in the long run. Zero Trust is a cultural or business problem. Zero Trust must be embedded into all your code, all your teams, all your people, and all your designs. You cannot buy a Zero Trust thing, slap it on your stuff, and then proudly proclaim your application as secure.
Your organization’s ability to adopt Zero Trust is more a factor of your organizational culture than what technologies you use. If your leaders truly embrace Zero Trust vision, specifically the need to automate everything, then you have a good chance at being successful. If you are still doing things manually and/or allowing vendors to control your architecture, it will be a rough ride.
Getting Past the Zero Trust Hype
So now what? To get past the hype, you need to honestly consider some key prerequisites to Zero Trust:
- Is your environment in the cloud (AWS, Azure, etc.)? ZTA is practically impossible in old-school on-premise environments.
- Have you automated your architecture? Build, test, inventory? Better get on that HI! No point in twiddling with ZTA tech until you have a fully automated environment, because manually managing access rights is a nightmare. And you might be carried off by a twister.
- Have a bunch of third-party dependencies in your environment. Do you know exactly what access they need?
- Do you have real-time asset inventory? This must be an inventory of everything, and not some spreadsheet on the IT admin’s desktop.
- Can you automate the testing of access rights, vulnerabilities, and configuration? This cannot be dependent on some unhappy dude clicking the correct buttons at 4:00am. It must be automated.
- Is user (and system) identity validated at every point in your app data flow? It must be.
- Do you have a team of people who can effectively run the environment 24/7? Why burn zillions building an app only to put it in the hands of underappreciated, overworked, and chronically devalued IT admins. The people who run app environments are as important (if not more so) than the people who build them.
- Is your leadership have the vision to adopt Zero Trust?
That last item is the clincher. Your team (and leadership) must commit to ZTA. Do not waste your time twiddling with Zero Trust technologies if your team will bypass the security and cut corners at a moment’s notice.
When you peel back the Zero Trust hype what remains is something non-technical: vision. Does your team have the tenacity and commitment to build, maintain, and monitor a Zero Trust environment? Is security engrained into your culture at every level?
If so, then go get some of those cool Zero Trust tools. If not, then all the tech, subscriptions, fancy words, and promises in the world are not going to plug those holes.
Well, okay then.
* Yeah, I know. That quote is originally from Eleanor Roosevelt and not Gale. Raising Arizona was funnier.
