Zero Trust, Secure Engineering and Policy as Code

Introduction

Modern data platforms rarely operate within a single, clearly bounded corporate network. Data may be distributed across cloud services, data centres, SaaS applications, employee devices, APIs, containers, and machine-learning pipelines. Users, workloads, and services can be both inside and outside an organisation’s traditional perimeter. Consequently, network location is no longer a reliable indicator of trust.

Zero Trust is a security architecture based on the principle that no user, device, workload, or network segment is inherently trusted. Access is granted only after explicit evaluation of identity, device or workload posture, requested resource, context, and policy. Verification continues throughout a session, and access is limited to the minimum necessary scope and duration.

This chapter connects Zero Trust with secure engineering, DevSecOps, continuous integration and delivery, infrastructure as code, policy as code, security testing, and vulnerability management. The emphasis is not on purchasing a particular product. It is on designing systems in which security decisions are explicit, testable, observable, and enforceable.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the principles and operating model of Zero Trust.
2. Design identity-centred access controls using continuous verification, least privilege, micro-segmentation, and just-in-time access.
3. Integrate security controls into software-development and CI/CD processes.
4. Distinguish infrastructure as code from policy as code and explain how they interact.
5. Select suitable security tests and vulnerability-management responses.
6. Evaluate governance, usability, privacy, resilience, and ethical implications of Zero Trust programmes.
7. Analyse a realistic implementation scenario and justify architectural decisions.

1. From Perimeter Security to Zero Trust

Traditional perimeter security assumes that a trusted internal network can be separated from an untrusted external network. Firewalls, virtual private networks, and gateway controls remain useful, but the assumption that internal traffic is safe is dangerous. Once an attacker compromises an endpoint, steals credentials, or enters through a supply-chain dependency, unrestricted internal access can enable lateral movement.

Zero Trust replaces the question “Where is the request coming from?” with questions such as:

• Who or what is making the request?
• Which resource is being requested?
• Is the request consistent with the user’s role and current purpose?
• Is the device or workload healthy and authenticated?
• What risk signals are present at this moment?
• What is the smallest permitted action and duration?

A useful conceptual model is:

Here, identity may represent a human, service, device, or workload; resource identifies the protected object; action describes the operation; context includes time, location, device state, and session information; risk is an evaluation of relevant threats; and policy determines whether the request is allowed. This is a conceptual model rather than a universal numerical equation. Its purpose is to show that access is a context-dependent decision, not a permanent property of a network location.

Zero Trust does not mean “trust nothing and block everything.” It means that trust is not assumed, access is explicitly authorised, and confidence is continually reassessed.

Core principles

The following principles are widely associated with contemporary Zero Trust practice:

2. The Zero Trust Policy Decision Model

A practical architecture separates policy evaluation from policy enforcement. A policy decision point evaluates a request. A policy enforcement point permits, denies, or constrains the request. A policy information point supplies attributes such as identity-group membership, device compliance, data classification, threat intelligence, and time of day.

For example, an employee may be allowed to read a low-sensitivity dataset from a managed laptop but denied access to a regulated dataset from an unmanaged device. A service account may be allowed to call a data-processing API only when its workload identity is valid and the request originates from an approved deployment environment.

Access decisions should be:

• Specific: They identify a subject, resource, action, and relevant conditions.
• Constrained: They limit scope, rate, data fields, and duration.
• Explainable: Administrators can determine why a request was allowed or denied.
• Auditable: The decision and important input attributes are recorded.
• Fail-safe: Failure of a critical authorisation dependency does not silently create broad access.
• Resilient: Essential business functions have carefully designed availability measures.

A deny-by-default posture is valuable, but it must be implemented with recovery and emergency procedures. An organisation that denies all access when an identity service is temporarily unavailable may protect confidentiality while creating unacceptable safety or operational risks. Availability requirements therefore belong in the policy design.

Authentication and authorisation

Authentication establishes or verifies identity. Authorisation determines what an authenticated identity may do. These functions must not be conflated. A successfully authenticated administrator should not automatically receive unrestricted access to every database.

