The SolarWinds supply chain attack ignited a frantic evaluation of supply chain risk management efforts globally. Included in this response was a sudden readjustment of the risk lens through which all third-party vendors are regarded. The Zero Trust Architecture offers a means of increasing third-party risk resilience, without sacrificing the operational advantages of vendor relationships.
A Zero Trust Architecture is now a mandatory requirement under Joe Biden's Cybersecurity Executive Order.
What is the Zero Trust Architecture (ZTA)?
Zero Trust is a Cybersecurity architecture developed by the NIST (National Institute of Standards and Technology). This framework assumes all network activity, whether internal or external, is a security threat. As the name suggests, Zero Trust assumes all users are threat actors until proven otherwise.
It’s this obstinate determination to incriminate all users that makes Zero Trust effective at preventing and identifying supply chain attacks.
Does the Zero Trust Security Framework Prevent Supply Chain Attacks?
No security defense is guaranteed to prevent supply chain attacks, however, a Zero Trust Architecture (ZTA) is one of the most effective solutions for limiting the impact of supply chain attacks.
For the ZTA to have maximum potential, this framework should be implemented both within an organization and throughout its vendor network.
Unfortunately, not all vendors implement this framework and it’s difficult to rapidly identify those that do. Rather than operating in blind faith, organizations support their ZTA with a solution that continuously monitors for vulnerabilities throughout the vendor network.
How does a Zero Trust Architecture work?
The components of a Zero Trust Architecture (ZTA) can either reside onsite or through a cloud-based service.
The figure below outlines a high-level ZTA architecture and the relationship between each basic component.
All unverified network activity is fed between the Policy Decision Point and the Policy Enforcement Point. Only requests that pass strict Policy Engine requirements are permitted to flow through to all Enterprise Resources.
The core component functions of the ZTA are as follows.
Policy Engine (PE)
The Policy Engine is the brain of the ZTA. This component ultimately decides whether or not network requests are permitted by filtering them through a Trust Algorithm (TA). This Trust Algorithm also grants access in accordance with strict role-based permissions.
Policy Administrator (PA)
The Policy Administrator instructs Policy Endorsement Point (PEP) actions based on the Policy Engine’s decision. If the PE passes a request, the PA commands the PEP to permit access to Enterprise Resources. If the Policy Engine does not trust the network request, the PEP blocks further access.
Policy Enforcement Point (PEP)
The PEP is the final gatekeeper. It either denies or permits network traffic based on the Policy Engine’s decision. The PEP can be configured with policy updates fed from the Policy Administrator (PA).
Different applications of the Zero Trust Architecture.
The ZTA can be adjusted to suit different ecosystem requirements. All ZTA variations are capable of protecting against supply chain attacks, but some are easier to implement than others.
Organizations should choose a ZTA structure that requires a minimal amount of implementation effort.
ZTA variation 1 - Enhanced Identity Governance
This is the most common ZTA integration. In this variation, only those with privileged access are permitted to connect with Enterprise Resources. To facilitate this protocol, Enterprise Resource Access policies need to include the following components:
- The identities of each permitted user
- The assigned attributes of each permitted user
- List of permitted devices
- Asset statuses
Enterprise Resource Access policies can also be configured to grant partial access to Enterprise Resources if certain conditions are met (for example, if access is requested from specific locations).
Enterprises that adopt the Enhanced Identify Governance model usually include a separate visitor access network. This limits enterprise resource access to privileged users while still permitting access to other, less vulnerable assets.
The Enhanced Identity ZTA model is optimized to identify security vulnerabilities at the user level first.
ZTA variation 2 - Micro-Segmentation
Large ecosystems that want to rapidly implement a digital supply chain attack defense solution will find it difficult to scale the Enhanced Identity Governance variation. The Micro-Segmentation model is much more ideal as it focuses on securing vulnerable network zones rather than the entire ecosystem.
These “zones” or “segments” are protected by Next Generation Firewalls (NGFWs) or special purpose gateway devices. The result is a series of protected segments granting or denied asset access through multiple PEP gateways.
ZTA variation 3 - Network Infrastructure and Software Denied Perimeters
In this variation, the network structure is modified to implement a ZTA, usually at layer 7. Once integrated the PA controls the network based on the decisions made by the PE.
In this setup, all network requests pass through a single PEP governed by a PA before they’re either permitted or denied access to enterprise resources.
ZTA variation 4 - Device agent or gateway-based deployment
In this variation the PEP is split into two parts - one resides on an asset and the other in front of a resource. This setup is typically implemented in a remote work setup.
For example, an employee issues a request to connect to a resource via a company-issued laptop. This request is facilitated through an agent (usually a software component). The laptop then connects with the Policy Administrator which then verifies access through the Policy Engine.
The Policy Administration and Policy Engine could either be a cloud service (client-server implementation of the Cloud Security Alliance) or a local asset. If the Policy Engine permits the request, the Policy Administrator activates the relevant resource gateway and a completed connection is established.
How to Implement a Zero Trust Architecture (ZTA)
The implementation of a ZTA framework can be summarized by three stages:
- Stage 1 - The verification of all users
- Stage 2 - The verification of all user devices
- Stage 3 - The verification of all access privileges.
Users need to pass all three layers of authentication to be labeled as trustworthy. Besides making it exceedingly difficult for threat actors to access sensitive data, a ZTA also makes it possible to track cybercriminals that attempt an attack by forcing them to meet compliance standards upon entry.
Organizations without a security framework can implement a pure ZTA solution. Existing frameworks can adopt a hybrid ZTA perimeter to integrate ZTA solutions, avoiding a competitive (and costly) overhaul.
A Zero Trust Architecture can be implemented in 7 steps
Step 1 - Identify all users
An organization needs to be aware of all network users at all times. Each event should be logged and compared against the details of approved users.
logged and compared against the details of approved users.
Approved user details should include the following:
- Names of approved users and their permitted functions
- Identities of all Non-Person Entities and their permitted functions
It’s important to understand that this step is an ongoing effort. In a ZTA framework, the identity of users is continuously verified throughout the entire access lifecycle.
Step 2 - Identify enterprise assets
Monitoring asset access starts with identifying all of the enterprise resources within your network. An up-to-date record should be maintained of all assets and their access protocols.
Network assets could include the following:
All internal and external end-points
- Employee laptops (especially remote employees)
- Mobile devices
- Internet of Things (IoT) devices
- Third-party devices
All software solutions
- Internal software
- Remote collaboration software
- Third-party vendor software
- Internal and external user accounts
With all assets identified, their access can be monitored and controlled. Multi-Factor Authentication (MFA) should ideally be implemented on all assets, where this isn’t possible, other forms of asset authentication should be used.
A detailed asset log should be regularly updated to document all authenticated asset connections, a list of asset updates, and any other asset changes.
Step 3 - Identify all network processes
No established connections in an FTA ecosystem should be a surprise, they should all be permitted and, therefore, expected.
All connections should be logged and categorized by their respective privileged access levels. The potential risks associated with each process should be known. This will support efficient resource monitoring allocation - high-risk processes require a greater depth of monitoring than lower risk processes.
Logged processes could include:
- Workflows
- Data flow
- Protocols
- Structured events
Step 4 - Draft ZTA policies
Now that all potential network activity has been identified, the rules governing these activities should be created, also known as Zero Trust policies.
ZT policies are a set of whitelist rules. They specify the criteria of authorized users and the specific resources they can access. All network traffic that doesn’t meet Zero Trust policies is blocked by a firewall.
The list below outlines all of the questions a Zero Trust policy should clearly answer and some examples of entities that could be used to answer them.
Who can access a given resource?
- User IDs.
- User authentication process, such as Multi-Factor Authentication (MFA).
- Host Information Profiles (HIPs) to block unauthorized users from accessing specific resources.
What applications are used to access resources?
- List all permitted applications by creating an application-based Layer 7 policy.
When do users access resources?
- Access schedules should be created for resources during certain hours. This policy is important to enforce because cyberattacks tend to occur outside of business hours to evade detection.
Where is each resource located?
- Specify the location of each resource. This will enable you to restrict access based on geolocations.
Why is the data accessed?
- Every user should have a convincing reason for accessing each resource. Knowing the “why” will help you plan the degree of protection each resource requires.
How is each resource accessed?
- Enforce endpoint encryption
- Implement the Principle of Least Privilege
Step 5 - Produce Zero Trust solutions
In this step, all policy documents are transformed into tangible plans. Ideally, multiple solutions should be created and then filtered down to the most efficient options.
The selection criteria could include the following:
- Implementation time
- Number of components that require installation
- Geolocation effects on efficacy
Step 6 - Deploy Zero Trust solutions
Now the ZTA solutions can finally be implemented. Solutions should initially be introduced to a small architecture subset and only scaled after achieving desired results.
All deployed Zero Trust solutions need to be monitored to identify issues and continuously optimize integrations. Because this is the first implementation of a Zero Trust Architecture, there should be stricter enforcement of policy conditions than after a complete rollout.
This will help organizations accommodate for worst-case scenario issues, giving them the highest chances of smoothly running a Zero Trust Architecture when it’s completely implemented.
Step 7 - Scale the Zero Trust Framework
With the ZT solutions proven to work on a test subset, the framework can now be rolled out to the entire organization.
Policies are designed and then created for each new ecosystem segment. A ZT solution is created and tested on a small subset of that segment and then rolled out to the entire segment.
After each cycle, new surfaced issues should be documented and immediately resolved to optimize efficiency.
