Secure Design Principles

Most architecture stems hide the product on purpose: they describe a flaw (an account with far more access than it uses, a control that fails open and lets traffic through, a flat network where one breached host reaches everything) and ask what you should do first or what design is best. The defensible answer is the option that embodies the right principle, not the one naming the most impressive tool. A secure design principle is a durable, vendor-neutral rule applied while a system is being engineered, before any specific control is chosen, so that security is a built-in property rather than a patch added after an incident; NIST's systems-security-engineering guidance puts it directly, security must be designed in, not bolted on^[1]. Internalize each principle and its trade-off (on top of the CIA triad and what a control is) and the product-level answer follows.

The principles matter on the exam because most architecture questions hide the product. A stem describes a situation - an account with far more access than it uses, a control that fails in a way that lets traffic through, a flat network where one breached host reaches everything - and asks what you should do first or what design is best. The defensible answer is the option that embodies the right principle (least privilege, fail securely, defense in depth), not the option that names the most impressive tool. Internalize the principle and its trade-off, and the product-level answer follows.

Keep two boundaries in mind as you read. Formal mathematical access models (Bell-LaPadula for confidentiality, Biba for integrity) implement these principles but are a separate topic - they live in security-models. Threat-modeling methodologies (STRIDE, PASTA) are how you discover where to apply principles; they live in the risk-management domain. This page owns the catalog of principles themselves and the decision of when each one applies.

This section walks the catalog one principle at a time; each entry states the rule, then the trade-off, so you can match a scenario to a principle on the exam. They are not mutually exclusive - a sound design layers several at once. The diagram above groups the catalog into the three families this section walks in order: constraining what an identity can reach, surviving failure, and setting scope and trust boundaries.

Constraining what an identity can reach

Least privilege grants each subject only the minimum access needed to do its job and nothing more, so a misused or compromised account can damage only a narrow slice of the system. NIST defines it as designing the architecture so each entity gets the minimum resources and authorizations it needs to perform its function^[2]. Need-to-know is least privilege applied to information specifically: a clearance sets the ceiling on what data a person could see, but need-to-know decides which data within that ceiling they may actually access. The two work together - clearance gates the level, need-to-know gates the item.

Separation of duties (SoD) extends the same containment idea across people: split a sensitive task so no one person can complete it alone. NIST's control objective is to reduce the risk of malevolent activity without collusion^[3] - the classic example is that whoever authorizes a payment must not also be able to issue it. SoD can be static (conflicting roles are never assigned to the same person) or dynamic (the conflict is enforced at execution time, as in a two-person rule). Job rotation and mandatory vacations are companion controls: they surface fraud that depends on one person continuously occupying one seat.

Surviving failure

Defense in depth places multiple independent layers of control across people, technology, and operations, so defeating one layer still leaves the attacker facing the next. NIST describes it as integrating people, technology, and operations to establish variable barriers across multiple layers^[4]. The load-bearing word is independent: two layers that share a single chokepoint or one credential store fail together and count as one layer, not two.

Keep it simple and small (economy of mechanism) says the smaller and simpler a mechanism, the fewer flaws it can hide and the easier it is to verify - complexity is where vulnerabilities live. It is why a minimal, auditable control beats a feature-rich one you cannot fully reason about.

Fail securely means that when a component crashes or a check errors out, it denies the protected action rather than allowing it - also called fail-closed or fail-safe. NIST's fail-safe definition is a termination mode that prevents damage to system resources when a failure occurs^[5]. Its opposite, fail-open, keeps the function available through failure and is correct only where loss of availability is itself the greater harm - a fire-exit door must unlock when its controller dies. The design choice is therefore a CIA trade-off: fail-closed when confidentiality or integrity dominates, fail-open when safety/availability of life dominates.

Secure defaults mean the system ships denying access until access is explicitly granted, so a forgotten setting leaves you safe rather than exposed. Note the relationship to fail securely - they are the same instinct at two moments: secure defaults govern the initial state, fail-closed governs the failure state.

Setting scope and trust boundaries

Privacy by design builds data protection into a system's defaults and full lifecycle from the outset - data minimization, purpose limitation, retention limits - rather than adding a consent banner at the end. Shared responsibility defines the security boundary in cloud: the provider secures of the cloud (facilities, hardware, hypervisor) while the customer secures in the cloud (data, identity, configuration), and that boundary shifts toward the provider as you move from IaaS to managed services. Zero trust removes implicit trust by network location and gets its own section below, because it is the principle the exam tests most heavily.