Strong authentication commonly combines multiple factors, such as a cryptographic hardware key, a secret, or a biometric characteristic. For machine identities, short-lived certificates, workload identity tokens, and attested platform identities are generally safer than long-lived static secrets.

Authorisation models may include:

• Role-based access control: permissions are assigned to roles, and users receive roles.
• Attribute-based access control: decisions use attributes of subjects, resources, actions, and environment.
• Relationship-based access control: access depends on relationships, such as a clinician’s relationship to a patient record.
• Policy-based access control: a central or distributed policy expresses conditions and obligations.

Role-based access control is understandable and useful, but large organisations often experience role explosion. Attribute and relationship models can express finer-grained decisions, although they require reliable attributes, stronger governance, and more sophisticated testing.

3. Continuous Verification and Risk-Adaptive Access

Traditional access systems often authenticate a user once and maintain access for an extended period. Continuous verification treats a session as conditional. Relevant signals may include new device posture information, unusual geographic movement, excessive data downloads, malware indicators, token misuse, or a change in employment status.

Continuous verification does not require interrupting users every few seconds. It can involve silent reassessment, short-lived credentials, step-up authentication, reduced permissions, session termination, or additional approval when risk changes.

A simplified risk model can be represented as:

where R is a risk score, I represents identity-related risk, D device or workload risk, C contextual risk, B behavioural or activity risk, and w_i, w_d, w_c, and w_b are organisationally selected weights. This is a modelling aid, not a universal security law. Scores must be calibrated using evidence, tested for false positives and false negatives, and governed to avoid unjustified automated decisions.

A policy may use thresholds such as:

• low risk: permit the requested operation;
• moderate risk: require step-up authentication or reduce scope;
• high risk: deny, quarantine, or require human approval.

Risk scoring should not replace deterministic controls. A known prohibition—such as a legal restriction on exporting a protected dataset—should not be overridden merely because a numerical score is low.

4. Micro-Segmentation and Limiting Lateral Movement

Micro-segmentation divides an environment into small, policy-controlled security domains. Segments may be based on application identity, workload identity, data classification, environment, or business function rather than only IP address and subnet.

A typical analytics platform might separate:

1. Internet-facing ingestion services.
2. API and application services.
3. Data-processing workers.
4. Metadata and orchestration services.
5. Sensitive data stores.
6. Administrative management interfaces.
7. Development, test, staging, and production environments.

The desired result is not merely more firewalls. It is a reduction in unnecessary communication paths. A processing worker may read from an approved object-storage location and write to a specific results store, but it should not be able to initiate arbitrary connections to administrative systems.

Micro-segmentation can be implemented through cloud security groups, network policies, service meshes, identity-aware proxies, host firewalls, database controls, and application-level authorisation. The choice should reflect the resource being protected. Network segmentation alone cannot prevent an authorised application from returning excessive data through a valid API.

Segmentation design must account for dependencies, observability, performance, failover, and operational support. Overly complex segmentation may encourage administrators to create broad exceptions, undermining the original objective.

5. Just-in-Time and Just-Enough Access

Standing administrative privileges increase the impact of credential theft, insider misuse, and accidental error. Just-in-time access grants privilege only when needed, for a limited period, often after approval and additional authentication. Just-enough access limits the granted permission to the smallest useful set of actions.

A well-designed privileged-access workflow usually includes:

1. A defined business or operational reason.
2. Authentication with a strong factor.
3. Approval appropriate to the sensitivity of the action.
4. A narrow role or task-specific permission set.
5. An automatic expiry time.
6. Session recording or detailed audit logging where proportionate.
7. Post-activity review and revocation of temporary credentials.

For example, a data engineer investigating a failed production pipeline may receive read-only access to logs and metadata for 30 minutes. Write access to the production warehouse might require a separate, explicitly approved operation. Emergency access should be exceptional, monitored, and reviewed rather than becoming a permanent alternative path.

6. Secure Engineering and DevSecOps

Secure engineering integrates security into requirements, architecture, implementation, testing, deployment, operation, and retirement. DevSecOps extends DevOps practices by making security a shared responsibility supported by automation and feedback.

Security activities across the lifecycle include:

