Sentinel Event Collection: Syslog, CEF, Windows Security, Custom Log Tables
Microsoft Sentinel ingestion at scale β Syslog and Common Event Format (CEF) collection via the Linux Azure Monitor agent, Windows Security events via Data Collection Rules (DCRs) and Windows Event Forwarding (WEF), and creating custom log tables in the workspace for non-standard sources.
Ingestion at scale β three patterns
Outside of Microsoft-first-party sources (which have purpose-built connectors), Sentinel ingests via three primary patterns:
- Syslog β the Unix-world log protocol used by Linux servers, network devices, and many appliances. Sentinel ingests via the Azure Monitor Agent (AMA) on a Linux collector machine that receives syslog and forwards to the workspace.
- Common Event Format (CEF) β a structured syslog variant used by enterprise security products (firewalls, IDS/IPS, security appliances). Same collection mechanism as syslog β AMA on a Linux collector β with the CEF parser applied.
- Windows Security events β two paths: directly via AMA on each Windows server (Data Collection Rule defines which event IDs to ship); OR via Windows Event Forwarding (WEF) where domain-joined servers forward to a collector that AMA then ingests.
And when none of those fit β for custom application logs, internal-tool exports, weird formats β you create custom log tables in the workspace with a defined schema, ingest via the Logs Ingestion API or an AMA custom-log DCR, and write KQL against them like any built-in table.
Syslog ingestion
| Component | Configuration |
|---|---|
| Collector machine | Linux VM (Azure or Arc-enabled), sized for the source volume; can be a fleet behind a load balancer for HA at scale |
| Agent | Azure Monitor Agent (AMA) installed via Azure VM extension or Arc extension |
| Data Collection Rule (DCR) | Sentinel-side DCR targeting the collector, defining the data source = Syslog with facility/severity filters, and the destination = the Sentinel workspace |
| Source devices | Network gear, Linux servers, appliances configured to send syslog (UDP 514 or TCP 514, or TLS-encrypted variants) to the collector's IP |
| Destination table | `Syslog` in the Log Analytics workspace |
For high-volume environments, deploy multiple collectors behind an Azure Load Balancer; source devices target the LB VIP. Sentinel-side DCR targets all collector VMs.
CEF ingestion
Same Linux collector pattern. Configuration tweaks:
- Source devices (typically enterprise firewalls, IDS/IPS, web gateways) send CEF-formatted syslog to the collector
- The syslog daemon on the collector is configured per Microsoft documentation to recognise CEF
- The DCRβs
Syslogdata source detects CEF messages and routes them to theCommonSecurityLogtable (with CEF fields normalised) rather than the genericSyslogtable
Source devices that natively emit CEF: Palo Alto firewalls, Cisco ASA / Firepower, Check Point, Fortinet FortiGate, Imperva, F5, McAfee β most enterprise security gear has a documented CEF output mode.
Windows Security event collection
Two collection topologies β both end up in the SecurityEvent table in Sentinel.
Direct (AMA on each Windows server)
The simpler topology. Steps:
- AMA deployed to each Windows server (via VM extension or Arc extension).
- Sentinel DCR with the Windows Security events data source, targeting the servers. Choose the event-ID set β All, Common, Minimal, or a custom XPath filter.
- Events flow directly to the Sentinel workspaceβs
SecurityEventtable.
Direct is right when servers are Azure-native or Arc-enabled and can talk directly to Azure Monitor.
Windows Event Forwarding (WEF)
The aggregator topology. Steps:
- Source servers are configured (via Group Policy) to forward selected Security events to a collector server running Windows Event Collector service.
- The collector aggregates events into its
ForwardedEventslog. - AMA on the collector + a DCR with the Windows Security events data source pulls events from the local
ForwardedEventslog to Sentinel.
WEF is the right topology when source servers canβt (or shouldnβt) install AMA directly β restricted production systems, regulated environments where Azure communication is centralised, or simply when thereβs already a WEF deployment in place.
Direct AMA vs WEF β when to pick which
Pick direct AMA when:
- Servers are Azure-native or already Arc-enabled
- You want per-server control over which event IDs ship
- You donβt have an existing WEF infrastructure
Pick WEF when:
- Source servers are tightly restricted from outbound Azure traffic
- You already operate a WEF collector for legacy SIEM
- You want to consolidate ingestion through a single AMA endpoint for fleet bandwidth reasons
The two can also coexist β some servers direct-AMA, restricted ones via WEF, all landing in the same SecurityEvent table.
Custom log tables
When the source isnβt covered by a connector or a standard ingestion pattern β application logs, custom data exports, weird formats β create a custom log table in the workspace:
- Define the schema β column names and types β for the custom table. Tables that end in
_CLare custom. - Ingest via one of:
- Logs Ingestion API β REST API that accepts JSON payloads, validated against a DCR-defined schema, and writes to the named table. The modern path for application-emitted logs.
- AMA custom-log DCR β for file-tailing patterns where an application writes a log file on a VM and AMA tails the file with a parsing rule.
- Query the custom table with KQL β same surface as built-in tables.
Custom tables can store data in the Analytics tier (full Sentinel features) or the new Auxiliary / Data Lake tiers (cheaper, more limited query model β for archival of high-volume but low-priority data).
Scenario: Dom builds an MSSP ingestion stack
For Kestrel Cyber Co-opβs new fintech client (200 users):
- Linux syslog/CEF collectors: 2 Azure Ubuntu VMs behind a Standard Load Balancer in the management VNet. AMA installed. DCRs configured for both Syslog and CEF.
- Source devices:
- Palo Alto firewall (CEF) β collector LB β
CommonSecurityLog - 3 Linux app servers (syslog) β collector LB β
Syslog - Cisco ASA edge (CEF) β collector LB β
CommonSecurityLog
- Palo Alto firewall (CEF) β collector LB β
- Windows Security events β direct AMA on the 18 client Windows servers (Azure VMs). DCR with the Windows Security events data source, set = Common. Events to
SecurityEvent. - Custom log table β the client has an in-house fraud-scoring API that emits scoring events as JSON. Dom defines a custom table
FraudScores_CLwith the relevant schema and uses the Logs Ingestion API from the scoring API to send events directly to Sentinel. - Content Hub β solutions for Palo Alto, Cisco ASA, and Microsoft Defender XDR installed; analytics rules tuned and enabled.
After standup: Sentinel ingests CEF + Syslog + Windows Security + custom JSON, all queryable in one workspace.
Key terms
Knowledge check
Dom at Kestrel Cyber Co-op needs to ingest CEF-formatted logs from a client's Palo Alto firewall into Microsoft Sentinel. Which collection pattern is correct?
Esme at Northwind Bank has 200 Windows Servers across the bank's regions. The production servers are tightly restricted from any outbound Azure traffic β they must forward Security events through a designated collector. Which Sentinel ingestion pattern fits?
Asha at Aurora Health Service needs to ingest scoring events from a custom in-house clinical-AI risk-scoring API as JSON payloads with a defined schema into a custom Sentinel table. Which ingestion path is the modern SC-500 right answer?
Whatβs next
Next: Sentinel automation, data retention, and the Purview Audit query in Defender XDR β automation rules and playbooks for response, data retention across Analytics / Auxiliary / Data Lake tiers, and how Microsoft Purview Audit is queried via the Defender XDR Advanced Hunting surface.