Sentinel Data Connectors

Microsoft Sentinel data connectors are the mechanisms that bring security data from various sources into your Sentinel workspace. They act as bridges between data producers (like firewalls, servers, cloud services) and the Sentinel data ingestion pipeline. Without connectors, Sentinel would have no data to analyze. The SC-200 exam tests your ability to select, configure, and troubleshoot these connectors.

Sentinel supports two main categories of connectors:

Additionally, there are API-based connectors (e.g., AWS S3, GCP) and agent-based connectors (e.g., Windows Security Events via MMA or AMA).

When you enable a connector, Sentinel creates a data collection rule (DCR) or uses a Log Analytics workspace as a target. For service-to-service connectors, the data flows directly from the source service to the workspace via Azure Monitor pipelines. For ingestion-based connectors, data is sent to a Log Analytics gateway (the Log Analytics agent) or directly to the workspace via the HTTP Data Collector API. The connector then maps the incoming data to specific tables in the workspace (e.g., Syslog, CommonSecurityLog, AWSCloudTrail).

#### Example: Syslog Connector

The Syslog connector uses the Log Analytics agent (or Azure Monitor Agent) installed on a Linux server that receives Syslog messages. The agent forwards the messages to the workspace. The connector defines the facility and severity levels to collect. By default, all facilities and severities are collected, but you can filter to reduce noise. The data lands in the Syslog table.

#### Example: CEF Connector

CEF is a standard log format used by many security appliances. The CEF connector uses a Syslog forwarder (Linux server with the Log Analytics agent) that listens on TCP port 25226 or UDP 514. The agent parses the CEF messages and forwards them to Sentinel. The data is stored in the CommonSecurityLog table. The connector requires the agent to be configured with a specific parser (the cef_parser.py script).

To verify connector health, you can use the following KQL queries:

// Check Syslog connector health
Syslog
| where TimeGenerated > ago(1h)
| summarize Count = count() by Computer

// Check CEF connector health
CommonSecurityLog
| where TimeGenerated > ago(1h)
| summarize Count = count() by DeviceVendor, DeviceProduct

For agent connectivity:

# On Windows agent, check connectivity to workspace
Test-CloudConnectivity -WorkspaceId <your-workspace-id>

# On Linux agent, check if agent is running
sudo /opt/microsoft/omsagent/bin/omsagent -d

| Connector Type | Examples | Data Table | Agent Required | |----------------|----------|------------|----------------| | Service-to-service | Azure AD, Office 365, Azure Activity | Varies | No | | API-based | AWS S3, GCP, Okta | Varies | No (but uses API) | | Agent-based (Windows) | Windows Security Events | Event | Yes (MMA/AMA) | | Agent-based (Linux) | Syslog, CEF | Syslog, CommonSecurityLog | Yes (MMA/AMA) |

A multinational company uses Palo Alto Networks firewalls across its global offices. They need to ingest traffic logs, threat logs, and system logs into Sentinel for centralized monitoring. The solution uses the CEF connector. A Linux server in each region acts as a Syslog forwarder. The firewalls are configured to send CEF-formatted logs to the forwarder's UDP 514 port. The forwarder runs the Log Analytics agent and the CEF parser. The data lands in CommonSecurityLog. The team monitors the forwarder's disk space and CPU usage, as high log volume (e.g., 10,000 EPS) can overwhelm the server. They also use the Sentinel Health workbook to track ingestion latency. A common issue is that the CEF parser stops due to memory corruption; the team has a script to restart it automatically.

A company uses AWS for its cloud infrastructure and wants to ingest CloudTrail logs into Sentinel. They use the AWS S3 connector. They create an S3 bucket for CloudTrail logs, enable SQS for notifications, and configure an IAM role that Sentinel assumes to read the bucket. The connector polls the SQS queue every 5 minutes. Data appears in the AWSCloudTrail table. They noticed that if the SQS queue is not set up, logs are delayed by up to 15 minutes (the polling interval). They also set up a Sentinel analytics rule to detect suspicious API calls. A challenge is managing cross-account IAM permissions and ensuring the S3 bucket policy allows Sentinel to read objects.

A company uses Windows Event Log forwarding to collect security events from 500 servers to a central Windows Event Collector (WEC). The WEC forwards events to Sentinel using the Windows Security Events via AMA connector. They use Azure Monitor Agent (AMA) with a Data Collection Rule (DCR) that filters for Event IDs 4624, 4625, and 4688. The DCR also transforms the data to include custom fields. The team monitors the Event table for ingestion volume. A common misconfiguration is forgetting to install the AMA on the WEC server, which causes no data to appear. They also use Azure Policy to deploy the AMA and DCR at scale across multiple subscriptions.