Secure design principles II: zero trust, privacy by design and shared responsibility

The principles in lesson 1 are decades old. The ones in this lesson are newer responses to how computing has changed: users who work from anywhere, applications that live in several clouds, partners who connect directly to internal systems, and personal information that regulators expect to be protected by default. The 2024 exam outline names them explicitly in sub-domain 3.1: zero trust, privacy by design, trust but verify, shared responsibility and secure access service edge. Each answers a question that the old perimeter model could not.

The end of the trusted perimeter

For many years network security followed a castle-and-moat model. A strong perimeter of firewalls separated the trusted internal network from the untrusted internet, and anything inside was largely trusted. The model failed for three reasons. Attackers learned to get inside through phishing, stolen credentials and compromised suppliers, and once inside they moved laterally with little resistance. Users and data left the castle, to laptops at home, mobile phones and cloud services that the perimeter never covered. And the network itself became too large and porous to defend as one trusted zone. Many major breaches of the past fifteen years followed the same pattern: an initial foothold through a phished account or a vendor connection, followed by weeks of quiet movement across a flat internal network.

Zero trust

Zero trust replaces location-based trust with explicit verification. Its core idea is never trust, always verify: no user, device or workload is trusted simply because it is on the corporate network. Every request for access is evaluated on its own merits, using as much context as possible, and access is granted with least privilege for a limited session. The United States National Institute of Standards and Technology describes the architecture in Special Publication 800-207. A policy decision point, made up of a policy engine and a policy administrator, decides whether to allow each request; a policy enforcement point, such as a gateway or proxy in front of the resource, carries out the decision. Inputs to the decision include the identity of the user, the health and management status of the device, the sensitivity of the resource, the time and location of the request, threat intelligence and behaviour analytics.

Zero trust is not a product that can be bought in one box, despite marketing claims. It is a strategy that is usually adopted over years. Common building blocks include strong identity with phishing-resistant multifactor authentication, device inventory and health checks, micro-segmentation that limits which workloads can talk to each other, encryption of all traffic including internal traffic, continuous monitoring, and automation that can revoke a session the moment risk rises. Maturity models help organizations plan the journey. The US Cybersecurity and Infrastructure Security Agency publishes a Zero Trust Maturity Model organized around identity, devices, networks, applications and workloads, and data. The Canadian Centre for Cyber Security publishes guidance encouraging Government of Canada departments and other organizations to adopt zero trust principles in the same way.

Trust but verify

Trust but verify is an older phrase that the outline lists alongside zero trust. It describes granting trust where it is needed to get work done, then checking that the trust is not abused. Examples include logging and reviewing administrator actions, auditing a vendor's controls through a SOC 2 or ISO 27001 report, reconciling financial transactions and reviewing access rights periodically. Zero trust can be seen as the strict end of the same spectrum: it verifies before granting access, every time, while trust but verify relies more on after-the-fact detection. Real organizations use both. A finance system might require strong verification at login and then also review unusual payments afterwards.

Privacy by design

Privacy by design was developed in the 1990s by Ann Cavoukian when she was Information and Privacy Commissioner of Ontario, and it has since spread worldwide. It rests on seven foundational principles: be proactive, not reactive; make privacy the default setting; embed privacy into the design; keep full functionality, so that privacy and other goals are positive-sum rather than trade-offs; provide end-to-end security across the life cycle; maintain visibility and transparency; and respect the user by keeping their interests central. The European Union's General Data Protection Regulation turned the idea into a legal duty in Article 25, data protection by design and by default, and Canadian and US privacy regulators expect it too.

For an architect, privacy by design becomes concrete decisions. Collect only the data the purpose needs. Pseudonymize or aggregate data as early in the pipeline as possible. Set the most privacy-protective option as the default, so that users who do nothing are protected. Separate identifying data from other data so that a breach of one store does not reveal everything. Build in deletion from the start, because retrofitting deletion into a system that copies data everywhere is very hard. And carry out a privacy impact assessment when a design processes personal information in new ways.

Shared responsibility

Shared responsibility describes how security duties are divided between a cloud provider and its customer. The provider is always responsible for security of the cloud: the physical data centres, hardware, hypervisors and the global network. The customer is always responsible for security in the cloud for the parts it controls, and always for its own data, identities and access decisions. Where the line falls depends on the service model. With infrastructure as a service, the customer manages the operating system, middleware, applications and data. With platform as a service, the provider also manages the operating system and runtime. With software as a service, the provider runs almost everything and the customer manages users, configuration and data.

Misunderstanding the model is a leading cause of cloud breaches. Storage buckets left open to the internet, unpatched virtual machines and administrator accounts without multifactor authentication are customer failures, not provider failures. Contracts, the provider's responsibility matrix and independent assurance reports tell the customer exactly which controls it inherits and which it must operate. The same idea applies outside the cloud, to managed service providers and outsourcers, and lesson 7 returns to cloud architectures in detail.

Secure access service edge

Secure access service edge, or SASE, is an architecture that delivers networking and security together as a cloud service close to where users are. The term was coined by the analyst firm Gartner in 2019. It combines software-defined wide area networking with security functions such as a secure web gateway, cloud access security broker, zero trust network access and firewall as a service. Instead of sending a remote user's traffic back to headquarters to pass through a central firewall, a practice called backhauling that adds delay, SASE inspects the traffic at the nearest point of presence of the provider and applies the same policy everywhere. Security service edge, or SSE, is the security half of SASE without the networking. For the exam, remember that SASE supports zero trust by applying identity-aware policy at the edge for users wherever they are.

Thinking like a manager

When a scenario describes attackers moving freely once inside a network, the answer usually involves zero trust or segmentation. When it describes a new system collecting personal information, the answer often involves privacy by design or a privacy impact assessment before launch. When it describes a cloud breach caused by a misconfiguration, remember that configuration in the cloud is the customer's responsibility. And when an answer promises to deliver zero trust by buying a single product, be sceptical: zero trust is a strategy and an architecture, built step by step.

Adopting zero trust in stages

Most organizations cannot rebuild everything at once, so zero trust programs are usually phased around the protect surface: the small set of critical data, applications, assets and services that matter most. A typical first phase strengthens identity, moving all staff to single sign-on with phishing-resistant multifactor authentication such as FIDO2 security keys or passkeys, and building an inventory of devices with health checks. A second phase segments the network around the protect surface, so that payroll servers, for example, accept connections only from the payroll application tier and from administrators coming through a hardened access gateway. Later phases replace traditional virtual private networks with zero trust network access, which connects a user to a single application rather than to the whole network, encrypt internal traffic and automate responses, such as ending a session when a device falls out of compliance.

Measuring progress matters as much as buying tools. Useful indicators include the share of logins using phishing-resistant authentication, the share of devices that report health before connecting, the number of flat network zones remaining and the time taken to revoke access when an employee leaves. Leaders should expect some friction: legacy applications that cannot use modern authentication may need to sit behind a proxy, and operational technology in factories often cannot run agents at all. A realistic roadmap records these exceptions with compensating controls rather than pretending they do not exist.