SIEM and log review
A SIEM that collects everything and detects nothing is an expensive archive. The question is not how much you are ingesting, it is what would still be missed.
The three things that are usually wrong
Most SIEM problems fall into the same three categories, and they compound. Coverage is narrower than anyone realises, a proportion of the rules produce noise that has trained people to ignore them, and some log sources stopped reporting months ago without anyone noticing.
Coverage
We map what you collect against what an attack would actually touch: identity and authentication, endpoint, email, network and perimeter, cloud control plane, and the applications that matter to your business. Then we look at the gaps in terms of what they cost you. A missing log source is only a problem if an attacker would have crossed it, and identifying which ones those are is most of the work.
The control plane gap is the common one. Organisations log user activity thoroughly and log almost nothing about changes to the environment itself: new privileged roles, new conditional access exclusions, new application consents, changes to logging configuration. Those are the actions an attacker takes to make the rest of their activity invisible.
Detection quality
We review the active rule set for what it genuinely covers, mapped to attacker techniques rather than to vendor categories, and separately for what it costs in attention. A rule that fires forty times a week and has never once been a real incident is worse than no rule, because it teaches an analyst that the category is safe to close without reading it.
The output is specific: rules to tune, rules to retire, and rules to write, with the technique each one is meant to catch.
Log source health
This is the failure that hurts most and is least visible. An agent stops reporting, a forwarder breaks after an update, a subscription lapses, and the SIEM goes on looking healthy because absence of data does not raise an alert. We check what has gone quiet and, more usefully, set up the monitoring that tells you next time. Everyone discovers this problem eventually. It is considerably better not to discover it during an investigation.
Cost
Ingestion-priced platforms make data volume a budget decision, and the usual response is to cut whatever is biggest rather than whatever is least useful. We identify high-volume, low-value sources that can be reduced or moved to cheaper storage, and the low-volume, high-value ones worth paying to keep. In Microsoft Sentinel estates this frequently funds the coverage gaps out of the existing bill.
What you get
A coverage map, a rule-by-rule assessment, a list of dead or degraded log sources, and a prioritised plan that separates what to fix this month from what needs a project. Written so an IT manager can act on it, not only a security analyst.
Common questions
Which platforms do you work with?
Most commonly Microsoft Sentinel and Defender, which is what the majority of organisations we work with already own. We also review Splunk, Elastic and the mainstream managed platforms. The method is the same regardless, because the questions are about coverage and detection rather than about the product.
Do you run the SIEM for us afterwards?
We can support it rather than take it over. Our preference is that you keep ownership and we provide the expert layer on top, because a platform nobody in your organisation understands is a dependency, not a capability.
Will this reduce our licensing bill?
Often, though we do not promise it. Where an estate is ingesting large volumes of low-value data the saving can be substantial. Where it is already lean, the honest finding is that you should probably be collecting more, and we will tell you that instead.
We only have Microsoft 365, not a full SIEM. Is this relevant?
Yes, and it is a common starting point. Microsoft 365 and Entra ID produce a great deal of useful data, much of it retained only briefly by default and switched off unless someone turned it on. Reviewing what you already have is usually the cheapest improvement available.
How long does a review take?
Typically three to five days depending on the number of log sources and the size of the rule set, with the findings delivered as a working session rather than only a document.
Related
Ready to talk?
Scoping conversations are free and there is no sales team to get past. Tell us what you're dealing with and we'll tell you honestly what you need.