Don't Let the Past Obstruct Your Zero Trust Future

I'm in awe of those who create the future free from the constraints of the present. Take Wells Coates, for example. In his day, high tech was music and news played from furniture, polished brass and wood that housed heavy electronics. I have a Brunswick phonograph from this time period that's larger than my desk. Coates reimagined what radio could be when he designed the Ekco AD-65. Small, round, portable. The mental leap is extraordinary.

I think about Coates often as I work with organizations on Zero Trust plans. In some cases, there's a desire to wait until our current projects get completed. Once we have everything documented and fully understood, that's when we'll move ahead with Zero Trust. Other times, there's a desire to cleanly break with existing technologies. Why have a VPN when everything is delivered with least trust?

I argue we need a balance of both.

Don't Wait
Both NIST and the UK NCSC have published principles for Zero Trust architecture, and both have a similar starting point: Know all the devices and all services. A complete asset inventory is the start of many control frameworks, like the CIS Critical Security Controls (CSC). But here's the rub: Building and maintaining a configuration management database (CMDB) is difficult under the best of circumstances. Add personal devices, cloud services, and working from anywhere, and it becomes next to impossible.

Data governance has the same problem. Take a data-centric approach, common wisdom says. Begin the Zero Trust journey by finding and classifying all data sources. Implementing a data governance program based on CMMI Data Management Maturity (DMM), or similar models, takes years of work. Obtaining agreement from management on data classification is difficult. Getting the workforce to tag the data consistently is even more challenging.

One other dependency is risk management. NIST and the UK NCSC describe setting policy to express our risk tolerance. I once read off this statement in a workshop I was giving on Zero Trust, only to be met by a roll of laughter from one table. It was the risk team. I asked what was funny, and team members put it this way: No one could agree what the risk tolerance should be. Moreover, the risk management function operated at a high level. The idea of using risk, even in a well-staffed and long-running program, for asset-level policy enforcement was laughable.

That's not to say we shouldn't use a CMDB, data governance, or risk management. When these programs are mature in our organizations, use them. The point is, we need to decouple Zero Trust from long-standing problem spots, if we're going to be successful.

Don't Waste
A consistent theme in Zero Trust is to not trust the network location. Existing architectures typically have the same trust level for everything within the network boundary. Attackers leverage this when they're in the environment moving laterally. Moreover, outside the organization's control, adversaries hide or spoof their Internet location. So it's vital that all network communications require strong authentication and be encrypted at the network level. However, when we create policies, it's valid to use network location as one signal. For example, simplifying the experience when working from the office or ramping up requirements when someone connects from an unusual location.

While on the topic of networks, consider the debate over VPNs. Zero Trust is often positioned as a VPN replacement. Some argue companies will only see the security benefits when we shift our entire infrastructure onto a Zero Trust model. All or nothing. Yet for decades, organizational IT shifted from one model to the next, often existing in a hybrid state for many years. (See also: cloud adoption.) A strong VPN capability allows practitioners to transition the right services to Zero Trust proxies and gateways, while securely protecting the rest of the services.

One final source of waste comes from confusing Zero Trust with least privileges. We trust a person to access a given resource based on the context, conditions, and attributes of the session. We apply the principle of least trust to prevent suspicious or malicious access. This shouldn't be confused with least privilege authorized within applications. The idea that Zero Trust replaces the need for well-defined application permissions and entitlements will cause problems down the road — if not with attackers, most certainly with auditors.

A Zero Trust strategy should build upon existing network-centric and identity-centric capabilities.

Conclusion
"We must not forget that the past all too often obstructs our view of the future," Wells Coates once said. We can't weigh down Zero Trust with dependencies on aspects of security that have long been difficult. At the same time, while we reach for the future, we can't step aside from aspects that are working well. This journey will take time, so keep it simple and build upon what works.

If you're looking for more information on how to implement Zero Trust, check out Duo Security's white paper, "From MFA to Zero Trust: A Five-Phase Journey to Securing the Workforce."

About the Author

J. Wolfgang Goerlich is an Advisory CISO for Duo Security, now part of Cisco. He regularly provides workshops and coaching on the topic of zero trust. With a background in leading IT and IT security in healthcare and financial services, Wolfgang has 25 years of information security experience.