The alert came in on a holiday. Mohana "Mo" Balakrishnan was off, his phone buzzed, and an early warning system on the network was reporting a sweep scan from an employee laptop.

He did the reasonable thing. He found the user and asked what was going on. The laptop had been closed all day.

"I said, hey, just take it off the network and keep it offline. We'll take a look at it when we get back to work. And I left it at that."

He talked himself out of the bigger response on the theory that a botnet had probably parked itself on one machine.

"My gut instinct should have been to shut down the perimeter."

By the time Mo was back at his desk, the damage had already begun. The team had to determine how the attacker entered, how far they had moved, and whether any part of the network could still be trusted.

Mo is now CTO at Schools Insurance Authority. In January 2021, he was SonicWall's security architect, having joined the company years earlier at the bottom of its London office.

On Episode 14 of the Full Metal Packet podcast, hosts Yegor Sak and Alex Paguis walk him through what the response looked like from the keyboard. The shutdown is the headline, but the harder question is how to bring a company back without reopening the same paths an attacker may still control.

TL;DR

• Escalate ambiguous canary alerts. If a device appears active while its owner says it is offline, investigate the identity and perimeter path instead of treating the endpoint as the whole incident.
• Build segmentation before you need it. Without internal boundaries, the only reliable containment option may be to disconnect the entire company.
• Prepare an out-of-band communication stack and a staged restoration procedure. During recovery, open only verified host-to-host paths rather than restoring broad access at once.
• Restrict server egress and collect logs from across the environment. Containment confidence comes from removing useful paths and observing what remains, not from claiming certainty that nobody is still inside.
• Keep an incident playbook, tested backups, and current contacts for legal counsel, cyber insurance, incident response, and law enforcement.

You Cannot Contain What You Cannot See

When Alex asks how the incident began, Mo goes back to the warning signs. The canary had correctly detected a network sweep, but the activity appeared under a real employee's credentials. The employee said the laptop was closed, so Mo treated it as one compromised endpoint rather than evidence that somebody had entered through the remote access system.

What the team later reconstructed was an attacker exploiting a zero-day in the company's own secure remote access product, logging in with that user's credentials, and scanning the network from behind the VPN.

The reason the team had any options at all is that Mo could reconstruct that attack path within hours. They had a SIEM that he had built and architected, and it was pulling enriched telemetry from across the estate. That gave the team a story rather than a symptom. The attacker came in through the VPN aggregator, moved laterally from one network to another, and ran scans along the way.

"You need good logs. You need good logs. You need logs from all your different sources, telemetry. You need a SIEM."

Every decision that followed depended on knowing roughly where the attacker had been. Without that visibility, the honest assumption is that any reachable system may be affected.

The canary was the other half, and Mo is unsentimental about missing what it meant.

"Canaries will save your ass. You gotta put those into your network because in a firefight they're going to alert you and give you those seconds, those precious minutes and seconds."

The canary worked. The failure was treating its signal as an endpoint problem when the contradiction around that endpoint pointed to a wider access problem.

Cutting The Line

Yegor asks what Mo did once the team understood the severity of the incident. The answer is blunt.

"We shut everything down."

They did not isolate one segment or block one address range.

"We literally unplugged the internet router."

The workforce was fully remote at the time, and Mo is direct about what that cost.

"You can imagine what chaos that did to a remote workforce."

The network had no meaningful segmentation, so the team had no smaller blast radius to isolate. Pulling the cable was the containment mechanism available to them. Even in hindsight, Mo says the disruption was enormous and the decision was still right.

When Yegor asks how quickly the complaints began, Mo explains that two things kept the shutdown from becoming total. The productivity suite was already in the cloud, so Microsoft 365 stayed up and email kept moving. His colleagues also gave the response team room.

"Everybody in engineering who used to give me a lot of grief about this, that or the other just gave me space."

Devon Ackerman arrives at the same framing in Episode 8, where the argument is that prevention is the wrong goal and containment is the measurable one. Mo's problem was that the internal network gave him nothing smaller to contain.

The Call At Hour Twelve

