Does Zero Trust Mean Better Audits?

Background

First coined in 1994 by Stephen Marsh in his doctoral thesis, Formalising Trust as a Computational Concept, the term Zero Trust was later popularized by a Gartner research analyst. Some years later in 2011, when Google announced its internal implementation of Zero Trust architecture, the concept helped spark a new, wide-spread interest in the technology and security communities. In response to this increased public interest, the National Institute of Standards and Technology (NIST), in coordination with the National Cybersecurity Center of Excellence (NCCoE), developed a special publication (SP 800-207) on Zero Trust architecture and have since published additional information on implementation practices.

What Zero Trust Is and What It Is Not

So what is Zero Trust? One major misconception floating around is that the term indicates a single type of architecture. Rather, Zero Trust is a set of guiding principles that are useful for developing a more versatile, responsive security strategy. As defined in the NIST Special Publication 800-207, the tenets of Zero Trust are the following:

1. All data sources and computing services are resources.
2. All communication is secured regardless of network location.
3. Access to individual resources is granted on a per-session basis.
4. Access to resources is determined by dynamic policy, including the observable state of client identity, application/service, and the requesting asset – this may also involve other behavioral and environmental attributes.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.

The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.

But these tenets are simply that—concepts or principles. Actual implementation of Zero Trust in an organization’s enterprise security model will vary based on how closely the organization’s model embraces these core tenets. When moving forward with such implementation, there is also the distinction between pure Zero Trust and hybrid Zero Trust to consider—while the former is an all-encompassing Zero Trust strategy, the latter indicates the coexistence of systems designed with traditional Defend-the-Moat security structures interacting with those that are designed with Zero Trust principles. For example, a hybrid approach might look like applying Zero Trust principles specifically in Amazon Web Services (AWS), Google Cloud Platform (GCP), or an Azure cloud environment supporting a software-as-a-service (SaaS) application while also running a traditional environment to support corporate systems such as e-mail, human resources and accounting applications, intranets, file servers, etc.

How Does Zero Trust Positively Impact an External Audit?

When it comes to compliance, there are advantages to both kinds of Zero Trust approaches. For most compliance standards or frameworks—SSAE 18, PCI DSS, HIPAA, HITRUST, NIST 800-53, FedRAMP, among others—an environment designed with pure Zero Trust principles generally sees more preventative controls implemented in the logical access components of the compliance framework or standard. Preventative controls are typically easier to test, as they are usually more configuration-based and provide additional value over reactive or corrective controls. With that said, a hybrid Zero Trust approach also has its merits, including where scoping is concerned. One of the more traditional challenges in most audits is identifying the scope of an assessment but using a hybrid implementation that includes micro-segmentation of the enterprise’s assets may make this process of identifying “in-scope” systems easier, as that segmentation effort would be already logically implemented and clearly defined.

Moreover, the use of API keys and multi-factor authentication (MFA) in Zero Trust architecture—regardless of which specific type—directly supports the principle of all resource authentication, and authorization is dynamically and strictly enforced. During an audit, these authentication techniques provide an additional level of support for validating the legitimate use of the enterprises’ resources and are integral in addressing the logical access or access control requirements found in most compliance frameworks.

What Challenges Are There With a Zero Trust Architecture Undertaking an External Audit?

Of course, Zero Trust does also present some unique hurdles when it comes to compliance, and some are even built into the architecture itself. Because Zero Trust uses cost-effective artificial intelligence to make policy administration decisions, there is an increased risk of both false positives and false negatives—i.e., identifying normal actions as attacks or identifying attacks as normal actions, respectively—and that will need to be accounted for within the organization’s risk management process.

In a similar vein, Zero Trust architecture can also make it trickier to secure devices that are not owned or able to be managed by the organization. Specifically, with bring-your-own-device policies, it is challenging for organizations to proactively require up-to-date patching and perform behavior analysis on these devices—considered resources within Zero Trust—when they are connecting to the enterprise architecture.

Perhaps less a challenge than additional risks that must be addressed with Zero Trust architectures are the policy engine and policy administration function—because they wield increased power within this setup, they necessitate extra attention paid to them. Likewise, more scrutiny will be obligatory for those organizations using Zero Trust while also utilizing temporary security tokens for accessing sensitive resources and securely sharing API and SSH keys for programmatically accessing computing resources. While many compliance frameworks address those related risks directly, audits under frameworks that do not will have to account for the extra risks related to use of temporary security tokens and trust certificates within Zero Trust.

Given all of these challenges, organizations implementing these architectures will need to adequately consider the risks related to the architectural change and determine if controls and procedures are in place to sufficiently address and document those risks. On the other side, those auditing Zero Trust should remain aware of all of these unique risks and become adept at navigating them as these architectures continue to be enacted and related industry knowledge continues to evolve.

Future Outlook

Though there clearly are both pluses and minuses to weigh in considering implementation of Zero Trust, it’s evident that making the switch—whether it be a pure or hybrid approach—should result in audits that include some combination of more preventative controls, easier scoping tasks, and proper addressing of the dynamic threats that organizations face in this advanced cybersecurity age. While there is no easy transition from traditional architecture to that of Zero-Trust, it is still fully expected that there will be a variety of incremental moves toward both pure and hybrid models in organizations. Look for those that are already embracing cloud computing to lead the charge in this paradigm shift, as companies everywhere all continue working to improve their information security and resiliency practices.