Zero trust treats the network as already compromised, so being on the corporate LAN earns no trust - a posture that builds on least privilege and defense in depth to retire trust-but-verify and place SASE correctly. Read the diagram first - it traces a single access request through a zero-trust decision.

Zero trust (ZT) is defined by NIST SP 800-207 as a set of concepts that minimize uncertainty in enforcing accurate, least-privilege, per-request access decisions in the face of a network viewed as compromised^[6]. That last clause is the whole idea: the model assumes an attacker is already inside, so being on the corporate LAN earns you nothing. Its first tenet that matters here is that no implicit trust is granted based on physical or network location^[6] - a request from inside the legacy perimeter must meet the same bar as one from the open internet. This is the "never trust, always verify" posture.

How the decision is made

Every access in zero trust is authenticated, authorized, and granted on a per-session basis with least privilege, and the decision is driven by dynamic policy that weighs the subject's identity, the requesting device's security posture, and contextual signals such as time and behavior. Architecturally, a request passes through a policy decision point (PDP) that judges it and a policy enforcement point (PEP) that allows or blocks it; SP 800-207 stresses that authenticating to one resource does not automatically grant access to a different resource^[6], and that the implicit-trust zone behind any enforcement point should be kept as small as possible. The enterprise also continuously monitors asset integrity - no asset is permanently trusted.

Trust-but-verify is the stance it replaces

Trust but verify is the older posture zero trust is built to retire: it extends trust up front (often based on network location or a one-time login) and checks behavior afterward. The gap is precisely the implicit trust zone - the window in which a subject is trusted before the next check - and that window is what an attacker who has breached the perimeter exploits for lateral movement. Zero trust shrinks that window toward zero by re-evaluating each request. Note the realistic nuance NIST itself states: most enterprises run a hybrid of zero-trust and perimeter modes during migration rather than flipping a switch.

Where SASE fits

Secure access service edge (SASE) is the cloud-delivered delivery model that converges networking - software-defined WAN (SD-WAN) - with security functions such as secure web gateway, cloud access security broker, and firewall-as-a-service, and enforces zero-trust network access at the edge close to the user, described in NIST's guide to a secure enterprise network landscape^[7]. The exam relationship to remember: zero trust is the principle (verify every session); SASE is one cloud-edge architecture that delivers it for a distributed, perimeter-less workforce. SASE is not a synonym for zero trust - it is one way to operationalize it.

This section maps the principles above onto the question shapes ISC2 actually uses, so you can read a stem and reach for the right principle. The exam rarely names a product; it describes a flaw and asks for the BEST design response. The diagram above pairs each common stem pattern with the principle that answers it; the prose below adds the distractor to rule out in each case.

Stem: an account or role with more access than it uses

The answer is least privilege - reduce the grant to what the function requires. If the stem instead describes one person able to both initiate and approve a sensitive action (issue and authorize a payment, both write code and deploy it to production), the answer is separation of duties, not least privilege. Distinguish them: least privilege limits how much one identity can reach; SoD splits a task so no single identity can complete it. A tempting wrong answer is "give the user a second account" - that does not separate the duties if the same person controls both.

Stem: a control fails and traffic gets through

The answer is fail securely / fail-closed - the control should deny on error. The classic distractor is choosing fail-open "to preserve availability." That is right only when the stem is a safety-of-life system (egress doors, life-support) where loss of availability is the greater harm; absent that, defaulting to fail-open trades confidentiality for convenience and is wrong.

Stem: a flat network where one breach reaches everything

The answer is defense in depth (independent layers) and, for a perimeter-less or remote/cloud workforce, zero trust (per-session verification, no trust by location). Watch the distractor that proposes a bigger perimeter firewall - zero trust's whole premise is that the perimeter is already breached, so reinforcing it misses the point. If the stem stresses a distributed cloud workforce, SASE may be the right delivery vehicle, but only as a way to enforce zero trust, never as a replacement for the principle.

Stem: a new system that will collect personal data

The answer is privacy by design - minimize collection and default to the least-revealing setting up front, rather than adding consent or anonymization later. The distractor is "add a privacy notice before launch"; a notice is disclosure, not design.

Stem: who is responsible for X in the cloud

Apply shared responsibility: the provider owns security of the cloud (physical, hypervisor) and the customer owns security in the cloud (data, identity, configuration). The boundary moves toward the provider from IaaS to managed services, but data classification and access control almost always stay the customer's job - the distractor that says "the cloud provider secures your data" is the trap.