I ZeroTrust you to do anything else

I ZeroTrust you to do anything else

This blog post is inspired by a the Google Security Podcast by Anton Chuvakin and Timothe Peacock, they talked with Sharon Goldberg about ZeroTrust

Quite honestly, I guess the people in the metro thought I am crazy cause I could not stop shaking my head in disagreement.

What drove me nuts is the fact that the definition of ZeroTrust which was given was miles apart from the original idea. It felt like a marketing definition which uses the word ZeroTrust to advertise for Identity and Access Management. Click Bait you may call it.
ZeroTrust is not about users. Yes, I know that users play a vital role in security, of course they do. But ZeroTrust is an architecture concept first of all, which affects all layers, Infrastructure, Applications and Users. Making the whole definition about users should be rather called SomeTrust.

Lets start with the very simple definition from Wikipedia and dive in what ZeroTrust means in detail

The zero trust security model (also, zero trust architecture, zero trust network architecture, ZTA, ZTNA), sometimes known as perimeterless security, describes an approach to the design and implementation of IT systems. The main concept behind the zero trust security model is “never trust, always verify,” which means that devices should not be trusted by default, even if they are connected to a permissioned network such as a corporate LAN and even if they were previously verified. Most modern corporate networks consist of many interconnected zones, cloud services and infrastructure, connections to remote and mobile environments, and connections to non-conventional IT, such as IoT devices. The reasoning for zero trust is that the traditional approach — trusting devices within a notional “corporate perimeter”, or devices connected via a VPN — is not relevant in the complex environment of a corporate network. The zero trust approach advocates mutual authentication, including checking the identity and integrity of devices without respect to location, and providing access to applications and services based on the confidence of device identity and device health in combination with user authentication.(Source: Wikipedia)

I guess it was intentionally called ZeroTrust and not SomeTrust, and it especially not limited to the user space.
ZeroTrust expands over three different areas (also take a look at the Palo Alto Networks Zero Trust Architecture)

  • Users: This is basically adopted from the “normal” way of doing things, Users need to be authenticated and the access needs to follow the least privilege and segregation of duties principles. With ZeroTrust in the user we need to have limited access privileges.
  • Applications: We remove the trust in applications when they talk to resources or other applications. So basically a service you access needs to be limited to the resources it really needs to access. A web application for example might be limited to talk to a single database or even just a view of the data it is needed to access.
  • Infrastructure: Same implies for infrastructure. A DNS server is limited to do DNS stuff. IoT devices talk to and get data from one bridge/data gateway and are not open for everyone. Same applies for switches, routers and the rest. I know you will ask how a ZeroTrust Firewall might look like, but thats the charm, think about what the Firewall is supposed to do and trust it to do just and only that, then you limit what it can do to that. Maybe your firewall isn’t a DNS server, maybe it isn’t a telnet hop.

So it comes basically down to a single purpose of what we trust you to do, and we limit the Trust in it to do anything else.

ZeroTrust is harder in some environments than others, I give you that.
You still have your traditional datacenter somewhere hidden in the office, the office assistant basically has the same access like the accountant. You are far behind from figuring out who should do what and which application should access which data exactly.

But that just means you need to start somewhere. Start small, user and access will bring you further already, start by implementing more granular roles adding Singe Sign on and multi factor authentication. You can build up the rest from there and adding trust levels of machines right after that.

If you are on any cloud it gets much easier. Google did a great job of creating service accounts with very granular permissions. So you can easily limit usage to a resource and also can have the service only being allowed to do one thing only.

Adding permissions to a service account on GCP

I have been an advocate for baselining for some years now. And this no different, learning about what’s normal in your environment is a stepping stone for whatever you do. You need to understand what users and machines are actually supposed to do, and enforce them to do only that and basically ZeroTrust them.

  • Once you have your baseline in place check it against security best practices, cause just because your DevOps team is a god amongst others, they maybe should not have the privileges they have. The buzzword here is “least privilege” and “segregation of duties”.
  • The baseline should also show which systems need to talk to each other. In the modern age of microservices you will find many applications accessing data which lives somewhere else, that’s great, you need to enforce that these applications only talk to the systems holding the necessary data and only the necessary data itself.
  • Also it should show the “normal” network activity, where do users come from, when do they access machines, what is normal web traffic. Does a server do what it should do or does it do everything.

These concepts are again not new, we introduced the several years ago when we tried to optimize and tune SIEM (Security Information and Event Management) alerts and tried to imagine new detection rules to provide better protection against malicious insiders and zero days.

That’s it for now and I am happy to get this off my chest, please leave a 👏 if you like it and a comment if you disagree and like always, 
be excellent to each other