Microsoft Sentinel Syslog, CEF, and Windows Event Collection – SC-200 Study Guide

Purpose of This Lesson

This lesson explains how Microsoft Sentinel ingests security event data from different operating systems, appliances, and log sources using common logging formats and data connectors.

For the SC-200 exam, this topic matters because a Microsoft Security Operations Analyst must understand how data gets into Microsoft Sentinel before it can be used for alerting, incident investigation, threat hunting, workbooks, analytics rules, and automation. Sentinel is only as useful as the data sources connected to it.

The main focus areas are:

• Syslog collection
• Common Event Format, or CEF
• Windows Security Events
• Windows Event Forwarding, or WEF
• Azure Monitor Agent, or AMA
• Data connectors and Content Hub
• Log Analytics workspace ingestion
• The transition between the Azure portal and Microsoft Defender portal for Sentinel management

---

Key Concepts

Microsoft Sentinel Depends on Data Ingestion

Microsoft Sentinel is a cloud-native SIEM and SOAR platform. Before it can detect threats, correlate alerts, or support investigations, it must ingest logs from data sources.

These data sources may include:

• Linux servers
• Network appliances
• Firewalls
• Routers
• Security appliances
• Windows servers
• Windows endpoints
• Cloud workloads
• Microsoft Defender products
• Third-party security tools

In Sentinel, data ingestion usually happens through data connectors. A connector defines how Sentinel receives, normalizes, and stores log data in a Log Analytics workspace.

The basic flow is:

1. A device, workload, or service generates security logs.
2. A connector or forwarding mechanism sends those logs to Azure.
3. Logs are stored in the Log Analytics workspace.
4. Microsoft Sentinel uses that data for detection, hunting, analytics, workbooks, incidents, and automation.

---

Syslog Overview

Syslog is a long-standing logging protocol and message format originally associated with Unix and later widely used in Linux environments.

Syslog is commonly used by:

• Linux systems
• Unix systems
• Firewalls
• Routers
• Switches
• VPN appliances
• Network security appliances
• Some third-party security platforms

In a Microsoft Sentinel environment, Syslog is important because many non-Microsoft systems do not generate Windows-style event logs. Instead, they send event data using Syslog.

A typical Syslog collection pattern looks like this:

1. A Linux server or appliance generates Syslog messages.
2. The messages are sent to a Syslog daemon or log forwarder.
3. The Azure Monitor Agent collects those logs.
4. The agent forwards the logs to Azure over TCP 443.
5. Microsoft Sentinel stores the data in the Log Analytics workspace.

Common Syslog transport details to remember:

• Syslog commonly uses UDP 514.
• Azure Monitor Agent sends collected data to Azure over HTTPS/TCP 443.
• Syslog collection often requires a Linux-based forwarder or agent system.

For SC-200, the key point is that Syslog is commonly used for Linux and appliance log collection into Sentinel.

---

Common Event Format, or CEF

Common Event Format, usually abbreviated as CEF, is a vendor-neutral event format used by many security products and network appliances.

CEF is commonly seen with:

• Firewalls
• IDS/IPS systems
• Security appliances
• Network devices
• Third-party SIEM integrations
• Vendor security platforms

CEF helps standardize how security events are structured. This makes it easier for Sentinel to parse and analyze logs from different vendors.

CEF is often transported using Syslog. This means a device may generate logs in CEF format and send those logs through a Syslog forwarding path.

A common CEF architecture looks like this:

1. Security appliance generates CEF logs.
2. Logs are forwarded using Syslog.
3. A Linux log forwarder receives the events.
4. Azure Monitor Agent collects the logs.
5. Events are sent to the Log Analytics workspace.
6. Microsoft Sentinel uses the data for analytics and investigation.

For the exam, remember that CEF is a log format, while Syslog is commonly used as the transport/collection mechanism.

---

Azure Monitor Agent and Log Forwarding

The Azure Monitor Agent, or AMA, is Microsoft’s modern agent for collecting monitoring and log data from machines.

In Microsoft Sentinel scenarios, AMA can collect logs from:

• Azure virtual machines
• On-premises servers
• Linux log forwarders
• Windows systems
• Syslog sources
• Windows Event Forwarding sources

