{"id":36606,"date":"2026-11-05T14:11:32","date_gmt":"2026-11-05T19:11:32","guid":{"rendered":"https:\/\/www.kaspersky.co.za\/blog\/kaspersky-siem-correlation-rules-knowledgebase\/36606\/"},"modified":"2026-11-05T21:21:05","modified_gmt":"2026-11-05T19:21:05","slug":"kaspersky-siem-correlation-rules-knowledgebase","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.za\/blog\/kaspersky-siem-correlation-rules-knowledgebase\/36606\/","title":{"rendered":"SIEM: which rules actually work in your infrastructure"},"content":{"rendered":"

In describing SIEM features, vendors almost invariably focus on numbers: how many correlation rules come out of the box, how many were added over the past year, and how many MITRE ATT&CK techniques they cover. Admittedly, these numbers matter. They do help gauge how effective a system is, and we share them from time to time too<\/a>. But correlation rules aren\u2019t a magic amulet, and having more of them doesn\u2019t make a SIEM more effective. In fact, the total number of available rules says more about the variety of use cases the system supports. The question a hands-on SIEM analyst cares about first of all is different: which of these rules will actually work and be useful at my company? The answer is far from always obvious, and the reason isn\u2019t even rule quality.<\/p>\n

How correlation rules work<\/h2>\n

A rule first and foremost describes the logic: what to match against what, in what order, and within what time window. It also specifies particular event types from particular sources. For example, a rule for Active Directory group creation waits for events from the Windows Security log; a rule for suspicious network activity \u2014 DNS queries; a rule for process manipulation \u2014 triggers on events from endpoint telemetry. In other words, whether a rule works depends on whether the SIEM receives the right data in the first place.<\/p>\n

The Active Directory rule above would be completely pointless at a company that avoids Windows on principle. It would load without errors, show up in the interface, and technically \u201cexist\u201d\u00a0\u2014 but it would never fire. The reason is simple: the events it was built for never reach the system.<\/p>\n

That dictates the only correct order of steps when setting up an SIEM. Don\u2019t start out from the list of rules and then work your way toward your infrastructure. Go the other way around: first pin down which event sources are actually connected and feeding data into the SIEM, and only then see which rules will work on that data. Doing it the other way around leads to one of two outcomes: unmet expectations (hundreds of rules, almost no detections), or a laborious rule-by-rule manual slog, where the analyst opens every rule\u2019s description, checks its event requirements, and decides whether the rule is worth using.<\/p>\n

What the MITRE ATT&CK coverage percentage means<\/h2>\n

MITRE ATT&CK coverage is much the same story: it\u2019s often used without a second thought as a yardstick for product effectiveness. The catch is that these are numbers in a vacuum, with no real-world conditions behind them. Coverage only makes sense for a specific set of working rules. And as we saw above, that set of rules depends on the set of event sources. That\u2019s why the same SIEM will show different MITRE ATT&CK coverage at two different companies. Where Windows logs, endpoint telemetry, an email gateway, and network equipment are all connected, coverage will be noticeably broader than at a company with fewer sources.<\/p>\n

Here\u2019s the right way to read this metric: it\u2019s not a score for the SIEM content, but a map of what your SIEM can see with its current telemetry. A tactic with low coverage is a signal that detecting it requires data you don\u2019t have yet. Framed this way, it becomes a clear argument for a management conversation. Not \u201cwe need one more event source\u201d, but \u201cthis part of the matrix is currently invisible to us, and here\u2019s what it takes to close the gap\u201d.<\/p>\n

What\u2019s worth checking in your SIEM<\/h2>\n

To get the most out of a SIEM, it\u2019s worth asking yourself a few questions\u00a0\u2014 not just when deploying the system, but regularly:<\/p>\n