They Did Not Hit The Tower, They Hit What The Tower Leans On
Picture the operations floor at a busy airport. The radar is up. The radios work. The controllers are at their stations and every system they think of as the job is running exactly like it did yesterday. Then the weather feed goes dark. Not the radar, not the comms, the weather. And without current, trusted weather data, you cannot safely space and sequence aircraft, so the whole operation starts to slow. Ground stops. Holding patterns. Flights backing up across the network because a supporting data service nobody outside the building has ever heard of stopped answering.
That is roughly what happened this week when ransomware hit a national air traffic control provider. The attackers did not take down the control systems. They hit the weather service those systems quietly depend on, and that was enough to degrade live operations at multiple airports. The part everyone will fixate on is that an attack touched aviation. The part that should change how you think is that it never had to touch the thing you would have spent your whole budget protecting.
Everybody hardens the obvious thing
Here is what we see in almost every assessment. The crown jewel gets the money and the attention. The control system, the SCADA box, the safety instrumented system, the badge controller, the thing with the scary name in the risk register. It gets segmented, monitored, patched, and watched, because leadership can point at it and say that is the thing that matters.
Then there is the other list. The unglamorous stuff the crown jewel cannot run without. The weather feed. The time server. The scheduling system. The DNS resolver nobody remembers deploying. The vendor portal that pushes updates. The database that holds the badge records. The comms relay that carries alerts. None of that shows up in a board deck as critical, so none of it gets hardened like it is. And that is exactly the problem. Your most protected system is only as available as the least protected thing it leans on.
An attacker who cannot get through the front door of your control system does not stand there knocking. They look at what feeds it, step one hop sideways to the soft dependency, and take that out instead. Same physical result, a fraction of the effort, and they walk right around every dollar you spent on the hard target.
Why nobody has this drawn on paper
This works because of where the dependency lives. It sits in the seam between two teams that each assume the other one has it.
The people who run the physical operation watch the operation. Aircraft, pumps, trains, production lines, the things you can see move. They know their control systems cold. What they often cannot tell you is every IT service riding underneath those control systems, because that stack belongs to someone else. The IT team watches the network and the servers, and they can tell you what is running, but they frequently do not know which of those services, if it blinked out at 0300 on a Sunday, would bring a physical operation to its knees. One side owns the consequence. The other side owns the dependency. Almost nobody owns the map that connects them.
So the dependency is invisible, not because it is hidden, but because responsibility for it falls in the gap. The attacker does not need that map handed to them either. They can study your vendors, your job postings, your public filings, and your support forums and work out what your operation runs on faster than your own two teams can agree on who owns it.
The question that finds the hole
Most people think resilience means protecting your critical systems. We would push back on that. We're getting beat badly on this exact assumption. Resilience means knowing what your critical systems silently depend on, and most organizations have never traced that chain even once.
When we run this against an operation, we do not start at the control system. We start at the physical outcome you cannot afford to lose and we walk backward. What has to be working for aircraft to keep moving, for the line to keep running, for the water to keep flowing. Then we ask what each of those things depends on, and what those depend on, until we hit something small, forgotten, internet reachable, and owned by no one. That is usually where we stop, because that is usually the answer.
What you can do this week
You can run a rough version of this yourself before you call anyone, and it will show you fast how deep it goes.
Start with the physical outcome, not the system. Write down the one or two physical things your business absolutely cannot have stop. Not the servers, the outcome. Planes moving, product shipping, patients monitored, power flowing. That is the top of the chain.
Now walk backward and list what each of those outcomes actually requires to keep happening. Push past the obvious control system. Keep asking what that needs, and what that needs, until people in the room start saying I think IT handles that. Every time you hear that phrase, you have found a dependency nobody truly owns.
Put a name next to each item on that list. Who is responsible for keeping it up, who would notice if it went down, and how fast could they tell the difference between a glitch and an attack. If a dependency has no clear owner, or the owner is a vendor you have never pressure tested, mark it. Those are the soft targets.
Then tabletop one ugly scenario end to end. Not the control system getting hacked. Pick a boring supporting service, the weather feed, the time source, the scheduling database, and declare it gone. Put your operations lead and your IT lead in the same room and ask each of them what happens next. Watch the moment one of them assumes the other has a workaround. That pause is your exposure, and it is the same pause that turned a weather outage into grounded flights this week.
Last, check what a stranger could learn about your dependencies. Your vendors, your manuals, your job listings, and your support tickets all advertise what your operation runs on. Read your own footprint the way an adversary would and you will see the shortcut they would take.
If those five moves feel uncomfortable, good. They are supposed to. They show that the risk was never really about the system with the biggest budget. It was about the quiet thing one hop away that holds the whole operation up, and the fact that no single person on your team was responsible for seeing the connection between an IT outage and a physical stop.
That connection is the work we do. We trace the chain from the physical outcome you cannot lose back to the forgotten service that can take it down, across the line where your physical and IT teams stop talking to each other. A pure cyber shop maps your network and never sees the runway. A pure physical team guards the operation and never sees the server that feeds it. We sit in both chairs, so we find the soft dependency before someone else does, and we help you decide what to do about it while it is still a line on a diagram instead of a ground stop.
We're based in Dallas, Texas, and we go wherever the problem is. Red Cell Security provides cybersecurity and physical security consulting to clients across the US and around the world.
Comments