AMA replaces older collection methods that relied on legacy agents. Microsoft may still support some legacy collection options, but the modern exam-oriented answer is usually to use Azure Monitor Agent with Data Collection Rules.

A common log forwarding design is:

Component	Purpose
Source device	Generates security logs
Syslog daemon or WEF collector	Receives forwarded events
Azure Monitor Agent	Collects logs from the forwarder or machine
Data Collection Rule	Defines what data should be collected
Log Analytics workspace	Stores the ingested logs
Microsoft Sentinel	Uses the logs for SIEM/SOAR operations

---

Data Connectors in Microsoft Sentinel

Data connectors are the mechanism Sentinel uses to connect to log sources.

Examples include:

• Syslog via AMA
• Common Event Format via AMA
• Windows Security Events
• Windows Forwarded Events
• Microsoft Defender XDR connectors
• Microsoft Entra ID connectors
• Microsoft Defender for Endpoint connectors
• Microsoft Defender for Office 365 connectors
• Microsoft Defender for Cloud connectors
• Third-party appliance connectors

For this lesson, the main connectors are:

• Syslog via AMA
• Common Event Format
• Windows Security Events
• Windows Forwarded Events

A connector does not automatically mean every device is sending logs successfully. It provides the Sentinel-side integration path, but the source devices, agents, forwarding rules, permissions, and network access still need to be configured correctly.

---

Content Hub vs Data Connectors

Microsoft Sentinel uses the Content Hub to install packaged solutions.

A solution may include:

• Data connectors
• Analytics rules
• Workbooks
• Hunting queries
• Parsers
• Playbooks
• Watchlists
• Other supporting content

After a solution is installed from Content Hub, its connector can usually be managed from the Data connectors blade.

For example:

1. Go to Microsoft Sentinel.
2. Open Content Hub.
3. Search for Syslog, CEF, or Windows events.
4. Install the relevant solution.
5. Go to Data connectors.
6. Open the connector page.
7. Configure collection rules or connection settings.

For the SC-200 exam, remember this relationship:

• Content Hub is where you install Sentinel content.
• Data connectors are where you configure ingestion from specific sources.

---

Azure Portal vs Microsoft Defender Portal

Microsoft Sentinel has been transitioning from the Azure portal experience into the Microsoft Defender portal experience.

Depending on the tenant and the timing, some Sentinel tasks may appear in:

• Azure portal at portal.azure.com
• Microsoft Defender portal at security.microsoft.com

You may see Sentinel configuration options in both places, including:

• Content Hub
• Data connectors
• Microsoft Sentinel workspace configuration
• Threat management
• Workbooks
• Incidents

For SC-200, do not get stuck on the portal location. Focus on the concept:

• Microsoft Sentinel uses data connectors.
• Content Hub provides installable solutions.
• Log data lands in a Log Analytics workspace.
• Microsoft is moving more Sentinel management into the Defender portal over time.

---

Windows Security Events

Windows systems generate security-related logs in Event Viewer. These logs include events such as:

• Successful logons
• Failed logons
• Privilege use
• Account changes
• Group membership changes
• Process creation, depending on configuration
• Security policy changes
• Object access events, depending on auditing configuration

In Microsoft Sentinel, Windows event data can be collected using the Windows Security Events connector.

This is useful for detecting activity such as:

• Suspicious logon behavior
• Brute-force attempts
• PowerShell attacks
• Suspicious command lines
• Living-off-the-land binary usage
• Registry manipulation
• Scheduled task abuse
• Endpoint threat activity

The transcript also references the Endpoint Threat Protection Essentials content dependency. This is an example of how installing one Sentinel solution may also install or depend on related content used for endpoint threat detection and investigation.

---

Windows Event Forwarding, or WEF

Windows Event Forwarding, abbreviated WEF, allows Windows systems to forward event logs to a collector.

This is useful when an organization wants a centralized Windows event collection model.

A basic Windows Event Forwarding flow looks like this:

1. Windows endpoints or servers generate event logs.
2. Events are forwarded to a Windows Event Collector.
3. Azure Monitor Agent collects the forwarded events.
4. A Data Collection Rule defines what should be collected.
5. Events are sent to the Log Analytics workspace.
6. Sentinel uses the data for detection and investigation.