Security automation is valuable only when its results are actionable. A scanner that produces thousands of unprioritised findings may cause alert fatigue. Teams should define severity, exploitability, asset criticality, exposure, compensating controls, and remediation deadlines.

CI/CD security controls

A mature pipeline commonly performs the following checks:

• secret detection in source code and build artefacts;
• software composition analysis for open-source dependencies;
• static application security testing;
• dynamic application and API testing;
• infrastructure-as-code scanning;
• container image and operating-system package scanning;
• licence and provenance checks;
• policy validation before deployment;
• verification of signed artefacts and trusted build provenance.

A pipeline should distinguish between a blocking failure and an advisory finding. Blocking rules should be few, clear, risk-based, and tested. Exceptions require an owner, rationale, expiry date, and compensating control.

7. Infrastructure as Code and Policy as Code

Infrastructure as code (IaC) expresses infrastructure configuration—such as networks, storage, identity bindings, compute resources, and databases—in version-controlled files. IaC improves repeatability, reviewability, and recovery, but it can also reproduce insecure configurations at scale.

Policy as code expresses security, compliance, and operational rules in a machine-evaluable form. Examples include:

• storage must not be publicly accessible;
• production data must be encrypted at rest;
• deployments must use approved images;
• privileged permissions require an expiry;
• resources containing regulated data must be deployed only in approved regions;
• a service may communicate only with declared dependencies.

IaC describes what should be created. Policy as code evaluates whether the requested state or action is acceptable. The two should be connected in pull requests, build pipelines, admission controls, and runtime monitoring.

A policy should have a clear subject, target, condition, decision, and exception process. For example:

deny if
   resource.type = "object_storage"
   and resource.public_access = true
   and resource.data_classification in {"confidential", "regulated"}

This example is intentionally simple. Production policies require defined attribute sources, handling for missing values, test cases, versioning, and a documented response to legitimate exceptions.

Policy lifecycle

Policy as code should be managed like software:

1. Define the control objective in plain language.
2. Identify authoritative data sources and attribute owners.
3. Encode the rule and its scope.
4. Write positive, negative, boundary, and exception tests.
5. Review the change through version control.
6. Evaluate it in a non-production environment.
7. Deploy with version identification and rollback capability.
8. Monitor decisions, failures, overrides, and unintended effects.
9. Review the policy when technology, threats, or regulations change.

Policy testing must include missing and contradictory attributes. A dangerous implementation may treat an unknown value as permitted. For high-impact controls, “unknown” should normally produce a safe and reviewable outcome rather than silent approval.

8. Security Testing and Vulnerability Management

Security testing is a collection of complementary techniques, not a single scan. Static analysis examines source or intermediate code. Dynamic testing examines running systems. Dependency analysis identifies vulnerable or risky components. Penetration testing explores attack paths using human expertise. Configuration analysis checks deployed state. Threat modelling examines how a system could be misused before implementation.

Vulnerability management is a risk-management process:

1. Discover assets and dependencies.
2. Identify vulnerabilities and affected versions.
3. Validate findings and remove duplicates.
4. Prioritise according to exploitability, exposure, asset value, business impact, and available mitigations.
5. Remediate, mitigate, transfer, or formally accept the risk.
6. Verify that the response worked.
7. Report trends and overdue items.

A common prioritisation mistake is treating a severity score as the complete risk decision. A highly severe flaw in an isolated, non-production system may be less urgent than a moderate flaw in an internet-facing identity service. Context matters.

Useful measures include mean time to remediate, percentage of critical assets covered, age distribution of unresolved findings, recurrence rate, and percentage of deployed software with verified provenance. Metrics should not encourage teams to close findings without reducing risk.

9. Worked Application: A Zero Trust Data Platform

Consider the following illustrative case. Northstar Analytics operates a cloud-based platform that ingests customer events, processes them with distributed workloads, and provides dashboards to internal analysts. The organisation has experienced excessive standing privileges, inconsistent cloud configurations, and a compromised developer credential that enabled access to a production storage bucket.

Background and problem

