Danna Bethlehem | Director, Product Marketing
Zero Trust architectural principles
In one of my previous blog posts, Zero Trust 2.0: NIST’s identity-centric architecture, I discussed the three approaches to implementing a Zero Trust architecture, as described in the NIST blueprint SP 800-207.
These security approaches need to be supported through foundational components and functions, and should be based on key overarching principles to ensure the implemented architecture effectively meets new requirements.
These architectural principles include:
- Comprehensive identity management. All access subjects should be identified, including people, devices, etc.;
- Application-level access control. The access should be evaluated at the application layer, rather than at the network layer;
- Adaptive trust. The trust level is evaluated based on attributes, behaviors and context. The access authority is dynamically and automatically adjusted in real time based on the trust level;
- Adapt to business scenarios. It is necessary to design the Zero Trust architecture based on actual business scenarios and security conditions. And the architecture should be adaptable and scalable to meet future security requirements;
- Adapt to all access scenarios. Zero Trust architecture should cover all possible access scenarios, like users accessing resources, API calls, requests from mobile and IoT devices, and a variety of deployment locations; and,
- High interaction between components. The components of Zero Trust should have great interactivity to mitigate all kinds of threats and to form a secure barrier to threats.
Core Zero Trust architecture components
The NIST SP 800-207 describes the logical components that make up a Zero Trust architecture deployment in an enterprise, which are displayed in the figure below.
Figure 1: Zero Trust Architecture Core Components. Source: NIST SP 800-207
The Zero Trust logical components use a separate control plane to communicate, while application data is communicated on a data plane.
Policy Enforcement Point. The Policy Enforcement Point (PEP) is a data plane component. It is the gateway to secure access for corporate resources, where the adaptive access control capability is enforced. After the PEP intercepts the access request, the requestor is authenticated through the Policy Administrator (PA) and authority is determined in a dynamic way. Only access requests that are authenticated and authorized are deemed trustworthy and allowed to gain access to corporate resources. All trusted access to resources is encrypted.
Policy Administrator. This component is responsible for establishing and/or shutting down the communication path between a subject and a resource (via commands to relevant PEPs). The PA component is linked to the PEP to authenticate and dynamically authorize all access requests based on policy decisions by the Policy Engine (PE). The authorization is based on context attributes, trust levels and security strategies. If the session is authorized and the request authenticated, the PA signals the PEP to allow the session to start. Otherwise, the session is denied, and the PA directs the PEP to shut down the connection.
Policy Engine. The PE is the core component to implement the capability of continuous trust evaluation in a Zero Trust architecture. As mentioned above, the PE is linked with the PA to provide trust level assessment for authorization decision. The PE combines behavioral analytics, external threat intelligence, enterprise security policy, regulatory requirements and identity and authority baselines to evaluate and generate access decisions (grant, deny or revoke access). While the PE makes and logs the access decision, it is the PA that enforces this decision.
Essential external functions
As we have discussed above, for the PE to reach to an access decision, the input of data from various external sources is required. Although these sources are not the core components of a Zero Trust architecture, they are essential to the effectiveness and efficiency of Zero Trust. These can include:
Continuous diagnostics and mitigation (CDM): This component provides the required visibility into the status of the corporate resources, and applies updates to configuration and software components. The CDM system informs the PE on the security posture of the asset making the access request. CDM systems are also responsible for identifying and potentially enforcing a subset of polices on privately-owned devices operating within the enterprise infrastructure, enhancing the trust level of Bring Your Own Device (BYOD).
Industry compliance: Ensures the compliance of corporate policies with regulatory security requirements. Such regulations include HIPAA, PCI DSS, GDPR, CCPA and others as applicable.
Threat intelligence: Provides information from internal or external sources about newly discovered attacks or vulnerabilities that help the PE make dynamic and adaptive access decisions.
Network and system activity logs: Aggregates asset logs, network traffic, resource access actions, and other events that provide real-time (or near-real-time) feedback on the security posture of enterprise information systems.
Data access policies: These define the attributes, rules, and policies about access to enterprise resources. These policies form the foundation for authorizing access to a resource as they provide the basic access privileges for accounts and applications/services in the enterprise. These policies should be mission tailored to accommodate organizational needs.
Enterprise public key infrastructure (PKI): This system is responsible for managing the lifecycle of digital certificates (X.509) issued by the enterprise to resources, subjects, services and applications.
Identity management: This is responsible for creating, storing, and managing both enterprise user accounts and identity records and federated non-enterprise, partner accounts. This system contains the necessary subject information (e.g., name, email address, certificates) and other enterprise characteristics such as role, access attributes, and assigned assets.
Security information and event management (SIEM): This collects security-centric information for later analysis to refine policies and warn of possible attacks against enterprise assets.
Trust in a Zero Trust partner
SafeNet Trusted Access is the starting point for effective Zero Trust security implementations, addressing specific principles, including:
- Access decisions are enforced dynamically at the application access point, irrespective of where the app or user resides, what device users use and network routing;
- Access decisions are aided by updated inputs from third-party network security vendor technologies such as VPNs, WAMs, WAFs, SASE etc.; and,
- Access decisions adhering to a ‘default deny’ stance are continuously reassessed even if Single Sign On (SSO) features are enabled.
Zero Trust security concepts allow organizations to grow securely in the cloud and adjust to borderless and dispersed environments. SafeNet Trusted Access meets these needs by ensuring a ‘trust no one, verify everywhere’ approach through its ability to continuously protect applications and services at the access point, regardless of the underlying network deployed.
For more information on NIST’s Zero Trust guidelines, read Meeting NIST Guidelines for Zero Trust Security