SIEM review
A fixed-price review of your SIEM, in two parts.
Log ingestion
Are the right logs arriving, complete and on time? The review checks for the problems found most often:
- Clocks out of step: sources without proper time sync (NTP) or with the wrong time zone, and the time an event happened correlated with the time the SIEM received it.
Example from a report
SOURCE EVENT TIME (UTC) RECEIVED (UTC) OFFSET fw-edge-01 08:41:02 08:41:03 1 s dc-02 07:41:05 08:41:06 1 h, time zone app-db-03 08:39:58 08:41:06 68 s, no NTP - Sources gone quiet: servers and devices that stopped sending logs. This is more serious than usually admitted: the rules that depend on them stop triggering, and nothing warns anyone.
Example from a report
SOURCE LAST EVENT USUALLY SENDS RULES AFFECTED vpn-gw-01 6 days ago every minute 14 dc-07 19 hours ago every second 9 proxy-01 2 minutes ago every second 0 - Logs not parsed: events in CEF over TCP, CEF over Syslog, plain Syslog, key/value pairs, JSON or vendor formats stored as raw text, or with fields mapped wrongly, so rules cannot read them.
Example from a report
SOURCE FORMAT FIELDS PARSED STATUS fw-edge-01 CEF over TCP 28 of 28 ok proxy-01 CEF over Syslog 4 of 31 mostly raw erp-app key/value 0 of 22 raw text - Gaps: important systems never connected, or connected only in part.
Example from a report
ASSET GROUP IN SCOPE SENDING COVERAGE Domain controllers 12 10 83% Firewalls 6 6 100% Cloud subscriptions 9 4 44%
Detection rules
Do your rules catch real attacks, and stay quiet the rest of the time?
- Silent rules that can never fire, because the data or field they depend on is missing.
Example from a report
RULE DEPENDS ON STATUS VPN brute force vpn-gw-01 logs cannot fire, source quiet LSASS memory access process access events cannot fire, field missing New admin account domain controller logs working - Noisy rules that analysts learn to ignore.
Example from a report
RULE ALERTS (30 DAYS) CLOSED AS BENIGN Sign-in outside office hours 1,240 98% Port scan detected 610 95% Mailbox forwarding rule 12 25% - Vendor default rules left untuned for your environment.
Example from a report
ENABLED RULES COUNT SHARE Vendor default, never changed 171 80% Vendor default, tuned 19 9% Written for you 24 11% - Coverage: which common attack techniques you can and cannot see, mapped to MITRE ATT&CK.
Example from a report
Recon Resource dev. Initial access Execution Persistence Privilege esc. Defence evasion Credential access Discovery Lateral movement Collection Command & control Exfiltration Impact TOTAL Identity 9 3 4 1 14 1 1 1 34 Endpoint 2 11 6 5 4 8 3 2 1 1 2 45 Network 2 7 1 1 2 1 4 1 19 Cloud 5 1 2 2 1 3 1 1 1 17 Email 12 1 1 14 TOTAL 2 0 35 13 11 11 7 27 6 4 2 5 2 4 129 Reading: 62 of 129 rules (48%) watch initial access or credential access. Only 8 (6%) watch lateral movement, collection or exfiltration, the stages after an attacker is in.
Industry research finds around one in five SIEM rules can never fire (CardinalOps, 2024).
Examples show the format only; names and figures are illustrative.
You receive a written report with findings ranked by risk and a short list of fixes.
The review covers the SIEM itself. It does not cover incident response or your analysts' work.
AI-enhanced SIEM
A semi-automated SOC, built on your own Microsoft Sentinel and Defender. AI agents take the routine work, and your analysts keep every decision that matters.
Examples:
- Triage and enrich new incidents before an analyst opens them.
- Handle phishing emails reported by staff.
- Flag noisy detection rules and propose fixes.
- Warn when a log source goes quiet.
Everything runs in your tenant, under your control. There is no new platform to buy.
About
More than 25 years in SIEM and security operations, 11 of them in London, across financial, energy and communications organisations. References on request.