13.2 Data Connectors, Syslog/CEF & Windows Event Collection

13.2 Data Connectors, Syslog/CEF & Windows Event Collection

Quick Answer: Use data connectors to ingest logs into Sentinel's workspace. Prefer service-to-service Microsoft connectors for Azure/Microsoft services, and Azure Monitor Agent (AMA) + data collection rules (DCRs) for Syslog, CEF, and Windows Security events (including designs that use Windows Event Forwarding). Confirm data lands in the right tables and filter early to control cost.

SC-500 skills include configure and use Microsoft data connectors for Azure resources, implement syslog and CEF event collections, and collect Windows Security events using data collection rules, including Windows Event Forwarding (WEF). This section is the ingestion engineering core of the exam domain.

---

How data connectors fit the architecture

After Sentinel is enabled, connectors are how events enter Log Analytics tables for analytics rules, hunting, and workbooks.

Many connectors ship inside Content hub solutions. Install the solution, open the connector page, complete prerequisites, and wait until status shows Connected and sample queries return rows.

Legacy note (awareness, not deep trivia): Microsoft has deprecated older agent patterns (Log Analytics agent / MMA and legacy HTTP Data Collector API timelines). Exam and production designs should center on AMA + DCR and modern ingestion APIs.

---

Microsoft data connectors for Azure resources

Common Microsoft-oriented connectors SC-500 candidates should recognize:

Azure Activity — classic first connector

Typical configuration pattern:

1. Install Azure Activity solution from Content hub.
2. Open the connector -> launch Azure Policy assignment wizard.
3. Scope the subscription/RG that should send activity.
4. Set the primary Log Analytics workspace to the Sentinel workspace.
5. Create the policy assignment and verify AzureActivity queries return events.

Scenario: After a suspicious role assignment, analysts query AzureActivity for Microsoft.Authorization/roleAssignments/write near the incident time. Without this connector, that control-plane trail is missing from Sentinel.

Connector permissions mindset

Each connector lists prerequisites: workspace write rights, policy assignment rights, Entra app permissions, or diagnostic settings authority on source resources. If a connector stays Disconnected, check permissions and whether the source is actually emitting logs — not only the Sentinel blade.

---

Syslog and CEF collection with AMA

Formats

• Syslog: Widely used host/device logging (RFC 3164 / 5424). Ingested messages typically appear in the Syslog table.
• CEF (Common Event Format): Security-oriented structured syslog extension used by many firewalls, proxies, and NDR tools. CEF events typically land in CommonSecurityLog.

Architectures

1) Agent on the Linux host itself (Syslog originator)

• Local syslog daemon (rsyslog / syslog-ng) receives local events.
• Daemon forwards to AMA.
• AMA sends to the Sentinel workspace per DCR.

2) Dedicated Linux log forwarder (most appliance designs)

• Network/security devices send Syslog/CEF (often UDP/TCP 514, or another agreed port) to the forwarder.
• Forwarder syslog daemon receives and hands messages to AMA.
• AMA uploads to Log Analytics.
• Forwarder can be Azure VM, on-premises, or another cloud — so long as AMA can reach Azure Monitor endpoints.

Connector setup outline

1. Install Syslog and/or Common Event Format solutions from Content hub.
2. Configure Syslog via AMA / CEF via AMA connectors.
3. Create a DCR selecting facilities/severities (or finer filters via API).
4. Select target Linux machines (AMA installs/autoprovisions as configured).
5. On forwarders, run the installation script so the syslog daemon listens for remote devices and opens required local ports.
6. Point devices at the forwarder; verify tables populate.

AMA version notes (high level): modern AMA versions receive from the syslog daemon on a local TCP port (for example 28330 on recent versions) rather than only Unix domain sockets — know that the daemon-to-agent path is local and version-sensitive, not something you reconfigure on every firewall.

Avoid CEF/Syslog duplication

If the same facility is collected as both Syslog and CEF, you can double-ingest into Syslog and CommonSecurityLog. Mitigations:

• On devices, send CEF on facilities not also collected as plain Syslog.
• Or add DCR transformKql filters that drop CEF payloads from the Syslog stream.

Exam trap: CEF does not always go to the Syslog table. CEF is stored in CommonSecurityLog; plain Syslog goes to Syslog.

---

Windows Security events via DCRs (and WEF)

AMA + DCR for Windows events

Data collection rules declare:

• Which machines (Azure VMs, Arc-enabled servers, scale sets)
• Which data sources (Windows Event Logs, performance, text logs, etc.)
• Destinations (Log Analytics workspace streams)
• Optional XPath filters to reduce noise

For general Windows Application/System logs, a Windows Event Logs DCR can send to the Event table. For Microsoft Sentinel security analytics, enable the Windows Security Events via AMA connector (Content hub / Sentinel data connectors). That path is designed so security events populate SecurityEvent, which Sentinel content expects.

Filter with XPath when basic log+severity selectors are too broad. Example pattern form: Security!*[System[(EventID=4625)]] for failed logons. Validate XPath with Get-WinEvent -FilterXPath on a sample host before fleet rollout.

Windows Event Forwarding (WEF)

WEF is the Windows platform feature that forwards event logs from many endpoints to a collector (subscription source-initiated or collector-initiated). In Sentinel designs, WEF is usually a centralization layer, not a replacement for AMA:

1. Configure event subscriptions so sources forward Security (and other) channels to a collector.
2. Harden collector capacity, network paths, and subscription filters (Event IDs/channels).
3. Install AMA on the collector (or on each source if not using WEF) and attach a DCR / Windows Security Events via AMA configuration that ships the needed events to the Sentinel workspace.

When to use WEF patterns:

• Existing enterprise WEF infrastructure already aggregates domain logs
• Segmented networks where only collectors may reach Azure Monitor
• Desire to reduce agent sprawl by collecting at tiered collectors

When direct AMA on each host is simpler:

• Cloud-native fleets already Arc/AMA managed
• You need per-host filtering with less WEF operational overhead

Scenario: A hybrid estate uses WEF to domain collectors for Event ID 4625/4672. Security engineers install AMA on collectors, enable Windows Security Events via AMA with XPath for those IDs, and confirm SecurityEvent ingestion before enabling brute-force analytics rules.

---

AMA agent concepts (exam-ready)

Cost and performance tips:

• Filter at DCR/XPath/facility before hot storage.
• Collect Security events you can detect on — not every informational channel by default.
• Separate noisy debug sources from SOC-critical streams.

---

Exam traps checklist

Configure Microsoft service connectors for Azure control/identity planes, use AMA-based Syslog/CEF for appliances, and implement Windows Security collection with DCRs — optionally fronted by WEF — and you can answer the SC-500 collection design questions confidently.