How to avoid 4 common zero trust traps (including one that could cost you your job)

Formulated by a research analyst over a decade ago, the zero-trust security model was embraced by thought leaders. And when Google, with its unlimited budget and resources, began adopting something close to the zero-trust framework through BeyondCorp, the effort had a legitimate and prominent early adopter.

Eleven years after its introduction, IT and security leaders still look at zero trust in exasperation. The gaps and needs of existing infrastructure, the demands to maintain incremental improvements, and the inability to simply start from scratch stand as obstacles between reality and utopia.

According to the National Security Agency’s guidance released on February 26, 2021, there are four key aspects of a zero-trust mindset:

• Coordinated and aggressive system monitoring, system management, and defensive operations capabilities
• Assuming all requests for critical resources and all network traffic may be malicious
• Assuming all devices and infrastructure may be compromised
• Accepting that all access approvals to critical resources incur risk, and being prepared to perform rapid damage assessment, control, and recovery operations.

Assuming the compromise of all devices, infrastructure, and traffic is as impractical in the boardroom as it is futile within the SOC. Unfortunately, mindsets, like frameworks, fail to offer practical direction, clear advice, or next steps. This leads to four key traps made by well-intentioned zero trust adopters.

Common zero trust traps

Before I explain these, let’s set the groundwork. The components of zero trust include the following six domains:

Identities: Describe, verify, and secure the accounts across your entire enterprise. This includes all user, service, API, and other access-granting accounts throughout your cloud, on-premises, and remote assets.

Assets: See every asset touching your environment. As with Identities, describe, verify, and secure every asset in whatever location it exists: cloud, on-premises, and remote. Ensure management and security requirements are in place and functional before access is granted.

Applications: Convert all shadow IT, shadow cloud, and bring-your-own applications to managed and secured applications. Reduce access based upon current analytics and demand. Monitor, control, and correct user permissions.

Data: Identify, classify, and label data in its repositories, throughout ELT/ETL, and in applications. Shift your attention from controlling the perimeter to controlling data access. Encrypt and control access based upon your classification labels and internal policies.

Infrastructure: Employ least-privilege-access or “default-deny”, monitor and alert on anomalies and suspected attacks. Use automation to block anomalous and risky behavior.

Network: Identify network zones with greater risk or higher-value data. Segment different network zones by risk and value and limit access by policy. Deploy encryption within your internal networks. Ensure devices and users aren’t trusted just because they’re on an internal network.

With that in mind here are the four zero trust traps to avoid with practical advice for doing so.

Trap #1: Choosing one, important application as a proving ground

This is common because it seems easier to prove zero trust by starting with one application. The difficulty is that you don’t know its interconnections with other applications, its pathways to access and what users require which access to the application.

Zero trust requires segmenting every application so they are isolated from one another. That’s extremely difficult because of an inevitable lack of knowledge within the organization about how the applications interact.

It’s better to start by segmenting the application’s ecosystem. Then you can gate access to that application and not have to worry about failure of service delivery. Dealing with the application ecosystem allows you to focus your attention solely on the user-to-application interaction boundary. Having to handle the user-to-application plus application-to-application and application-to-infrastructure boundaries will crush you.

Trap #2: Focusing exclusively on identities leads to interminable projects with no clear end in sight

The trap most practitioners fall into is the need to understand and define every identity in their organizations. Initially, this seems simple but then you realize there are service accounts and machine and application identities. It’s even more difficult because that identity project has to include permissions and each application has its own schema for what permissions are granted. There’s no standardization.

Instead, focus on the user accounts. When we start with the application ecosystems, our intent is to focus on the user and application boundary. Now if we look at identities, start with interactive logins, i.e., users who need to access an account to perform an action. Ensure non-repudiation by getting rid of generic logins, using certificates and rotating credentials.

Trap #3: Providing any device access to every application from anywhere will cost you your job

Most boardrooms see zero trust as a way of using any device to be able to conduct business. That should be the end result of a robust zero trust program. If it is where you start, you will be overwhelmed with breaches. The purpose of zero trust is to technically express the fact that you don’t trust any device or network. You don’t accomplish that by closing your eyes to it.

Start by providing the right identity access to the right applications and ensuring there is segmentation between those users and their access. Next, move approved devices where you can authenticate the device or the user on any advice to ensure that authentication infrastructure is in place. Once it is and you can validate the device, you can broaden the type and variety of devices that access the network.

Trap #4: Deciding that abandoning your data center for the cloud will make zero trust a sudden reality

Lifting and shifting your data center environment to the cloud inevitably guarantees disaster from a zero-trust perspective. The trap here is lacking proper visibility of the assets in your data center, what they’re connecting to, and the segments in your enterprise. Simply re-instantiating your data center in the cloud does not grant you that visibility. In fact, it exacerbates your lack of visibility because there are fewer controls adding friction to the cloud than in the data center.

Before moving to the cloud, gain visibility into the triad described above — the application ecosystem-to-user group boundary, the user identity attributes necessary to perform authentication and the devices that need access. Moving an application ecosystem that you’ve already contained as a well-known entity will save you from disaster.

The digital transformation imperative means that the journey to zero trust starts now. As with all major initiatives, charting your course beforehand, understanding the traps that exist along that journey and thinking practically how to avoid them will alleviate the exasperation that keeps many organizations from getting started.