How to approach a Zero Trust security model for your enterprise

For decades, security controls have been built around protecting a single, massive corporate perimeter. As seen with the latest breaches in the industry, this method has proven unsuccessful at realizing its core intent, which is to protect the critical systems, data and personnel that allow companies to successfully operate. Once this corporate perimeter is breached, through a phishing attack or unpatched system, a threat actor can freely move across other security layers and systems, where data can be compromised.

The Zero Trust model shifts the single, large perimeter and moves it to every endpoint and user within a company. The premise is built on strong identities, authentication, trusted endpoints, network segmentation, access controls, and user and system attribution to protect and regulate access to sensitive data and systems. The two primary principles that make up Zero Trust are that you don’t inherently trust anything on or off your network, and that you apply security controls only where they are needed, to compartmentalize and protect critical systems and data.

When looking at Zero Trust from a breach perspective, the intent is that a compromise of one asset doesn’t compromise the entire company and that you only apply security controls to what matters most. It’s similar in theory to how the Titanic was built, where one compartment could flood and the boat wouldn’t be compromised.

The original Zero Trust model concept was developed by Forrester in 2010, and later leveraged by Google as a part of their “Beyond Corp” initiative. If you want to implement Zero Trust today, you can buy and implement Google’s Beyond Corp as a service, but they lock you in to using everything Google (Google Cloud, Google Identity, the entire G Suite, and all users must be on Chromebooks). There are, however, many variations on how to implement the Zero Trust model by leveraging many off-the-shelf products and cloud solutions. 

If Zero Trust sounds eerily familiar to you, it’s because many of us have seen this act before when access control lists (ACLs), then role-based access controls (RBAC), and then principles of least privilege were all the rage. As with RBAC and least privilege, the Zero Trust model starts with a subject or identity, with assigned roles and permissions specific to the role (and nothing more). However, the folly in RBAC, and subsequently least privilege, was that it allowed for subjects to be assigned multiple roles and permissions, which eventually loosened to a point that defeated the purpose and intent of the control in the first place. Combine this with the arduous task of mapping out and classifying all your systems, networks and data (in an effort to protect all of it), and the introduction of cloud and diverse SaaS offerings for core applications and services, and it becomes very difficult to implement and manage effectively.

If you (1) take the core principles of RBAC, including strong subjects, role definitions and governance using identity and access management and privileged access management products in combination with a single source of truth for all subjects or identities and roles (I’d recommend using something other than Active Directory), (2) apply stringent access controls to toxic or sensitive data, systems and applications and only provide permissions for assets needed for the employee to do their job, (3) include attribute-based authentication (computer fingerprint, mobile device fingerprint, certificates, keys, login time, location, protective and detective apps and controls installed, etc.), and (4) implement user and entity behavior analytics (UEBA) as a compensating control to look for and alert on behaviors outside of normal for a specific user, system or device, and require step up authentication measures and other additional security checks to continue); you’ve got the making of a strong Zero Trust implementation.

I’ll admit that implementing a Zero Trust model is not for the faint of heart. It forces you to unwind legacy infrastructure, legacy workflow and legacy processes (transactional) that have been around for decades, in some cases. The larger your company is, the more complex your infrastructure is. The amount of legacy workflow, processes and systems that you have to account for, and the flexibility of your organization to adapt to change, are all obstacles to implementation. A great example of how long the implementation can take for a large but nimble company is Google, which took six years to fully build and implement their model.

The six key steps for implementing zero trust:

1. Identify your sensitive or toxic data sources
2. Identify roles and assign people to a single role
3. Map the transaction flows regarding the toxic data
4. Architect a Zero Trust network based on the toxic data sources and the way they are used transactionally
5. Write rules on your segmentation or policy gateway (e.g. Cloud Access Security Broker or CASB) based on expected behavior of the data (users and applications)
6. Monitor the network; inspect and log the traffic; and update rules based on your behavior analytics

The five key technologies I’m leveraging to implement Zero Trust at my company include:

1. Identity and access management (e.g. Okta, Ping, Centrify, etc.)
2. Privileged access management (e.g. Beyond Trust, CyberArk, Centrify, etc.)
3. Cloud access security broker or policy orchestrator (e.g. NetSkope, SkyHigh, Symantec)
4. HR systems as the recommended single source of truth (ADP, Workforce, not Active Directory)
5. SIEM or other user and entity behavior analytics solution

While it might seem like a daunting task for many, especially at larger companies, I’ve hopefully provided some information to give some CISOs some hope and high-level guidance for implementing a Zero Trust network at their company.