When several serious cybersecurity stories break in the same week, the pressure on security teams is immediate. Executives want to know whether the company is exposed. People responsible for keeping systems safe and operational need to understand what an emergency fix might disrupt. The security team has to make decisions before it has all the answers.
The cluster of serious vulnerability disclosures and security incidents this October has been dubbed “Black October.” For me, the lesson is that organizations need to practice the full response, including what happens when containing an attack disrupts a service the business depends on.
Some of October’s headlines concerned newly disclosed vulnerabilities. Others involved confirmed compromises. We should be careful not to treat them as evidence of the same thing. A researcher demonstrating an exploit tells us something important about what’s possible. It doesn’t tell us how many businesses have been breached.
Revisit assumptions about software risk
PHP2Shell shows how AI is changing the effort required to exploit longstanding software flaws. Researchers used AI to help uncover vulnerabilities in PHP and develop working exploits.
Security teams may need to revisit vulnerabilities they’ve deprioritized because exploiting them no longer requires substantial expertise. Complexity still matters, and the researchers noted that they had to adapt exploits to different environments. But security leaders should question whether yesterday’s assessment of exploitability still holds.
The compromise of LiteLLM, software that connects applications to AI models, raises a different concern. Attackers distributed malicious software through a compromised release pipeline, putting credentials at risk. Replacing the software wouldn’t revoke credentials the attacker had already stolen, so affected organizations also needed to address that access.
These are different problems, but both reach into dependencies that organizations may struggle to see clearly. A business can secure its own application code and still be exposed through a third-party component or a compromised update.
Calling all of this AI-driven would get in the way of understanding it. The useful task is to identify what changed and decide which security assumptions need another look.
Test incident response through containment and recovery
My biggest lesson from October is to rehearse what happens after a team recognizes the problem.
Take a compromised software component. Finding every affected system can be difficult enough. Then someone has to work out which credentials were accessible from those systems, what those credentials allow, and whether they’ve been used elsewhere.
Containment gets harder when the affected system supports something the business depends on. Revoking access or taking a server offline could disrupt customer service, so whoever approves the action needs to understand the trade-off and have a plan to restore service safely.
Those decisions are much easier to work through in an exercise than during an incident. An exercise gives people room to discover that an inventory is incomplete or that two teams have different ideas about who owns a decision.
The same scrutiny needs to apply to security automation. An agent might spot suspicious activity correctly and still recommend an action that causes an unnecessary outage. Teams need to establish when the agent can act on its own and when someone needs to step in.
I wouldn’t end the exercise once the team detects the attack. Keep going until they’ve removed the attacker’s access and brought the affected service back safely. That’s where you’ll find problems an alert alone won’t reveal.
Use exercise findings to guide 2027 security priorities
Before year-end, I’d bring the security team and the people running an essential service into the same exercise to see how they’d handle an incident affecting it. Working through the response together can reveal where they’re waiting on each other or where containing the attack would disrupt the service.
What goes wrong in that exercise should help shape the work for 2027. If the team loses time waiting for approval to isolate a system, for example, they’ll need to agree on who has that authority before they face the same delay during an attack.
Black October has already generated plenty of warnings. The useful outcome is a team that can point to a weakness it found, explain what it changed, and show that the response works better when tested again.
Lee Rosseyis co-founder and CTO of SimSpace. Previously, he established and led the Cyber System Assessments Group at MIT Lincoln Laboratory, overseeing cyber range development, red teaming, and the testing and evaluation of more than 30 DARPA programs. His work for the Department of Defense helped lay the foundation for the National Cyber Range Complex and the Persistent Cyber Training Environment.
