Ransomware Containment for a Multi-Site Network

Picture a hospitality operator: dozens or hundreds of properties — hotels, restaurants, venues — each with its own local network of point-of-sale terminals, back-office machines, property-management systems, guest Wi-Fi, and building systems, all stitched back to a central corporate core for reservations, loyalty, finance, and reporting. Each site is small, but there are many of them, and they are connected. That connectivity is the whole risk. Ransomware that lands at one property and finds an open path can ride the inter-site links straight into the core, and from the core back out to every other site.

The defining characteristic of a multi-site incident is speed of propagation against a backdrop of thin local defenses. Individual sites rarely have on-premises IT staff; they have a manager and a support line. The machines are often a mix of ages and patch levels, sometimes running vendor-mandated legacy software that cannot be touched. So the architecture cannot assume you will detect and clean an infection at the edge before it spreads. It has to assume the infection is already moving and be built to slam doors shut faster than the ransomware can open them.

Containment, in this context, is a distinct engineering discipline from recovery. Recovery asks how you rebuild; containment asks how you stop the bleeding while it is still happening. For a multi-site network the containment question is specifically: when property number seven lights up, how do you prevent properties one through six and the corporate core from being next — in minutes, not hours, and without physically dispatching anyone.

The strongest containment work is done long before any incident, by shaping the network so that a compromise at one site is structurally unable to reach the others. The core principle is that inter-site connectivity should be a set of narrow, explicitly-permitted flows rather than a flat, any-to-any mesh. A property needs to talk to a handful of central services — reservations, payment authorization, loyalty, reporting — and it almost never has a legitimate reason to talk directly to another property's back-office network. So the design default is deny between sites, permit only the known central flows.

Modern SD-WAN and network-fabric tooling makes this enforceable and, critically, centrally controllable: the same control plane that defines which flows are permitted can be used during an incident to cut a site off from the fabric entirely with a policy change rather than a truck roll. We design that isolation capability in deliberately, so that 'quarantine site seven' is a control-plane action, not a phone call to someone at the property asking them to unplug a cable.

Within the central core, the same microsegmentation logic applies, because the core is the crown jewel — the one system every site connects to and therefore the one whose compromise is catastrophic. The core is segmented internally so that the reservation front-end cannot freely reach the finance database, and administrative access to core systems is tightly restricted. The honest trade-off is that this segmentation adds real friction to legitimate operations: an integration that used to 'just work' across a flat network now needs an explicit rule, and every new business need becomes a small change-management task. That friction is the cost of blast-radius control, and part of the engineering is keeping the rule set legible enough that it does not collapse under its own exceptions.

When an incident is live, containment comes down to two kill switches operated in parallel: isolating machines and locking down identity. EDR provides the first. With agents deployed fleet-wide and centrally managed, an operator can isolate a single infected host or, when the pattern warrants it, mass-isolate every endpoint at an affected site or matching a behavioral signature — severing their network access at the agent level while keeping them reachable for forensics. This is the fastest available way to freeze a spreading infection, and it works precisely because it does not depend on the local network still being trustworthy or on anyone being physically present.

The second kill switch is identity, and it is the one teams most often underestimate. Much of modern ransomware's lateral movement uses valid stolen credentials rather than malware exploits, which means isolating machines is only half the containment. The architecture has to make it possible to rapidly disable compromised accounts, force credential resets, and — the part that is frequently missing — revoke active sessions and authentication tokens, because an attacker with a live session keeps their access even after the password changes. We design for the ability to invalidate sessions and rotate the high-value secrets (domain admin credentials, service accounts, and the keys attackers pivot through) quickly and, ideally, in a scripted rather than manual way.

Both kill switches depend on a control plane that survives the incident. If the EDR console or the identity provider is itself reachable and compromisable from the production network, the attacker can blind your response. So the management planes for EDR, identity, and network are treated as protected tier-zero infrastructure with their own isolated administrative access — and we design a break-glass path: a small set of pre-provisioned, strongly-protected emergency credentials and an out-of-band way to reach the consoles, so that responders can still act even if the normal administrative avenues are exactly what the attacker took over.

You cannot contain what you cannot see, and the specific weakness of a multi-site estate is fragmented visibility — each site a silo, no single place showing that the same indicator just appeared at three properties within minutes. So the architecture centralizes telemetry: EDR events, authentication logs, network flow data, and DNS activity from every site stream to a central platform (a SIEM or equivalent) where they can be correlated across the whole estate. The unit of detection becomes the pattern across sites, not the alert at one.

That central view is what turns containment from reactive to anticipatory. When telemetry shows the same credential authenticating at multiple properties in impossible succession, or the same malicious process hash appearing at several sites, responders can pre-emptively isolate sites that have not visibly detonated yet but are clearly on the attacker's path. The design intent is to let the defender act on the campaign, not just the individual infection.

The operational counterweight is alert fatigue and cost. Centralizing telemetry from many noisy sites produces enormous volume, and a stream nobody can triage is worse than useless because it buries the signal. So the design includes tuning, aggregation, and clear correlation rules from the start, and it defines who watches the console and how alerts escalate. We are honest that this is an ongoing operational commitment, not a one-time deployment: the value of centralized visibility decays quickly if the tuning and the watching are not sustained.

All of this capability has to collapse, under pressure, into a decision procedure someone can actually follow. The containment runbook defines the triggers for declaring an incident, names who holds the authority to isolate a site or lock down identity estate-wide, and sequences the actions: isolate confirmed-infected hosts, cut affected sites from the fabric, disable and reset compromised credentials, revoke sessions, protect and verify the tier-zero management planes, then widen the net to sites showing precursor indicators. Because the highest-leverage containment actions — cutting a whole property offline, forcing an estate-wide credential reset — are also disruptive to a running business, the runbook pre-authorizes them against defined criteria, so responders are not negotiating permission to act while the infection spreads.

We design these actions to be as scripted and rehearsed as possible, because the difference between containing an incident and merely documenting one is usually measured in how fast the first correct action is taken. Tabletop exercises that walk the team through a simulated multi-site outbreak surface the gaps — the site that turned out to have an undocumented flat link to its neighbor, the service account nobody knew how to rotate, the console that could only be reached from the network now assumed compromised — while those gaps are still cheap to fix.

The honest limits deserve stating. Containment reduces damage; it does not prevent the initial compromise, and aggressive isolation carries a real cost — cutting a property offline stops the ransomware and also stops that property operating, so there is a genuine business trade-off in every isolation decision, which is exactly why the authority and criteria are settled in advance rather than argued mid-incident. Containment also does not, by itself, get you back to normal; it buys the clean, bounded starting point from which recovery and rebuild proceed. And it says nothing about data already exfiltrated before containment closed the doors. We build containment to do one thing well — stop the spread across the estate quickly and decisively — and we are careful not to let a strong containment posture masquerade as a complete answer to ransomware on its own.