There’s been a paradigm shift over the past decade and a half in the world of cybersecurity. Whereas older models and systems prioritized perimeter defense, the definition of “perimeter” itself has changed over time. Today, businesses are increasingly mobile and remote, utilizing cloud servers to extend the workforce far outside the office or headquarters.
These changes are all the more necessary in our current environment of pandemic response. Our mandated practices of social distancing and work from home (WFH) have created an environment in which every company is rethinking its perimeters in real time. These challenging times call for new practices, and zero trust framework is the future of cybersecurity.
This guide will walk through how to implement a zero-trust architecture (ZTA) network strategy.
Implementing a Zero Trust Network Security Strategy
Zero trust is the future, but it’s also been around for quite some time. Cybersecurity experts and organizations have been theorizing ZTA, in different names, since at least 1994. And in 2007 the United States Department of Defense incorporated ZTA concepts into its global cyberdefense planning. It’s also in wide use across various industries, including:
- Higher education
- Government
- Technology
- Finance
In 2020 businesses of all shapes and sizes can benefit from shifting cybersecurity away from the perimeter. The National Institute for Standards and Technology (NIST) has published a working draft of their comprehensive guide to ZTA, NIST SP 800-207 for Zero Trust Architectures. In the sections below, we’ll walk through the strategies for implementing ZTA.
But first: where are you starting from? What kind of implementation plan do you need?
Let’s discuss.
Contexts for Implementation: Greenfield vs. Migration
One doesn’t necessarily implement ZTA in a vacuum. The context surrounding your adoption of ZTA determines exactly what the implementation process will look like.
The two main kinds of implementation are:
- Greenfield ZTA implementation – Starting fresh and building a completely new ZTA architecture. This context implies either no preexisting cybersecurity framework in place, or a complete restructuring and replacement of a given system.
- Migration ZTA hybrid – The more common context is implementation and integration of ZTA concepts into a preexisting, perimeter-focused cyberdefense system. This context entails renaming elements and establishing new relationships between them.
Depending on your needs and means, you may be starting up with ZTA as your first, or a brand-new, security scheme. Or, you might by integrating ZTA into an existing scheme, either to exist as a permanent hybrid or to eventually overtake the old system.
In either case the most important part of implementation is creating or renaming parts to establish a system based on ZTA’s logical framework.
Assess your NIST 800-171 / DFARS / CMMC compliance
Install the Key Logical Components
Whether you’re building from scratch or doing renovations, you need a solid floor plan.
Installing a ZTA in your business requires knowing all the parts that make up a ZTA and establishing them. It also requires setting up connections and relationships between these “parts” that help them function properly. As with real-world architecture and building design, a ZTA cybersecurity scheme is more than the sum of its parts.
In any ZTA there are two main kinds of components to install:
- Core components
- Data source components
Let’s get into what these are and how they work together.
Core Components
The heart and soul of a ZTA, the core components, are what make up the two most important areas of the whole framework, the policy decision point (PDP) and policy enforcement point (PEP). The system breaks down into these four parts:
- Policy engine (PE) – This is the seat of decision making, in terms of grant or refusal of access. Processing all inputs from various data source components (see below), the PE ultimately determines whether or not to grant access; it also logs the decision.
- Policy administrator (PA) – This is the active agent that materializes the PE’s decision. Working together with the PE, the PA executes the decision and grants or refuses access. Taken together, the PE and PA make up the PDP.
- Policy decision point (PDP) – The PDP is the combination of the PE and PE into the decision making motor of your ZTA. The PDP may consolidate the PE and PA into one resource. While the PE only interacts with the PDP, the PA also liaises with the PEP.
- Policy enforcement point (PEP) – This is “where” and “when” the decision made in the PDP are applied. This system contains the interface by which users request and receive (or are denied) access. Through the portal of the PEP lies the “implied trust” of the ZTA.
Importantly, these logical components are considered separate abstract units, but that’s simply a logical distinction. They don’t necessarily correspond to separate individual resources or end-points. As we’ll discuss further below, one or more components can be combined into a single resource. Or one component can be deployed across multiple resources.
As long as each component’s function is accounted for, your architectural plan is solid.
Data Source Components
The PDP works by processing vast amounts of input data to make its decisions about access. In order for it to receive and process that data, it must be connected to a number of resources that monitor and collect actionable information.
These data source components comprise the following:
- Continuous diagnostics and mitigation system (CDM) – This is the system that gathers every single piece of relevant information about a given access request, overlapping with other components below. The CDM acts as an aggregator, streamlining PDP input. Ultimately, the CDM is the most important data source component.
- Threat intelligence feed(s) – Like the CDM, threat intelligence spans various other components. However, this component is limited to data about all existing and potential threats. This includes internal and external information on:
- Attacks targeting comparable enterprises
- Common malware and hacking practices
- Identification management system – This system handles the creation, processing, and storage of all identifying information for users, assets, and resources.
- Data access policies – This system contains an updated set of all relevant regulations governing access to a resource, a starting point for the PDP decision processing. The system may generate this information automatically, or it may be actively maintained.
- Enterprise public key infrastructure (PKI) – This system generates all certificates issued to resources, subjects, and applications. It also logs each such transaction.
- Industry compliance system – This system scans for any and all relevant requirements of the particular set of regulatory codes a given company is required to follow. Some examples include:
- Network and system activity logs – This system logs all relevant information pertinent to each individual access request. This goes for successful and failed access requests. It also tracks resource and user activity after each request (whether granted or denied).
- Security information and event management (SIEM) system – Finally, this system is responsible for collecting and aggregating information from all other systems and optimizing it for future use (analysis and corrective or preventative measures).
The basic blueprint of all ZTA is contained in these components, along with the ones above. By installing the core elements and ensuring the proper flow of input from these data source components into them, you will have effectively implemented a ZTA.
There’s more than one way to implement these components across your organization.
Consider Alternative Methods of Implementation
As noted briefly above, the implementation of these logical components needs to execute each of the functions detailed above. But that doesn’t mean that each component needs to be or have its own dedicated resource. It also doesn’t mean that there are any determined priorities in terms of which components (or resources) matter most or least.
Different companies may choose to foreground varying aspects of their ZTA architecture, leading to different driving factors and styles of implementation. The three most common are:
- ZTA driven by identity governance
- ZTA driven by micro-segmentation
- ZTA driven by network infrastructure and software perimeters
Let’s take a close look at each.
Enhanced Identity Governance
One of the most common, and the simplest way to integrate ZTA into existing workflows, this approach places a strong emphasis on the management of identities. While other elements of the ZTA architecture are still in place, an enhanced ID governance system prioritizes data pertaining to individuals’ and resources’ identity.
This information includes but is not limited to:
- User credentials
- Logged user behavior
- User and resource profiles
This implementation plan foregrounds this data rather than information about protocols or external threats. The algorithm is designed to “look for” vulnerabilities at the level of the user first and foremost.
Micro Segmentation of Zero Trust Architecture
This is another very common way to integrate ZTA into an existing perimeter-focused system. Organizations with larger or more complex cybersecurity systems often face issues of scale when trying to implement ZTA.
If your existing systems are simply too large to overhaul all at once, micro-segmentation is key.
Micro-segmentation involves a process of creating individual zones or “segments” separate from the rest of your overall networks and systems. These zones are protected by a complete ZTA framework, albeit on a smaller scale, “behind” PEP gateways.
Within these zones there is no “implicit trust” granted until a full ZTA-approved access request is granted by the PDP. When implemented, it works like an establishment of several smaller perimeters working in concert.
Network Infrastructure, Software Perimeters
In this scheme the network structure itself is used to implement a ZTA or ZT-like web of protection, also known as a software defined perimeters (SDP).
This scheme uses a handful of defined networks and software as the engine for cybersecurity of all resources. The defining characteristic of this approach is that the PA’s main function is to configure the network according to decisions made by the PE.
This practice is a common agent or gateway deployment (see below). In practice, the PEP creates a channel through which clients access the network. While this works and looks like a perimeter, it’s secured by ZTA protections embedded in the components detailed above.
Besides these methods, there are also distinct variations on the deployment of components.
Varied Deployment of the Zero Trust Architecture
The final consideration in your implementation plan is also one of the most open-ended.
When setting up your overall structure, there are numerous ways to configure the individual components. The effect produced is that the perceived or actual “location” and other characteristics of the PEP may differ for both client and administrator.
Rather than simply designating one component to a given resource, consider some of these alternative schemes, as outlined by NIST:
- Device agent or gateway deployment – Dividing the PEP into separate components residing on or directly in front of each resource protected. The user interacts with an agent gateway for access to each individual resource.
- Enclave-based deployment – Similar to the agent/gateway model, in this version the gateway grants access to a cluster or “enclave” of resources rather than just one. In practice, this forms a kind of micro-perimeter around the enclave.
- Deployment via resource portal – Like the two gateway models above, this system combines the PE and PA into one unified component PEP, granting access to a portal (temporary perimeter) that contains one or more resources.
- Device application sandbox deployment – A final variation on the gateway theme, this deployment vets individual applications and grants access to a resource via the application. In practice, the PEP is (within) the application itself.
The important thing isn’t how you deploy the components of your ZTA: it’s that you do, one way or another. Whatever form your ZTA takes, your best bet to successful implementation is recruiting the help of professional technicians.
For that, we’re here to help.
Optimize Your Cyberdefenses with RSI Security
At RSI Security, our mission is to help businesses protect themselves from cybercrime.
Whether you’re looking for guidance on implementing ZTA or other compliance requirements, our NIST advisory services are customized to your specific needs and means.
And that’s not all we do. From compliance to deep analysis and penetration testing, our qualified efforts offer full-service cybersecurity testing and strengthening. We’re industry leaders who have provided cybersecurity solutions to various companies for over a decade.
Stay one step ahead of the hackers. Contact RSI Security today!