Before the story reaches the recovery call, Yegor asks Mo to separate the architect's job from the CISO's. The architect is on the keyboard, reading logs, working out the blast radius, and containing what they can. The CISO is working with executive leadership on communications, calling the cyber insurance provider, and bringing in the response teams that the insurer already keeps under contract.

That division matters because Mo's lane was the technical path back. Around twelve hours in, leadership needed to know how the company could resume operating.

Mo is careful about this part. When Yegor asks how a technical team should handle pressure from leadership, Mo says that SonicWall's leaders gave the team space, brought in Mandiant and Microsoft DART, and let the technical people work. The difficult moment was not a hostile executive demand. It was a call where the available choices had narrowed to leaving the network down or switching it back on, and where the people senior to Mo were quiet.

"I don't think we should do this. There's another way to do this."

He proposed keeping broad access closed while rebuilding only the paths people could justify. He is specific about how clearly that plan had to be delivered.

"I couldn't be wishy-washy or I couldn't be a little bit uncertain about what the path forward is."

He credits his inexperience for his willingness to speak. The practical lesson is that silence on an incident call can be mistaken for agreement with the fastest available option. A technical leader who rejects that option needs to explain the alternative, its sequence, and how long it is likely to take.

This is why Mo describes a breach as a communications battle before a technical one. Once the plan was accepted, much of the work became procedural. Getting the room to accept a slower, controlled recovery was the difficult part.

Rebuilding Out Of Band

The rebuild depended on infrastructure that did not exist the day before.

A colleague in IT stood up a parallel stack with a new domain, a separate Google Workspace, and a separate Jira. Corporate communications were suspect because nobody knew how much access the attacker had, whether they had persistence, or whether they were reading email. The recovery therefore ran somewhere the attacker had never been.

From there, the process was manual and deliberately narrow. Engineering leaders filed tickets. Mo wrote explicit host-to-host firewall rules, one at a time, opening a known good machine to a known good server and nothing else.

When Yegor checks whether the team had built an entirely new network and burned the old one down, Mo corrects him. They restored the existing network in a controlled way because that was faster than building a clean environment from scratch. Every path had to be deliberately recreated and verified at both ends.

In parallel, Mandiant, then FireEye, and Microsoft DART ran the forensics. Mo is explicit that he is naming the vendors they happened to use and that other firms provide the same kind of response work.

Backups, And Why Mo's Confidence Is Not Universal

Only part of the estate was encrypted before the shutdown, and Mo credits early adoption of cloud backup for the rest.

"Backups will always save you."

Alex immediately supplies the condition.

"Unless they're also encrypted."

That exchange matters because backup is not one control with a universal result. In this incident, cloud copies gave the team something usable to restore. In Episode 12, Zach Lewis walks through a LockBit incident where every planned backup layer failed in turn and recovery survived on a single credential someone had saved against policy.

A useful backup must remain reachable when normal identity infrastructure is down, exist somewhere the attacker cannot delete it, and have a restoration process the team has tested.

How He Knew They Were Out

Yegor asks Mo when he became 99 percent confident that the breach had been contained and the attack path had been eradicated. Mo does not accept the percentage.

"I don't know if we ever had that full confidence."

Instead, he explains the control that gave the team a defensible operating position. The server network had been allowed to reach almost anywhere online.

"Our outbound policy was terrible. It was just like go anywhere on the internet."

There was no meaningful separation between the server network and the user network beyond IP addressing. A permissive outbound rule makes command and control easier because an attacker can reverse proxy out and preserve a channel even when the front door is closed.

The team removed that path by cutting outbound internet access for servers.

"How could they have control when they have no line of sight? So I cut off their line of sight."

That did not prove that every foothold had disappeared. It removed the normal external route that would let a retained foothold receive commands or send data. Mo's answer replaces an unsupported claim of certainty with a control the team could inspect and enforce.

The Project That Nobody Would Fund

The company had been advocating microsegmentation to customers for years. Internally, the migration was priced, considered, and declined as too costly and too much effort.

"After the breach, that calculus changed completely."

What followed was a rebuild into a heavily microsegmented network with zero trust controls, and Mo says it is largely still in place. Alex asks the operational question that follows: if people still need to cross between segments, how do you decide where they are allowed to land?