The platform uses separate development and production accounts, but administrators share broad roles. A VPN provides network access to internal services. Production data is encrypted, yet one storage bucket permits overly broad access through a misconfigured identity policy. Vulnerability scanning occurs before major releases but not consistently for infrastructure changes.

The organisation’s objectives are to reduce lateral movement, prevent public or unauthorised data access, improve auditability, and preserve delivery speed.

Analysis

The principal weaknesses are not only technical. They include:

• network location being treated as evidence of trust;
• long-lived credentials and standing privilege;
• insufficient separation between deployment identity and human administration;
• policy variation across environments;
• incomplete evidence about who accessed which data and why;
• security testing occurring too late in the lifecycle.

Approach

Northstar adopts the following design:

1. Human users authenticate through a central identity provider with phishing-resistant multifactor authentication.
2. Workloads use short-lived federated identities rather than embedded cloud keys.
3. Production administration requires just-in-time access with a stated reason, approval, expiry, and audit trail.
4. Micro-segmentation permits only documented service-to-service paths.
5. Data stores receive classification labels, and access policies use both identity and classification.
6. IaC changes are reviewed through version control and checked by policy-as-code rules.
7. The CI/CD pipeline scans secrets, dependencies, images, application code, and infrastructure definitions.
8. Deployment requires signed artefacts and an approved provenance record.
9. Runtime monitoring detects unusual downloads, privilege escalation, and access from noncompliant devices.
10. Emergency access is separately controlled, time-limited, and reviewed after use.

A policy denies any production storage resource that is public, lacks required encryption, or permits access from an unapproved principal. A second policy prevents a deployment role from directly reading customer records; the running application receives only the narrowly scoped data access it requires.

Outcome

The organisation eliminates broad standing roles, catches an insecure storage configuration during pull-request review, and obtains clearer evidence for investigations. Deployment time initially increases because teams must define ownership and dependencies. After reusable modules and policy tests are established, delivery becomes more predictable. The programme does not eliminate all risk: compromised authorised applications, incorrect data classification, and policy defects remain possible. These risks are addressed through monitoring, testing, review, and incident response.

Learning points

The case demonstrates that Zero Trust is an operating model rather than a single access product. Identity, segmentation, policy, secure delivery, logging, and governance must reinforce one another. Automation improves consistency but can also amplify mistakes; therefore, policy changes require testing and accountable ownership.

10. Governance, Ethics, and Regulatory Considerations

Zero Trust produces extensive identity, device, activity, and access data. Such monitoring can support security and accountability, but it may also create privacy risks, especially when behavioural analytics are used to infer employee intent or trustworthiness.

Governance should address:

• purpose limitation and data minimisation;
• retention periods for access and session records;
• transparency about monitoring;
• lawful processing and regulatory obligations;
• access to, correction of, and protection for identity data;
• human review of high-impact automated decisions;
• segregation of administrative duties;
• documented exception and appeal processes.

Policy enforcement must avoid discriminatory effects. For example, geographic or behavioural signals may correlate with legitimate travel patterns, disability-related work arrangements, or regional workforce differences. Security teams should test controls for disproportionate false positives and provide appropriate recovery paths.

Regulatory frameworks differ by jurisdiction and sector, but common expectations include least privilege, access review, secure development, incident detection, auditability, data protection, and demonstrable risk management. Compliance should be treated as a constraint and source of assurance, not as a substitute for threat-informed engineering.

11. Limitations and Contemporary Developments

Zero Trust has important limitations. Identity systems can be compromised; attributes can be inaccurate; policies can contain logic errors; segmentation can be bypassed through application vulnerabilities; and excessive authentication friction can drive unsafe workarounds. Legacy systems may not support modern workload identity or fine-grained authorisation. Small organisations may lack the staff to operate a complex control plane.

Contemporary developments include:

• passwordless and phishing-resistant authentication;
• software and workload identity for cloud-native systems;
• confidential computing and hardware-backed attestation;
• software bills of materials and build-provenance verification;
• continuous authorisation for APIs and data services;
• identity-aware service meshes;
• automated detection of configuration drift;
• generative-AI-assisted code review and security analysis.

