Critical infrastructure protection: a dependency problem

Critical means depended on, not big

Critical infrastructure protection starts with a definition most discussions get backwards. Infrastructure is not critical because it is large, valuable, or famous. It is critical because other essential things stop working when it stops working. A water utility with a staff you could fit in one conference room is critical infrastructure, because the county it serves has no second source of water. A consumer platform with a thousand times the revenue is not, because nothing essential fails when it fails.

Criticality is a property of the dependency graph, not of the node.

I spent four years administering both the office network and the process-control network at a petrochemical plant, and that vantage point teaches the definition viscerally. From the org chart, a plant is a private industrial facility — one company’s asset, one company’s problem. From the dependency graph, it is a node in several webs at once: it consumes grid power, natural gas, water, and telecom services it does not control, and it feeds product into supply chains whose downstream customers have never heard of it. The plant’s criticality was never about its size. It was about who stood upstream and downstream of it, and how little slack existed in either direction.

That framing matters because it changes what protection means. If criticality lived in the node, protection would be perimeter hardening — make the important thing hard to attack. Because criticality lives in the edges, protection is a systems problem: understanding what you depend on, what depends on you, and how failure propagates across boundaries that no single operator owns. The hardening still matters. It is just not where the analysis starts.

The interdependency problem

The defining engineering problem in critical infrastructure is that the sectors form a mesh of circular dependencies, and the circularity is what turns local failures into regional ones.

Walk one loop. Water treatment and distribution run on electric pumps, so water depends on power. Generating stations need cooling and boiler feedwater, so power depends on water. Grid operations depend on communications — SCADA telemetry, inter-utility coordination, protection signaling — so power depends on comms. And every communications site runs on grid power backed by batteries and generators measured in hours or days, not weeks, so comms depend on power. Add fuel: pipelines move fuel with electric pumps and compressors, while backup generators everywhere assume fuel deliveries will continue. Every arrow eventually bends back around.

Sector	Depends on	Is depended on by
Power	Fuel, water, communications	Effectively everything
Water	Power, chemicals, communications	Power, healthcare, food, chemical plants
Communications	Power, (fuel for backup)	Power, water, finance, emergency services
Fuel/pipelines	Power, communications	Power generation, transport, backup generation

Three consequences follow, and each one shapes how operators should think.

Failures cascade across ownership boundaries. The event that takes your facility down can originate two sectors away, in an organization you have no contract with and no visibility into. A risk model that stops at your fence line is a model of the wrong system.

Restoration is an ordering problem. When multiple interdependent systems are down together, each one’s restart can require services from the others — the grid’s black-start problem is the canonical case, where restarting generation requires power that normally comes from the grid being restarted. Operators who have only rehearsed single-system recovery discover the ordering problem live, which is the most expensive possible classroom.

Buffers are the honest measure of resilience. How long can you run degraded when an upstream dependency fails — hours of battery, days of diesel, weeks of treatment chemicals? Those buffers, not the firewall count, are what determine whether an upstream outage is an entry in your log or the end of your service. In the plants I have supported, the utilities-failure scenarios were treated with the same seriousness as process hazards, and that instinct — treating dependency loss as a design case rather than an anomaly — is the one worth exporting everywhere.

The regulatory map, read factually

The US regulatory structure is easier to navigate if you separate what is coordination from what is binding, because the two get conflated constantly.

The coordination layer. CISA designates sixteen critical infrastructure sectors — energy, water and wastewater, communications, chemical, transportation, healthcare, food and agriculture, financial services, and others — and each sector has a designated Sector Risk Management Agency: the Department of Energy for energy, the EPA for water, and so on. The 2024 National Security Memorandum on critical infrastructure security and resilience reaffirmed and updated this structure, which traces back through two decades of policy. Designation gets a sector threat briefings, information-sharing channels, and voluntary guidance — including CISA’s Cross-Sector Cybersecurity Performance Goals, a deliberately short, prioritized baseline aimed at organizations that will never staff a full framework implementation. What designation does not do, by itself, is compel anyone to do anything.

The binding layer, where it exists. The clearest example is NERC CIP: mandatory, audited, financially enforceable standards for the North American bulk electric system. Conceptually, the CIP family requires utilities to categorize their systems by the impact their loss would have on the grid, and then apply graduated controls: defined electronic security perimeters, personnel screening and training, physical protection of critical cyber assets, configuration change management, incident reporting, recovery planning, and supply-chain risk management. Whatever one thinks of any individual requirement, CIP has done something rare — it made a baseline of security engineering non-optional across an entire sector, and it is the model people point to when they argue for or against binding rules elsewhere.

