Attack surface: architecture reviews, data flows and trust boundaries

Why this matters

The previous lesson generated threats against a design. This one is about the design itself: what an architecture review asks, how to see the boundaries that matter, and how to count exposure honestly.

The reason it earns its own objective is that scanning and testing are both blind to design. A penetration test finds what is exploitable in the implementation you have. A vulnerability scanner finds known defects in software it can reach. Neither can tell you that the architecture places a component inside a boundary it should be outside of, because from the implementation's point of view that is simply how it was built. Design defects survive every technical assessment and are found by reading.

The other reason is economic. Attack surface reduction is the control class with the best long-run return, because a removed interface needs no patching, no monitoring and no access review for the rest of its life. Reducing surface is the only security decision that makes future security work smaller.

The lesson

What an architecture review asks that a vulnerability scan cannot

An architecture review examines a design against its security requirements before or independently of implementation. Its questions are structural, and a scanner has no way to ask any of them:

• Where does trust change, and is the change enforced? A scanner sees two services communicating successfully; it cannot tell that one is treating the other's output as trusted when it should not.
• Is authority proportionate? A component holding credentials that let it reach far more than it needs is correctly configured and badly designed.
• What is the blast radius of compromising each component? This is a property of the graph, not of any node.
• Are controls placed where they can be enforced? Validation performed in a client that the server also accepts is a design defect; every individual piece works.
• Can this be operated? A design requiring a manual step per deployment will be automated by someone eventually, usually by granting a service the rights the human had.
• What happens when a component fails? Failing open versus failing closed is a design decision that scanners never see and incidents always reveal.

The practical framing worth carrying: a scanner answers "is this implementation defective"; a review answers "is this the right structure". A design can be entirely free of known vulnerabilities and still be wrong, and scenarios describing a breach where "all systems were patched and the penetration test had passed" are describing exactly that.

Reviews are most valuable early, because the cost of change rises steeply after build. But a review of an existing estate is also worth running once, precisely because nothing else in the assurance programme has ever asked these questions.

Drawing data flows and marking every point where data crosses a trust boundary

A trust boundary is any point where the level of trust changes — between an untrusted network and yours, between two tenants, between user space and privileged context, between an internal service and a supplier's, between production and a lower environment, between a browser and a server.

The rule that makes them useful: data crossing a trust boundary must be validated, authenticated and authorised on the receiving side, every time, regardless of what the sending side did. Most serious design defects are a boundary that exists in reality and not in the design's thinking.

Boundaries that are commonly missed, and each is a recognisable scenario:

• Between microservices. Services inside one cluster often trust each other implicitly because they are "internal". The boundary is real; an attacker who reaches one service gets the trust of all of them. This is the argument microsegmentation and zero trust answer, two and six lessons ahead.
• Between an application and its own database, when the application uses one highly privileged account for every operation.
• At the management plane. Cloud control APIs, hypervisor management and orchestration APIs are boundaries whose compromise exceeds anything inside them, and they are frequently drawn as infrastructure rather than as a flow.
• Around third-party code. A dependency, an agent or an embedded script executes inside your trust context; the boundary is at the point you accepted it, and it is crossed at build time rather than at run time.
• Around data exports. A report leaving for a supplier crosses a boundary as definitively as a network connection, and is usually governed by nothing.

Drawing this well is mostly discipline: enumerate the flows rather than the boxes, state what data each carries and its classification, and for each boundary crossing state what is checked. A flow with no stated check is either a finding or an implicit trust decision somebody should make explicitly.

Counting attack surface honestly: interfaces, identities, dependencies, not just open ports

Attack surface is routinely under-counted because the traditional measure — listening network ports — is the smallest component in a modern estate.

A complete count includes:

• Network interfaces. Listening services, including those reachable only internally; internal surface is what matters after initial access.
• Application interfaces. Every API endpoint, parameter and file upload; unauthenticated endpoints count several times over.
• Identities. Every user, service account, API key, token and certificate is an entry point. In cloud-heavy estates this is frequently the largest category and the least enumerated.
• Dependencies. Every library, container base image, agent and installed package — code you execute and did not write.
• Suppliers with access. Every integration, managed service and support channel with a path into your estate.
• Human surface. Addresses, phone numbers and named staff that support social engineering; the help desk's identity-verification process is attack surface.
• Physical and wireless, where relevant.

Two properties are examinable. Surface is not uniform: an unauthenticated internet-facing API is worth vastly more than an internal port behind authentication, so a count without exposure and authentication context misleads. And surface grows by default — every project adds and nothing removes, unless removal is somebody's explicit job.

The practical measure is a small number of tracked figures reviewed over time: internet-facing services, unauthenticated endpoints, privileged identities, external integrations. Their trend is the signal. A rising count with a stable headcount means design decisions are accumulating exposure faster than anyone is retiring it.

Shadow IT and acquisitions as the two most common sources of unmapped surface

Both add estate that no design ever included, and they fail differently.

Shadow IT is technology adopted without going through the process — typically SaaS bought on a card, a cloud account opened for a proof of concept, or an integration authorised by a user granting a third-party application access to corporate data. It usually indicates that the official route is too slow rather than that staff are careless, and a scenario naming a long approval process alongside a shadow IT problem is making that link.

Detection comes from egress logs and DNS, identity provider consent grants and third-party application registrations, expense data, and certificate transparency for hostnames on your domains. The governance response that works is a fast sanctioning path — adopt, assess and bring inside — because blocking alone drives the same activity somewhere less visible. Blocking is right where the data classification makes the risk unacceptable, which is a decision the classification table from lesson seven should already make for you.

Acquisitions add an entire unassessed estate, usually with an urgent business requirement to connect it. The characteristic failure is connecting first and assessing later, which extends your trust boundary around an unknown environment.

The defensible sequence is discovery before connection, a temporary boundary treating the acquired estate as untrusted with brokered access only, a time-boxed remediation programme with the funding negotiated as part of the deal, and integration in stages as each area reaches the standard. A scenario describing an incident that entered through a recently acquired subsidiary is describing the absence of that boundary.

Both sources share one property worth stating: the surface exists whether or not it is recorded, and the only question is whether you find it or somebody else does.

Reducing surface as a design decision rather than a remediation task

The strongest form of this control is not finding and fixing exposure but designing so that it never exists, and the difference is worth making explicit because the two land in different budgets.

Design-time reductions, roughly in order of value:

• Do not build it. The feature that is not implemented has no vulnerability, no patch and no access review. Scope decisions are security decisions.
• Reduce what is reachable. Private endpoints, brokered access and a single entry path instead of many; most estates expose management interfaces that no design ever required to be reachable.
• Reduce authority. Narrow, purpose-specific identities rather than one broad one; this shrinks the identity surface and the blast radius together.
• Reduce dependencies. Fewer components, smaller base images, no library for a function you can write in ten lines. Every dependency is permanent surface.
• Reduce lifetime. Short-lived credentials, ephemeral compute and immutable infrastructure remove persistence opportunities and shrink the window in which any given exposure is useful.
• Retire deliberately. Decommissioning from lesson five is surface reduction, and it is the only category that makes the number go down.

The governance mechanism that makes this happen is an explicit criterion in architecture review — what surface does this design add, and what is being retired — and, where an organisation has one, a rule that new exposure requires a justification recorded against the design. Without it, reduction competes for time with delivery and loses every quarter, and the estate's surface follows a monotonic curve that no amount of remediation capacity can catch.