Domain 4 β€” Module 4 of 6 67%
26 of 28 overall
Domain 4: Manage and monitor security posture Free ⏱ ~11 min read

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

Simple explanation

Outside of Microsoft-first-party sources (which have purpose-built connectors), Sentinel ingests via three primary patterns:

  1. 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.
  2. 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.
  3. 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

Syslog ingestion via AMA + Linux collector β€” the components
ComponentConfiguration
Collector machineLinux VM (Azure or Arc-enabled), sized for the source volume; can be a fleet behind a load balancer for HA at scale
AgentAzure 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 devicesNetwork 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 Syslog data source detects CEF messages and routes them to the CommonSecurityLog table (with CEF fields normalised) rather than the generic Syslog table

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:

  1. AMA deployed to each Windows server (via VM extension or Arc extension).
  2. 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.
  3. Events flow directly to the Sentinel workspace’s SecurityEvent table.

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:

  1. Source servers are configured (via Group Policy) to forward selected Security events to a collector server running Windows Event Collector service.
  2. The collector aggregates events into its ForwardedEvents log.
  3. AMA on the collector + a DCR with the Windows Security events data source pulls events from the local ForwardedEvents log 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:

  1. Define the schema β€” column names and types β€” for the custom table. Tables that end in _CL are custom.
  2. 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.
  3. 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):

  1. 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.
  2. Source devices:
    • Palo Alto firewall (CEF) β†’ collector LB β†’ CommonSecurityLog
    • 3 Linux app servers (syslog) β†’ collector LB β†’ Syslog
    • Cisco ASA edge (CEF) β†’ collector LB β†’ CommonSecurityLog
  3. 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.
  4. Custom log table β€” the client has an in-house fraud-scoring API that emits scoring events as JSON. Dom defines a custom table FraudScores_CL with the relevant schema and uses the Logs Ingestion API from the scoring API to send events directly to Sentinel.
  5. 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

Question

What is the Azure Monitor Agent (AMA)?

Click or press Enter to reveal answer

Answer

The unified Azure Monitor agent for Windows and Linux that ingests logs and metrics into Log Analytics workspaces. Replaces the legacy Log Analytics Agent / OMS Agent. Configured via Data Collection Rules (DCRs) for granular control over what data is collected and where it routes.

Click to flip back

Question

How does CEF ingestion differ from generic syslog ingestion in Sentinel?

Click or press Enter to reveal answer

Answer

Both use the same Linux collector + AMA pattern. CEF is a structured syslog variant used by enterprise security gear (firewalls, IDS/IPS). Sentinel parses CEF messages via the configured syslog daemon + AMA DCR and lands them in the `CommonSecurityLog` table (with CEF fields normalised), whereas generic syslog lands in the `Syslog` table.

Click to flip back

Question

What is Windows Event Forwarding (WEF) for Sentinel ingestion?

Click or press Enter to reveal answer

Answer

An ingestion topology where source Windows servers forward selected Security events to a Windows Event Collector server (configured via Group Policy). AMA on the collector ingests events from the local `ForwardedEvents` log to the Sentinel workspace's `SecurityEvent` table. Used when source servers can't or shouldn't talk directly to Azure Monitor.

Click to flip back

Question

What is a custom log table in Log Analytics?

Click or press Enter to reveal answer

Answer

A workspace table created with a defined schema for ingestion of custom (non-standard) data. Named with the `_CL` suffix. Modern ingestion paths: Logs Ingestion API (REST + DCR-validated JSON) for application-emitted logs, or AMA custom-log DCRs for file-tailing patterns. Queryable with KQL like any built-in table.

Click to flip back

Question

What is the modern path for ingesting application-emitted logs into Sentinel?

Click or press Enter to reveal answer

Answer

The Logs Ingestion API + a Data Collection Rule with a defined schema, writing to a custom table (`_CL` suffix). REST endpoint accepts JSON payloads validated against the DCR schema. Replaces older patterns like HTTP Data Collector API and provides per-table RBAC, schema enforcement, and column-level transformations.

Click to flip back

Knowledge check

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?

Knowledge Check

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?

Knowledge Check

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.