In Sentinel, this is handled through the Windows Forwarded Events connector.

This connector is different from simply collecting local Windows Security Events from a single machine. WEF is about collecting forwarded events from multiple Windows systems through a collector.

---

Data Collection Rules

A Data Collection Rule, or DCR, defines what data Azure Monitor Agent should collect and where it should send that data.

When configuring Windows Forwarded Events or similar AMA-based connectors, you may create a DCR that specifies:

• The rule name
• The target machine or resource
• The event logs to collect
• Whether to collect all events or only selected/custom events
• The destination Log Analytics workspace

In the video example, a DCR is created to collect Windows forwarded events. The rule is associated with a machine running the Azure Monitor Agent.

For the exam, remember:

• AMA performs the collection.
• DCR controls what gets collected.
• Log Analytics workspace stores the collected data.
• Sentinel analyzes the collected data.

---

Legacy Agents vs Azure Monitor Agent

Microsoft has older log collection methods, including legacy agents. However, the modern Microsoft direction is the Azure Monitor Agent.

You may still see references to:

• Legacy Syslog collection
• Legacy Log Analytics agent
• Older Microsoft Monitoring Agent methods

For SC-200, if a scenario mentions modern Sentinel log ingestion, especially for Syslog, CEF, or Windows events, expect Azure Monitor Agent and Data Collection Rules to be the preferred answer.

---

Microsoft Security Operations Context

In a real SOC, log collection is foundational. Analysts cannot investigate what the SIEM never received.

A Microsoft Security Operations Analyst uses these connectors and event sources to support:

Alert Triage

When an alert fires, the analyst needs event data to validate whether the activity is suspicious.

Examples:

• Failed logons from a Windows server
• Suspicious process execution on an endpoint
• Firewall deny/allow events from a network appliance
• VPN authentication attempts
• Linux privilege escalation events
• CEF logs from a security appliance

Without the right connector, the alert may not exist or may lack enough context.

---

Incident Investigation

During investigation, Sentinel correlates alerts and entities across data sources.

Important entities may include:

• User accounts
• Hostnames
• IP addresses
• Processes
• Files
• Mailboxes
• Cloud resources
• Network devices

Syslog and CEF help bring non-Microsoft infrastructure into the same investigation workspace as Microsoft-native telemetry.

---

Scope and Impact Analysis

A SOC analyst may use collected logs to answer questions such as:

• Which systems communicated with a suspicious IP?
• Did multiple Linux servers show the same authentication pattern?
• Which firewall allowed traffic from the attacker?
• Did a Windows server show suspicious PowerShell execution?
• Did a network appliance detect exploit traffic?
• Was the activity isolated or widespread?

The broader the ingestion coverage, the better the analyst can determine scope.

---

Containment and Remediation

Log data does not always perform containment directly, but it informs containment decisions.

Examples:

• If Syslog data shows one Linux server affected, isolate that host.
• If CEF firewall logs show malicious inbound traffic, block the source IP.
• If Windows events show credential abuse, disable or reset affected accounts.
• If endpoint telemetry shows malicious process execution, isolate the device using Defender for Endpoint.

Sentinel helps centralize the evidence used to choose the right response action.

---

Detection Improvement

Collected logs can also be used to improve detection engineering.

SOC teams can use ingested data to build or tune:

• Analytics rules
• Hunting queries
• Workbooks
• Automation rules
• Playbooks
• Watchlists
• Entity mappings

For example, if CEF firewall logs repeatedly show allowed connections from suspicious regions, the SOC might create an analytics rule to detect similar behavior in the future.

---

Exam-Relevant Takeaways

For the SC-200 exam, remember these points:

• Syslog is commonly used by Linux, Unix, and network/security appliances.
• CEF is a vendor-neutral security event format often transported using Syslog.
• Windows Security Events come from Windows Event Logs and are useful for endpoint/server activity monitoring.
• Windows Event Forwarding centralizes Windows events from multiple systems.
• Azure Monitor Agent is the modern Microsoft agent for collecting logs.
• Data Collection Rules define what AMA collects and where it sends the data.
• Log Analytics workspace stores the data used by Microsoft Sentinel.
• Content Hub is used to install Sentinel solutions.
• Data connectors are used to configure log ingestion.
• Some Sentinel configuration may appear in Azure portal, while other parts may appear in Microsoft Defender portal.
• Sentinel cannot alert, hunt, or investigate data that has not been ingested.
• Legacy agents may exist, but AMA is the modern preferred collection method.

