Byline: Nikola Petrovic
Accelerating Attacks. Our Detection Processes Are Still Running on Human Time.
In one of my previous roles, I regularly dealt with incident reports. Most of them arrived ex post. An incident happened, the immediate issue was handled, and a report followed afterwards explaining what went wrong, what the impact was and what needed to change. Unless it was a critical incident requiring an immediate hotfix, this approach was generally considered acceptable.
And to be fair, it worked.
Teams had enough time to investigate. Security could collect evidence. Engineering could reproduce the issue. Management could review the impact. Everyone came together to discuss the root cause and define the follow-up actions and lessons learned.
But I am increasingly wondering whether this model still will work for the AI economy. My instinct is telling me no.
Not because incident reporting itself is wrong. We absolutely need documentation, root-cause analysis and accountability.
The problem is speed.
Attackers can now discover weaknesses, test different approaches and adapt their tactics much faster than before.
Meanwhile, many enterprise detection and response processes still depend on alerts being reviewed manually, context being collected across different systems and several people agreeing that the situation is serious enough to act.
The attack is accelerating. The response process often is not.
When people talk about incident response, they often focus on containment and recovery.
How quickly can we isolate the affected machine? How quickly can we patch the vulnerability and how fast can we restore the service (most important one)?
But before any of that happens, someone first needs to understand that there is an actual incident. This is where I see one of the biggest risks: detection lag.
Detection lag is not only the period between an attacker entering a system and an alert being generated. The alert might already be there, whichs is fine, but…
The bigger delay can happen afterwards:
Every individual step might be reasonable. Together, they can create a dangerous delay. And they actually do delay.
In the past, that delay may have given an attacker several hours to work. Today, even a few minutes can matter, if not seconds.
A recent example made this very tangible for me.
Anthropic reported that its Mythos Preview system had identified thousands of high-severity vulnerabilities in foundational open-source software, including software used across major operating systems and browsers. One analysis referenced an estimated 6,202 high- or critical-severity findings, while only a small portion had reportedly been addressed at that point. the important point is not whether every finding becomes a real-world exploit.
The important point is that vulnerability discovery itself is being industrialised.
Software that has existed for years, has been reviewed repeatedly and is considered reliable can now be examined again at a completely different speed and scale. We are speaking about thousands of issues detected.
The same capabilities can support defenders. That is the good part.
But we also need to assume that these capabilities will become more widely available and will not remain exclusively in the hands of responsible security researchers.
“Stable” software does not automatically mean safe software.
“Widely used” does not mean nobody will find another weakness.
And “we patched similar issues before” does not mean the next issue will give us the same amount of time to react.
That is the wake-up call. Time changed, the entire infrastructure changed, and is actually being changed.
The obvious response would be to increase monitoring. Add more tools. Add more rules. Collect more logs. Generate more alerts. I am not convinced this solves the problem.
Many security teams already have enough alerts. In some cases, they have far too many.
The issue is not always that suspicious activity was invisible. The issue is that the signal was buried among hundreds of other signals or lacked enough context for someone to act confidently.
A login from a new location may not be critical. A large download may not be critical. A newly created access token may not be critical. But when these events happen together, within a short period, around the same identity (another big gap to be closed with AI Agents), the picture changes completely.
Attackers do not operate as isolated alerts. They operate through sequences. Our detection needs to understand sequences as well.
Enterprise security teams are understandably careful about automated action.
Locking an account, disabling a service or isolating a production machine can cause real business damage. Nobody wants the security system to create the outage it was supposed to prevent.
Because of that, organisations often wait until they have strong evidence before taking action. That makes sense when the attacker is moving slowly. It becomes dangerous when the attacker is moving at machine speed.
I do not believe the answer is to automate every security decision. That would create a different set of problems. But I do think we need to stop treating response as a binary choice between doing nothing and shutting everything down. There should be several steps in between.
For example, when an identity starts behaving suspiciously, the organisation could:
They are ways to slow the attacker down while the investigation continues.
That may become one of the most important defensive concepts: do not wait until you understand everything. Create friction as soon as the risk becomes meaningful.
I have been thinking about what organisations can do now without starting another two-year security-transformation programme.
A few actions seem practical.
Many teams measure when an alert was created and when an incident was closed. That is not enough.
We should also measure how long it took before somebody understood:
It is fast notification followed by slow understanding.
During an active incident, valuable time is often lost deciding who has the authority to do what.
Organisations should define in advance which actions security teams may take without executive approval. Requiring reauthentication is different from shutting down a production environment. Revoking a suspicious session is different from disabling an entire customer-facing system.
The lower-impact actions should not become stuck in the same approval process as the most disruptive ones.
Most attacks eventually touch identity.
A user account, administrator credential, service account, API token or machine identity is used to access something valuable. Instead of only examining separate events, defenders should connect activity around the identity:
This can reveal the attack before every individual event becomes severe enough to trigger a critical alert.
Many organisations are not yet comfortable with automated containment. That is fine.
A good first step is to automate the preparation of the decision.
When an important alert appears, the analyst should not need to open six dashboards and contact three teams just to understand the situation.
The system should automatically prepare an evidence package containing the affected identity, device activity, recent access, relevant changes, data sensitivity and available containment options. The human still decides. But the human starts with context instead of starting with a blank screen.
Many incident-response exercises test whether people know the process.
Who calls legal? Who informs management? Who writes the report?
Those questions matter, but the exercise should also test whether the organisation can react before the fictional attacker completes the attack. Give the team five minutes, not five hours. Change the situation while they are discussing it.
Let the compromised account create another token. Let it access another system. Let it begin downloading data.
That will quickly reveal where approvals, ownership and technical visibility are slowing everyone down.
I do not believe AI suddenly makes every security setup useless.
But it changes how long we can assume that an undiscovered weakness will remain undiscovered. It also changes how quickly an attacker can move after finding that weakness.
This means our defensive advantage cannot depend only on prevention.Prevention will fail somewhere.
The advantage must come from how quickly we notice unusual behaviour, how quickly we understand its meaning and how quickly we create friction for the attacker. The traditional incident report will still be important.
We still need to know what happened and why. But an excellent report produced two weeks after the incident does not help much if the attacker only needed ten minutes.
The real question for enterprise defenders is becoming very simple:
When the next attack begins, will we recognise it and slow it down before the attacker has already moved on?
My view is simple: enterprise security teams need to stop measuring success only by whether an alert was generated and start measuring how quickly the organisation understood the risk and acted on it.
The practical direction is to reduce the gap between signal and decision through better context, pre-approved low-impact containment actions and faster evidence collection.
We do not need to automate every security decision, but we do need to create friction for attackers much earlier. In an AI-accelerated environment, speed of understanding will become just as important as strength of prevention.
Hackers are actively probing AI systems, turning exposed gateways and agent tools into routes for…
Hackers are making some phishing pages harder to track by changing the code delivered to…
A cyber incident reportedly forced a British power plant to halt operations for about four…
Russian hackers have used a new backdoor called HOOKEDGE to target defense manufacturers, government bodies,…
TITAN ransomware is pairing file encryption with an ambitious claim: artificial intelligence that can sort…
A fake student resume is being used to place a remote-access tool on researchers’ Windows…