Exposure reduction and zero trust
By the end of this module you will be able to:
- Explain the three core zero trust principles and how they differ from perimeter-based security
- Map the NIST SP 800-207 logical components to their functions in a zero trust architecture
- Apply CISA Zero Trust Maturity Model v2.0 to assess an organisation's current state
- Design a microsegmentation policy for a simple three-tier application
Real-world incident · December 2020
The attackers were already inside. The perimeter protected nothing.
In December 2020, FireEye disclosed that attackers had compromised the build system of SolarWinds Orion, a widely used IT monitoring platform. The attackers inserted a backdoor, later named SUNBURST, directly into the signed software update distributed to customers. More than 18,000 organisations installed the update, including the US Treasury, the Cybersecurity and Infrastructure Security Agency (CISA), and the Department of Defence.
Because the malicious code arrived as a digitally signed, vendor- issued update, it bypassed perimeter controls entirely. Once installed, SUNBURST lay dormant for up to two weeks before activating. It then used the existing Orion service account to authenticate inside the network and began surveying connected systems. VPN credentials issued to the monitoring platform gave lateral access to adjacent segments. The attackers moved through trusted internal networks for months before detection.
A zero trust architecture would not have prevented the initial compromise of the build server. It would, however, have constrained what SUNBURST could reach once active. If the Orion service account held only the minimum rights needed for monitoring, and if segment-to-segment traffic required explicit authorisation at each hop, lateral movement would have been detected or blocked long before the attackers reached sensitive systems.
SolarWinds customers had firewalls, antivirus, and VPNs. Why did none of that help?
SolarWinds illustrates the fundamental weakness of perimeter security: once an attacker is inside the wall, they can move laterally with few checks. Zero trust replaces implicit trust with continuous, explicit verification regardless of where a request originates.
With the learning outcomes established, this module begins by examining 18.1 the perimeter model and its failure in depth.
18.1 The perimeter model and its failure
The traditional security model treats the network boundary as a castle wall. Traffic originating outside is suspect; traffic originating inside is trusted. A VPN acts as the drawbridge: it lowers entirely for authenticated users, granting broad internal access once the credential check passes. The castle-and-moat analogy held when employees worked from a fixed office, all applications lived on-premises, and attackers operated externally. None of those conditions reliably hold today.
Supply chain attacks, credential theft, and insider threats all originate from within the perimeter or arrive with valid credentials. When the perimeter is the only control, a single breach of it grants an attacker the same implicit trust as a legitimate employee.
Common misconception
“A VPN keeps us secure.”
A VPN creates an encrypted tunnel between the endpoint and the corporate network. Once connected, most implementations grant broad internal access based on the user's group membership. An attacker with stolen VPN credentials inherits that access immediately. The VPN authenticates the credential, not the intent or the device state.
Common misconception
“Zero trust requires replacing all existing network infrastructure before any benefit is realised.”
CISA's Zero Trust Maturity Model v2.0 defines four maturity stages (Traditional, Initial, Advanced, Optimal) precisely to enable incremental adoption. Meaningful risk reduction begins at the Initial stage, achievable without replacing infrastructure: enforce MFA on all privileged access (one of the highest-value identity controls), deploy a cloud access security broker to enforce policies on SaaS applications, and implement conditional access policies requiring compliant device state. Each step reduces implicit trust and improves visibility independently of the others. Treating zero trust as an all-or-nothing programme is the most common reason organisations do not start.
With an understanding of 18.1 the perimeter model and its failure in place, the discussion can now turn to zero trust principles, which builds directly on these foundations.
18.2 Zero trust principles
Zero trust is built on three core principles that collectively dismantle implicit trust:
- Never Trust, Always Verify: every request must be authenticated and authorised at the time it is made, regardless of whether it originates inside or outside a network boundary.
- Assume Breach: design systems as though attackers are already present, so that a successful entry does not grant unrestricted movement.
- Least Privilege Access: grant only the minimum rights needed for the specific task, scoped to the shortest duration necessary.
Together these principles shift security from a one-time perimeter check to continuous, contextual evaluation. The SolarWinds Orion service account had far broader rights than monitoring required. Least Privilege would have limited what SUNBURST could do even after it activated.
“Zero trust is not a product, a technology, or a simple on/off switch.”
CISA - Zero Trust Maturity Model v2.0, p.1
CISA's framing is deliberate: zero trust is a strategy and a set of principles, not a vendor product category. Organisations that treat it as a checkbox purchase will achieve neither the security nor the maturity the model requires.
“Zero Trust Architecture assumes no implicit trust is granted to assets or user accounts based solely on their physical or network location. Authentication and authorisation are discrete functions performed before a session is established to an enterprise resource.”
NIST SP 800-207: Zero Trust Architecture, Section 2 (2020) - Section 2.1
NIST SP 800-207 defines the logical components of a zero trust architecture: the Policy Engine, Policy Administrator, and Policy Enforcement Point. These three components together make every access decision explicit and auditable, replacing the implicit trust a perimeter firewall grants to all internal traffic.
Google's BeyondCorp initiative, launched internally in 2009 and published in 2014, is the canonical reference implementation. Rather than placing employees on a trusted corporate VPN, Google moved every application to the public internet and required per-service authorisation based on device state and user identity. By 2017, the majority of Google employees worked without a VPN. BeyondCorp demonstrated at scale that zero trust is operationally viable for large enterprises.
With an understanding of zero trust principles in place, the discussion can now turn to 18.3 nist sp 800-207 architecture, which builds directly on these foundations.
18.3 NIST SP 800-207 architecture
NIST SP 800-207 defines three logical components that together implement a zero trust access decision. The Policy Engine (PE) is the brain: it evaluates all available signals and produces a grant or deny decision. The Policy Administrator (PA) acts on that decision by issuing or revoking credentials and session tokens. The Policy Enforcement Point (PEP) sits between the subject and the resource, intercepts every request, and enforces whatever the PA communicates.
A request flows as follows: a subject (a user, service, or device) makes a request; the PEP intercepts it and forwards context to the PA; the PA consults the PE; the PE evaluates the trust algorithm inputs and returns a decision; the PA instructs the PEP to allow or block. The trust algorithm draws on device posture, user identity, behavioural analytics, and request context. No single factor is sufficient on its own.
With an understanding of 18.3 nist sp 800-207 architecture in place, the discussion can now turn to 18.4 cisa zero trust maturity model v2.0, which builds directly on these foundations.
18.4 CISA Zero Trust Maturity Model v2.0
CISA's Zero Trust Maturity Model v2.0 organises zero trust adoption across the following pillars, each assessed against four maturity stages: Traditional, Initial, Advanced, and Optimal.
- Identity
- Devices
- Networks
- Applications & Workloads
- Data
The model provides a structured path for organisations to incrementally improve their posture rather than attempting a wholesale replacement of existing infrastructure. Most organisations assessed against CISA ZTMM sit at the Initial stage. Reaching Optimal requires mature automation, continuous monitoring, and policy-as-code. The diagram below is interactive: click each pillar to see what each stage looks like in practice.
With an understanding of 18.4 cisa zero trust maturity model v2.0 in place, the discussion can now turn to microsegmentation, which builds directly on these foundations.
CISA recommends treating the maturity stages as a journey rather than a destination. Organisations that attempt Optimal across all pillars simultaneously typically stall. A phased approach that drives one pillar to Advanced before moving to the next sustains momentum and produces measurable security outcomes within each planning cycle.
18.5 Microsegmentation
Microsegmentation divides a network into small zones, each governed by its own access policy. Unlike traditional macro-segmentation (VLANs or a single perimeter firewall), microsegmentation controls east-west traffic between internal services as strictly as it controls north-south traffic between users and servers.
In a three-tier web application, the principle is straightforward in its intent: the payment database should be reachable only from the payment service, not from the web tier or from any monitoring agent beyond what is explicitly required. An attacker who compromises the web tier should encounter a policy boundary before they can query the payment database, even though both reside inside the corporate network.
CISA recommends beginning microsegmentation with crown-jewel assets: the highest-value, highest-risk data stores and services. Attempting full network microsegmentation in a single phase overloads operations teams and produces fragile policy sets that are difficult to maintain. Starting with the most sensitive segments first delivers the greatest risk reduction per unit of effort.
In NIST SP 800-207, which component makes the grant/deny decision?
Which zero trust principle is most directly responsible for limiting the blast radius of the SolarWinds attack?
A company has a firewall, but all internal servers can reach each other freely. In CISA ZT Maturity Model terms, their Network pillar is at which stage?
Key takeaways
- Perimeter security fails when attackers obtain valid credentials. Zero trust removes implicit trust and verifies every request explicitly.
- The three zero trust principles are Never Trust Always Verify, Assume Breach, and Least Privilege Access.
- NIST SP 800-207 defines three logical components: Policy Engine (decides), Policy Administrator (acts), and Policy Enforcement Point (enforces).
- CISA Zero Trust Maturity Model v2.0 assesses Identity, Devices, Networks, Applications and Workloads, and Data across four maturity stages: Traditional, Initial, Advanced, and Optimal.
- Microsegmentation limits east-west lateral movement. Start with crown-jewel assets rather than attempting full network coverage in one phase.
- Zero trust is a journey, not a product. Organisations that buy a 'zero trust appliance' without redesigning their identity and access policies have changed nothing except the vendor name on their firewall.
You now understand zero trust principles and how to reduce exposure. Modern workloads increasingly run in cloud and container environments with their own security models. What changes when your infrastructure is someone else's responsibility? Module 19 covers runtime and cloud security.
Standards and sources cited in this module
NIST SP 800-207, Zero Trust Architecture
Section 2: Zero Trust Basics
The authoritative US federal definition of zero trust logical components (PE, PA, PEP) and trust algorithm.
CISA Zero Trust Maturity Model v2.0 (2023)
Pillars and Maturity Stages
Defines the five-pillar, four-stage maturity model used for assessing zero trust adoption.
Target Level Zero Trust Activities
US Department of Defense implementation roadmap for zero trust, with 91 target-level capabilities.
Google BeyondCorp Research Series
Ward et al., 2014: Design to Deployment
Describes Google's internal implementation that replaced VPN with per-service authorisation, the reference architecture for enterprise zero trust.
US Senate Select Committee on Intelligence: SolarWinds Report 2023
Findings on lateral movement
Provides the authoritative account of how SUNBURST exploited implicit trust after initial access.