Zero Trust Architecture
Zero Trust Architecture
TLDR: For Zero Trust every user, device, and system must prove its legitimacy every time it requests access to company resources (such as logging into email or cloud accounts). Zero trust architecture forces checks on device health, location, and behavior before granting access to login. This prevents unknown devices from accessing company resources.
According to NIST SP 800-207 “Zero trust assumes there is no implicit trust granted to assets, or user accounts based solely on their physical or network location”. Traditionally, we would secure company networks using physical firewalls. Think of a firewall as a box at the edge of your network, sort of like the front door. However, when your users are collaborating on documents stored in the cloud, the need for users to “connect” to the corporate network becomes obsolete. We can no longer consider a physical location as trusted, we needed a way to identify devices regardless of the network and enforce controls upon them. This is where Zero Trust (ZT) comes from. ZT attempts to solve this by forcing devices to be known in order to grant access to a resource. Now, “Zero trust architecture (ZTA) uses zero trust principals to plan industrial and enterprise infrastructure and workflows”. So as we build new network infrastructure into and beyond 2025, ZTA is the new gold standard for network and endpoint security.
How does zero trust work?
TLDR: Zero trust architecture works by having a system in place that says YES or NO when a user requests a login to company resources such as email, cloud resources like Salesforce or HubSpot, or before opening specific applications from a device that meets specific requirements.
ZTA: Core Zero Trust Logical Components. Source: NIST SP 800-207
Let’s try to break down Zero Trust (ZT) from ZTA, both equally important.
Zero Trust Architecture (ZTA) has as few core components required to make the ecosystem work.
- Policy Engine and a Policy Administrator: This is what will determine when the endpoint should be allowed to access company resources or be considered “trusted”. It will also continually check the device to determine when it is no longer “trusted”. It must be paired with a policy administrator, which is the component that shuts down the communication between a resource and the device.
- Policy Enforcement Point: This is the system that will enable, monitor, and terminate an endpoint to a enterprise resource. For the DUO ecosystem example, this is an agent. However, for other ecosystems it might be a gateway.
The other pieces in the diagram are important, but they sometimes overlap with other enterprise systems that might already be in use in your infrastructure.
- SIEM System, which collects, displays, and stores logs from various sources for analysis. This piece is typically an add-on in the form of an agent.
- PKI is going to generate and log certificates issued to enterprise resources, services, and applications.
- ID Management is going to manage user accounts and identity records. We can also refer to it as the Identity Provider (IDP). Common ones are Entra, formally Azure AD, or Duo SSO, or Okta, or Google Workspace.
- Threat Intelligence is exactly what it sounds like, information that feeds the policy engine about vulnerabilities or attacks.
- Continuous diagnostics and mitigation (CDM): This is the information about the current state and configuration or software requirements needed for the PEP to say, YUP TRUSTED. For example, your PC might need to be on Windows 11, or need to be patched.
- Industry Compliance System: So for regulated industries, this is policy rules or security requirements that the endpoint must have enabled, such as full disk encryption.
- Data access policies: Policies and rules that are generated by the policy engine. These rules authorize accounts for applications and services within the enterprise.
ZTA has a lot of moving components and no two networks will have the same ZTA. Some networks might lack specific components and will still be able to function. The best place to start is at your Identity Provider. Your IDP is at the heart of authentication and access controls. Is it scalable for the cloud? Is there conditional access logic that can be applied to enforce a Policy Enforcement Point (PEP)?
Zero Trust and NIST Frameworks
Looking at the Risk Management Framework side, ZTA reduces the reliance on network perimeter defenses. Therefore, the same risk management framework should be followed. NIST Risk Management Framework (RMF) [SP800-37]
From the Privacy Framework side of the house, “Organizations will need to identify any possible risks associated with
intercepting, scanning, and logging network traffic [NISTIR 8062]”.
What kinds of zero trust architecture are there?
Cisco Duo | Duo Device Health
One of the most effective tools available today is Cisco Duo Device Health, part of Cisco’s broader Zero Trust Access Platform. Duo Device Health ensures that only secure, trusted, and compliant devices can access your systems, even before authentication happens. Duo constantly evaluates device health, ensuring compliance even after login.
Duo Device Health can deny access to devices that do not meet specific requirements, such as a firewall or bitlocker enabled.
How can zero trust help your business?
This approach drastically reduces risk because even if credentials are stolen or malware enters the network, Zero Trust segmentation and continuous authentication prevent it from spreading or doing damage. With tools like Duo Device Health, you can enforce Zero Trust or Zero Trust Architecture principles instantly.
Technical Information
TLDR; Zero trust architecture prevents unknown devices from gaining access to company resources based off of location, cybersecurity baselines, or authentication requirements.
Service Information
Technical Control
$$
DUO Device Health
Regulatory Information
23 CRR-NY 500.2
23 CRR-NY 500.12
23 CRR-NY 200.16
Frameworks
Zero Trust Architecture
New York, USA