This is the second in a 4-part series of blogs covering the end-to-end aspects of zero trust.
Find the others here:
Blog 1: Adopting a Zero Trust Mindset
Blog 3: Instrumenting for Zero Trust
Blog 4: Operating for Zero Trust
Architecting for Zero Trust
Once organizations are on-board with the commitment to evolve their cybersecurity strategy towards one that increasingly enforces zero trust concepts, there is need to better understand what a "to be" zero trust architecture looks like. As discussed in the first blog, adopting a zero trust mindset must be followed by an organization-specific plan designed to gradually and purposefully move toward a mature or optimal zero trust cybersecurity implementation. The right plan will consider the organization's current enterprise cybersecurity posture and technologies, cybersecurity resources, high value IT assets, tolerance for risk, regulatory requirements, and organizational mission and objectives. Once established, the organization is ready to turn their zero trust vision into reality - which begins with a deeper look at the enterprise-wide network and cybersecurity architecture.
Why does Architecture Matter?
Why bother with an effort around architecture when IT teams can buy and deploy any number of tools to chip away at improving cybersecurity posture? Critically, because any tool deployed in a poorly designed, inadequately architected enterprise system will struggle to deliver the value they promise - leaving IT teams with limited potential to mature their systems along an achievable zero trust roadmap. As discussed on part 1, Zero Trust relies heavily on integration to achieve a defensible security architecture. This requires careful planning and well-defined security outcomes that are aligned to business goals. This is essentially what a security architecture provides.Failing to architect holistically for zero trust will result in a Whac-A-Mole and incomplete approach to cyberdefense, an inevitably, in an "indefensible security architecture". On the flip side, a well architected system will be equipped with the right building blocks for zero trust - laying the foundation on which zero trust solutions and supporting policies can incrementally improve, expand, adjust, and evolve, as business requirements continue to change. Said differently, teams can implement tools and technologies that improve various components of zero trust in isolation, but a solid understanding of zero trust architectural core components is required to realize the full benefit of this new and effective approach to cyberdefense.
Architecture Guidance from the Government
Given the government's commitment to improving the nation's cybersecurity also covered in the first blog in this series (ref Executive Order (EO) 14028, "Improving the Nation's Cybersecurity" and OMB's "Federal Strategy to Move the U.S. Government Towards a Zero Trust Architecture"), not to mention the many ZTA principles now baked into compliance standards like National Institute of Standards and Technology (NIST) SP 800-53, FISMA and FedRAMP baselines - getting on board with zero trust is no longer optional. Thankfully, the government has invested heavily in efforts to provide guidance for organizations and IT teams committed to the principles of zero trust - including architectural guidance. The National Cybersecurity Center of Excellence (NCCoE) team at NIST has recently published an updated Zero Trust Reference Architecture as part of their special publication on Implementing a Zero Trust Architecture (NIST SP 1800-35B). Given NIST is a U.S. government agency that leads efforts to advance measurement science, standards, and technology - federal employees and contractors supporting the secure operation of government IT systems or systems leveraged by government agencies should minimally familiarize themselves with this publication. The following diagram is a general zero trust reference architecture that highlights core components associated with zero trust implementations.
Figure 1 - NIST's Zero Trust Reference Architecture
ZTA Core Components
The core components presented in NIST's ZTA reference architecture (Policy Decision Point(s), Policy Information Points, Policy Enforcement Point(s), Policy Engine(s), and Policy Administrator(s)) are purposefully designed and positioned within the system to enable IT teams to implement and manage zero trust environments. Together these core components can be leveraged by organizations to implement and manage increasingly granular control that considers identity, context, organizational resource, and data to name a few. Remember, zero trust rejects the idea that perimeter security or granting blanket trust to "insiders" is adequate enough, pushing the concept of least-privilege access to a highly granular level. This requires a system to have deeply embedded policy management components throughout. Combined with thoughtful network macro and micro segmentation, granular control for system and session access protects each system's data and high value assets from potentially malicious outsiders and insiders alike.
Intertwined with the core ZTA components in the reference architecture are Subjects and Resources, representing the actors requesting/requiring access and the corporate resources they are requesting access to respectively. These put the components in context of generic system sessions and transactions.
- Subjects: Subjects may be devices, end users, applications, servers, and other non-human entities that request information from resources. Human subjects (i.e., users) are authenticated. Non-human subjects are both authenticated and protected by endpoint security.
- Resources: Resources refers to enterprise resources (e.g., data, applications, corporate services) that may be located on-premises or in the cloud, representing all that needs to be secured, protected, and judiciously made available to subjects in a least-privilege manner.
Understanding Each Core Component
Each of the following core components plays a specific role in the protection of a system's data, and work together in a configured/coordinated fashion to do so.
Policy Decision Points (PDP)
A Policy Decision Point (PDP) makes decision about whether or not to permit a subject to access a resource. A PDP consists of the combined activities of the PE and PA functions, meaning the PDP owns the decision making and administration of those decisions within a ZTA environment. Many zero trust systems leverage the PE and PA capabilities inherent in identity, credential and access management (ICAM) technologies.
Policy Engine (PE)
A Policy Engine (PE) handles the ultimate decision to grant, deny, or revoke access to a resource for a given subject - delivering continuous trust evaluations in a ZTA environment. The PE calculates the trust scores/confidence levels and ultimate access decisions based on enterprise policy and information from supporting components. The PE executes its trust algorithm to evaluate each resource request it receives.
Policy Administration (PA)
A Policy Administrator (PA) executes the PE's policy decision by sending commands to the Policy Enforcement Point (PEP) to establish and terminate the communications path between the subject and the resource. It generates any session-specific authentication and authorization token or credential used by the subject to access the enterprise resource. While the PE makes and logs access decisions, the PA is responsible for enforcing those decisions.
Policy Enforcement Points (PEP)
The Policy Enforcement Point (PEP) is a data plane component and guards the trust zone that hosts one or more enterprise resources. Once the PEP receives an access request, the requestor is authenticated through the PA and authority is dynamically determined. The PEP handles enabling, monitoring and eventually terminating connections between subjects and enterprise resources. It operates based on commands it receives from the PA. Note that highly distributed systems which are very common in government and large corporations may require multiple PEPs to protect resources in different locations. Multiple PEPs may also be implemented to support load balancing.
Policy Information Points (PIP)
Policy Information Points (PIP) collect and deliver important information derived through telemetry and logs generated by supporting components in a system. Supporting components include technologies and capabilities that each contribute uniquely to establish maturity across CISA's (Cybersecurity and Infrastructure Security Agency) zero trust support pillars and cross-cutting capabilities discussed in Blog 1 of this series. The information gleaned from PIP supporting components is used to inform ZTA policy and policy enforcement.
ICAM - Identity, Credential and Access Management
Identity is at the heart of access control. The ICAM component includes the strategy, technology and governance for creating, storing, and managing subject (e.g., enterprise user) accounts and identity records and their access to enterprise resources. Cloud solutions consumed by government agencies are required to use multi-factor authentication as a part of FedRAMP baseline requirements, with some systems going so far as requiring a hard token (e.g., PIV card, CAC card, Yubikey) as a part of their authentication process. Identity has been referred to as the "new perimeter" in the era of zero trust - and is a key consideration for determining and ultimately implementing least-privilege access rights throughout a system.
EDR/EPP - Endpoint Detection & Response/Endpoint Protection Platform
The endpoint protection component includes the strategy, technology and governance to protect endpoints (e.g., servers, desktops, mobile phone, IoT devices and other non-human devices) and their data from threats and attacks as well as protect the enterprise from threats from managed and unmanaged devices. Some devices may have ZTA agents installed, while others may be agentless. Host firewalls, malware protection, and consistent vulnerability scanning on endpoint software are some examples of solutions that satisfy parts of this component - with an increasing interest in extended detection and response (XDR) solutions that bring some elements of automation to the area of endpoint protection - automation being another zero trust capability described by CISA.
Security Analytics
The security analytics component encompasses all the threat intelligence feeds and continuous traffic/activity monitoring for a hybrid enterprise environment. This component gathers security and behavior analytics about the current state of enterprise assets and continuously monitors those assets to actively respond to threats or malicious activity. This information can be used to inform the policy engine (PE), helping make dynamic access decisions. Analytics (combined with visibility) is also a fundamental ZTA component that cross-cuts CISA's zero trust pillar model. Most government and commercial organizations have existing tools that support security analytics to some degree (network detection and monitoring, traffic analysis, vulnerability scanners, and SIEM log analysis tools to name a few) - but it's also likely they may not be fully leveraging the tools in their stack or benefitting from all of the tools' capabilities.
Data Security
The data security component includes the policies an enterprise needs to secure access to enterprise resources, as well as the means to protect data at rest and in transit. Data security is a high priority item for government and commercial entities alike, with the government requiring FIPS-validated encryption for all data in transit and at rest in any systems that process federal data. Teams will need to consider capabilities including but not limited to data discovery, classification and labeling, encryption, integrity, availability, access protection, and audit and compliance as a part of this component.
While there are many components that constitute an enterprise-wide IT system, the ZTA core components are defined specifically to deliver the granular access and management capabilities required for optimal zero trust implementations.
It should be noted that each of the core components do not necessarily directly correlate to physical hardware or software element. In fact, while the simplicity of the architecture might lead readers to believe that the supporting components are simple plug-ins that respond in real-time to the PDP, in many cases the PIP supporting components (ICAM, EDR/EPP, security analytics, and data security) will each represent complex infrastructures and suites of tools and technologies working in an integrated way through automation and orchestration. Some ZTA logical component functions may be performed by multiple hardware or software components, or a single software component may perform multiple logical functions. Understanding each component, the work it does and the purpose it serves must precede analysis of and decisions about specific tools and technologies used to instrument and configure an environment for zero trust.
What Comes Next? A Plan to Implement...
Among several measures, EO 14028 actually requires all federal civilian agencies to establish plans to drive adoption of ZTA. Reaching the point in a zero trust journey where an organization has defined a reference architecture that works for their operations - the implementation plan is right around the corner. Implementation, along with the zero trust architecture, will be a part of the organization's broader cybersecurity improvement plan. The implementation portion of the plan will require teams to begin mapping existing/legacy tools and capabilities against the target architecture to gain clarity around what they have to work with and identify significant gaps in their enterprises where new capabilities need to be acquired.
Post-architectural development plans should include a validation that the enterprise-specific zero trust architecture contains the right ingredients and is aligned with the use cases and mission of the organization being served. All organizations and government agencies have unique risk tolerances and cybersecurity needs specific to their missions, so teams must ensure the system is architected to provide protection that is appropriate for the information it processes/contains and the business it supports. For those supporting government IT systems that are required to adhere to standards and regulations like FISMA, FedRAMP, CMMC, or DoD ILs (DoD's FedRAMP Plus authorization), those additional baseline requirements will also need to be taken into consideration as a part of the zero trust-centric strategic cybersecurity improvement plan. Understanding the basic architectural components presented in this blog should help IT and security teams realize their zero trust objectives are within reach and identify the right use of core components - paving the way for incremental but well-orchestrated movement along the zero trust path.
More to come! Look for Blog 3 in this zero trust series, "Instrumenting for Zero Trust," which will focus on the technologies and tools that can be used to implement them.
Grow You Zero Trust Competencies with SANS
SANS is pleased to offer a 6-day course to equip participants with skills and knowledge to translate the concept of zero trust into actionable steps. Acquired skills will aid in building a robust security infrastructure, layer by layer, across hybrid environments, as you embark on a journey towards Zero Trust.
Course: Defensible Security Architecture and Engineering: Implementing Zero Trust for the Hybrid Enterprise 36 CPEs
This course is designed to help students establish and maintain a holistic and layered approach to security, while taking them on a journey towards a realistic 'less trust' implementation, based on Zero Trust principles, pillars and capabilities. Effective security requires a balance between detection, prevention, and response capabilities, but such a balance demands that controls be implemented on the network, directly on endpoints, and within cloud environments. This course will help your organization:
- Identify and comprehend deficiencies in security solutions
- Design and Implement Zero Trust strategies leveraging current technologies and investment
- Maximize existing investment in security architecture by reconfiguring existing technologies
- Layer defenses to increase protection time while increasing the likelihood of detection
- Improved prevention, detection, and response capabilities
- Reduced attack surface
For course details: https://www.sans.org/cyber-security-courses/defensible-security-architecture-and-engineering/
About SANS
SANS empowers cyber security professionals with the practical skills and knowledge they need to make our world a safer place through high quality training, certifications, scholarship academies, degree programs, cyber ranges, and resources to meet the needs of every cyber professional. Our data, research, and the top minds in cybersecurity collectively ensure that individuals and organizations have the actionable education and support they need.