AI can help classify findings, identify anomalous access, generate test cases, and explain policy conflicts. However, AI-generated code and security decisions require human review, provenance, privacy protection, robustness testing, and resistance to prompt injection or poisoned training data. AI should augment accountable security engineering rather than become an unexamined authorisation authority.

12. Best-Practice Implementation Roadmap

A practical programme can proceed incrementally:

1. Establish scope and ownership: inventory critical data, applications, identities, and dependencies.
2. Strengthen identity: implement central identity, multifactor authentication, lifecycle automation, and workload identities.
3. Remove standing privilege: introduce role review, just-in-time administration, and short-lived credentials.
4. Map communication: document service dependencies and implement segmentation in high-value environments first.
5. Codify controls: write versioned policy-as-code rules and reusable IaC modules.
6. Shift security left: integrate scanning, threat modelling, and security tests into development workflows.
7. Improve runtime assurance: monitor decisions, configuration drift, unusual activity, and policy exceptions.
8. Measure outcomes: track reduced privilege, remediation effectiveness, coverage, incident containment, and user friction.
9. Exercise failure: test identity-provider outage, credential compromise, emergency access, rollback, and recovery.
10. Continuously improve: review controls against incidents, near misses, architectural changes, and emerging threats.

The roadmap should prioritise risk reduction rather than attempting a large-scale transformation without operational evidence. Pilot controls with a representative application, measure their effects, and then create reusable patterns for wider adoption.

Chapter Summary

Zero Trust treats every access request as conditional and requires explicit verification of identity, resource, action, context, and risk. Its principal practices are least privilege, continuous verification, micro-segmentation, just-in-time access, strong workload identity, and comprehensive evidence collection.

Secure engineering embeds security throughout the development and operational lifecycle. DevSecOps and CI/CD automation can detect secrets, vulnerable dependencies, insecure code, unsafe infrastructure, and unapproved artefacts before deployment. Infrastructure as code improves consistency, while policy as code makes security and compliance rules versioned, testable, reviewable, and enforceable.

Effective vulnerability management combines discovery, validation, contextual prioritisation, remediation, mitigation, verification, and reporting. Zero Trust programmes must also address privacy, governance, availability, usability, legacy integration, policy defects, and the risk of excessive automation. The central lesson is that security is strongest when architectural controls, engineering practices, organisational processes, and accountable governance operate as one system.

Key Terms

Zero Trust: A security model that assumes no implicit trust and verifies every access request.

Continuous verification: Reassessment of access conditions throughout a session or activity.

Least privilege: Granting only the permissions necessary for an authorised task.

Micro-segmentation: Dividing systems into small, policy-controlled communication domains.

Just-in-time access: Temporary privilege granted only when needed.

Just-enough access: Permission limited to the smallest useful scope of action.

Policy decision point: Component that evaluates an access request against policy.

Policy enforcement point: Component that permits, denies, or constrains a request.

Attribute-based access control: Authorisation using attributes of subjects, resources, actions, and context.

Workload identity: An identity assigned to a service, process, container, or other machine workload.

DevSecOps: Development and operations practice that integrates security into shared delivery workflows.

Infrastructure as code: Version-controlled, machine-readable definition of infrastructure.

Policy as code: Machine-evaluable representation of security, compliance, or operational policy.

Threat modelling: Structured analysis of assets, trust boundaries, threats, and mitigations.

Software composition analysis: Examination of dependencies for vulnerabilities, licences, and provenance.

Vulnerability management: The lifecycle of identifying, prioritising, treating, and verifying vulnerabilities.

Security exception: An approved deviation from a control, with rationale, ownership, expiry, and compensating measures.

Configuration drift: Unauthorised or unintended divergence between approved and deployed configuration.

Software provenance: Evidence describing how, where, and by whom software was built and supplied.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorisation?
2. Why is network location insufficient as a basis for trust?
3. Define micro-segmentation and state one benefit.
4. What is the purpose of just-in-time access?
5. Distinguish infrastructure as code from policy as code.

Long Answer Questions

