5.2.2. Data Connectors, Syslog/CEF, and Windows Security Event Collection
💡 First Principle: Different data sources speak different "languages," and Sentinel needs a specific ingestion path matched to each one — a Microsoft-native connector, a syslog/CEF path for network appliances and non-Microsoft security tools, or a Windows-specific collection path — using the wrong path for a given source either fails to ingest the data or ingests it in a form that doesn't parse correctly.
Microsoft data connectors for Azure resources (Defender for Cloud, Entra ID, and others) are largely one-click, pre-built integrations tuned for that specific service's data. Syslog and Common Event Format (CEF) collection handles network devices, firewalls, and third-party security tools that speak these standard log formats rather than a Microsoft-specific API. Windows Security event collection — via data collection rules (DCRs), including Windows Event Forwarding (WEF) for centralizing events from many Windows machines before they reach Sentinel — captures OS-level security events (logons, privilege use, process creation) critical for detecting on-host attacker activity.
⚠️ Exam Trap: A scenario describing a non-Microsoft firewall or network appliance as a data source is a syslog/CEF question, not a "find the Microsoft connector" question — many third-party security appliances have no native Microsoft connector and rely entirely on standard syslog/CEF forwarding.
Reflection Question: Why would a third-party firewall vendor's logs typically arrive in Sentinel via syslog/CEF rather than through a dedicated Microsoft data connector?
