Why Attacker Dwell Time Is Exposing the Shortcomings of Legacy SIEMs

The cybersecurity metric that should concern us most is not necessarily the number of vulnerabilities published this week, the latest malware family, or whichever threat actor just got a flashy new name. It’s the amount of time attackers are able to remain in an environment undetected before someone finds them and kicks them out, otherwise known as attacker dwell time.

The reality is that, for many organizations, attackers spend far too much time in their environment once they’ve been compromised – an average of 241 days according to the latest reporting. This gives them ample time to perform reconnaissance, move laterally, disrupt systems, steal data, and stage additional attacks. 

As an industry, this tells us we’re doing something wrong. While we’re hyperfixated on the latest APT, we’re not doing enough to monitor the rest, like the opportunistic hackers operating out of their garage just trying to make a quick buck. As a result, too many organizations are still treating the problem like it can be solved with more out-of-the-box detections, IOC feeds, ATT&CK mapping, and dashboards that make the red boxes turn green.

Some of that has value. Known-bad indicators are not useless. If a hash, domain, IP address, etc. is obviously malicious, alert on it. The problem is what happens when the attacker does not use yesterday’s vulnerability, does not trigger the prebuilt rule, and does not behave in a way that some vendor could have predicted across every customer environment.

That is where the one-size-fits-all SIEM mindset starts to break down.

The traditional approach assumes defenders already know what they are looking for. Collect the approved log sources. Normalize them into a schema. Apply a huge pile of detection content. Generate alerts. Map it to a framework. Generate alerts. Build the dashboard. Generate alerts… oh God, the alerts. Show “coverage”.

But “coverage” can be a slippery word. Out-of-the-box coverage is, by definition, lowest-common-denominator coverage. It has to work across many organizations, which means it cannot deeply understand any one organization. Is it ok for a detection rule to bypass itself if the DNS request came from pirate streaming software in YOUR organization? Because out-of-the-box rules are full of exceptions like that. The problem there is that every organization is different; it operates differently, its employees behave differently, and they care about different things. 

A generic rule can tell you something that is commonly suspicious. It cannot tell you that, in your environment, this specific machine should only ever talk to that specific controller on that specific port. It cannot know that this service account should never be used from that subnet. It cannot know that this DNS behavior is abnormal for your business but not abnormal for someone else’s.

That context matters because a lot of attacker activity does not look malicious in isolation. It just looks like normal technology being used in the wrong way.

That is especially true as attackers continue to live off the land. DNS, PowerShell, scheduled tasks, service accounts, SMB, remote management tools, and cloud storage links are not inherently malicious. They all have legitimate applications in enterprise environments. The badness is in the context around who used it, where it ran, what happened before, what happened next, and whether that sequence makes sense for the system involved.

SIEMs struggle with this because they were not built for the kind of flexible, messy, environment-specific investigation that modern threat hunting requires. They were built around predefined data, predefined parsing, schemas, and detections. That model works until the investigation gets weird. And cybersecurity is mostly about the weird.

Sometimes, the evidence of compromise is one log line buried in terabytes of data. Sometimes the interesting activity is spread across SharePoint, Sysmon, Zeek, Windows Defender, DNS, SMB, and syslog. Maybe the attacker’s communication is split into chunks and shoved through DNS queries, but those queries are carrying recon data, audio, video, or some other payload you will never understand if your investigation stops at “bad domain.”

That is the real issue with IOC-first security. It encourages teams to stop too early.

A domain looks suspicious, so we block it. A file hash is known to be bad, so we quarantine it. A rule fires, so we open a ticket. Fine. But what did the attacker actually do? What did they touch? Which systems were involved? Was data exfiltrated? Was the payload reconstructed? Did the behavior happen elsewhere under a slightly different domain? Did the rule catch the tactic, or did it just get lucky?

This is why dwell time exposes the shortcomings of SIEMs. If attackers are living in environments for weeks or months, the answer is not simply more rules written by someone else. The answer should be better visibility, longer retention, much more flexible querying, and a deeper understanding of what is normal inside the organization.

That is Defender Advantage.

Defender Advantage comes from knowing your environment better than the attacker does. This is where generic detection and framework-driven thinking hit a wall. Frameworks like ATT&CK are useful organizational tools. But if they become a coverage map divorced from actual telemetry, they can create a false sense of security. “We detect this technique” is not enough. With what data source? At what fidelity? With how much retention? Against which systems? With what blind spots? A green box on a slide does not mean you can actually investigate the incident when it matters.

The same applies to AI. AI can help accelerate security work, but it does not magically solve context. Context is the hard part, and AI has a very limited context window. An AI model does not inherently know your weird legacy application, your OT network, your developers’ habits, your business workflows, or the device that should never initiate outbound traffic except during a maintenance window. That knowledge lives with people: security analysts, engineers, IT teams, developers, and operators. It lives in terabytes and terabytes of log data. Is it any mystery why “AI will save us” vendors also advocate you should shrink your log data and throw all that pesky “waste” away?

Trying to replace that human context with generic automation is how organizations end up being faster at missing the point.

Reducing dwell time requires a different mindset. Keep the raw data and keep it long enough to matter. Do not throw away evidence just because it is expensive, ugly, or inconvenient. Give analysts the ability to parse on the fly, inspect nested fields, reassemble activity across events, decode payloads, baseline systems, and ask new questions of old data. Let teams turn internal knowledge into detection logic. Let them hunt for what is abnormal in their environment, not just what is globally known to be bad.

Attackers already know how to hide in the gaps between tools, teams, and assumptions. Defenders need to close those gaps with visibility, flexibility, and a better understanding of themselves. 

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

Notice how Sun Tzu doesn’t say anything about knowing your enemy but not yourself? Because that would be silly. Even in modern times, this ancient wisdom holds true. While defending their organizations from attacker activity, security teams should be taking it to heart.