How to prepare your SIEM to detect real-world cyberattacks

A SIEM can be fully deployed and well funded and still miss the attack that matters. That is rarely because the attacker was unusually clever. It is because the SIEM was built around the data that was easy to collect and the rules that came in the box, rather than around how real intrusions unfold.

Here is how to turn that around.

Start from the threats that are actually happening

The big annual reports agree on the shape of today’s attacks. Verizon’s 2026 Data Breach Investigations Report found that exploitation of vulnerabilities was behind 31% of breaches, ahead of stolen credentials, and that ransomware was involved in 48% of breaches. [1] Mandiant’s M-Trends 2026 found exploits were the most common initial infection vector for the sixth year running, and that the hand-off from initial access to a second threat group now takes a median of 22 seconds. [2]

For a SIEM, that points to a short list of attack paths to prepare for first:

• Exploited internet-facing systems: VPNs, firewalls, file-transfer tools and web applications, followed by a webshell or remote access.
• Ransomware intrusions: credential theft, lateral movement, backups and shadow copies destroyed, then encryption.
• Cloud and email account takeover: phished or sprayed credentials, MFA fatigue, inbox rules and mass downloads.
• Data theft and extortion: collection, staging and exfiltration, sometimes with no encryption at all.

Build detections around attack stages

Each of those attacks is a sequence, and each step leaves traces in different logs. A ransomware intrusion, for example:

Detecting one stage is good. Correlating several on the same host or account within hours is what turns a pile of medium alerts into one alert the SOC acts on straight away. Aim for at least two detectable stages per attack path, so a gap in one log source doesn’t blind you to the whole attack.

Make sure the right logs are there

Most detection gaps are telemetry gaps. For the attack paths above, these sources do most of the work:

• Identity: Entra ID or Okta sign-in and audit logs, domain controller security logs, VPN authentication.
• Endpoint: process creation with command lines (Sysmon or 4688), PowerShell script-block logging, and EDR alerts forwarded to the SIEM.
• Edge and network: firewall, VPN and WAF logs, proxy logs and DNS. Edge devices are a favourite target, so their own logs matter.
• Cloud and SaaS: the Microsoft 365 unified audit log, CloudTrail or Azure activity, and the admin logs of your key SaaS platforms.

For each source, check that the event types and fields your detections need are arriving and parsed, not just that the source shows as connected. Then rank the sources you don’t have yet by how much detection coverage each one would unlock.

Measure coverage with MITRE ATT&CK

Map every detection to the ATT&CK techniques it covers and look at the picture honestly. The average enterprise SIEM covers about 21% of techniques despite ingesting enough data for more than 90%. [5] Don’t aim for 100%. Aim for solid coverage of the techniques your priority attack paths depend on, across initial access, credential access, lateral movement, defence evasion, impact and exfiltration.

Prepare for speed

A 22-second hand-off between attackers means the response has to be ready before the alert fires. For each high-confidence detection, decide in advance who is paged, what they check first, and which containment steps they can take without asking: disable the account, revoke sessions, isolate the host. Then put those decisions into response playbooks in your SOAR, so enrichment runs the moment the alert fires and pre-approved containment is one click away. LogLens builds an ATT&CK-aligned playbook for each of its use cases, with every step marked as automatic, needing approval or manual, ready to export to your SOAR. Mandiant found that global median dwell time rose to 14 days in 2025. [2] Every hour you take off the time to find and contain an intruder is an hour they don’t have to steal or encrypt.

Test like an attacker

Don’t wait for a real incident to find out whether your detections work. Run attack simulations for each priority path, schedule penetration tests and red-team exercises, and compare what the attackers did with what the SIEM saw. Every step that was logged but not alerted is a rule to write. Every step that wasn’t logged is a source or audit policy to fix. We cover this in detail in How to detect a red team or penetration test with your SIEM.

Keep it current

Attack techniques shift every year, and so does your estate. Revisit your attack paths when the major threat reports come out, when CISA or your national CERT publishes advisories about techniques in active use, and whenever you add a significant system. The CISA #StopRansomware Guide is a good checklist for the ransomware path in particular. [6] A SIEM that was ready last year isn’t automatically ready this year.

A readiness checklist

1. Your top four or five attack paths are written down, each broken into stages.
2. Every stage has a log source that can see it, with the right events and fields arriving.
3. Each attack path has at least two detectable stages, correlated on user or host.
4. Detections are mapped to MITRE ATT&CK, with no empty tactics on your priority paths.
5. Each high-confidence alert has a response playbook in your SOAR, with pre-approved containment steps.
6. Detections are tested by simulation or a red team at least once a year.
7. Data health is monitored, so a source that goes quiet is noticed within a day.