What's changed: Created SC-200 Chapter 2 (Domain 1 middle: Sentinel roles/data retention (Analytics, Data lake, XDR tiers)/workbooks/SOC optimization; data connector selection/Windows Security Events via AMA/Azure Monitor Agent (AMA)/data collection rules (DCR)/Windows Event Forwarding (WEF); Syslog via AMA, CEF via AMA/Azure activities (resource diagnostic settings, Azure Policy)/threat indicators (IOCs, threat intelligence connectors)/custom log tables).
2.3Syslog/CEF, Azure activities, and threat indicators
Understand Syslog via AMA and Common Event Format (CEF) via AMA connectors, collecting Azure activities (Azure Policy, resource diagnostic settings), ingesting threat indicators, and creating custom log tables.
Beyond Windows, you see the whole picture only by also collecting appliance logs (firewalls, proxies), Azure resource logs, and external threat intelligence. This section organizes those ingestion points.
2.3.1Syslog/CEF and Azure activities
Network devices/appliances emit Syslog. Devices emitting structured Common Event Format (CEF) (many firewalls) use CEF via AMA; other generic Syslog uses the Syslog via AMA connector. Azure resource operations/metrics go to Log Analytics (Sentinel) via resource diagnostic settings, and Azure Policy can enforce those diagnostic settings across all resources. "Firewall structured logs" = CEF; "send Azure resource logs to Sentinel at scale" = diagnostic settings + Azure Policy.
2.3.2Threat indicators and custom log tables
Ingest external threat indicators (IOCs) (malicious IPs/domains/hashes) via threat intelligence connectors (TAXII, platform integration, Defender TI) so analytics rules and hunting can match them against your logs. For custom logs that do not fit standard tables, create custom log tables in the workspace. This makes any source available for detection/investigation.
Cues: "structured firewall logs (CEF)" = CEF via AMA; "generic Syslog" = Syslog via AMA. "send Azure resource logs to Sentinel and enforce across all" = resource diagnostic settings + Azure Policy. "ingest IOCs (malicious IPs/domains) and match" = threat indicators (TI connector). "store custom-format logs" = custom log tables.
Watch the mix-ups: (1) CEF (structured) vs generic Syslog—different connectors. (2) Diagnostic settings (resource → Sentinel) vs Azure Policy (enforce that setting org-wide). (3) Threat indicators are "matching material for detection"—not detection rules themselves.
2.3.3Section summary
- Structured firewall logs = CEF via AMA; generic Syslog = Syslog via AMA
- Azure resource logs = resource diagnostic settings to Sentinel; enforce org-wide via Azure Policy
- Ingest threat indicators (IOCs) for matching; store custom logs in custom log tables
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A firewall emits structured logs in Common Event Format (CEF). What is best to ingest into Sentinel?
Q2. You want to enforce, consistently across all resources, the setting that sends many Azure resources’ logs to Sentinel. Which is best?
Q3. You want to ingest external threat intelligence (malicious IPs/domains/hashes) and match it against your logs in analytics rules and hunting. Which is best?
Q4. You want to store custom-format logs in Sentinel that do not fit standard tables. Which is best?
Q5. Which correctly distinguishes CEF via AMA from Syslog via AMA?