Perimeter Security is Dead

A Requiem for the Data Centre

Keeping up with various buzzwords-as-a-service is never easy — but there’s one phrase that’s been at the top of most LinkedIn feeds over the last few months; Zero Trust.

What is Zero Trust? As a canonical technical implementation, I’m not sure 🤷 Thank you for coming to my TED talk 🙇

More generally though — it’s many things to many people. I’ve seen articles from NCSC, HashiCorp, Monzo, GCP, and plenty of others, all of which frame Zero Trust through a slightly different lens which most closely aligns to the problem they’re trying to solve.

Therein lies the true definition of Zero Trust: a holistic approach to design which forces a strong defence in depth posture.

At every step of your architecture ask yourself the following question:

Is this interaction expected and permitted with my policy, can all parties of the interaction prove who they are to the satisfaction of all others, and is there any implicit trust in any part of the process?

Or to put it in architect vernacular — on your next architecture diagram, imagine all the boxes hate each other, and the arrows are lava.

Flowing out of this, the range of technical implementations is essentially endless, based on what you’re building. As a starter for ten:

• Kubernetes microservices mutually authenticate against each other. Services don’t trust each other just because they share a cluster and namespace, they trust each other because they can prove who they are.
• Network policies define what Kubernetes microservices can reach each other. The network layer doesn’t implicitly trust the services just because they’re attached to it.
• Data is only accessible in a bucket or a database to specified managed identities. Our data isn’t accessible because the caller shares a CIDR range, or because it’s attached to an interconnect we own, it’s accessible because the caller can prove who it is.
• Containers will only run if they’re signed by your build process. The runtime doesn’t trust the container just because it’s come from our registry, or has the right name, it trusts it because it this artifact has the attestations that can prove where it came from, who built it, who tested etc.
• Managed services all mutually authenticate. Managed services don’t trust us just because we share a billing account, an organisation or a VPC — they trust us because we can prove who we are, and that we’re authorised to access that resource.
• Connections can only flow out to the internet to approved domains, via approved routes defined in advance. We don’t trust our services to only egress what they should just because they’re ours, we trust them because they’re behaving as we expect.
• Data is encrypted in flight on our own networks. We don’t trust the network just because we own it, it’s impossible to identify the provenance of what’s happening on the network, so just assume it’s all hostile.

There’s a pattern emerging here. Policy, identity, authentication, and an inherent lack of trust… or Zero Trust, some might say 🤔

This allows everything to be audited. Now we’re ensuring who during every interaction, it’s easy to keep a clear audit trail of who did what, when, and which policy allowed it. This is a whole lot more insightful than IP x connected to port y.

And in this policy-driven world, if we want to off-board a service or change its posture, we just update its roles and permissions within the centralised IdP, rather than chasing a handful of firewall rules across an indeterminable amount of hops.

Defence in Depth 101

Defence in depth is the well known design pattern of having security baked in at every layer, so should one fail you, there’s another waiting right behind it to limit the blast radius of any mis-configuration, which is exactly what Zero Trust gives you. In fact, a cynic might say that Zero Trust is no more than defence in depth in a hat.

Organic matter is fallible and hard problems are hard. I guarantee at some point someone will press the wrong button, and that’s fine — that’s not a failing of an engineer, that’s just the human condition. Defence in depth makes this okay. Engineers should feel safe to fail, especially when delivering magic at pace.

In a true Zero Trust nirvana, one could deploy actively hostile code, with no material risk to the running system.

For example, you could deploy a container out to a cluster whose sole purpose is to talk trash to services, exfiltrate data, and generally cause mayhem in any way it can, and the world will keep turning.

• It can’t talk to any other services, they won’t talk back.
• It can’t move around the network, no policy is defined for it.
• It can’t phone home, the egress routes are locked down.
• It can’t read other data on the wire, nothing is in the clear.

Try it — chaos engineering is fun!

This is probably a worst case breach, actively deployed hostile code. Whilst it would still be a bad day at the office, with Zero Trust it likely won’t end with a phone call to the Information Commissioner’s Office.