Mo's answer is a policy engine that evaluates identity and real-time telemetry, then decides whether a user should receive an address on a particular network or have that access revoked.

"If this breach had never happened, we would never have migrated and evolved to the network that we had put in place post-breach."

He names process failures alongside the architecture. Security standards were not universal across corporate and engineering environments, and the lab ran with looser controls on the theory that lab machines are just lab machines. He also says, with some uncertainty about the exact build, that the exploited appliance was running alpha code.

"I get it, eat your own dog food. But sometimes you're eating dog shit and not dog food. You don't want to run your alpha code on the front end of your network."

What He Would Tell You To Do Before Any Of This

Mo's first recommendation is to have a playbook. The team did not.

"We kind of winged it."

His second is to call the cyber insurer early, which he counts among the things they got right alongside involving the FBI. Insurers often have incident response firms under contract, which can shorten the time required to bring the right people into the response.

He also gives a language warning. The word breach carries legal and notification consequences. Until the facts and legal counsel support it, describe the event as a security incident.

Earlier in the conversation, he explains why preparation has to account for asymmetry.

"The attacker only needs to get right once and you always have to be right."

Paul Bleicher works from the same constraint in Episode 13, where the problem is that fixing every flagged vulnerability would consume years of engineering capacity. Both conversations end at prioritization: defenders cannot do everything, so they need evidence for the controls and decisions they choose.

Asked for one takeaway, Mo gives a direct answer.

"Be prepared."

Preparation does not guarantee that an organization prevents a breach. It gives the response team a way to find out what is happening while there is still time to act.

"You'll want to know in the middle of that what's going on."

Where The Perimeter Went Next

Yegor asks Mo to explain a phrase from his writing: the prompt perimeter. Mo begins with the previous versions of the perimeter.

It started as a castle and a moat, with a firewall at the edge. Defense in depth added an email security gateway and other layers behind it. Zero trust followed from the assumption that attackers would get inside and needed controls around internal access. Identity became the next perimeter because stolen credentials were often the path to that access.

These layers accumulated rather than replacing one another. A strong edge, defense in depth, zero trust controls, and identity protections still matter. Mo argues that organizations must now add the prompt because sensitive inputs and unsafe outputs can move through browsers, IDEs, terminals, personal accounts, corporate tenants, and local models.

Yegor asks whether running a model locally changes that equation. Mo calls local deployment an architectural choice, but says it does not remove the need to inspect what enters and leaves the model. Alex separates the risk into three areas: the information entered into the model, the output it produces, and the systems or data an agent can access.

That exchange makes the prompt perimeter more concrete. The interface changes, but an organization still needs policy, logging, and an audit trail around prompts, outputs, and agent actions. Mo's argument is that there is no good universal control plane for all of those surfaces yet.

The same attacker-defender asymmetry applies to AI. Alex offers an example: an attack technique that works 80 percent of the time would be extraordinarily useful to an attacker, while a defense that works only 80 percent of the time would be a serious failure. Mo agrees that defenders need reliable autonomous agents, not simply more autonomous behavior.

Cutting Line Of Sight At The DNS Layer

Mo's response depended on two things: telemetry that showed where the attacker had moved and outbound controls that removed useful paths from the network. DNS activity contributes to both because most outbound connections begin with a resolution request.

These Control D tools and capabilities help security teams inspect and retain that part of the outbound picture:

• DNS Leak Test shows which resolver is actually answering your queries, which is the first thing to establish when the outbound path is uncertain.
• Dragonfly returns a domain's category, DNS records, TLS data, and WHOIS information for a lookup the team cannot immediately place.
• DNS logging records queries with device and user attribution, so investigators can identify which endpoint requested a domain.
• SIEM data streaming puts DNS activity on the same timeline as firewall and endpoint events during an incident.

The Control D guide to DNS logging best practices explains what to capture, how long to keep it, and how to stream the records into a SIEM.

DNS visibility does not replace segmentation or endpoint forensics. It gives the response team another inspectable record of what systems tried to reach, which helps answer the question Mo keeps returning to: what is happening right now, and what path still needs to be closed?

