The Ransomware Took The Cameras First
The front office found out the network was gone when a parent walked up to the glass and asked to be buzzed back to a classroom. The staff member reached for the button and nothing happened. Then she looked at the bank of monitors that should have shown every hallway and every exterior door, and the monitors were black. She picked up the desk phone to call the assistant principal and there was no dial tone. In the span of a morning a building full of children had lost the ability to see its own hallways, lock its own doors from the office, and call for help on its own phones. Nobody had kicked in a door to do it.
Somebody had encrypted a server.
That is roughly how it went at Richmond Public Schools, where a ransomware attack confirmed on 21 October left teachers staring at ransom notes on their laptops.
Ransomware is malicious software that scrambles an organization's files and holds the key for a payment. What the coverage led with was the data, because that is what ransomware is supposed to be about. What actually went down tells a different story. The Wi-Fi went. The cameras went. The desk phones went. The copiers, the Smartboards, and the student Chromebooks went. The attack did not just lock up records in a back office. It took out the systems a building uses to keep the people inside it safe, and days later the network was still down.
Most writeups will file this under school ransomware and move to the next victim. That misses the thing that changed.
The safety systems and the email now run on the same wire
Walk through how a building like this got wired and the problem explains itself. Twenty years ago the cameras ran on their own closed circuit. The phones ran on their own copper. The door controllers, the intercom, the fire panel, and the bell schedule were each their own little island with their own cabling, and none of them cared what the computers were doing. If the file server died, the cameras kept recording and the phones kept ringing, because they were not connected to the file server in any way.
Buildings are not wired like that anymore. The cameras are internet protocol devices, which means each one is a small computer that sends its video over the same data network that carries the email and everything else. The phones run over that same network as voice over internet protocol, usually shortened to VoIP, which is telephone calls carried as data instead of over their own dedicated line. The door access controllers, the intercoms, the public address system, and often the bell schedule were all moved onto that one network as well, because running a single network costs less and takes less staff than running six separate ones. Now that everything shares the same wires and the same servers, a network outage does not take the email and spare the cameras. It reaches the cameras, the phones, the doors, and the email together, because the different labels were always hiding the fact that they had become one system.
Plenty of people will read that and say their cameras and phones are in the cloud now, so a ransomware hit on the local servers cannot reach them. For a lot of buildings they have a real point. A cloud managed camera keeps its own recording on storage built into the camera and syncs a copy up to a provider, so encrypting a server in the closet does not erase the footage. Hosted phone service, the kind where the call logic lives at a provider instead of on a box in the building, keeps ringing when a local server dies. Some phone systems even run a local fallback on purpose, a feature called survivable remote site telephony, that holds dial tone when the link to the outside goes down. The flat claim that a camera stores nothing and a phone is a brick is wrong, and the people who actually run these systems will know it is wrong the moment they read it.
Cloud and hybrid systems do not come through the incident any better, they just fail for a different reason, and it is a reason almost nobody plans for. When a response team moves to contain a ransomware event, the first thing they do is pull the network. They isolate segments, cut the internet connection, and shut down switches to keep the malicious software from spreading to the machines it has not reached yet. That is the correct call for the data fight, and a good responder makes it fast. The same action cuts every cloud camera and cloud phone off from the provider they rely on to work, so the devices the attacker could not reach go dark anyway, taken offline by the people defending the network. A lot of this equipment is also powered straight from the network switch over the same cable that carries its data, which means shutting that switch to stop the spread kills the power to the cameras and phones in the same motion. By the end of it the on premises gear is down because its server got encrypted, and the cloud gear is down for the opposite reason, because the building cut itself off to survive. From the hallway it makes no difference which. The building cannot see, call, or control its own doors. That second path is the one that never makes it into a plan, because pulling the network does not feel like damage. It feels like the responsible thing to do, which it is, right up until you count what went dark with it.
Access control holds up longer than the cameras and the phones, for a reason worth understanding. Most door controllers keep a copy of the access rules locally and keep enforcing the last set they had even after they are cut off, so the doors do not all fail in the first minute. What you lose is visibility and control. You cannot see who badged through which door, you cannot lock anything down from a central point, and revoking a person's access while the incident is live is off the table. In the middle of an event that is still a serious loss, just a slower and quieter one than the cameras and the phones going black. The crew that hit this kind of network was almost certainly aiming at the data and the ransom. The physical systems were collateral, and whether they died from the encryption or from the containment, they went dark the same morning the rest of the building did.
The incident plan stopped at the data and the building was left standing there
Here is where the two jobs come apart. The incident response plan, the document that lays out what an organization does when it gets breached, is almost always a technical plan written by technical people. It covers isolating infected machines, preserving evidence, calling counsel, working with the insurer, and deciding whether to restore from backup or pay. For the fight it was written for, it is usually a reasonable plan.
It has nothing to say about the building. It does not name who stands at the front door when the badge readers are down and anyone can pull the handle. It does not say how the office accounts for every child when the phones are dead and the intercom is silent. It does not say who is watching the parking lot and the side entrances now that the cameras show nothing, or how a teacher in a far classroom calls for help with no phone and no network. Those are physical security questions. The people in the room during a ransomware event are the information technology team and outside incident responders, and physical security, if the organization even has it, was never called, because the whole thing got filed as a cyber event the moment the ransom note appeared.
So the breach creates a physical security emergency and routes it to people who are measured on getting the data back. They are not the wrong people. They are just not the people who own the question of how you keep eyes on a building and a count of the people in it while the systems that normally do that are offline. In most organizations that question has no owner at all, because the day it matters is the one day the cyber team and the physical team were supposed to already be the same team and were not.
What you can walk yourself this week
You can measure most of this before you call anyone, and the walk tends to show you how much of your physical safety is quietly leaning on a network nobody thinks of as a safety system.
Start with your own building and make a list of every physical safety function you would reach for in a bad moment. Seeing a hallway on camera. Locking an exterior door from a central point. Calling the front office from a classroom. Making a building wide announcement. Checking who badged through which door and when. Now take each one and find out where it actually lives. If it runs on a server in your own building, ask what happens to it the hour that server is encrypted, because the answer is that it stops. If it runs in the cloud, do not stop there and assume it is safe. Pull up your own incident response plan and read what the team is told to do first when ransomware hits. If it says isolate the network, cut the internet, and shut down switches, which is what almost every sound plan says, then you have just found the order that takes your cloud cameras and cloud phones down with everything else. What matters is not whether a system is modern but whether anything you would reach for in an emergency depends on a server the attacker encrypts or a network path your own people sever to contain him, and almost all of it depends on one or the other, and almost nobody has checked which of their safety systems survive either one.
Then do the uncomfortable part. Assume that network is down and walk the building as if it happened at 0830 on a full day. Stand at the main entrance with the badge reader dead and ask how anyone controls who comes in. Stand in a classroom with no phone and no network and ask how that teacher reaches anyone. Go to the office and ask how staff would account for every person in the building with no cameras, no intercom, and no phones. Do not let yourself answer we would figure it out. Figuring it out in the moment, with no plan and no practice, while a crisis is live, is the exact failure the Richmond building is living through right now.
Finish by looking at your incident response plan with one question in mind. The moment the network locks, who owns the building. Not the data. The building, and the people standing in it. If the plan covers servers, evidence, counsel, and restoration but says nothing about posting a human at an unlocked door or accounting for people with the cameras down, you have found the gap. In most organizations that gap is total, because the plan was written for a data problem and what you actually have during ransomware is a data problem and a physical security problem happening in the same ten minutes.
Work through those and the shape of it comes clear. This is not a question of a better backup, though you need one. It is that a cyber incident now lands in the physical world the moment the network carries the cameras, the doors, and the phones, and almost nobody has planned for the building as a thing that has to keep protecting people while the network is gone.
That is the work we do. We assess facilities and we plan and run incident response, so we can look at a ransomware event as the technical fight to get the network back and the physical problem of a building that went blind while you fight it. We map which of your physical safety systems depend on a server the attacker can encrypt or a network path your own team will sever to contain him, and which of them would actually fall over the day it happens. We write the branch of the incident plan that stands a human posture back up around the building when the electronic one drops, with a named owner and a way to account for people when the cameras and phones are dead. A cyber firm will work to restore your servers and never think about the unlocked front door. A facilities firm will plan your doors and never see the ransomware coming for them. The gap between restoring the network and protecting the building while it is down is exactly where we work.
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