Implementing Zero Trust Security

At its core, Zero Trust is an intuitive concept: assume that every device, user and network is compromised until proven otherwise.

It is music to the ears of security practitioners professionally predisposed to paranoia. That said, there remains a gap between understanding the Zero Trust model and the complexity of its practical implementation. For that reason, Zero Trust has remained mostly aspirational.

Earlier this month the National Institute for Standards and Technology released its publication on Zero Trust Architecture. NIST SP 800-207 details core concepts of Zero Trust Architecture and its implementation. Here are some of the core tenants of Zero Trust Security and some implementation advice for your adoption of these concepts.

Before we dive in, boot up your Commodore 64 and join me on a brief trip down memory lane. There was a time, now long forgotten, when all that stood between our trusted enterprise networks and the barbaric hordes of hackers on the public internet was a lone packet-filtering firewall. From this chaotic, prehistoric era known as the nineties one model emerged predominant; that of perimeter defense. The internal network became a zone of implicit trust, a land of milk and honey where traffic flowed unhindered and usually unencrypted.

As the new millennium dawned, companies started segmenting their internal networks and added additional defensive tools to the arsenal. Concentric circles of defense were built. Defense-in-depth was the prevailing model. The castle and moat was the prevailing analogy. Salesmen the world over eagerly made forced analogies about why their product alone could be considered the true drawbridge to your enterprise's castle and moat. This evolution did not fundamentally challenge the concept of an implicit zone of trust. An attacker willing and capable of bypassing one wall is rarely deterred by one more.

Snap back to 2020 and the global pandemic. Gone is the era of a single, manageable corporate network. Perhaps it never really existed outside of our imaginations. The new reality is one of remote users, bring-your-own-device (BYOD) policies, VPNs and cloud-based assets aplenty. Enter Zero Trust as the new darling of the security industry, which reflects the realities of our times: most networks and devices are inherently untrustworthy. This is not a departure from the model of perimeter defense but rather its natural evolution in light of innovations in technology and process. We now have the ability to create a perimeter around every individual asset under management, and seamlessly but explicitly grant access on demand.

Before diving into the nitty-gritty of implementation plans, it's important to define the core tenants of the initiative. These will be referred to religiously to justify architectural decisions and should be adapted to fit your requirements.

1. Secure all communication. The flip side of "trust no-one." Access requests coming from within and without the network meet the same security requirements.

2. Grant the least privileges. Access should also be granted with the least privileges needed to complete a given task.

3. Grant access to a single resource at a time. Authentication and authorization to one asset must not grant access to another resource.

4. Make access policies dynamic. Beyond federated identity, access requests should evaluate dynamic attributes such as device analytics, behavioral analytics or environmental factors.

5. Monitor the security posture of your assets. No asset should be inherently trusted. A robust monitoring and reporting system should provide actionable data about the current state of enterprise resources.

6. Periodically re-evaluate trust. This is a constant cycle of obtaining access, scanning and assessing threats, adapting and continually reevaluating trust in ongoing communication.

7. Collect and use data to improve your security posture. Collect data about asset security posture, network traffic and access requests. Use insights gained to improve policy creation and enforcement.

All of these concepts are great in theory, but in practice they can be quite complex to implement. Your implementation plan should be guided by the details of your organization. However, here is some high-level guidance:

1. Identify your protected resources. Before any of the legwork occurs, you need to determine which assets, data and services you will be protecting. Leverage existing lists if possible and ensure that processes or technology exist to keep it up-to-date.

2. Define your policies. You'll need to document the expected behavior of your users. A good way to do this would be to document the five Ws of access: who, what, when, where and why.

3. Identify your data feeds. Identify the data that will be used to make access-granting decisions. This should include, at the very least, an identity management system, but can include any number of security feeds including threat intelligence, security incident and event management, activity logs, compliance systems, continuous diagnostics and mitigation systems or whatever else fits your specific use case.

4. Define your Trust Algorithm. Your Trust Algorithm will evaluate the request, the policy and the data feeds in order to make an access-granting decision.

Will your Trust Algorithm be singular or contextual? The first will evaluate each access request individually, whereas the latter will evaluate contextual data such as behavioral patterns.

Will your Trust Algorithm be score-based or criteria-based? A score-based system assigns a level of confidence based on weighed data inputs, whereas a criteria-based system will only grant access if certain conditions are met.

5. Define your architecture. This step is highly dependent on your organization and its current setup. A word of warning on implement proxies or wrappers to manage access decisions. You may be tempted to integrate each of your enterprise resources's backends directly with the policy administrator, however this would impose limitations to scalability, increase maintenance costs and hamper your ability to rapidly launch new products. Learn from Google's experience. You can find an example of Zero Trust Architecture below.

And of course the final step; implement! Congratulations on reading all the way through, I hope that this has helped demystify some of the core concepts of Zero Trust! What is your experience with Zero Trust, have you successfully implemented some or all of its tenants yet? If so what challenges have you run into?