Zero Trust is not a product, it’s a concept, and it applies broadly across many cybersecurity processes, controls, and products. It also refers to a particular information systems architecture and strategy. Despite the term’s overuse these days, its importance in reducing enterprise risk can’t be overstated.
The National Institute of Standards and Technology (NIST) defines Zero Trust Architecture (ZTA) as follows.
Zero trust provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. ZTA is an enterprise’s cybersecurity plan that uses zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a ZTA plan.
In short, zero trust can be thought of as reducing access to the least amount necessary. This least privilege or least access applies to data, applications, networks, infrastructure, and anything else that has value to an organization (and therefore to an attacker). That’s a long list, however - how should we structure zero trust architecture when thinking about it and planning out a security strategy?
Thankfully, CISA has published a helpful Zero Trust Maturity Model that breaks this down into five ‘pillars’.
- Applications & Workloads
There are then three foundational capabilities that apply to each of these five pillars.
- Visibility and Analytics
- Automation and Orchestration
Zero Trust Pillars and SaaS
One of the primary reasons SaaS is attractive to organizations is that it simplifies the application delivery model. Without any infrastructure to deploy, networks to configure, or software to install, implementing a new SaaS solution could be (and often is) as simple as clicking “Log in with Google” or “Log in with Microsoft”. With devices and networks less relevant in the SaaS model, the job of implementing zero trust is focused on three of the five pillars: identity, applications/workloads, and data.
Identity is at the heart of SaaS adoption, with single-sign on making adoption (and over-adoption, shadow IT, abandoned SaaS) as simple as clicking “sign up”. Managing and securing these identities is also a challenge, as MFA is rarely enabled or enforced by default, even today. Reducing unnecessary permissions attached to Identities is one of the most effective zero trust exercises when it comes to real-world risk avoidance. To this point, gone is the idea of an administrator as someone that has “all the permissions” that are available. Modern applications recognize that administrative functions often need much less access than originally assumed (ability to monitor, maintain, grant access to others). Legacy applications (even SaaS), however, often over privilege administrative roles, giving access to data and functions that aren’t necessary for admins to perform their jobs.
Applications and workloads are still a consideration, even within SaaS platforms. Nearly everything from environmental controls for commercial buildings, to cloud infrastructure, and even security products are managed through SaaS applications these days. Low-code and no-code platforms like Workato, Zapier, and Microsoft Power Apps are complex platforms with permissions managed at many different layers. At one level, these platforms are SaaS applications, and access to automated workflows should have the principal of least privilege applied to each workflow: the ability to create/delete/edit workflows and the ability to create/delete/edit connectors to each SaaS application that can be used as a building block within each workflow. Furthermore, the privileges granted by the credentials used for each connector is a concern as well - the connector should have only the access needed to perform the workflow, and no more.
Data remains one of the top challenges to secure. For it to be useful, it must be easy to access, explore, and share. Once lost, stolen, or exposed, however, there’s no undo. Data can be copied and exposed forever, meaning permissions must be carefully managed, and revoked when there is no clear business benefit to leaving it exposed. The benefit of SaaS is that auditing and managing these permissions can be fully automated, thanks to the convenience of APIs. There’s little excuse not to implement least privilege for SaaS-related data sharing when privileges can be codified and much of this work can be fully automated.
Zero Trust Capabilities Within Each Pillar
While CISA’s pillars divide ZTA into logical categories, achieving maturity within each pillar requires action. To operationalize and mature each pillar, CISA outlines three capabilities.
Visibility and analytics is essential to understand the scope and severity of the SaaS security situation. Visibility and analytics is all about discovering insights and answering questions. How many employees lack MFA enforcement? How many data shares are open to anyone with the link? How many no-code workloads have been configured with accounts that have too many permissions? Answering these questions is necessary to both understand the SaaS environment and assess the level of risk it poses to the organization.
Automation and orchestration in a zero trust context tends to focus on response capabilities and playbooks. In a SaaS context, it’s highly linked to hygiene and governance: ensuring data shares and identities don’t have unnecessary permissions, for example. Automation and orchestration can manage identity and data lifecycles, ensuring abandoned, or idle resources don’t create additional, avoidable attack surface for the organization.
Governance, as alluded to from the previous description of automation and orchestration, is the process of ensuring that zero trust principles are actually being applied in an effective and consistent manner. Reporting becomes very important in this stage, without which, it can be difficult or impossible to track progress in an organization’s zero trust maturity journey.
Achieving Zero Trust Architecture Maturity with Valence
The Valence platform provides visibility into identities, mapping business users and identity-related security issues across multiple SaaS applications and platforms. Governance issues can also be identified: over privileged users, dormant accounts, and accounts unmanaged by the corporate identity provider.
Visibility into external data sharing helps identify unnecessary attack surface and inappropriate permissions. Policies address governance challenges, automating data lifecycle management.
Finally, visibility into SaaS applications and workloads provides analysis of unused, abandoned, and overprivileged configurations and SaaS-to-SaaS integrations. Policies here can also automatically remove unnecessary or unused integrations.
This policy-based approach of automatically maintaining least privilege across dozens of SaaS applications simplifies the process of achieving zero trust maturity while minimizing manual work.