1. Explain the major principles of Zero Trust and discuss how they alter traditional perimeter security.
2. Describe how continuous verification, risk signals, and step-up authentication can operate together.
3. Explain how security should be integrated across the software-development lifecycle.
4. Discuss the benefits and risks of using policy as code in cloud infrastructure.
5. Evaluate the governance and privacy challenges created by extensive identity and activity monitoring.

Analytical / Application Questions

1. Design a Zero Trust access model for a data lake containing public, confidential, and regulated datasets. Specify identities, policies, segmentation, monitoring, and emergency access.
2. A CI/CD pipeline reports a medium-severity dependency vulnerability in an internet-facing service and a high-severity vulnerability in an isolated development tool. Explain how you would prioritise and justify remediation.
3. An organisation’s policy-as-code system denies deployments whenever its identity attribute service is unavailable. Analyse the security and availability consequences and propose a safer design.

Multiple Choice Questions with Answers

Question 1

Which statement best expresses the central principle of Zero Trust?

A. All internal network traffic is trusted after VPN authentication.

B. Access is explicitly verified and continually evaluated.

C. Users should receive broad access to reduce administration.

D. Security decisions should be based primarily on IP address.

Correct Answer: B. Access is explicitly verified and continually evaluated.

Question 2

What is the primary purpose of micro-segmentation?

A. To increase the number of public endpoints.

B. To eliminate the need for identity management.

C. To limit unnecessary communication and lateral movement.

D. To replace all application-level authorisation.

Correct Answer: C. To limit unnecessary communication and lateral movement.

Question 3

Which practice most directly reduces standing administrative privilege?

A. Long-lived shared administrator passwords

B. Just-in-time access with automatic expiry

C. A larger internal network perimeter

D. Permanent membership in a global administrator role

Correct Answer: B. Just-in-time access with automatic expiry

Question 4

What does infrastructure as code primarily describe?

A. Machine-readable definitions of infrastructure resources and configuration

B. A database of employee performance reviews

C. A manual procedure for responding to phishing

D. A method for encrypting all source code

Correct Answer: A. Machine-readable definitions of infrastructure resources and configuration

Question 5

Which statement correctly distinguishes policy as code from infrastructure as code?

A. Policy as code evaluates rules, while infrastructure as code defines infrastructure state.

B. Policy as code is always executed manually, while infrastructure as code cannot be versioned.

C. Policy as code replaces authentication, while infrastructure as code replaces encryption.

D. Policy as code applies only to physical networks, while infrastructure as code applies only to applications.

Correct Answer: A. Policy as code evaluates rules, while infrastructure as code defines infrastructure state.

Question 6

A service needs database access only during a scheduled processing task. Which design best follows least privilege?

A. Give the service permanent administrator access.

B. Embed a shared password in the application image.

C. Use a narrowly scoped workload identity with limited duration or operation scope.

D. Allow every service in the network to access the database.

Correct Answer: C. Use a narrowly scoped workload identity with limited duration or operation scope.

Question 7

Which activity is most appropriate for detecting vulnerable open-source dependencies?

A. Software composition analysis

B. Physical badge inspection

C. Network address translation

D. Data visualisation formatting

Correct Answer: A. Software composition analysis

Question 8

Why should vulnerability severity not be the only prioritisation factor?

A. Severity scores are never useful.

B. Risk also depends on exposure, asset criticality, exploitability, and mitigations.

C. Only the age of a vulnerability matters.

D. All vulnerabilities have identical business impact.

Correct Answer: B. Risk also depends on exposure, asset criticality, exploitability, and mitigations.

Question 9

What is a suitable response when a critical authorisation attribute is unavailable?

A. Automatically grant broad access.

B. Ignore the missing attribute permanently.

C. Apply a defined fail-safe or reviewable decision appropriate to availability needs.

D. Disable all audit logging.

Correct Answer: C. Apply a defined fail-safe or reviewable decision appropriate to availability needs.

Question 10

Which control most directly supports trustworthy software supply-chain evidence?

A. Unsigned artefacts copied between build servers

B. Signed artefacts and verified build provenance

C. Shared production credentials in source control

D. Disabling dependency review to accelerate releases

Correct Answer: B. Signed artefacts and verified build provenance