Zero Trust: What does it actually mean – and why would you want it?

Since publishing our article and video on APIs, I’ve talked with a few people on the API topic, and one aspect that keeps coming up is the importance of security for APIs. In particular, I hear the term “zero trust” increasingly being applied to APIs, which led to the idea for this post. At the same time, I’ve also noticed …

[Pascal Monett]

Firewalls

I appreciate that firewalls may give a false sense of security, but I very much prefer that my work PC not be continually bashed by TCP requests from some Russian hacker.

Even in a zero-trust environment, they have their use.

[Paul Crawford]

Re: Firewalls

The reality of many businesses is there are products and protocols in use that have little or no security, and replacing them is going to be unfeasibly expensive, so the use of firewalls and related network segmentation is still going to be essential for achieving an acceptable degree of security.

Then you can add in the provisioning or modification of running machines that may well drop certain levels of protection, so keeping them private by default is really a good idea.

TL;DR firewalls are not going away.

[Mike 137]

"Perimeter-based security (as provided by perimeter firewalls for example) is a good counterexample"

"Perimeter-based security" does not exist (i.e. it's not security, only a simulacrum of it). A perimeter firewall is legitimately part of a security architecture, but only a small part of it. There should also be internal segmentation according to the needs of legitimate access, plus all the other necessary controls (application allow listing, remote resource validation &c.)

It's true that many organisations do operate a "hard shell, soft centre" network architecture, but that's not real security. However it does at least partly explain the success of ransomware.

[Arthur the cat]

Nomenclature

So “zero-trust” might be better termed “narrow and specific trust after authentication” but that’s not very catchy.

Given computing's history of overloading TLAs with entirely unrelated meanings, I suggest we call "NAT" for "No Automatic Trust".

[EnviableOne]

Re: Nomenclature

yeah, but let's not start done the acronym reuse in the same space rabbit hole

Just ask a physicist what rho represents.

I still go back to this quote I found somewhere:

Build your network as if the endpoint is owned.

Build your endpoint as if the network is owned.

– @0DDJ0BB

— SecuriTay (@SwiftOnSecurity) November 21, 2015

[Arthur the cat]

Re: Nomenclature

Just ask a physicist what rho represents.

I am (was anyway) a physicist.

I was also told repeatedly at school I had the wrong attitude.

[yetanotheraoc]

Re: Nomenclature

`So “zero-trust” might be better termed “narrow and specific trust after authentication” but that’s not very catchy.`

"Narrow and specific trust after authentication" might be better termed "least privilege", and here we are running in circles. I'm pretty sure there is more than one camp out there using the term "zero-trust". Some of them mean minimum trust, others mean don't worry your tiny brain about it, we have a trust solution to sell you at zero effort on your part.

[thejoelr]

Re: Nomenclature

Exactly. If this is zero trust, it has been regular practice for a long time where I've worked. It does not resemble all the flashy products I've failed to understand...

[Robert Carnegie]

Re: Nomenclature

Choose a neat acronym, then pick words to fit it. Come to think, is "Neat" used for something already? Probably! Or something like "netsafe"... except that that sounds like when you've got it then you're safe, which is not the right attitude.

[Blacklight]

Layers

It's all about the layers. APIs & inter-app comms are probably an afterthought for most.

The 'tightest' place I've encountered had:

a) Windows desktop & server firewall controlled by AD policy

b) Cisco ISE operating on all switch ports (assigning VLANs etc) with MAC and 802.1x back to AD

c) Switch port policies applied to ports based on the VLAN or ISE assignment

d) Site level firewalls (Palo Alto) governing intersite and internet access

e) SD-WAN (Silverpeak)

f) Regional firewalls for internet (and any failover between intersite if SDWAN routing went awry)

g) VPN with device and user authentication, and policies applied dynamically based on both

h) WAFs and NSGs running on the Azure side of things (if you made it that far)

i) AD ACL and SEC groups, applied thoroughly on actual servers, shares & resource groups

But, as outlined in the article, if (or once) you were 'in', you were generally able to 'get around' - but that was also partly due to a hangover from a prior set of circumstances where they were no proper firewall policies previously, and there was still reasonable paranoia as to restricting things further.