- SIEM value tracks log source coverage and enrichment, not ingestion volume or licence size
- The first months after go live should validate that high value systems are logging correctly, before anyone writes detection rules
- Vendors are commercially incentivised to recommend "forward everything", that advice usually works against the buyer
- Detection quality tracks analyst skill and rule specificity more than the product name on the invoice
The Platform Gets Blamed for a Data Problem
A SIEM correlates and stores whatever you point it at. It has no opinion on whether that feed is useful. So when an incident response walkthrough finds that lateral movement across a domain was invisible to the platform, the honest diagnosis is rarely "the SIEM missed it." It is "Event ID 4624 was never forwarded from most endpoints, so there was nothing to correlate."
This pattern repeats across the region because log collection is treated as a checkbox for retention requirements rather than a design decision. Whatever is easiest to point at a collector, firewalls, network gear, perimeter proxies, gets forwarded because it is low effort and generates a lot of events, which looks like activity on a dashboard. Domain controllers, identity providers, file servers holding regulated data and the control planes of cloud tenancies are harder to instrument correctly and get skipped. The result is a platform full of noisy, low value telemetry and blind on exactly the systems an attacker needs to touch.
Compliance Tells You to Log, Not What to Log
NESA, CBUAE guidance, ISO 27001 Annex A logging controls, and equivalents elsewhere in the region require log retention, monitoring and the capability to reconstruct an incident. None of them hand you a list of which event IDs matter for your environment. That decision sits with the security team, and it is where most implementations go wrong: they default to volume because volume is defensible in an audit ("we retain 500GB a day for twelve months") even when the content of that data cannot answer a single real question about privileged access, lateral movement or data exfiltration.
Assessors reviewing SIEM deployments for regional frameworks generally ask a narrower question than "how much do you log": can you show, end to end, the log trail for a specific privileged action, and can you reconstruct authentication and process activity for a specific host over a specific window. If the answer requires cross referencing three tools that were never designed to talk to each other, the deployment has a coverage problem regardless of what the retention dashboard shows.
The First Months: Validate Coverage Before Writing Rules
The instinct after a SIEM go live is to start building detection rules and dashboards for a steering committee. That instinct is backwards. The first stretch after deployment should be spent confirming that the systems you actually care about are logging the right events at the right fidelity, because a detection rule built on a log source that silently stops forwarding is worse than no rule at all: it creates false confidence.
Start with the assets an attacker would actually want: domain controllers, identity providers, ERP and finance systems, database servers holding regulated data, and the admin planes of your cloud tenancies. For each one, confirm collection at the event level rather than trusting that "the agent is installed." On Windows estates that means checking that these are enabled, forwarded and actually arriving with usable field parsing:
- Event ID 4624 and 4625 (logon success and failure), correlated with logon type
- Event ID 4670 and 4663 (permission changes and object access) on systems holding regulated data
- Event ID 5140 (network share access)
- PowerShell module logging and script block logging (Event ID 4104), decoded rather than left as raw Base64
- Event ID 4662 on directory service objects, which is what a DCSync attempt against Active Directory shows up as
PowerShell logging in particular gets disabled in production more often than it should, usually over a performance concern that is rarely quantified. That tradeoff deserves scrutiny: script block logging is one of the highest value single log sources against modern intrusion techniques, and the CPU cost on a modern endpoint is small next to what you lose in visibility.
Once coverage is verified, and only then, build use cases that match how intrusions in the region actually unfold rather than generic templates shipped with the product. A rule like "ten failed logins in five minutes" produces volume without insight, most of it noise from misconfigured service accounts. A rule that correlates a login from one geography with a login from a distant geography shortly after, with no MFA re-prompt in between, is a signal worth an analyst's time. The difference is not cleverness, it is specificity: source, target, and behaviour, not just a threshold.
How Weak Logging Lets an Intrusion Walk Past a SIEM
A typical low visibility intrusion chain looks like this: valid credentials from a compromised third party account reach an internal portal, the session pivots to a domain joined workstation, a misconfigured Group Policy Object is used to escalate privilege, credential material is dumped locally, and the session moves laterally to a domain controller. Every one of those steps generates an event somewhere. None of them trigger an alert in an environment with the coverage gaps described above, because the command line arguments behind the credential dump are Base64 encoded and never decoded, the authentication logs from the target servers were never forwarded, and the directory service access event that the final step produces maps to a rule that was disabled for performance reasons.
This is not a sophisticated attacker doing anything novel. It is standard tradecraft that has worked for years, and it works because SIEM programmes get built around procurement milestones (platform selected, licence signed, dashboards demoed) rather than around whether the specific techniques attackers use in the region actually generate a detectable event. In hybrid GCC environments, on premises Active Directory, cloud workloads and third party SaaS integrations, the fragmentation compounds the problem: each layer has its own default logging posture, and nobody owns making them consistent unless someone is explicitly tasked with it.
Ingestion Volume Is a Vendor Incentive, Not a Security Outcome
Most commercial SIEM licensing is priced by ingested volume. That pricing model creates a straightforward incentive: a vendor recommending "send everything, filter later" is optimising for a larger deal, not for your detection coverage. It is worth treating that advice with the same scrutiny you would apply to any vendor recommendation that happens to increase what you pay them.
The practical failure mode shows up later, not at signing. An organisation licenses a large daily ingestion allowance, finds that a large share of it is low value network device noise (repetitive firewall denies, debug logs, health check traffic), and then hits the ingestion cap exactly when it wants to add something genuinely useful: detailed cloud control plane activity, endpoint command line telemetry, or DNS query logs. At that point the choice is an unplanned budget increase or filtering out something that should have stayed.
The fix is to negotiate and design around enriched, security relevant volume rather than raw ingestion. Ask a vendor to map every proposed log source to a specific detection use case before it goes into the licensing calculation. If a source cannot be mapped to something an analyst would act on, question whether it belongs in the primary SIEM tier at all, some low value telemetry belongs in cheaper cold storage for retention purposes rather than hot, correlated ingestion. Our Splunk tuning guide goes into the mechanics of separating high value indexed data from retention only volume without losing audit defensibility. For teams evaluating whether a name brand platform is worth the premium, FortiSIEM's licensing model, which is priced differently from the leading log volume based platforms, is worth putting in the same evaluation as the more commonly shortlisted options.
Cost pressure under regional compliance obligations is real, but it cuts both ways: overpaying for unfiltered volume is exactly as wasteful as underspending on coverage of the systems that matter.
Analyst Capability Decides Whether Any of This Gets Used
A SIEM with excellent coverage and well designed rules still fails if the people staffing the console cannot tell a failed RDP attempt from a Kerberos pre-authentication attack, or if the job is defined as clearing a queue rather than investigating what is behind an alert. A security operations centre that only ever looks at alerts, never at the raw log behind them, functions as a compliance reporting desk, not a detection capability.
Building analyst capability that matches the tooling means treating detection engineering as an ongoing discipline rather than a one time deployment task: picking a MITRE ATT&CK technique relevant to the organisation's threat model, building a detection for it from the log sources actually available, testing it against historical data, and documenting why the rule exists and what normal looks like for it. Regular purple team style exercises, testing detections against simulated technique execution rather than once a year red team reports, keep that discipline current. Our guide to SOC metrics covers how to measure whether that investment is actually improving outcomes rather than just activity.
Common Questions Answered Directly
What Makes a Good Detection Rule?
Specificity. "Multiple failed logins" produces volume without direction. "Five failed RDP attempts from a single external IP followed by a successful login to a privileged account with no prior access history from that account" gives an analyst source, target and behaviour, and tells them exactly what to check next: whether the login is expected, whether the account should have that privilege, and whether to isolate the host.
How Do You Measure Whether a SIEM Deployment Is Working?
Not by alert volume or dashboard uptime. Mean time to detect and mean time to respond are the metrics that matter, because they measure whether the investment shortens the window an intruder has to operate in. A programme where meaningful detections take more than a day to surface, or where response takes multiple days once something is flagged, has an operational gap that no amount of additional licensing will close on its own.
Is a Cloud Native SIEM Better Than an On Premises One?
It depends on where your workloads actually live. A cloud native platform integrates tightly with the identity and workload telemetry of its own ecosystem, which is a genuine advantage for organisations that have moved most of their estate to that cloud. Organisations, including much of the regional public sector, that still run core systems on premises do not get to skip the operational work: log forwarders, parsers and governance still need to exist, the SIEM being cloud hosted moves where the compute runs, it does not remove the work of getting the right data into it.
Where This Actually Starts
If a SIEM programme is already live and generating more alerts than confidence, the fix is not a platform migration. It is an audit of what is actually being collected from the ten or so systems that matter most, followed by rules built against confirmed data rather than assumed data. Our SIEM services page outlines what that assessment covers if you want a structured starting point. Fix the logging first. The dashboards will start meaning something once there is real data behind them.
