- A SIEM with partial log coverage is worse than no SIEM: it creates false confidence while missing lateral movement, privilege escalation, and account takeover.
- Logging design starts from a threat model and a source list, not from the vendor console.
- NESA and similar frameworks reward evidence of working monitoring, not a licence purchase order.
- Automation speeds up response to known patterns. It does not replace an analyst who can judge context.
Why a clean dashboard does not mean you are covered
Buying a SIEM is the easy part. Vendors will get you to a working console, a handful of default dashboards, and a set of out-of-the-box correlation rules within days. None of that tells you whether the platform can see an attacker moving through your environment. The most common gap in UAE deployments is not a missing feature. It is a missing log source: domain controllers not forwarding authentication events, cloud IAM activity never onboarded, database access logs left on the vendor's "advanced" tier that nobody enabled. The SIEM alerts happily on firewall drops and antivirus signatures because those feeds are easy to wire up. It stays blind to the events that actually matter for detecting a breach, because those feeds take design work.
This is why "we have a SIEM" and "we have visibility" are different claims. A platform ingesting perimeter noise while missing identity and lateral-movement telemetry will pass a checkbox audit and fail an actual incident.
What adequate logging actually means
Adequate logging is not "log everything." Verbose logging across every endpoint floods a SIEM with volume that inflates licensing costs and buries the events that matter under noise. Adequate logging means mapping specific threats to specific event sources and making sure those sources arrive intact, in real time, for as long as your retention obligations require. The SIEM FAQ covers the terminology gaps that come up most often in these conversations.
The sources that decide whether you catch anything
For identity-based attacks, which cover the large majority of breaches that start with phishing or credential theft, the sources that matter are: domain controller security logs (authentication, account lockouts, group and permission changes), Kerberos ticket activity, MFA and conditional access decisions, and VPN or remote access logs. For cloud environments, that means IAM activity logs, console sign-ins, and API call history from every cloud account in use, not just the ones the security team remembers exist. For lateral movement, you need endpoint process and network telemetry that correlates with authentication events, which is why SIEM and EDR integration matters more than either tool in isolation.
Specific Windows event IDs are worth naming because they map directly to detections: 4625 (failed logon), 4768 and 4769 (Kerberos ticket requests, useful for detecting Kerberoasting and golden ticket activity), and 4670 (permissions changed on an object). None of these are exotic. They are default Windows security auditing categories that are routinely left disabled or forwarded only at a summary level, which quietly removes the detections that depend on them.
Building the logging plan before you touch the console
The sequence that works is threat model first, log sources second, console configuration last. Decide what you are actually trying to detect: credential theft, data exfiltration, insider misuse of privileged access, ransomware staging. Each of those maps to a different set of sources. Credential theft needs identity provider and MFA logs. Exfiltration needs proxy, DLP, and cloud storage access logs. Insider misuse needs privileged access management session logs alongside standard authentication events.
Once the sources are mapped, enforce collection deliberately rather than accepting agent or connector defaults. Normalise log formats so correlation rules actually fire across heterogeneous sources, and test forwarding rather than assuming it works because the connector shows a green status. A connector reporting "healthy" and a log source actually arriving with the right fields populated are not the same thing, and the gap between them is where most rollouts quietly fail.
Retention is part of the design, not an afterthought. Compliance frameworks in the region generally expect a meaningful retention window for security-relevant logs, and the exact number depends on the framework and the log category, so size storage for your actual obligation rather than a guess. Multi-cloud environments make this harder because retention and export controls differ by provider, so plan for that scaling before the first onboarding wave, not after storage runs out.
Automation helps. It does not replace judgment
SOAR playbooks are genuinely useful for repeatable, low-ambiguity patterns: repeated failed logins from one source, known-bad IP matches, malware detonation on an isolated host. They cut response time on the alerts that do not need a human decision. What they cannot do is interpret context. A login from two distant locations within an hour might be a travelling user on a VPN, a shared account, or credential theft, and only an analyst with account and travel context can tell the difference reliably.
Overly aggressive automation creates its own failure mode. Auto-quarantine rules tuned too tightly lock out legitimate users working from branch offices or over unreliable connections, and the operational pain that follows tends to get the automation disabled entirely rather than tuned. The fix is graduated response: automate containment for high-confidence indicators, route ambiguous ones to an analyst queue, and revisit the thresholds on a schedule rather than leaving default rules running unchanged for years.
Where rollouts fall apart after go-live
Integration gaps are as common as logging gaps. A SIEM that does not talk to EDR, firewall, and cloud security posture management platforms loses the context that turns three low-severity events into one high-confidence detection. Endpoint detection flags a process; the SIEM never sees it because the integration was never built past the proof-of-concept stage; no correlation happens; nobody investigates.
Alert fatigue is the other consistent failure. Default rule sets ship broad on purpose, and teams that never tune them end up with hundreds of low-priority alerts a day. Analysts start triaging by volume rather than by risk, and the genuine detections get lost in the backlog. Tuning is not a one-time project step. It is ongoing work that needs a named owner, or the SIEM degrades back into noise within a quarter, whether the backend is a Splunk deployment being tuned or a fresh Microsoft Sentinel rollout; the platform is rarely the differentiator, the operating discipline is.
Testing whether your SIEM would actually catch an attacker
The honest test is simple to describe and uncomfortable to run: simulate a compromised account and see whether detection fires within the window you would need to respond. Purple team exercises against your own correlation rules answer this far more reliably than a compliance checklist does, because they test the actual data path rather than the paperwork describing it.
Review log sources on a fixed schedule, not only after an incident prompts it. Agents fail silently, APIs change their authentication requirements, and connectors that worked at go-live stop working months later without anyone noticing until the source is needed. A quarterly gap analysis, mapping expected sources against what is actually arriving, catches this drift before an attacker finds it for you.
The decision rule
If you cannot answer three questions with confidence, your logging is not adequate regardless of what the dashboard shows: which identity, cloud, and lateral-movement sources are actually forwarding right now; whether your correlation rules have been tested against a simulated compromise in the last quarter; and who owns tuning when alert volume changes. This is true whether you are running FortiSIEM or any other platform: licensing tier does not fix a source that was never onboarded. Fix the sources first. The console configuration is the part that was always going to be easy.
