SIEM Log Source Coverage: The Complete Checklist for SOC Teams
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A SIEM is only as good as its log sources. Detection rules cannot fire on data that is not being ingested. Yet most enterprise SIEMs are missing between 30 and 50 percent of the log sources required to detect the attack techniques that appear in real incident investigations. The gaps are not random, they cluster around the same categories: cloud identity providers added after the SIEM was deployed, SaaS applications that were never connected, network equipment that ships logs in non-standard formats, and EDR telemetry that was never normalized into the SIEM schema. This checklist works through every log source tier with ingestion priority, normalization guidance, and the specific detection use cases that each source enables.
Tier 1: Identity and Authentication (Highest Priority)
Identity logs are the single most important category for detecting modern attacks. Over 60% of initial access techniques involve compromised credentials, and identity logs are where every authentication event, MFA result, and privilege escalation is recorded.
Microsoft Entra ID (Azure AD) sign-in logs
Sign-in logs, audit logs, and risk detection logs. Sentinel: use the Azure Active Directory data connector (native). Splunk: Microsoft Azure Add-on. Elastic: Azure Logs integration. Key fields: userPrincipalName, ipAddress, conditionalAccessStatus, riskLevelDuringSignIn, authenticationDetails.authenticationMethod, resourceDisplayName. Detection use cases: AiTM cookie replay (same session, multiple IPs), brute force, MFA bypass, impossible travel, legacy auth usage.
Okta system log
Okta System Log captures all authentication events, MFA challenges, policy evaluations, and admin actions. Sentinel: Okta SSO data connector. Elastic: Okta integration. Key events: user.authentication.sso, user.mfa.factor.deactivate, policy.evaluate_sign_on, system.api_token.create. Detection use cases: credential stuffing (high failed authentications), session hijacking (suspicious authentication context), admin API token creation from unusual location.
Active Directory Domain Services (Windows Event Log)
Windows Security event logs from domain controllers. Critical event IDs: 4624 (successful logon), 4625 (failed logon), 4648 (logon with explicit credentials), 4672 (special privileges assigned), 4768/4769 (Kerberos TGT/service ticket), 4771 (Kerberos pre-authentication failed), 4776 (NTLM authentication), 4728/4732/4756 (security group membership changes). Use Windows Event Forwarding (WEF) or a log shipper (Winlogbeat, NXLog) on every domain controller.
VPN and remote access authentication
All authentication events to your VPN gateway (Cisco ASA, Palo Alto GlobalProtect, Zscaler ZPA, Cloudflare Access). Key events: successful connection (with source IP, user identity), failed authentication, MFA failure, certificate validation failure. Detection use cases: credential stuffing against VPN, account takeover via VPN, authentication from TOR exit nodes or known-bad IPs.
Privileged Access Workstation (PAW) and jump host logs
All session logs from privileged access infrastructure. CyberArk/BeyondTrust/Delinea session recordings and logs. Bastion host (AWS Session Manager, Azure Bastion) session initiation events. Detection use cases: privileged session initiated outside approved maintenance windows, commands executed during privileged sessions that match threat actor TTPs, privileged access from non-PAW devices.
Tier 1: Endpoint Telemetry
Endpoint EDR telemetry is the second highest-priority category. It provides the process execution, file, network, and registry events required to detect post-compromise behavior.
EDR process and network telemetry
CrowdStrike Falcon: use the Falcon Data Replicator (FDR) to stream process, network, and file events to your SIEM. SentinelOne: Deep Visibility streaming to SIEM. Microsoft Defender for Endpoint: Advanced Hunting tables via streaming API or Sentinel connector. Key event types: process creation (with command line and parent), network connection (process to external IP), file write to sensitive paths, registry modification for persistence keys.
Windows Sysmon
Sysmon is a free Microsoft Sysinternals tool that provides detailed process, network, and file telemetry on Windows. Use the SwiftOnSecurity or Olaf Hartong Sysmon configuration for a production-ready ruleset. Key event IDs: 1 (process create with full command line), 3 (network connection), 7 (DLL load), 8 (CreateRemoteThread, injection indicator), 10 (process access, LSASS access indicator), 11 (file create), 12/13/14 (registry events), 22 (DNS query). Ship via Winlogbeat.
macOS unified log (Endpoint Security Framework)
macOS security logs from the Endpoint Security Framework. Key sources: /var/log/auth.log (authentication), unified log with subsystem com.apple.security and com.apple.launchd (LaunchAgent/LaunchDaemon events), OpenBSM audit log (/var/audit/) for process and file events. Use macOS ESF-based EDR (CrowdStrike, SentinelOne, Microsoft Defender) to get structured telemetry, or ship raw unified log entries for specific subsystems via osquery or a log agent.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Tier 1: Cloud Control Plane Logs
Cloud control plane logs record every API call made in your cloud environment, resource creation, IAM changes, configuration modifications, and data access.
AWS CloudTrail
Enable CloudTrail in all regions with log file validation enabled. Store to S3 with SSE-KMS encryption and Object Lock. Forward to your SIEM via CloudWatch Logs subscription filter or S3 SQS notification. Critical event categories: ConsoleLogin, AssumeRole (especially cross-account), CreateAccessKey, AttachUserPolicy, RunInstances with admin instance profile, S3 GetObject on sensitive buckets. Use CloudTrail Insights to detect anomalous API call rates.
GCP Cloud Audit Logs
Enable Data Access audit logs (not just Admin Activity, these are off by default) for Cloud Storage, BigQuery, and Compute Engine. Forward to your SIEM via Pub/Sub export sink. Critical events: SetIamPolicy (especially adding primitive roles like roles/owner), CreateServiceAccountKey, ListObjects/GetObject on sensitive buckets, instances.insert with high-privilege service account.
Azure Activity Log and Microsoft Defender for Cloud
Azure Activity Log: all control plane operations across your subscription. Forward via Diagnostic Settings to Log Analytics workspace (Sentinel). Enable Microsoft Defender for Cloud with all plans active, it provides security posture findings and threat detection alerts that are distinct from Activity Log. Critical events: roleAssignments/write, virtualMachines/write with user-assigned identity, storageAccounts/listKeys, keyVaults/secrets/read.
Tier 2: Network Infrastructure
Network logs provide visibility into lateral movement, C2 communication, and data exfiltration that endpoint logs cannot detect for unmanaged or network-tier devices.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Tier 2: SaaS Application Logs
SaaS applications are increasingly the primary target of attacks, and most are not connected to enterprise SIEMs.
Microsoft 365 Unified Audit Log
Covers Exchange Online, SharePoint, OneDrive, Teams, and admin activity. Enable via Compliance Center or PowerShell: Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true. Forward to Sentinel via the Microsoft 365 data connector. Critical operations: New-InboxRule (mail forwarding rules), Add-MailboxPermission, SearchQueryInitiatedExchange (mailbox searches by admins), FileAccessed/FileDownloaded (bulk file access), TeamsMessageSent with external domains.
GitHub audit log
GitHub Organization audit log captures all administrative events. Forward via GitHub's audit log streaming feature (Enterprise) or the GitHub Audit Log API. Critical events: org.add_member (new organization member), repo.access (repository visibility changed), protected_branch.update_settings, repo.create (especially forks of private repos), team.add_repository, personal_access_token.created.
Slack audit log
Slack Enterprise Grid audit log via Audit Logs API. Critical events: user_login, user_session_invalidated, app_installed, file_downloaded, channel_created (public channels that should be private), workspace_accepted_invite (external workspace federation). Forward via custom Slack app with audit:read scope or a SIEM connector (Splunk Slack Add-on, Sentinel Slack connector).
Salesforce and other business SaaS
Salesforce Event Monitoring provides Login History, API Usage, and Report Export events, the latter being critical for detecting bulk data export. Other high-priority SaaS: Workday (HR system access logs for insider threat), ServiceNow (ticket manipulation, admin actions), Jira/Confluence (sensitive document access). Prioritize SaaS applications that contain PII, financial data, or source code.
Tier 3: Application and Container Logs
Application-level logs surface attacks that bypass all network and endpoint controls, injections, authentication bypasses, and business logic abuse.
Web application access and error logs
Apache/nginx/IIS access logs for all internet-facing applications. Key fields: source IP, HTTP method, URL, response code, user-agent, bytes sent, request time. Detection use cases: SQL injection attempts (error responses to input with SQL keywords), directory traversal (400/403 responses to paths with ../ sequences), scanner patterns (rapid sequential requests to non-existent paths), credential stuffing (many 401 responses from same IP across multiple user accounts).
Kubernetes API server audit log
Enable Kubernetes audit logging at the policy level. Key event types: pod/exec (someone ran commands in a pod), secrets/get (secrets read, especially from outside normal application namespace), pods/create with privileged securityContext, clusterrolebindings/create (privilege escalation). Ship via a log agent (Fluentd, Fluent Bit) to your SIEM. Alert on any of these events from a service account identity that does not normally perform them.
Container runtime logs (Falco events)
Falco generates structured JSON alerts for detected policy violations: container escape attempts, sensitive file access, shell spawned in containers, outbound connections from unexpected processes. Forward Falco output via JSON webhook or gRPC stream to your SIEM. Each Falco alert includes container name, image, process, command line, and the rule that triggered, high-fidelity, low-noise alerting suitable for high-priority alerting.
Coverage Gap Analysis
Use this process to identify your current coverage gaps against MITRE ATT&CK.
Map your ingested log sources to ATT&CK data sources
Go to attack.mitre.org/datasources. For each of your ingested log sources, identify which ATT&CK Data Source components it provides. Load your current source list into the MITRE ATT&CK Navigator as a layer, and generate a coverage heat map. Techniques with no coverage (white cells) are your blind spots. Prioritize adding log sources that close the highest-risk technique gaps.
Run a detection coverage test
Use Atomic Red Team (atomicredteam.io) to execute test behaviors for specific ATT&CK techniques in a controlled environment, then verify whether your SIEM generated alerts. Techniques that execute successfully without generating alerts are confirmed coverage gaps. This is more reliable than theoretical coverage mapping because it validates that your normalization and detection rules actually work against real telemetry.
The bottom line
A SIEM with incomplete log source coverage is a detection program with known blind spots. Start with the Tier 1 sources: Entra ID or Okta sign-in logs, EDR telemetry, and CloudTrail, these three categories alone cover the majority of initial access and post-compromise detection use cases. Run an ATT&CK Navigator coverage assessment to identify your specific gaps. Then work through Tier 2 and Tier 3 systematically, normalizing each source to your SIEM schema before building detection rules. A well-covered SIEM does not need more rules, it needs the right data flowing in.
Frequently asked questions
How do I prioritize which log sources to add first?
Prioritize by detection use case coverage, not by data volume. The three highest-priority categories are: (1) Identity logs (Entra ID, Okta, Active Directory), required for detecting credential-based attacks that account for over 60% of initial access. (2) Endpoint EDR telemetry, required for detecting post-compromise behavior. (3) Cloud control plane logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Logs), required for detecting cloud account compromise and privilege escalation. Everything else is secondary until these three are complete.
What is the difference between log ingestion and log normalization?
Log ingestion means getting raw log data into your SIEM. Log normalization means transforming that raw data into a consistent schema (ECS for Elastic, ASIM for Microsoft Sentinel, CIM for Splunk) so that detection rules written against the schema work across all log sources. A SIEM with good ingestion but poor normalization requires separate detection rules for every log source. A normalized SIEM allows a single rule to detect the same behavior regardless of whether it came from CrowdStrike, SentinelOne, or Windows Event Logs.
How much storage does a SIEM log source program typically require?
Rough sizing: a 1,000-user organization generates approximately 50-150 GB of security-relevant log data per day across all sources. Identity logs: 2-5 GB/day. Endpoint EDR: 10-30 GB/day. Network flow logs: 20-50 GB/day. Cloud logs: 5-20 GB/day. SaaS logs: 1-5 GB/day. At 180-day retention, this is 9-27 TB of total storage. Use tiered storage, hot storage (0-30 days, fast query) and cold storage (31-180 days, slower query) to manage costs.
What is the MITRE ATT&CK Data Sources framework?
MITRE ATT&CK Data Sources maps each ATT&CK technique to the specific log sources and fields required to detect it. For example, T1078 (Valid Accounts) maps to Authentication logs with specific fields. Use this mapping to identify which ATT&CK techniques you currently have coverage for given your ingested log sources, and which are blind spots. The MITRE ATT&CK Navigator allows you to visualize your coverage as a heat map.
How do I calculate the cost of SIEM log ingestion before onboarding a new log source?
Estimate ingestion volume by sampling: enable the log source for 24-48 hours in a non-production environment or on a representative subset of production systems and measure daily gigabyte volume. For cloud-based SIEMs priced per GB: Microsoft Sentinel charges per GB ingested (with a commitment tier discount); Splunk Cloud charges per GB per day; Chronicle Security Operations charges per license tier. For most enterprise environments, Windows Security Event logs and network flow logs are the highest-volume sources (often 70-80% of total ingestion). Calculate monthly cost by multiplying daily GB by 30 and applying your SIEM's pricing tier. Many SIEMs offer free ingestion tiers for specific high-value sources (Sentinel offers free ingestion for MDE, M365, and several other Microsoft sources).
How do you maintain SIEM detection quality as log volume grows and analysts get alert-fatigued?
Alert fatigue management in a SIEM is an engineering discipline, not a tuning exercise done once. The operational approach that works at scale: implement a tiered alert severity model where only Tier 1 alerts page on-call analysts, Tier 2 alerts populate a hunting queue for next-business-day review, and Tier 3 detections feed a weekly threat hunt dashboard with no paging. Measure your signal-to-noise ratio per detection rule every 30 days -- any rule with a true positive rate below 5% is a noise generator and should be demoted or disabled. Use SIEM aggregation and deduplication aggressively: a rule firing 500 times for the same host within an hour should generate one correlated alert with a count, not 500 individual pages. For growing log volumes, filter at the collection layer rather than the indexing layer -- Cribl Stream or Elastic Agent pipeline processors can drop known-benign events before they reach your SIEM index, reducing volume by 30-50% without losing detection coverage. Review detection rule coverage quarterly against your threat model rather than adding rules continuously without pruning those that no longer reflect your environment.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.