The idea of zero trust is much discussed but not always well understood. At its core, it’s meant to provide a strategic approach to protecting an organization’s data. Spurred on by growing cloud adoption and the need to support remote work (which has spiked during the current pandemic), agencies are struggling with a sense of urgency to affect a highly secure posture — with zero trust seemingly a complex and expensive brass ring that’s out of reach.
Fortunately, it’s not, but it does require thoughtful planning and a little patience. Zero trust is an architectural strategy — it’s not about adopting all new technology or any particular product. It won’t happen overnight or even in the next few months; it will evolve over time.
An Incremental Approach
As more agencies embrace the benefits of migrating at least some of their data and applications to the cloud, traditional on-premise security architectures no longer suffice. Zero trust is an attractive design concept for addressing this radically different environment. It’s not all or nothing. Rather, it’s an adaptive flow, a journey that should be programmatically mapped according to an agency’s unique use case requirements and existing capabilities.
There is no need to “rip and replace” existing technology that’s working well. Instead, the right tactic may involve augmenting it to meet a broader set of requirements. The approach must be flexible to holistically address the required outcomes over time. A given technology should not drive business or mission decisions. Instead, mission requirements should drive zero-trust technology choices.
Start small, as you will learn along the way and can scale your efforts accordingly. First, define your required outcomes; identify which use cases need to be addressed. What are the business or mission drivers behind those? Where do the business outcomes and data reside? From where are they accessed? Identifying your protection surface will inform where you need to focus your efforts.
These early decisions on which data, applications, assets and services (DAAS) elements are crucial to mission and business operations will guide the architectural design phase in which you determine where segmentation gateways or policy enforcement points (PeP) are deployed.
Defining Where to Create Microperimeters
Zero trust uses a concept of microsegmentation to isolate and secure protection surfaces. It may be at the organizational level, keeping distinct project access separate to the responsible teams. If so, assess where project teams house their data and applications, and from where team members access them.
Microsegmentation may instead be employed at the application level to secure and limit specific application access to authorized users or applications. In this case, you’ll need to determine which environments the applications are running in.
Alternatively, microsegmentation may be needed down at the data level, where specific sensitive or classified data needs to be guarded, regardless of which applications access it. In that case, you’ll need to determine what data is in the cloud, what is on-premise, and what may reside with a managed service provider.
Armed with this information, it’s time to determine where to establish the microperimeters to be enforced by a PeP that restricts access to the DAAS element.
Common Use Cases
It’s helpful to consider use cases that show how these principles can be implemented in production environments. While each agency will have its own unique circumstances, these widely recognized use cases are outlined in NIST Special Publication 800-207:
This use case includes users accessing data from their home or branch offices connecting into the data center, hosted locations, or cloud locations.
DAAS access for remote users needs to be contextual according to who they are, which types of applications they’re using, what they’re doing with the accessed data, and if that behavior is authorized. It may make sense for remote data access to be treated differently — for example, requiring two-factor authentication for remote but not on-prem.
Cloud data can be hosted in different locations, so each must be addressed individually. Vendor software-as-a-service (SaaS) solutions should be reviewed to determine if they are sanctioned, unsanctioned or tolerated. Because SaaS applications can consume and store sensitive data that requires protection, a zero-trust model would restrict access to unsanctioned SaaS applications and also limit the amount of data that can be shared. Unfortunately, it’s not uncommon for agencies to allow access to many unsanctioned SaaS applications, which can result in individuals storing corporate data on personal and unsecured platforms.
Cloud native applications should also be designed with a zero-trust model in mind. Both in the development environment and the production environment, DAAS elements can be unintentionally shared with unauthorized users and systems. It is crucial that organizations design cloud native applications with zero trust principles in mind.
Palo Alto Networks Enables Strategic Zero Trust
The Palo Alto Networks research team continually reviews over 250 SaaS applications and applies an exhaustive, proprietary ranking system to assess their associated risk. Enforced through our VM-Series Virtual Next-Generation Firewall and Prisma SaaS, this information helps agencies quickly determine which applications should be allowed or blocked, and enables agencies to enforce appropriate microsegmentation, whether access is remote or on-premises.
For federal customers who need a secure access service edge (SASE) solution for remote users and remote branches, Prisma Access is a powerful option. Prisma Access uses our next-generation firewall platform to create a cloud-based PeP, providing the same Layer 7 visibility and security feature parity as on-prem security platforms—with the auto-scaling and ubiquitous access that cloud services provide.
Customers who want to extend zero trust principles from the cloud into the data center can use our next-generation firewall in a physical or virtual form factor as a segmentation gateway. For useful recommendations, Palo Alto Networks has a publicly available reference architecture guide for zero trust architectures that includes both on-prem and cloud use cases.
Best Practices to Get Going
As you begin your zero trust initiative, there are a few additional practices that will help start and keep your efforts on track:
- Establish a zero trust center of excellence so all involved parties get aligned and can communicate; use this forum for leadership to reach agreement on what the zero trust strategic approach will be.
- Institute a regular cadence of workshops for stakeholders to share progress and lessons learned that can benefit everyone.
- Most importantly, don’t start with a business-critical application — start with something low-risk; gain momentum from smaller wins as you work your way up to protecting the highest value agency crown jewels.
Zero trust is a long game, but when strategically approached, it’s well worth the journey.
Read more guidance for government agencies to implement zero trust.