The uneven middle. Between those layers, density varies enormously by sector. Pipeline operators came under TSA security directives after 2021. Water utilities — thousands of them, many small and thinly staffed — operate under a far lighter regime despite sitting inside the tightest dependency loops. Nuclear power has its own regulator entirely. The unevenness is the practical point: which rules bind you is an accident of sector, but your dependency exposure is not. Compliance, where it exists, is a floor. NIST SP 800-82 and the engineering it represents are the actual discipline, and the operators who treat the audit as the finish line have confused the map for the terrain.

Defense priorities that actually move risk

For an operator, the honest question is not “how do we address the critical infrastructure threat” — it is where the next unit of engineering effort buys the most risk reduction. Across the OT environments I have worked in and around, the answer has a fairly stable order.

1. Map your dependencies, both directions. Upstream: power feeds, telecom circuits and their physical diversity (or the shared conduit that quietly negates it), fuel arrangements, treatment chemicals, the vendors whose remote support your operation silently assumes. Downstream: who loses what when you go dark, and how fast. This map is the criticality assessment, and every subsequent priority is sequenced by it. Most organizations discover during their first serious mapping exercise that their two “diverse” telecom paths ride the same pole line.

2. Know what you have and bound what can reach it. The fundamentals do not change because the sector is critical: an asset inventory built passively, and segmentation that separates the control environment from the enterprise with a brokered DMZ between them. I cover the OT-specific mechanics in ICS security fundamentals and the zone logic in network segmentation strategy; the point here is priority. Segmentation is what turns “the enterprise network got ransomware” into an inconvenience instead of a service interruption, and ransomware spillover remains the realistic threat for most operators — far more probable than the bespoke attacks that dominate headlines.

3. Fix remote access before it fixes you. Vendor and integrator remote access is the most common initial-access path into control environments I have seen firsthand, and in critical infrastructure the population of vendors is large: equipment OEMs, integrators, engineering firms, municipal IT contractors. Every path gets brokered, MFA-enforced, time-boxed, and recorded — the architecture I detail in OT remote access architecture.

4. Preserve the ability to operate degraded. This is the priority that distinguishes critical infrastructure from ordinary OT security. Can the process run with the SCADA layer impaired? Can operators run manually, and — the harder question — do any current operators still have the training and recent practice to do it? Manual capability that exists on paper but not in muscle memory is a diagram, not a defense. The same discipline applies to islanding from failed upstream dependencies: buffers, transfer switches, and fallback procedures that get exercised, not laminated. This is operational resilience in its most literal form.

5. Be able to put it back. Backups of control logic, controller configurations, and the aging engineering software needed to restore them — tested against the scenario where restoration happens during a regional event, when vendor support is saturated and your own people are the only ones coming.

6. Build the relationships before the incident. Sector ISACs, CISA regional advisors, the utility on the other end of your interconnection, county emergency management. During a cascading event, the operators who recover fastest are the ones who already knew who to call and had already exchanged the technical context that matters. Trust does not stand up under load any faster than infrastructure does.

The public-private reality

The structural fact underneath all critical infrastructure policy is that the government protects very little of it directly. The large majority of US critical infrastructure is privately owned and operated — a figure commonly cited around 85%, and whatever the precise number, the implication is not disputed: the operators own the risk, the assets, and the engineering.

That produces a division of labor worth stating plainly. Government — CISA, the sector agencies, the intelligence community — can warn, convene, share indicators, publish guidance, fund research, and regulate at the edges. It cannot patch a utility’s HMIs, segment its network, or staff its night shift. The defense is carried by operator investment, which means the defense is ultimately governed by operator economics — and there is the honest tension. Security spending at a regulated utility competes inside a rate structure; at a small water district it competes with pipe replacement. The sectors with the most critical dependency positions are frequently the ones with the least discretionary budget, which is exactly why CISA aims its performance goals at the small operator rather than the Fortune 100 SOC.

The information flow has genuinely improved — sector ISACs, faster advisories, joint analysis after major incidents. An operator who is not consuming those channels is leaving free intelligence unread. But no briefing substitutes for engineering, and the reverse asymmetry persists: government sees the threat picture better than any single operator, while the operator understands the process, the assets, and the actual failure modes better than any agency ever will. The partnership works when each side supplies what the other structurally cannot. It disappoints whenever either side expects the other to do its job.

The lesson that generalizes

Critical infrastructure protection resists being reduced to a product category because it is not, at bottom, a security problem with an industrial accent. It is systems engineering under the hardest constraint: the system spans organizations, sectors, and decades, and no one owns the whole graph.

The operator’s share of it, though, is concrete. Map the dependencies in both directions. Bound what can reach the process. Control the paths in. Keep the ability to run degraded and the ability to restore. Know your neighbors in the graph before the night you need them. None of this is exotic — it is the same discipline that makes any system reliable, applied to systems where the consequence of skipping it lands on people who never chose the risk.

Sectors, threat actors, and policy memoranda will keep changing. The dependency graph, and the engineering obligation it creates for everyone who operates a node in it, will not.