This article was adapted from a conversation on the All Things Cyber podcast, hosted by Robin de Vries and Stephane Konarkowski of ThingsRecon.

I work in government-funded cybersecurity programs, particularly with the governments of the Balkans, improving their cyber capacity building through people, process, and technology projects. When I arrive at an incident, the first question is always: what went down? Not in the technical sense, as I can reconstruct that from the logs.  

But in the human sense: What stopped working? What could people no longer do? Who noticed first, and why?

The answers are almost always surprising. The things that caused the most disruption were not the systems that were directly targeted; They were the systems nobody had thought to include in the dependency map.

Let me share the top three incidents I was involved in remediating, and the lessons about what interconnected infrastructure means when it fails.

Albania: The Attack That Stopped School Registrations

Last year I was called into Tirana, Albania, to help with incident response after the municipality was attacked. The equivalent of the Greater London Authority. Iranian threat actors had started wiping servers on the same night that US forces were striking Iran. Whether that timing was a trigger or a coincidence, I genuinely don't know.

The technical picture was straightforward enough. Server wipes, significant data loss, the kind of destructive attack you see when the objective is disruption rather than espionage. But the impact that the response team cared most about, the impact that the population felt, was a different story.

Here’s what went down:

• The city's public wifi went offline. The police outside the municipality building were using that wifi on their mobile phones to coordinate the response. No wifi, no coordination.

• The traffic cameras were connected to the same network. With the cameras offline, nobody could see where the congestion was building.

• Water bill payments were processed through the municipality's systems. Nobody could pay their bills. Revenue stopped.

• And then this detail, which I think about often: it was the week that parents had a two-week window to register their children for kindergarten. The system was down. Families were genuinely worried their children would miss the registration window entirely and not be able to start school that year.

Unless you've mapped out where all your connections and suppliers are, the secondary and tertiary impacts from an initial attack are very difficult to predict... and even harder to recover from.

None of those impacts were in anyone's pre-incident dependency map. The wifi, the cameras, the billing system, the school registration portal — all on the same network, all connected in ways that only became visible when everything stopped.

Montenegro: Schools Closed Because of an Electricity Bill

In Montenegro, a national-level cyberattack spread outward and hit a number of CNI institutions. Schools had to close across the country.

Not because the school systems were compromised or student data was at risk. Because the schools could not pay their electricity bills: the billing infrastructure was down. In the summer heat, the classrooms were simply too hot for children to sit in.

That is a tertiary effect. The attack, the billing system failure, the inability to pay suppliers, the school closures — again, that chain was not mapped anywhere. There was no contingency for it because nobody had modelled the path from a cyber incident to a closed school building.

This is the nature of interconnected infrastructure. The blast radius of an attack is not the perimeter of the systems that were directly compromised. It is everything those systems touch, and everything those things touch, out to whatever distance your dependencies extend.

Heathrow: It Is Never the System You Think It Is

People assume that if you want to disrupt an airport, you target air traffic control. Or the ticketing system. Or the payment infrastructure. Those are the systems that feel critical, the ones that come to mind when you think about what makes an airport function.

I designed one iteration of the SOC at Heathrow's disclaimer center. The thing that the security team was most focused on, the thing that was always treated as the highest priority, was the baggage system.

The baggage system is old, physical, and mechanical. It has a lot of moving parts and a lot of maintenance requirements. It is also automated, and it is what keeps an airport running. When the Heathrow fire happened, the thing that grounded the planes was not a compromised ATC system. It was the physical infrastructure that moves the bags.

The lesson is simple but consistently ignored: the most critical system in any complex infrastructure is rarely the one that looks most important on a network diagram. It is the one that everything else depends on when something goes wrong.

What These Three Incidents Have in Common

In each case, the unexpected impact was the result of dependencies that existed but were not documented. In each case, the recovery was complicated by the fact that nobody had mapped what would need to be restored in what order to return to operational normality.

Secondary and tertiary effects will unfold. The question is whether you have done the mapping work before the incident, or whether you are doing it in the middle of one.

What Mapping Dependencies Requires

Dependency mapping is a continuous exercise, because digital supply chains change continuously. New integrations are added, old connections persist after relationships end, third-party infrastructure shifts without notice.

What mapping requires, in practice, is:

• A discovery process that starts from what is actually connected, not from a vendor list or a procurement record

• Continuous monitoring so that new connections and new dependencies are identified as they emerge, not twelve months later

• A documented understanding of blast radius — for each system, what stops working if this system stops working, and in what order

• Recovery planning that is informed by the actual dependency chain, not by the systems that feel most important

The municipality of Tirana had the tools to respond, but they didn’t have a dependency map. The response was faster once we understood the chain, but that should have been documented before the attack... not reconstructed during it.

David Smith is Regional Lead Consultant for Eastern Europe and the Balkans at BAE Systems Digital Intelligence. He has spent 17 years working in government and critical national infrastructure security. This post was adapted from Episode 5 of the All Things Cyber podcast.
Watch the full episode: