Data connectors and the content hub

An empty workspace detects nothing. On Wednesday, November 4, the sprint turned to data, and Nadia began with a question that surprised Ama: "Which incidents from October would we have missed without the Defender portal?" Ama listed them from memory. The phished buyer's mailbox had been caught by Defender for Office 365; the storage token leak by Defender for Cloud; the laptop with the malicious label utility by Defender for Endpoint. Every one had been caught by a product that already sent its alerts to the Defender portal. "So Sentinel isn't here to repeat those," Nadia said. "It's here for what those products can't see, and for keeping evidence longer than they do." That framed the choice of connectors.

How data reaches Sentinel

A data connector is the configuration that brings data from a source into the workspace. Connectors are not all built the same way, and knowing the type tells you what it needs and what can go wrong. Microsoft's own services mostly use service-to-service connections, where you switch the connector on and the service writes into the workspace. Servers and network devices use the Azure Monitor Agent, covered in lesson 4. Other cloud services and software-as-a-service products are reached through their APIs, either with connectors built on Microsoft's Codeless Connector Framework, which Sentinel runs for you, or with older connectors built on Azure Functions, which run in your subscription and are billed separately.

The content hub

In Sentinel, connectors usually come packaged with other content in solutions from the content hub. A solution for a product typically contains its data connector, parsers that turn its raw logs into usable fields, analytics rule templates, hunting queries, workbooks and sometimes playbooks. Microsoft publishes solutions for its own products and many partners publish solutions for theirs. Installing a solution needs the Microsoft Sentinel Contributor role on the workspace's resource group, which is why Sunil activated his eligible role at the start of the session.

Installing a solution does not switch anything on by itself. The connector still has to be configured, and analytics rule templates have to be turned into active rules, ideally after reading them, because a template written for a generic environment may be noisy in yours. Solutions also have versions. When a publisher updates a solution, the content hub shows that an update is available, and installed templates can show that a newer version exists; rules created from them are not changed automatically. Sunil added a monthly task to review content hub updates, because detection content that never changes slowly falls behind the threats it was written for.

The Microsoft sources

The team connected four Microsoft sources on the first afternoon. Each needed a decision about which data types to bring in, because a connector often covers several tables with different costs and value.

The Defender XDR connector deserved the most thought. Because the workspace is connected to the Defender portal, advanced hunting can already query Defender XDR tables for about the last 30 days without ingesting them into Sentinel at all. Ingesting them costs money, so the reasons have to be real. Nadia had two. Investigations sometimes need device and mail evidence older than 30 days, as the October penetration test review had shown when the testers asked about a laptop's activity from early September. And Sentinel analytics rules and workbooks can only use what is in the workspace. Nadia did not ask for every raw table: DeviceFileEvents and DeviceRegistryEvents, the largest ones, stayed in the Defender portal only, available for 30-day hunting and for custom detection rules written in Defender itself.

The Microsoft Entra ID connector works through diagnostic settings on the tenant, which needs the Security Administrator or Global Administrator role in Entra ID to configure. Sign-in logs come in several tables: interactive user sign-ins in SigninLogs, non-interactive sign-ins (tokens refreshed by apps in the background) in AADNonInteractiveUserSignInLogs, and service principal and managed identity sign-ins in their own tables. Non-interactive sign-ins are the big one, often many times the volume of interactive sign-ins, so Sunil checked their size during the free trial before deciding to keep them in the analytics tier. They stayed, because the token theft in the October phishing cases had shown up only in non-interactive sign-ins from an unfamiliar address.

Usage
| where TimeGenerated > ago(7d)
| where IsBillable == true
| summarize GB = round(sum(Quantity) / 1024, 2) by DataType
| sort by GB desc

Ama ran that query at the end of the first week of the trial. Non-interactive sign-ins were 1.6 GB a day against 0.5 GB for interactive sign-ins, and DeviceNetworkEvents was the largest Defender table at 2.9 GB. The Usage table itself is a good habit: it shows what each table really costs rather than what the estimate in lesson 1 assumed.

Partner and SaaS sources

Two non-Microsoft sources were in scope for the sprint. The store and head office firewalls send logs in Common Event Format (CEF), which lesson 4 connects through a Linux log forwarder. The firewall vendor publishes a content hub solution with a parser and rule templates, so Sunil installed it to get the content even though the data would arrive through the generic CEF via AMA connector. The second source, the hosted HR and payroll system, has an API that reports sign-ins and changes to bank details. Its connector would use the Codeless Connector Framework, but the vendor's API credentials needed a contract change, so the team planned it for January 2027.

Nadia ruled out a third request. The cloud team had suggested sending every Azure resource's diagnostic logs to the security workspace. She asked which threats each log would help detect, and for most of them nobody could name one. Key Vault access logs, Azure Firewall logs, the storage accounts with supplier and customer data, and the SQL servers' auditing logs went to the security workspace. Everything else stayed in the operations workspace, reachable by a cross-workspace query if an investigation ever needed it.

Checking connector health

A connector that stops working fails quietly: the detections that depend on it simply stop firing. Sentinel has a health feature that, once enabled in the workspace settings, writes events about connectors, analytics rules and automation to the SentinelHealth table, which is free to ingest. The data connectors page also shows when each connector last received data. Sunil enabled health monitoring on the first day and wrote an analytics rule that raises a medium-severity incident if any billable table that normally receives data every hour has received nothing for three hours.

from datetime import datetime, timedelta
now = datetime(2026, 11, 12, 9, 0)
last_seen = {
    "SigninLogs": now - timedelta(minutes=12),
    "AADNonInteractiveUserSignInLogs": now - timedelta(minutes=9),
    "CommonSecurityLog": now - timedelta(hours=4, minutes=20),
    "SecurityEvent": now - timedelta(minutes=31),
    "OfficeActivity": now - timedelta(hours=1, minutes=5),
}
threshold = timedelta(hours=3)
for table, seen in sorted(last_seen.items(), key=lambda kv: kv[1]):
    gap = now - seen
    hours = gap.total_seconds() / 3600
    flag = "SILENT - raise incident" if gap > threshold else "ok"
    print(f"{table:<32} last data {hours:4.1f} h ago  {flag}")

CommonSecurityLog                last data  4.3 h ago  SILENT - raise incident
OfficeActivity                   last data  1.1 h ago  ok
SecurityEvent                    last data  0.5 h ago  ok
SigninLogs                       last data  0.2 h ago  ok
AADNonInteractiveUserSignInLogs  last data  0.1 h ago  ok

The check paid for itself in the second week. On the morning of November 12, CommonSecurityLog had been silent for over four hours. The cause was not an attack: a configuration change on the head office router overnight had removed the route from the store network to the log forwarder. Without the check, nobody would have noticed until an investigation needed firewall data and found a hole in it.

Owning each connector

Every connector depends on something outside the SOC: a diagnostic setting someone could delete, a forwarder someone could patch, a credential that will expire. Nadia insisted that each connector have a named owner on the source side as well as in the SOC. For the Microsoft Entra ID connector the source owner is the identity team; for the firewalls it is the network team; for the future HR connector it will be the HR systems administrator. When the silent-table rule fires, the incident's first task is to contact that owner, which is why the owner's name is in the connector record rather than in someone's memory.

Changes on the source side are the commonest cause of silent connectors, so Sunil asked the change advisory board to add one question to every change request touching a logged system: will this change affect what the system sends to the security workspace? The router change that silenced the firewalls on November 12 would have been caught by that question.

By the end of November 4 the workspace was receiving data from eight sources. Ama recorded each connector in the design record with its type, the tables it fills, the person who owns the source system, and how a failure would be noticed, so that when something goes quiet the SOC knows whom to call.