---

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Collect logs from Linux servers into Sentinel	Syslog via AMA	Linux commonly uses Syslog, and AMA is the modern collection agent
Collect firewall or appliance logs in a vendor-neutral format	Common Event Format, or CEF	CEF standardizes third-party security event data
Collect security logs from Windows systems	Windows Security Events connector	Windows Security Event Logs contain authentication, policy, and security activity
Centralize Windows events from many systems before sending to Sentinel	Windows Forwarded Events connector	WEF allows multiple Windows systems to forward events to a collector
Define which event logs AMA should collect	Data Collection Rule	DCR controls the data collection scope and destination
Install Sentinel connector packages, workbooks, and detection content	Content Hub	Content Hub provides installable Sentinel solutions
Configure the actual log source connection	Data connectors	Connectors define how Sentinel receives logs from a data source
Store ingested Sentinel log data	Log Analytics workspace	Sentinel uses Log Analytics as its data store
Use modern log collection instead of older agents	Azure Monitor Agent	AMA is Microsoft’s modern collection method
Investigate correlated alerts across multiple data sources	Microsoft Sentinel incidents	Incidents group related alerts and entities for SOC investigation

---

KQL Notes

The transcript does not include detailed KQL queries, but KQL is important because once Syslog, CEF, and Windows events are ingested, analysts use KQL to search and analyze the data in Microsoft Sentinel.

The exact table names may vary depending on connector configuration and data source, but common tables include:

• Syslog
• CommonSecurityLog
• SecurityEvent
• WindowsEvent

Example: Query Syslog Events

Syslog
| where TimeGenerated > ago(24h)
| where SeverityLevel in ("err", "crit", "alert", "emerg")
| project TimeGenerated, Computer, Facility, SeverityLevel, SyslogMessage
| order by TimeGenerated desc

What This Query Does

• Searches the Syslog table.
• Looks back over the last 24 hours.
• Filters for higher-severity events.
• Displays the most useful fields for triage.
• Sorts the newest events first.

This could help an analyst quickly identify serious Linux or appliance events.

---

Example: Query CEF Events

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor != ""
| project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, Activity, DeviceAction
| order by TimeGenerated desc

What This Query Does

• Searches CEF-style security logs stored in CommonSecurityLog.
• Displays vendor and product details.
• Shows source and destination IPs.
• Includes the activity and device action.
• Helps analyze firewall, appliance, or third-party security logs.

---

Example: Query Windows Security Events

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4624, 4625)
| project TimeGenerated, Computer, Account, EventID, Activity, IpAddress
| order by TimeGenerated desc

What This Query Does

• Searches Windows Security Events.
• Looks for successful logons and failed logons.
• Displays account, computer, event ID, activity, and IP address.
• Helps investigate authentication behavior.

Common Windows event IDs to recognize:

Event ID	Meaning
4624	Successful logon
4625	Failed logon
4688	Process creation, if enabled
4720	User account created
4728	User added to a privileged group
4732	User added to a local group

For SC-200, you do not need to memorize every Windows Event ID, but you should understand that Windows Security Events are used heavily for identity, endpoint, and server investigation.

---

Common Exam Traps

Confusing Syslog and CEF

Syslog and CEF are related but not identical.

• Syslog is commonly used as a logging protocol and transport mechanism.
• CEF is a structured event format used by many security vendors.
• CEF logs are often sent using Syslog.

If the question asks about vendor-neutral security event formatting, think CEF.
If the question asks about Linux or appliance log forwarding, think Syslog.

---

Forgetting That Sentinel Requires Data Connectors

Microsoft Sentinel does not magically receive logs from every device in the environment.

You need to configure:

• Connector
• Agent or forwarding method
• Data Collection Rule
• Destination workspace
• Network path
• Source device forwarding

If the data source is not connected, Sentinel cannot query it, alert on it, or include it in incidents.

---

Choosing Legacy Agents Instead of AMA

Microsoft’s preferred modern collection method is Azure Monitor Agent.