Continue the Argument

• Episode 8: Ex-FBI Agent: One Phone Call Gave Hackers Full Network Access examines why containment is a more useful security objective than promising prevention.
• Episode 12: How a University CISO Refused a $1.25M LockBit Ransom Demand shows what recovery looks like when the expected backup layers fail.
• Episode 13: Why Top Security Teams Deliberately Leave Vulnerabilities Unpatched asks how defenders make and document risk decisions when they cannot fix everything.
• Browse the Full Metal Packet series for more conversations with security operators and leaders.

Common Questions Answered in Episode 14

What should a security team do when a canary alert conflicts with what the user reports?

Treat the contradiction as a reason to expand the investigation. If a device appears to be scanning while its owner says it is offline, check whether the activity could be coming through stolen credentials, a VPN, or another identity path. In this incident, the canary worked, but the signal was initially treated as one compromised laptop.

When is disconnecting an entire company from the internet justified?

When the team has evidence of active compromise and no smaller boundary it can trust. A segmented environment may allow responders to isolate one zone, account, or service. Without those boundaries, disconnecting the perimeter may be the only available way to stop continued access while the team investigates.

What is an out-of-band incident-response stack?

It is a set of communication and coordination tools that sits outside the potentially compromised environment. The response described in the episode used a separate domain, Google Workspace, and Jira instance. This let the team coordinate without assuming that corporate email or chat was private.

How should access be restored after a network-wide shutdown?

Restore only the paths the team can justify. In the episode, engineering leaders submitted requests and the response team created explicit host-to-host firewall rules between verified machines and servers. This is slower than restoring broad connectivity, but it gives responders a clear record of what access exists.

How can a security team know that an attacker is out of the network?

Complete certainty may not be available. The practical alternative is to remove the paths an attacker would need and monitor for continued activity. Mo's team cut outbound internet access for servers so a retained foothold could not use the normal route to external command and control.

What is the difference between an architect's role and a CISO's role during an incident?

The architect works on the immediate technical questions: what happened, how far it spread, and how to contain it. The CISO works with leadership, legal counsel, insurers, and outside response teams on communication, resources, and organizational decisions. The work happens in parallel.

Are backups enough to recover from ransomware?

Only if the copies remain available and can actually be restored. Useful backups must survive the compromise, remain accessible when normal identity systems are unavailable, and have a recently tested restoration process. Cloud backups helped in this incident, while Episode 12 presents a case where the planned backup layers failed.

When should an organization contact its cyber insurance provider?

Early in the incident. Insurers often have response firms already under contract and can help activate forensic and legal resources. The episode presents the early insurance call as one part of the response that worked well.

When should a security incident be called a breach?

Only when the known facts and legal counsel support that term. Breach can trigger legal and notification consequences. Mo's guidance is to use security incident while the team is still determining what occurred.

How long does recovery from a breach take?

There is no universal timeline because restoring operations, completing forensics, and rebuilding controls are different jobs. In this case, much of the company was back online within a few days, while the investigation and wider changes continued much longer. Mo describes the first month as the worst 30 days of his life, which conveys the intensity rather than a standard recovery period.

What is microsegmentation?

Microsegmentation divides an internal network into smaller zones and controls the paths between them. If one host or identity is compromised, the attacker cannot automatically reach everything nearby. The episode shows the operational cost of not having those internal boundaries before an incident.

What is the prompt perimeter?

It is Mo's term for applying security policy and visibility to what people enter into AI systems, what those systems return, and what connected agents can access or do. The model may run in a browser, IDE, terminal, corporate tenant, or local machine, so the control problem extends beyond one interface.

Mohana "Mo" Balakrishnan is CTO at Schools Insurance Authority. He began his career as a geophysicist in the James Bay Lowlands, living in a tent at minus 60 while looking for chromite, before moving to London and joining SonicWall at the bottom. He went on to become its security architect and later served as CISO at the University of the Pacific.

Full Metal Packet is hosted by Control D co-founders Yegor Sak and Alex Paguis. Watch Episode 14 on YouTube, or listen on Apple Podcasts, Spotify, or wherever you get your podcasts.