Why Bother?

“This is a whole pile of work, why should we not trust our perimeter? It’s well established, has been in use since 1985, and besides from a few hairy moments served us well.”

Inherited risk is the short answer to that question.

Whilst still thinking in terms of perimeter security, you will always inherit all of the organisation’s risks. If you’re running a cloud project, and implicitly trust everything at the other end of the interconnect, you’re inheriting the risks of every single on-premise project. If there are other cloud projects in the organisation, attached to the same interconnect, you’re inheriting theirs too.

One vulnerability anywhere in the organisation can just meander effortlessly up to your cloud infrastructure unchecked and unchallenged.

“But my project is protected by a firewall only allowing the range foo, bar, and baz through”

And you’re now one mis-configured firewall rule away from inheriting all that risk again (see also: organic matter). Firewalls are brittle, range definitions can change, subnets can be added post the event, and a CIDR range tells you very little about who’s passing through the firewall.

A firewall rule standing between you and a network’s worth of risk is quite frankly just the coefficient of the risk variable; easily factored out, and quickly removed.

Silos are bad in organisations — I’m not advocating looking after your own world view at the expense of others, I’m just advocating you trust everyone else’s infrastructure as little as you trust your own.

Clouds and Data Centres

Which brings me to the eulogy.

Perimeter security is dead. If everything is identifying and authorising itself, why does it matter how it got there? Knowing who you are is orders of magnitude more important than knowing where you came from (inspirational cat poster coming soon). I’d take an IAM authorised request that’s flowed across the internet over an unauthenticated ‘internal’ request every time.

Can I build a production ready cloud architecture without a firewall? Sure. Can I build a production ready cloud architecture without IAM? Absolutely not.

I once read an excellent blog about why front-end bugs are no longer a real concern (I think it was from the early days of godbolt); in the absolute worst case an attacker compromises a pod, has nowhere to go, and the master just kills the pod, recreates it and moves on. I certainly wouldn’t recommend this to my customers, but it brings home what level of security comes for free with Zero Trust.

Any resilient, scalable architecture will by definition span a handful of availability zones, on-premises or otherwise. People work from home, and access their email from their phone. Handfuls of short lived ephemeral services spark to life under load, only to die again 30 seconds later. SaaS providers integrate with your SAP systems to manage email delivery to your customers, and host their infrastructure in <?>. Trying to draw a continuous box around ‘stuff on my network’ is a fool’s errand in 2022.

Ill defined nebulous concept as it is — Zero Trust still needs a technical toolchain to underpin it built upon the cornerstones of an IdP and IAM, both of which come out of the box in any of the big three cloud providers, with robust, mature, battle-tested stacks backing them.

As you take your first steps to Zero Trust, the cloud will catapult you on this journey forcing you to think in terms of IAM policies and mutual authentication from day one, and offering you a whole range of integrated tools to support you as you move to Zero Trust.

Of course, this is by no means unachievable in house, there are still plenty of big on-premises outfits who undoubtedly have world class security, with Cloudflare and Netflix springing to mind as top of the list. But moving to a Zero Trust paradigm is hard, you need technical endeavours, architectural commitment, security buy-in, and all the cultural changes that go with moving away from ‘But on-premises is safe’. By letting a hyperscaler take the technical heavy lifting, you’re free to focus on selling the dream, changing minds, and organising the data centre’s funeral.

Wherever you are on your Zero Trust journey, CTS can help!

Like ranting about tech online? Join us!

About CTS

CTS is the largest dedicated Google Cloud practice in Europe and one of the world’s leading Google Cloud experts, winning 2020 Google Partner of the Year Awards for both Workspace and GCP.

We offer a unique full stack Google Cloud solution for businesses, encompassing cloud migration and infrastructure modernisation. Our data practice focuses on analysis and visualisation, providing industry specific solutions for; Retail, Financial Services, Media and Entertainment.

We’re building talented teams ready to change the world using Google technologies. So if you’re passionate, curious and keen to get stuck in — take a look at our Careers Page and join us for the ride!