Legacy agents may appear in older documentation or environments, but exam scenarios often expect:

• Azure Monitor Agent
• Data Collection Rules
• Log Analytics workspace destination

---

Confusing Windows Security Events and Windows Forwarded Events

These are related but not the same.

• Windows Security Events are security logs from Windows systems.
• Windows Forwarded Events are events forwarded using Windows Event Forwarding to a collector.

If the scenario involves multiple Windows devices forwarding logs to a central collector, think Windows Forwarded Events.

---

Confusing Content Hub with Data Connectors

Content Hub is where you install Sentinel solutions.
Data connectors are where you configure the ingestion connection.

A solution may include multiple pieces of content, including connectors, analytics rules, workbooks, and hunting queries.

---

Assuming the Portal Location Is the Main Concept

Microsoft Sentinel may be managed in Azure portal or Microsoft Defender portal depending on the tenant and Microsoft’s current rollout.

The exam is more likely to test the feature or workflow than the exact portal navigation.

---

Real-World SOC Analyst Notes

Alert Fatigue

Bringing in Syslog, CEF, and Windows events can greatly increase log volume. More data is useful, but it can also create noise.

SOC teams should tune:

• Analytics rules
• Event collection scope
• Severity thresholds
• Suppression logic
• Watchlists
• Automation rules
• Entity mappings

Collecting everything may be useful during testing, but it can become expensive and noisy in production.

---

False Positives

Raw event logs are not automatically malicious. For example:

• Failed logons may be normal user mistakes.
• Firewall denies may be normal background internet noise.
• PowerShell activity may be legitimate administration.
• Scheduled tasks may be normal software maintenance.

Good investigation requires context, baselines, and correlation.

---

Evidence Preservation

When investigating an incident, preserve the relevant evidence:

• Original event timestamps
• Source device
• Destination device
• User account
• IP addresses
• Event IDs
• Query results
• Screenshots or exported evidence when required by process
• Incident notes in Sentinel or the ticketing system

SOC analysts should document how they determined whether the activity was benign, suspicious, or confirmed malicious.

---

Escalation Paths

Different log sources may require different escalation teams.

Examples:

Evidence Source	Likely Escalation Team
Windows Security Events	Endpoint, server, identity, or AD team
Syslog from Linux	Linux/server administration team
CEF firewall logs	Network/security engineering team
Defender for Endpoint alerts	Endpoint security team
Entra ID sign-in logs	Identity team
Cloud resource logs	Cloud operations or cloud security team

A good SOC analyst does not just detect activity; they route it to the correct owner with clear evidence.

---

Automation Safety

Automation can help reduce response time, but it must be scoped carefully.

Examples of risky automation:

• Blocking IPs too broadly
• Disabling users without validation
• Isolating production servers automatically
• Closing incidents without adequate evidence
• Applying suppression rules that hide real attacks

For high-impact actions, organizations often require approval, change control, or human review.

---

Sentinel Cost Considerations

Microsoft Sentinel costs are closely tied to data ingestion and retention.

Syslog, CEF, and Windows event collection can produce large amounts of data, especially from:

• Firewalls
• Domain controllers
• High-volume Linux servers
• Web proxies
• VPN appliances
• Endpoint fleets

In production, teams should consider:

• Which logs are required for detection
• Which logs are required for compliance
• Which logs are too noisy
• Retention requirements
• Basic logs vs analytics logs, where applicable
• Filtering at the source where appropriate
• DCR scope and collection rules

From a real-world operations perspective, “collect everything forever” is rarely the best answer.

---

Quick Reference Summary

• Syslog is commonly used for Linux, Unix, and appliance logging.
• CEF is a vendor-neutral event format often transported over Syslog.
• Azure Monitor Agent is the modern Microsoft agent for collecting logs.
• Data Collection Rules define what AMA collects.
• Log Analytics workspace stores Sentinel data.
• Content Hub installs Sentinel solutions.
• Data connectors configure ingestion.
• Windows Security Events collect Windows security log data.
• Windows Forwarded Events collect WEF-based centralized Windows events.
• Sentinel may be managed from Azure portal or Microsoft Defender portal depending on the tenant.
• For SC-200, focus on choosing the correct connector, collection method, and investigation workflow.

---

Flashcards

