Against the Clock: Cyber Incident Response Plan
Experts generally agree that cybersecurity breaches are inevitable. The only real variables are when they will happen, how severe they will be—and how prepared an organization is to handle them. Advanced defenses are essential, but a strong security posture must also include a well-defined incident response process.
While that process will vary based on each organization’s unique circumstances, it should cover the steps involved in identifying, containing, and recovering from a successful attack, as well as all responsibilities and communication channels, legal counsel involvement, and post-resolution procedures.
The following fictional scenario illustrates what that might look like in action based on Trend Micro’s experience helping organizations define, implement, and manage incident response plans. The situation: a global metal fabrication company’s security operations center (SOC) team picks up a network anomaly and calls in Director of Incident Response Stacy Bell…
Incident response process: The alert
My phone rang just before 8:30 on Friday night. It was my SOC Manager, Raj, who said the team got an alert from an AV product on a file server in the Cincinnati data center. It didn’t look like much at first, but they probed a little and saw someone had installed remote management (RM) software, a program we’ve used before but not extensively—or recently.
Raj and I agreed we couldn’t take any chances. Two days ago, we’d received a bulletin from our cybersecurity vendor about a ransomware threat targeting manufacturing companies like ours. Before pulling the pin, the attackers were known to sit in a network for days or weeks using RM tools to siphon off data and propagate malware.
I drove in to the office, 20 minutes from my place at that hour. Raj and the team had already started to run our incident response playbook, the informal first step being to put on a pot of coffee because we all knew it could be a long night.
I quickly reviewed the incident response steps even though I knew them by heart. I was glad our XDR platform was up and running. My CISO and I had the chance to make the business case for XDR to the Board last year. They got it—the visibility, control, and speed we’d gain in situations like tonight’s. If there’s an attack in the network, one thing is ultra-clear: time is always of the essence.
Scoping the spread
The team used our XDR platform to run a callback server (C2) analysis. They confirmed an unauthorized IP address had established a remote connection to the file server. My stomach did a flip when they said data was exfiltrated, even though they assured me it was nothing sensitive or private. I told them to give a complete accounting to our legal team—they’d be the ones to judge our liability.
We isolated the server and took it offline.
The next step in our cyber incident response process was to find out if—and how far—the attack had spread. That meant two things: one, determining if any other endpoints were affected, here or at our locations worldwide; and two, pinpointing ‘patient zero’, the device where the attack originally got in. I’d been on teams that thought containing the first device found solved the problem, only to be hit again because other machines were infected.
We used network and endpoint sensors to ping every device in the company for interactions with the unauthorized IP address. A half-dozen instances came back: two in Canada, four in Estonia.
I tasked a couple of our SOC team members with isolating those devices, knowing we were still a long way from done. Threat actors often change domains mid-breach, making it highly unlikely that this initial IP address would be the only one we needed to watch for. We needed to look at every other incoming IP address and spot any more anomalies.
Rounding up the suspects
I was in constant contact with our CISO by this point, who was keeping our company exec up to date. The SOC folks were dialoguing with colleagues at our other sites. All of this happened outside of email and text messaging. Per the incident response plan, we used an encrypted messaging channel to make sure internal discussions stayed internal until we had a better understanding of the breach and its implications.
It was 9:43 PM EST and someone malicious was still in our network actively implementing a cyberattack. I put on my ‘zero trust’ hat, knowing every endpoint was a potential threat and had to be treated as suspect. We scanned our whole network again, all our devices, looking for signs of data loss, illegitimate software installs, or other potential indicators of compromise (IOCs).
All of that tracing exposed a handful more infected devices, yielded the malware hash we had to look for, and locked us in on ‘patient zero’: an IoT control module at the Estonia plant, breached 36 hours ago.
“Slam every door”
With XDR automation, we were able to rapidly upload all identified IOCs to our network firewalls for perimeter protection. That gave us an advantage: if there were infected machines we hadn’t found, we could watch the firewalls for blocked IOC-related activity, trace back, and mitigate. We also reset the network connections of all affected devices and ran sample queries to see if any ‘quiet’ machines—ones that hadn’t called out and been blocked by our firewalls—contained the malware hash.
Per our incident response process, we identified not just infected devices but also the associated users, restricting their privileges temporarily to prevent any misuse. Our plan spelled out when and how we needed to inform users of those constraints; we had a couple of team members on that.
At the same time, we started running analytics on our firewall logs for mass data transfers. We looked at the entire period from initial infection to present. Any data theft looked to be minimal and inconsequential—though, again, I knew our lawyers would be the ultimate judge of that.
With every infected device accounted for, patient zero identified, and containment measures in place, I thanked the team and asked what I always ask when a threat has been mitigated successfully: “Did you hear that? That was the door slamming.”
We’d repelled the attack in just over two hours, barely enough time to work through that pot of coffee. The XDR platform had been an undeniable help. Executing our incident response process manually could have taken up to 12 hours and we’d never have been as confident we’d found patient zero. I’ve always had full faith in my team, but there was peace of mind knowing not everyone had to be a superstar because we had good tech to back us up.
I was relieved it was over but also concerned. Despite our defenses and a good cyber incident response process, the bad guys got data and deployed malware. Yes, it could have been worse. We were lucky. But luck isn’t in my job description.
I talked to the team and we agreed to adopt a full zero-trust posture. It wouldn’t be easy. Zero trust is a discipline monster, but it massively reduces breaches and helps avoid close calls like the one we had tonight. We also agreed to review all our installed security software to make sure the right policies are in place for next time.
The best defense is a solid incident response plan
As the above story shows, a well-defined incident response plan is crucial to good cyber defense—covering not just technical steps but also clarifying decision chains, when to involve outside legal counsel, and how to communicate with customers, partners, and the public.
Organizations that are unsure how to develop a comprehensive cyber incident response plan can call on third-party partners for help. Trend Micro has partnered with Net Diligence to give customers 50% off that company’s Breach Plan Connect service, which helps develop customized incident response plans.
Next steps
For more Trend Micro thought leadership on a good cybersecurity incident response process, check out these resources:
To Fight Cyber Extortion, Shift Left
Incident Response Services & Playbooks Guide
Integrate Cybersecurity Incident Response in DevSecOps
Read More HERE
