Zero Trust must be enforced at the application and workload layer

This article is part of our Opinions section.

Have you Googled data breaches lately? Not even the TfL in the UK seems to be able to catch a break. The pile of headlines concerning thousands – if not millions – of customer and personal records exposed seems to just get bigger and bigger each month.

It’s not only sensitive data being compromised. Entire business operations are being disrupted, with companies taking systems offline to assess and contain the blast radius of compromised systems.

DevOps and cloud infrastructure is way too complex. We’re paying for that now with fragmented identity and access silos that have created ripe opportunities for cybercriminals to breach and pivot across the infrastructure. All it takes is a little misconfiguration or one tiny human mistake. This is why roughly 85% of data breaches in 2023 involved servers.

But don’t worry, we can exit this breach nightmare together. It will, however, require a new cybersecurity paradigm – of eliminating secrets, enforcing Zero Trust, enforcing the principle of least privilege, and hardening access with identity security and centralised policy governance. For today, though, let’s focus on a very specific problem – enforcing Zero Trust at the application and workload layer, not just the network level.

But first, let’s set the stage for why this new paradigm is needed. It has everything to do with how broad the attack surface area has become.

Complexity and security are like oil and water

Well, engineering infrastructure evolved. It was bound to. It was easier a couple of decades ago to standardise the security model for a handful of layers in a company’s tech stack. But in today’s cloud-heavy environments, everything is ephemeral, and nothing is static. There are layers upon layers of technology across physical and virtual servers, containers, Kubernetes clusters, IoT, cloud provider accounts, large language models for GenAI, and so on.

Everything is now defined by code. Every access is privileged access, so if an attacker obtains a DevOps credential, they can breach and pivot to other infrastructure resources and sensitive corporate data. Without an effective strategy against this, the blast radius can span deployment pipelines or other sensitive privileges held by the engineers who build and maintain the infrastructure-as-code pipeline.

The unfortunate by-product of this is the perfect storm for threat actors. The amount of access and identity silos is good news for criminals, but for organisations, it has made protecting the whole stack – not just part of it – very difficult. Too often, cybercriminals can persist on a network to a company’s infrastructure that houses ultra-sensitive data – all because they found some long-lived, stale privilege to exploit. Zero Trust in depth is key to stopping this. But what does that look like?

After all, Zero Trust has been a wonderful thing – the answer many companies sought to create a perimeter-less environment. That was especially true during the pandemic when many realised their VPNs weren’t fit for purpose for a large, remote workforce. With Zero Trust, everything needed authentication (in other words, never trust, always verify). You weren’t authenticating to the network anymore, but rather, you were authenticating every single time you needed access to a resource.

The problem is that while many companies figured out how to authenticate users and enforce Zero Trust at the network level, they haven’t necessarily enforced Zero Trust principles at the application and workload level. That means that to this day, many still have to contend with the most comprehensive challenge of enforcing a fully Zero Trust architecture for cloud and data centre operations.

The solution is for companies to adopt the mentality of always asking, “does this person have the right authorisation to access this specific resource in this particular context?”

Make authentication attribute-based

If companies want to enhance defences for their access control, they have to make sure that resource access is only ever taking place in the context it should.

This is where attribute-based authentication – not just role-based authentication – is king. In other words, we have to set very fine-tuned requirements for when someone is permitted to access a resource.

Imagine that you have a database table that houses sensitive data. Yes, you could only grant access to employees with a specific job title – basically, role-based authentication. But it would be a mistake to stop there because there are other factors you can and probably should weigh here for whether or not a user gains access. For example, what’s their location? Are they at the office… or Tahiti? What device are they using? Is it their personal phone or their work laptop? And what time is it anyway? Maybe you don’t want to grant access to a resource that is currently in production. 

With these parameters, you can create an environment where you have rules like, “All senior programmers trying to access database table XYZ have to be in Chicago between 1pm and 5pm.” And voila: now no-one can access your sensitive resource unless they meet these conditions. Governing on attributes, rather than granting access to anyone within a network, is a crucial aspect of reducing the attack surface that has grown so large worldwide.

Although Zero Trust solutions are broadly deployed in network security, it is time for engineering leaders to extend these principles to modern infrastructure, while making life easier for employees who manage the resources and data driving their business. Modern DevOps infrastructure will only get more complex, dynamic, and ephemeral as time goes on. By investing in access solutions that improve user experience for engineers while hardening security, companies can protect against the riskiest part of their infrastructure:  the human element that attackers are exploiting.