Q: What is Syslog commonly used for?
A: Collecting logs from Linux, Unix, network appliances, firewalls, routers, and other non-Windows systems.

Q: What is Common Event Format, or CEF?
A: A vendor-neutral event format commonly used by security appliances and third-party security products.

Q: How are CEF logs often transported to Sentinel?
A: They are often sent using Syslog to a log forwarder, then collected by Azure Monitor Agent.

Q: What is the modern Microsoft agent for log collection into Sentinel?
A: Azure Monitor Agent, or AMA.

Q: What does a Data Collection Rule do?
A: It defines what data Azure Monitor Agent collects and where the data is sent.

Q: Where does Microsoft Sentinel store ingested log data?
A: In a Log Analytics workspace.

Q: What is Content Hub used for in Microsoft Sentinel?
A: Installing solutions that may include connectors, analytics rules, workbooks, hunting queries, and other content.

Q: What is the Data connectors page used for?
A: Configuring specific ingestion connections between Sentinel and data sources.

Q: Which connector would you use for Linux server logs?
A: Syslog via AMA.

Q: Which connector would you use for vendor-neutral firewall or appliance logs?
A: Common Event Format, or CEF.

Q: Which connector is used for Windows Event Forwarding collection?
A: Windows Forwarded Events.

Q: What is WEF?
A: Windows Event Forwarding, a method for forwarding Windows events from multiple systems to a collector.

Q: Why is log ingestion important for SOC investigations?
A: Sentinel can only alert, correlate, hunt, and investigate data that has been collected.

Q: Which KQL table commonly stores CEF logs?
A: CommonSecurityLog.

Q: Which KQL table commonly stores Windows Security Events?
A: SecurityEvent.

---

Practice Questions

Question 1:

You need to collect security logs from several Linux servers and make them available for Microsoft Sentinel hunting queries. Which connector should you use?

A. Microsoft Defender for Office 365
B. Syslog via Azure Monitor Agent
C. Windows Forwarded Events
D. Microsoft Defender for Identity

Correct Answer:
B. Syslog via Azure Monitor Agent

Explanation:
Linux systems commonly use Syslog for event logging. Microsoft Sentinel can ingest Syslog data using Azure Monitor Agent and a Data Collection Rule.

---

Question 2:

A firewall vendor supports exporting security events in a vendor-neutral format. You want Microsoft Sentinel to ingest and analyze these logs. Which format is most likely being used?

A. Windows Event Format
B. Common Event Format
C. Microsoft Graph format
D. Azure Resource Manager format

Correct Answer:
B. Common Event Format

Explanation:
Common Event Format, or CEF, is a vendor-neutral event format commonly used by firewalls, appliances, and third-party security products.

---

Question 3:

You installed a Sentinel solution from Content Hub, but logs are still not appearing in the workspace. What is the most likely issue?

A. Content Hub only installs content; the connector and source forwarding still need configuration.
B. Microsoft Sentinel does not support third-party logs.
C. Logs can only be collected from Microsoft Defender XDR.
D. Analytics rules must be disabled before logs can be ingested.

Correct Answer:
A. Content Hub only installs content; the connector and source forwarding still need configuration.

Explanation:
Installing a solution from Content Hub provides the Sentinel content, but ingestion still requires correct connector configuration, agent setup, forwarding rules, and workspace destination settings.

---

Question 4:

You need to centralize Windows events from many Windows servers and forward them into Microsoft Sentinel through a collector. Which feature is most appropriate?

A. Windows Forwarded Events
B. Common Event Format
C. Defender for Office 365 Explorer
D. Microsoft Entra ID Identity Protection

Correct Answer:
A. Windows Forwarded Events

Explanation:
Windows Forwarded Events supports ingestion of events collected through Windows Event Forwarding. This is appropriate when multiple Windows systems forward events to a collector.

---

Question 5:

A SOC analyst wants to search recently ingested CEF firewall logs in Microsoft Sentinel. Which KQL table is commonly used for this type of data?

A. SecurityEvent
B. CommonSecurityLog
C. AuditLogs
D. SigninLogs

Correct Answer:
B. CommonSecurityLog

Explanation:
CEF data is commonly stored in the CommonSecurityLog table, which is used for many third-party security appliance logs.