One Continuous Surface: Building the Attack Graph
Everything in this course converges on a single deliverable: an attack graph that treats the facility as one continuous surface from the internet to the motor. Build it, and defense stops being a set of disconnected worries and becomes a problem of geometry. This lesson assembles it.
An attack graph is simply a map of every place an attacker can stand and every step they can take to reach the next place, ending at the outcomes you most fear. The nodes are footholds: an engineer's mailbox, a workstation, a domain controller, a jump host, a data historian, a protocol gateway, a supervisory server, a controller, a breaker. The edges are the moves between them: a phished credential, a reused vendor account, a firewall rule, a dual-homed machine, an unauthenticated control command. The terminal nodes are the impacts that matter to a data center: heat rejection stopped, power dropped, safety interlocks disabled, operators blinded by falsified readings. Draw it honestly and the whole point of the course appears on one page — the path from an email to a motor is a connected line, and it was connected all along.
The discipline that makes the graph real is refusing to stop at the IT edge. Most organizations' security maps end where the corporate network ends and hand the rest to facilities, who keep a separate map, if any. The attacker keeps no such boundary. So the graph must include the OT nodes as first-class citizens: the historian in the middle zone, the gateway in the closet, the flat controls network, the legacy controller with no logging, the sensor whose reading an operator trusts. Populate those nodes from the inventory Module 1 demanded, connect them across the seam Module 3 dissected, and annotate the edges with the adversary techniques Module 4's frameworks named. The graph is where the earlier modules stop being separate lessons and become one picture.
Once the graph exists, prioritization becomes tractable in a way it never is with a flat list of vulnerabilities. Three structural ideas do most of the work. The first is chokepoints: some nodes sit on nearly every path from the outside to an impact — the IT-to-OT crossing, the engineering jump host, the domain identity system, the supervisory server. Hardening a chokepoint shortens or severs many attack paths at once, so it buys more security per unit of effort than hardening a leaf node the attacker can route around. The second is shortest path: find the fewest steps between an internet-facing node and a catastrophic impact, and treat that path as your most urgent work, because it is the one a capable adversary will find first. An internet-exposed controls gateway that sits two hops from stopping the cooling is a five-alarm finding no matter what a generic vulnerability score says. The third is the last line: the terminal impacts should be guarded by controls an attacker on the network cannot reach at all — independent, hard-wired safety systems and physical interlocks that trip equipment to a safe state regardless of what the control logic has been told to do. When the network layer fails, that physical layer is what stands between a manipulated setpoint and a destroyed plant.
Notice how the graph reprioritizes work compared with siloed thinking. A conventional IT program might spend heavily on a data-loss risk that, on the graph, leads nowhere near an operational impact, while ignoring a quiet vendor tunnel that sits one hop from the plant. A conventional facilities program might diligently maintain chillers while leaving the gateway that controls them exposed. The graph exposes both errors because it forces every investment to be justified by its effect on real paths to real impacts. It also turns the organizational problem into a shared one: IT and OT teams looking at the same graph are, at last, defending the same thing, and can argue productively about which edge to cut first instead of guarding two halves of a whole they never see together.
Operationalizing the graph is a continuous act, not a one-time drawing. The inventory drifts as vendors add connections and projects open firewall rules, so the graph must be revisited or the map will lie. Passive OT monitoring feeds it by revealing links and devices no one documented. Threat intelligence updates the edges as adversaries adopt new techniques. Incident lessons add paths you did not know existed. The mature program treats the attack graph as a living model of the facility's real exposure, reviewed jointly by the people who defend the compute and the people who run the plant.
End where the course began, in the Mach register. The AI data center is one machine, not two, and its threat surface is one surface, not two. Operational-technology exposure, the state-sponsored adversary, the building-controls attack surface, and the framework lens are not four separate subjects. They are four views of a single graph that runs unbroken from an email attachment to a spinning motor. Defend it as one, prioritize by the geometry of the paths, and back the whole thing with a physical safety layer the network cannot touch. Whoever holds the graph holds the building.