Security Architecture and Engineering experimental

Security Architecture and Engineering A system is a graph of trust boundaries, and you defend the graph Architecture as a graph of trust boundaries. Components, data flows and trust boundaries as a graph, and why the boundary is the unit of security analysis.. Model a system as components, data flows and trust boundaries.. Explain why a trust boundary is where privilege or trust changes.. Mark the trust boundaries of a given architecture.. Components, flows and boundaries, What a trust boundary is, The boundary as the unit of analysis, Reading an architecture as a graph Security architecture starts by refusing to think of a system as a monolith. Instead, model it as a graph: nodes are components (processes, services, external entities, data stores) and edges are data flows between them. Overlaid on that graph are trust boundaries, lines that cross the graph wherever privilege or trust changes. This lesson builds the vocabulary you will use for the rest of the course. Components, flows and boundaries Four element types recur in almost every architecture diagram, borrowed from data-flow-diagram threat modelling (see Shostack, 'Threat Modeling'): external entities (users, third-party APIs, anything outside your control), processes (services that transform or route data), data stores (databases, caches, file systems, queues at rest), and data flows (the edges connecting them, each carrying specific data). Each element type answers a different question: an external entity tells you where trust cannot be assumed, a process tells you where data is transformed and therefore where a bug can corrupt it, a data store tells you where data persists and therefore accumulates value as a target, and a flow tells you where data is in motion and therefore exposed to whatever medium carries it. A payments system, for example, has an external entity (the shopper's browser), a web front end (process), an order database (data store), and a flow of card data between the browser and the front end. Drawing this graph before touching a single control is not busywork: it is the only way to know what exists to protect. The diagram itself does not need special tooling; a whiteboard sketch or a simple box-and-arrow drawing is enough, provided every component, store and flow the design actually has is represented, and the diagram is revisited whenever the architecture changes rather than treated as a one-time artefact. What a trust boundary is A trust boundary is not a network cable or a firewall rule; it is a semantic line drawn wherever two sides of an edge trust each other differently. Crossing from the public internet into your API is a boundary. Crossing from an authenticated end-user session into an administrative function is a boundary, even if both run on the same host. Crossing from your own service into a third-party payment processor is a boundary. The test is simple: would you assign different privilege, different assumptions, or different blame to the two sides? If yes, there is a boundary between them, and it needs to be drawn and named, not left implicit. A boundary is a property of trust, not of physical topology, so two processes on the same machine can still be separated by a boundary, and two machines on opposite sides of the world can share none at all if they are operated by the same trusted party under the same assumptions. The boundary as the unit of analysis A flow that never leaves a single trust domain is comparatively low risk: both ends already share the same assumptions. A flow that crosses a boundary is where an attacker's foothold on one side can become a compromise on the other, and it is where controls such as authentication, authorisation and encryption actually earn their keep. This is why security review concentrates on boundaries rather than on components in isolation: a component reviewed alone tells you little, but a boundary tells you exactly which assumptions must be enforced by a mechanism rather than taken on faith. Reviewing a system by walking its boundaries, one at a time, and asking what enforces the trust change at each one, finds real gaps far faster than reading through each component's code in isolation and hoping the boundaries take care of themselves. Reading an architecture as a graph To read an architecture securely, trace every path from each external entity to each data store and ask, at every edge that crosses a boundary: what enforces trust here? A single missing boundary, for example an internal admin panel reachable from the same unauthenticated entry point as public users, lets a small compromise (one exposed endpoint) become a total one (full admin access). Later modules build the specific controls, namely authentication, encryption, segmentation, and invariants, that belong on these crossings. This module's job is to make you fluent in seeing the graph and its boundaries before reaching for any of them, because a control applied to the wrong boundary, or to no boundary at all, provides no real protection no matter how strong the mechanism itself is. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Assets, flows, and the security problem definition. Identifying assets, classifying flows by sensitivity, and stating the security problem before designing controls.. Identify the assets a design must protect.. Classify flows by sensitivity.. Write a security problem definition for a brief.. Identifying assets, Classifying flows, The security problem definition, Problem before solution Before you can choose a single control, you need a precise statement of what you are protecting and from what. This is the discipline of writing a security problem definition: assets, threats, assumptions and policies, stated in that order, before any mechanism is chosen. Skipping this step is how designs end up with controls that protect nothing and gaps where something valuable has no control at all. Identifying assets An asset is anything of value the design must protect: customer data, payment credentials, a signing key, the trust relationship a partner API depends on, or even the availability of a service. Assets are not always data: a capability (the ability to issue refunds) or a relationship (a partner's trust that you will not leak their data) can be just as valuable as a database row. List assets explicitly, tied to the components and data stores from the architecture graph, so that every later control can be traced back to something concrete it protects. An asset list that stays abstract, such as 'protect customer trust' with nothing more specific, gives a designer nothing to check a control against; naming the exact database row, key, or capability at stake is what makes the later choice of control verifiable rather than a matter of opinion. Classifying flows Once assets are named, classify each data flow by the sensitivity of what it carries: public, internal, confidential, or a scheme matching your organisation's policy. A flow carrying a session token is not equivalent to one carrying a marketing banner, even if both cross the same boundary. Classification is not decoration: it directly determines how strong the controls at a boundary crossing must be. Two flows carrying the same underlying data at different sensitivities should be controlled according to the higher sensitivity wherever they share a boundary, since an attacker will simply target the weaker path. A classification scheme only earns its keep once it is actually consulted when a boundary's controls are chosen, rather than recorded once in a document and never referenced again. The security problem definition A security problem definition is a short, structured statement covering: the assets in scope, the threats against them (who might attack, with what capability), the assumptions you are making about the environment (for example, 'the cloud provider's hypervisor is trusted'), and the policies to enforce (for example, 'only finance staff may initiate a payout'). Crucially, it does not yet say how these will be achieved: no firewalls, no token formats, no library names. That comes later. Keeping mechanism out of the problem definition is deliberate: naming a mechanism too early anchors the design on a specific solution before you have confirmed it actually answers the threats and assumptions you just wrote down, and it makes the definition harder to reuse if the mechanism later changes. Problem before solution Writing the problem before the solution prevents two failure modes. The first is security theatre: controls added because they sound secure but trace to no asset or threat, adding cost and attack surface for no reduction in risk. The second is a silent gap: an asset that turns out to have no control at all because no one asked what protects it. Both failure modes are easy to miss in review because a design document full of controls looks thorough regardless of whether each one actually answers a stated threat. If an environmental assumption later proves false, for instance the network you assumed was isolated turns out to be shared, every control resting on that assumption loses its justification, and the problem definition tells you exactly which ones to re-examine. Only once the problem is written do you move to selecting principles, patterns and mechanisms, which is where the rest of this course goes next. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Secure design principles. The classical Saltzer and Schroeder principles: least privilege, complete mediation, fail-safe defaults, economy of mechanism, and the rest.. List the classical secure-design principles.. Apply a principle to improve a design.. Diagnose which principle a flawed design violates.. Least privilege and separation of privilege, Complete mediation, Fail-safe defaults and economy of mechanism, Open design and psychological acceptability In 1975, Jerome Saltzer and Michael Schroeder published 'The Protection of Information in Computer Systems', naming a small set of design principles that remain the working vocabulary of secure architecture fifty years later. These principles do not tell you which product to buy; they tell you how to judge any design, including your own, and they let you name a flaw precisely instead of gesturing at a vague unease. Least privilege and separation of privilege Least privilege says a component should hold only the privileges its task requires, and no more. A reporting service that only reads sales data should not also hold write access to the payments table; if it is compromised, the blast radius is limited to what it actually needed. Separation of privilege goes further: a single sensitive action (say, a large funds transfer) should require more than one independent condition or party to authorise, so that compromising one credential is not enough. A service running as administrator 'to avoid permission errors' violates least privilege directly, trading a small convenience for a much larger compromise surface. The two principles compose: a system built from least-privilege components, with separation of privilege enforced on its most sensitive actions, has no single credential whose compromise alone yields a catastrophic result. Complete mediation Complete mediation requires that every access to every protected object be checked against the current authority, every time, with no bypass and no caching that outlives the authority. Checking identity once at login and then trusting every subsequent request forever is a classic violation: if a permission is revoked mid-session, an unmediated system keeps honouring it. Complete mediation is why access-control checks belong at the boundary a request actually crosses, not only at an earlier, now-stale point in the flow. A cache that speeds up an authorisation check is not itself a violation, provided it is invalidated the moment the underlying authority changes; the principle is violated only when a stale grant can still be honoured after it should have been revoked. Fail-safe defaults and economy of mechanism Fail-safe defaults means the default decision, in the absence of an explicit grant, is deny: access is allowlisted, not blocklisted. A firewall rule that allows all traffic by default and blocks known-bad addresses violates this principle, because anything unanticipated is allowed through. Economy of mechanism asks you to keep the security-critical parts of a design as small and simple as possible, because a mechanism that cannot be understood cannot be verified. A reference monitor with ten thousand lines of edge-case logic is far harder to trust than one with a hundred. The two principles reinforce each other: a small mechanism is easier to audit for whether its default truly is deny, while a sprawling one hides exceptions that quietly turn an intended deny-by-default into an accidental allow. Open design and psychological acceptability Open design holds that security must not depend on secrecy of the mechanism itself (security through obscurity); it should hold even when an attacker knows exactly how the system works, resting instead on the secrecy of keys. Psychological acceptability recognises that a control too burdensome for its users gets bypassed, written down, or disabled, defeating its purpose. A password policy so strict that staff write credentials on sticky notes has failed on this principle even though it looks strong on paper. Applying these principles together, and being able to name exactly which one a flawed design violates, is the core diagnostic skill this module builds. In practice a single flawed design usually violates more than one principle at once, and naming all of them, rather than stopping at the first one noticed, is what separates a thorough review from a superficial one. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Authentication and authorisation at boundaries. Establishing identity and enforcing access where a flow crosses a trust boundary.. Distinguish authentication from authorisation.. Configure authentication and authorisation checks on boundary-crossing flows.. Explain why identity must be established before access is granted.. Authentication versus authorisation, Identity at the boundary, Enforcing access, Tokens, sessions and mediation Every trust boundary a sensitive flow crosses needs two distinct questions answered: who is asking, and what may they do. Conflating these, or placing them in the wrong order, is one of the most common architecture flaws this course will ask you to find and fix. Authentication versus authorisation Authentication establishes identity: who, or what, is on the other end of this flow. Authorisation then decides what that authenticated identity is permitted to do. The order matters: you cannot sensibly decide what an identity may do before you know who it is, so authorisation always logically follows authentication. A design that checks 'is this action allowed' before establishing 'who is asking' has nothing to anchor that decision to, and typically falls back to an unsafe default such as trusting the network path instead. Keeping the two steps distinct in the design, rather than folding them into a single ad hoc check, also makes each one separately testable: authentication can be verified with a forged or missing credential, authorisation with a valid credential asking for something it should not have. Identity at the boundary Identity must be established at the boundary the flow actually crosses, not assumed from context such as network location. An internal API that trusts any request originating inside the corporate network, with no authentication of its own, is relying on implicit network trust: a single foothold anywhere inside that network reaches the API unchecked. The fix is to authenticate at the boundary itself, using mutual Transport Layer Security (TLS) between services, a signed service token, or an equivalent mechanism, so identity does not depend on which wire the packet arrived on. This is the same implicit-trust failure the zero-trust model later in this course names explicitly: network location is not identity, and a boundary that only checks location has not actually authenticated anything. Enforcing access Authorisation must be enforced on the side of the boundary you control, and it must be complete mediation: every boundary-crossing request checked against current policy, not just the first one in a session. Placing the enforcement only in the client, for instance hiding an admin button in the user interface (UI), is not enforcement at all, because anyone who controls the client (which, for an attacker, means anyone) can simply skip the missing check and call the underlying endpoint directly. The server-side boundary is the only place this can be trusted. Applying least privilege here means granting each identity only the permissions its actual task requires, not a broad role granted for convenience. A role granted 'to save time setting up the next feature' is a common way least privilege quietly erodes, since the excess permission tends to outlive the convenience that justified it. Tokens, sessions and mediation Bearer tokens and session identifiers grant access to whoever holds them, which means they must be protected in transit and at rest, scoped narrowly to what is needed, and kept short-lived; otherwise a leaked token becomes a portable, long-lived key to the resource it names. A token scoped to a single action and expiring within minutes limits the damage of a leak far more than one scoped broadly and valid for weeks. Centralising authorisation logic at a single policy enforcement point, rather than scattering slightly different checks across a dozen services, gives you one place to audit, update and reason about consistently, a theme this course returns to when it introduces the reference-monitor pattern. Together, authentication and authorisation at every boundary-crossing flow are the mechanism that turns 'we drew a trust boundary' into 'we actually enforce it'. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Protecting flows: encryption in transit and at rest. Confidentiality and integrity of data on the wire and in storage, and where to terminate protection.. Configure encryption in transit for sensitive flows across boundaries.. Protect sensitive data at rest.. Explain where encryption is terminated and what that exposes.. Encryption in transit, Encryption at rest, Where protection terminates, Integrity and authenticity of flows Authentication and authorisation decide who may cross a boundary and with what permission; encryption and integrity protection decide what happens to the data itself while it is exposed to an untrusted path or medium. A sensitive flow that crosses a trust boundary in plaintext has a confidentiality and integrity gap regardless of how well access is otherwise controlled. Encryption in transit Encryption in transit protects a flow against eavesdropping and tampering while it crosses a network you do not fully trust, which, for any boundary-crossing flow, is exactly the case that matters. The current standard for this on the web is Transport Layer Security (TLS) 1.3 (RFC 8446, Rescorla), which replaced earlier, weaker protocols such as Secure Sockets Layer (SSL). Any sensitive flow crossing a trust boundary should be encrypted end to end across that crossing; anything less leaves the data readable to anyone positioned on the path. 'End to end' here means from the originating process to the terminating process, not merely from the client to the first hop, because a gap anywhere along that path is a point where the data reverts to plaintext. Encryption at rest Encryption at rest protects data held in storage (a database, a backup, an object store) against theft of the physical or virtual medium, or unauthorised access to the store outside the normal application path. It is a distinct control from encryption in transit and does not substitute for it: encrypting a database but transmitting its contents in plaintext (or the reverse) leaves the unprotected leg fully exposed. A sensitive flow's protection must cover the entire path a realistic threat model puts an adversary on, not just the leg that was convenient to encrypt. A stolen backup tape or a snapshot copied out of a storage account is just as real a threat as a network eavesdropper, and encryption at rest is the control that specifically answers it. Where protection terminates Encryption is not protection forever; it ends at whatever point it is terminated, and past that point the data is plaintext again. A load balancer or reverse proxy that terminates TLS becomes a place where the data is exposed and must itself be trusted, monitored and secured; it has effectively become part of the trust boundary. Deciding where to terminate encryption requires knowing which intermediaries you must trust with plaintext, where your threat model places the adversary, and what the destination genuinely needs to inspect. A design that encrypts client-to-load-balancer traffic but then sends load-balancer-to-service traffic in plaintext across a shared internal network has quietly reintroduced the exact exposure it appeared to have solved. Naming the termination point explicitly on the architecture graph, rather than leaving it implicit in a vendor's default configuration, is what lets a reviewer actually see this exposure instead of assuming the whole path stayed encrypted. Integrity and authenticity of flows Confidentiality alone is not enough: integrity protection, typically a message authentication code or a digital signature, ensures that tampering in transit is detected and the modified message is rejected rather than trusted. Combined with endpoint authentication, this is what lets a receiver be confident that a message came from the claimed sender and arrived unaltered. Key management underlies all of this: encryption is only as strong as the secrecy and lifecycle of the keys behind it, which is why key ceremonies and rotation are treated as first-class architecture concerns rather than an implementation detail to defer. A design that gets encryption algorithm choice right but leaves key rotation undocumented and manual has moved the weak point from the cipher to the process around it. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Segmentation, zero trust, and defence in depth. Partitioning the graph, removing implicit trust, and layering controls so no single failure is total.. Segment a flat design into isolated zones.. Identify and remove an implicit-trust edge under a zero-trust posture.. Layer controls for defence in depth.. Segmentation, Zero trust and implicit trust, Defence in depth, Blast radius Individually correct controls at individual boundaries are not enough if the overall shape of the graph is flat: one compromise reaching everything else. This module addresses the shape of the whole design: how it is partitioned, what it implicitly trusts, and how many independent controls stand between an attacker and an asset. Segmentation Segmentation partitions a system so that a compromise in one segment does not automatically reach the others. A web tier, an application tier and a data tier in separate network segments, each only able to reach the next with a defined, mediated path, is a classic example. Micro-segmentation pushes this further, to the level of individual workloads or services, so that lateral movement is constrained even within what used to be treated as one trusted zone. Without segmentation, a breach of a single public-facing server can reach the database, the billing service and the backups in one step, because nothing stood between them. The design question is not whether to segment at all, but where the boundaries between segments should fall, which is answered by the asset and flow classification from earlier modules rather than by network convenience. Zero trust and implicit trust NIST Special Publication (SP) 800-207 (Rose et al.) defines Zero Trust Architecture around a simple tenet: never grant trust based on network location; authenticate and authorise every access regardless of where it originates. This directly attacks the classic perimeter model, a hard shell with a soft, trusting interior, which fails precisely because once an attacker is inside the shell, implicit internal trust lets them move laterally with little resistance. An implicit-trust edge is any flow trusted merely because of where it comes from (inside the office network, inside the virtual private cloud (VPC)) rather than by verified identity. Signs a design over-trusts its network include internal services with no mutual authentication, flat connectivity with no segmentation, and access decisions made by source subnet rather than by who is actually asking. Removing an implicit-trust edge does not mean discarding the network entirely; it means the network location stops being treated as sufficient evidence of identity on its own. Defence in depth Defence in depth layers multiple independent controls so that the failure of any single one does not expose the asset outright. A firewall, an authenticated gateway, and least-privilege service accounts are each individually fallible; combined, an attacker must defeat several unrelated mechanisms rather than one. This is a direct architectural application of the classical principle that no single control should be a single point of total failure. The controls must be genuinely independent to count: two firewalls from the same vendor sharing the same misconfiguration are not two layers of defence, they are one control duplicated, and defeating one likely defeats both. Blast radius Blast radius is what remains reachable after a single component is compromised. Segmentation, least privilege, and removing implicit-trust edges all work together to shrink it: instead of one breach reaching the whole system, it reaches only what that one component was actually entitled to touch. Judging any design by its blast radius, asking "if this one node falls, what falls with it?", is a fast, effective way to find where segmentation or zero-trust controls are missing before an incident forces the question. A small blast radius does not mean the compromise does not matter; it means the compromise is contained to a scope the design has already reasoned about and accepted, rather than spreading to assets no one budgeted for. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Secure architecture patterns. Reusable structures: the reference monitor, the secure gateway, the least-privilege service, and fail-safe defaults.. Explain the reference-monitor concept.. Apply a named secure pattern to a design.. Refactor a flawed design onto a secure pattern.. The reference monitor, The secure gateway, The least-privilege service, Refactoring onto a pattern Principles tell you what a good design must satisfy; patterns are the reusable structures that satisfy them in practice, with properties that are already studied and understood rather than invented fresh each time. This module names four such structures you should recognise and reach for. The reference monitor The reference-monitor concept, from James Anderson's 1972 Computer Security Technology Planning Study, describes an access-control mediator that must satisfy three properties at once: it is always invoked (complete mediation, with no bypass path), it is tamper-proof (an attacker who could modify the mediator could grant themselves any access), and it is small enough to be analysed and verified (economy of mechanism). All three properties are necessary together: a mediator that is invoked every time but can be tampered with is worthless, and one that is tamper-proof but skippable is equally worthless. The third property, being small enough to analyse, is what makes the first two verifiable at all: a mediator too large to review in full cannot be shown to be always invoked or genuinely tamper-proof, it can only be assumed to be, which defeats the purpose of naming it a reference monitor in the first place. The secure gateway A secure gateway, or policy enforcement point, is a single mediated entry point that authenticates, authorises and inspects flows crossing into a protected zone. Rather than scattering slightly different access checks across a dozen services, a gateway concentrates mediation at one choke point that can be consistently enforced, monitored and audited. This is the reference-monitor concept applied at the network or API-boundary level: every crossing request passes the same gate, so there is one place to get the check right rather than many places to get it subtly wrong. A gateway does introduce a single point that must itself be highly available and carefully hardened, since concentrating mediation also concentrates the consequence of the gateway itself failing open, which is why gateways are typically built to fail closed rather than fail open. The least-privilege service A least-privilege service is granted only the permissions and network reach its function actually requires: a reporting service gets read access to what it reports on, nothing more. This directly limits what its compromise yields: an attacker who takes over the service inherits only that narrow scope, not the whole system's privilege. This is least privilege made structural, rather than a policy you merely intend to follow. Encoding the restriction into the service's actual permissions and network configuration, rather than trusting the operator to remember not to grant more, means the constraint holds even when the person who set it up has moved on or forgotten the original reasoning. Refactoring onto a pattern When you find ad hoc, ungoverned controls (ten slightly different authorisation checks, a service running with broad privilege 'for now'), the fix is to refactor onto a named pattern rather than patch the specific instance. Consolidating scattered checks behind a reference-monitor-style gateway, or cutting a broadly privileged service down to a least-privilege one, replaces a bespoke, unreviewed mechanism with a structure whose security properties are already known, auditable, and communicable to the next reviewer. Preferring known patterns over novel mechanism is itself an application of economy of mechanism at the architecture level. A novel, bespoke access-control scheme might well work, but it carries the cost of having to prove that from scratch, on every review, for as long as it stays in the design, whereas a named pattern only needs to be recognised. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Architecture invariants and machine-checking. Expressing structural security invariants and checking them over the design graph.. Express a structural security invariant over a design graph.. Check an invariant against a design.. Explain a named invariant violation.. What a structural invariant is, Writing an invariant, Checking over the graph, Reading a violation So far this course has taught you to reason about a design by eye. This module makes a subset of that reasoning objective: structural properties that can be stated once and checked automatically over the design graph, rather than re-argued from scratch on every review. What a structural invariant is A structural security invariant is a property that must hold everywhere over the design graph: for example, 'every sensitive flow crosses an authenticated, encrypted boundary' or 'no external entity reaches a data store without passing an authorisation node'. Unlike a runtime benchmark or a style guideline, an invariant is stated over the graph's typed elements (nodes, edges, boundaries), so it can be evaluated independent of implementation detail such as which language or library was used. NIST Special Publication (SP) 800-160 (Ross et al.) frames this as systems security engineering: treating security properties as requirements to be specified and verified, not bolted on after the fact. Stating a property as an invariant rather than a guideline forces precision: a guideline can be satisfied 'mostly' or 'in spirit', but an invariant either holds on every path in the graph or it does not, with no room for a partial pass. Writing an invariant A good invariant names the elements it constrains precisely: which flows count as 'sensitive' (by the classification from Module 01), which nodes count as 'authorisation nodes' (from the patterns in Module 06), and what 'crosses a boundary' means (from Module 00). Writing invariants declaratively, as a rule over the graph rather than an ad hoc, one-off inspection, makes them auditable, reusable across different briefs, and evaluable by a shared, deterministic grader rather than a human eyeballing a diagram differently each time. An invariant with a vague term left undefined, such as 'sensitive' without a reference back to the classification scheme, is not yet a usable invariant, because two reviewers could disagree on what it actually requires. Checking over the graph Checking an invariant means walking every path in the graph that the invariant's rule concerns and confirming the required element is present on all of them, not just some. For 'no external entity reaches a data store without an authorisation node', a checker examines every path from every external entity to every data store; if even one path bypasses the authorisation node, the invariant fails on that path specifically. Machine-checking this way gives an objective pass, or a named violation identifying the exact offending node, edge or boundary, not a vague opinion about whether the design 'looks secure'. Checking every path rather than a sample matters because the one path a reviewer happens not to look at is exactly where an attacker who has studied the design will look first. Reading a violation A named violation is more useful than a bare pass or fail bit because it points straight at the element to fix: for example, 'a flow from the public API to the billing store bypasses the authorisation node'. The fix is to route that flow through the missing control (or add one), then re-check. Passing every invariant does not mean the design is perfectly secure: it means the specific structural properties you checked hold; judgement about trade-offs and threats outside the invariant set still requires the reviewed written rationale this course also asks for. Invariants and rationale are complementary: one fixes the structural facts objectively, the other carries the judgement calls that cannot be reduced to a graph rule. Treating a passing invariant set as the entire security case, rather than as one necessary component of it, is itself a common and avoidable mistake. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Constraint injection: re-solving under a new threat. Absorbing a withdrawn assumption or a new threat and re-deriving a compliant design.. Absorb an injected threat or constraint into a design.. Re-solve so the invariants hold again.. Explain why a static design fails an injection.. The injected constraint, Re-deriving the design, Why memorised designs fail, Trade-offs under pressure Real architecture rarely stays still: a component is later found to be compromised, a network you assumed was trusted turns out not to be, a new jurisdiction rule forbids a data path you relied on. This module tests whether you actually understand your design well enough to keep it compliant when one of its assumptions is pulled out from under it, a discipline called constraint injection. The injected constraint An injected constraint is a late, previously unseen threat or a withdrawn assumption that the design must now accommodate: a component is newly declared compromised, a flow must now avoid a particular jurisdiction, or a network previously treated as trusted is now treated as hostile. These are not edge cases invented for difficulty; they mirror how real requirements actually change after a design is already in production. A cloud region losing a compliance certification, a vendor disclosing a breach of their own infrastructure, or a new law restricting where a category of data may be stored are all real-world equivalents of an injected constraint, arriving on their own schedule rather than the designer's. Re-deriving the design When a constraint is injected, the invariants from Module 07 must be re-checked and, where they now fail, the design must be re-solved so they hold again under the new condition. If a component is newly assumed compromised, the invariants must hold even treating that component as hostile, meaning its blast radius must actually be contained, not merely hoped to be small. If a previously trusted network is withdrawn from trust, flows that relied on that implicit trust now need explicit authentication and encryption added at that crossing, exactly the controls from Modules 03 and 04, now required somewhere they previously were not. Re-solving in this way is only possible if the original design actually recorded which invariants depended on which assumptions, which is one more reason the written rationale this course asks for is not optional paperwork. Why memorised designs fail The entire point of injection is to distinguish a design that was understood from one that was merely produced: memorised, templated, or generated without grasping why each control was there. A design that only ever satisfies the invariants it was originally built against, and collapses under any injected change, demonstrates a brittle result rather than genuine command of the graph. Re-deriving a compliant design under an unseen constraint requires understanding the specific graph in front of you well enough to know exactly what breaks and exactly what minimal change restores it. A learner who can explain, for each control in their design, which assumption or threat it answers, is the learner who can re-solve quickly when that assumption changes; one who cannot explain it usually cannot re-solve it either. Trade-offs under pressure Re-solving well means changing the minimum necessary to restore the invariants under the new constraint, not rebuilding everything defensively. If a message broker is newly declared compromised and sensitive data still flows through it in plaintext, the correct response is to encrypt end to end around the broker (or re-route the sensitive flow), so a hostile broker cannot read the data, then re-run the invariant checker to confirm the property actually holds again. Where the injected constraint conflicts with another invariant and both cannot be fully satisfied, the discipline is to surface that conflict openly, choose and justify the trade-off in the written rationale, and state plainly what now holds and what does not, rather than quietly hiding the gap. A rationale that names the abandoned invariant explicitly is far more defensible in review than a design that silently drops it and hopes no one checks. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/) Capstone: design, check, and defend an architecture. Produce a full architecture against a brief, pass the structural invariants, survive an injected constraint, and defend the rationale.. Design an architecture to a brief and pass its invariants.. Identify and survive an injected constraint by re-solving.. Defend the architecture in writing.. Designing to the brief, Passing the invariants, Surviving the injection, Defending the design The capstone asks you to do, unaided and in one pass, everything this course has built towards: design a real architecture against a brief, pass its structural invariants, survive an injected constraint, and defend the result in writing. Nothing here is new content: it is the integration of Modules 00 through 08 into a single, judged piece of work. Designing to the brief Designing to the brief starts exactly where Module 01 started: not with a diagram, but with a security problem definition: the assets in scope, the threats against them, the environmental assumptions, and the policies to enforce. From there, build the component-and-flow graph (Module 00), mark its trust boundaries, and place authentication, authorisation, encryption, segmentation and named patterns (Modules 02 through 06) at the crossings the classification and threat model actually demand. A design that skips straight to picking technologies without this grounding will typically show it in the defence stage, when asked to justify a choice that traces to nothing. The capstone deliberately rewards working in this order, problem definition first, graph and boundaries second, controls last, because that order is what makes every later choice traceable back to a stated asset or threat rather than to habit or preference. Passing the invariants Every sensitive boundary-crossing flow in the submitted design must be authenticated and encrypted, per the core invariant this course has built towards since Module 07, and the full invariant set must be machine-checked to hold over the graph as submitted, not asserted by eye. The capstone's pass condition is the invariants actually holding, before and after the injection, not a polished diagram or a long rationale; structure is judged objectively and separately from the quality of the argument. A visually tidy diagram with an unauthenticated crossing hidden in a corner fails the invariant check exactly as surely as a messy one with the same gap, because the checker reads the graph, not its presentation. Surviving the injection After the base design passes, a constraint is injected exactly as in Module 08: a component is assumed compromised, an assumption is withdrawn, or a new restriction appears. The learner must re-derive the design so the invariants hold again under the new condition, then re-check them; ignoring the injection, or arguing it away rather than accommodating it, fails this stage regardless of how strong the original design was. A capstone that passes the base invariants but cannot be re-solved after injection is treated as incomplete, because the injection is part of the gate, not an optional extra. The injection stage exists precisely because a design that only ever faced the conditions it was built for proves nothing about whether it was actually understood, as Module 08 establishes. Defending the design The written defence is reviewed by a person, not auto-graded, because trade-offs and judgement calls do not reduce to a structural check. It should state what was designed and why, what changed under the injected constraint and why that change restores the invariants, and (where a trade-off was unavoidable) which invariant or preference was given up and why that was the right call given the brief. A design that passes every invariant but offers an indefensible or absent rationale is not a complete capstone: architecture here is judged on argument as well as structure, and an honest defence acknowledges that passing the checked invariants means the checked structural properties hold, not that every possible threat has been eliminated. This closing honesty, naming what the invariant set does not cover rather than implying it covers everything, is itself part of what the written defence is judged on. Related CCI capabilities CySSURANCE: Model it. Compute it. Govern it. (https://www.cambridgecyberinternational.com/en/platform/). CySSURANCE Framework Modules: (https://www.cambridgecyberinternational.com/en/platform/). PerfMeter: Numbers first; the platform can come later. (https://www.cambridgecyberinternational.com/en/platform/). cVaR: Risk registers rank; cVaR prices. (https://www.cambridgecyberinternational.com/en/products/cvar/). DORA-MAST (aligned to the EU Digital Operational Resilience Act (DORA) and CCI's Metrics-driven Adversary Simulation Testing (MAST) methodology): Prove resilience, do not assert it. (https://www.cambridgecyberinternational.com/en/products/dora-mast/)