A Roadmap to Zero Trust Architecture

Originally published by DoControl here.

Written by Corey O'Connor, DoControl.

Zero Trust was first introduced in 2010, which was also the same year Apple introduced the iPad! This new concept was a bit slow to catch on before really gaining any sort of traction. Fast forward to today, Zero Trust went from a high level concept, to a practical reality that is now at the foundation of most modern security programs. ‍

Knowing how, and where to get started was an initial challenge. The majority of organizations leveraged existing frameworks and standards such as ISO/IEC 2700, mapping controls to the pillars of Zero Trust. Eventually, more specific publications and reference architectures such as NIST SP 800-207 were introduced providing more practical guidance in the context of Zero Trust.

Today, a full-fledged Zero Trust program takes anywhere from 2 to 3 years depending on a number of factors; and as is with any security program, approaching Zero Trust becomes a living, breathing thing that continually evolves. Many tools and technologies need to be evaluated, integrated, and adjusted over time to effectively mitigate the risk of a cyber breach and the long list of negative outcomes that come along with it.

Cloudflare recently launched a detailed architecture and roadmap to Zero Trust. A number of security experts and practitioners established the reference architecture to provide a vendor agnostic Zero Trust Architecture (ZTA), as well as an example implementation timeline. The timeline assumes that an organization is at the beginning stages of their Zero Trust journey, but it can certainly be useful for all organizations regardless of where they are in the process.

The reference architecture features a number of different components and considerations. The main objective – which comes to no surprise – is to secure the IT estate without disrupting end user productivity or connectivity. Of course every ZTA deployment is unique, but there are a common set of steps that most projects follow. While many organizations are well into the execution phase of their Zero Trust strategy, this resource can benefit any organization to get closer to:

"Never trust, always verify."

The roadmap outlines 4 phases in the implementation timeline which cover everything from deploying global DNS filtering, to establishing corporate identity, creating an inventory of corporate applications, and enforcing Multi-Factor Authentication (MFA). Even prior to the emergence of Zero Trust, the majority of organizations likely had in place corporate identity and MFA solutions to protect user access and authenticate workflows. As outlined in this roadmap and many other publications on ZTA, these are certainly core principles to get organizations closer to Zero Trust.

The same goes for enforcing the principle of least privilege. Least privilege has been around for awhile; it was first introduced in a paper published the year before Steve Jobs and Wozniak founded Apple. In most cases, least privilege is exclusively enforced at the individual user level (i.e. establishing the appropriate permissions and entitlements for users to do their jobs effectively).

Once a user has the appropriate access they require, if they become compromised in some way – or deliberately attempt to cause harm to the business – there’s trouble on the horizon for that organization. An environment with Zero Trust at its core is something you strive for, but never quite fully get there.

Back in 2010 when Zero Trust was first introduced, many “as a Service” technologies were on the radar for organizations but the preference to remain on-premises reigned supreme. Fast forward to today, the majority of organizations both public and private are leveraging the cloud to become more agile. Incorporating any tool or technology that enables the business always brings with it security implications – and the cloud is no exception to this rule.

Security is paramount now more than ever.

Phase 1 of this reference architecture lists out “identifying misconfigurations and publicly shared data in SaaS tools.” Extending least privilege to critical egress channels such as SaaS applications is the next logical step as organizations look to scale out their Zero Trust model. Cloud misconfigurations are a known security vulnerability. This reference architecture sheds light on the importance of securing the sensitive data that is being accessed, manipulated, and shared within and across SaaS tools.

Why is this an issue? Consider the fact that the average enterprise leverages 200 applications, multiplied out by the number of internal and external users accessing those apps, and multiplied yet again by the number of files and data generated within these platforms. There quickly becomes a challenge at scale with unmanageable data, accessible by far too many users (who oftentimes shouldn’t have access to begin with!), ultimately increasing the risk of data breaches and exfiltration.

Today, SaaS applications are one of the most preferred methods to share data – both sensitive or otherwise. It's imperative that security teams monitor and control access, as well as automatically remediate the loss, leakage, and misuse of sensitive company data.