15.2 Microsoft Sentinel Data Connectors, Content Hub & Normalization

Connector Types and When Each Applies

Choosing correctly is a common exam task. Anything Microsoft-to-Microsoft should be a native connector, never a custom API integration. Anything from a network appliance is CEF or syslog through a forwarder. Anything from a cloud provider has a purpose-built connector — for AWS, the S3-based connector reading CloudTrail, GuardDuty, and VPC flow logs.

---

Content Hub: Connectors Arrive With Their Detections

The Content hub is Sentinel's marketplace of solutions — packaged content for a product or scenario. Installing a solution can deliver, in one action:

• The data connector and its configuration steps.
• Analytics rule templates tuned to that source.
• Workbooks for visualization.
• Hunting queries for proactive investigation.
• Playbooks for automated response.
• Parsers, including ASIM parsers where relevant.

The practical lesson: install the solution from Content hub rather than only enabling the connector, because a connector without rules is just an ingestion bill. After installing, review the analytics rule templates and create rules from the ones that match your environment — templates are not active until instantiated.

---

The CEF and Syslog Forwarder Pattern

For firewalls, proxies, and other appliances that emit syslog or CEF:

1. Deploy a Linux virtual machine to act as a forwarder, reachable from the appliances.
2. Install the Azure Monitor Agent on it and run the provided installation script, which configures rsyslog or syslog-ng to listen and forward.
3. Create a data collection rule targeting the forwarder that collects the Microsoft-CommonSecurityLog stream (CEF) or Microsoft-Syslog stream, and sends it to the Sentinel workspace.
4. Point the appliances at the forwarder, typically on UDP or TCP 514.

Security considerations for the forwarder: it becomes a chokepoint and a target, so harden it like a jump host — no public IP, NSG restricted to the appliance source addresses, Defender for Servers enabled, and monitoring for the forwarder process itself. Size for peak events per second and deploy more than one behind a load balancer where volume demands it.

---

ASIM: One Rule, Many Products

The Advanced Security Information Model (ASIM) solves the problem that every vendor names the same field differently. ASIM defines normalized schemas — Authentication, Network Session, DNS Activity, Process Event, File Event, Web Session, Registry Event, and others — and ships parsers that map each source's native table into that schema.

• Source-specific parsers map one product's table to a schema.
• Unifying parsers (named with the _Im_ prefix for parameterized versions, _ASim_ for the non-parameterized form) query across all source-specific parsers at once.

The payoff: an analytics rule written against _Im_NetworkSession covers every firewall you have normalized, including ones you onboard next year, with no rule changes. Without ASIM you would write and maintain one rule per product. When a scenario mentions "one detection covering multiple firewall vendors", ASIM is the answer.

The cost is query-time computation, since parsers are functions evaluated at query time. For very high-volume, latency-sensitive rules, a source-specific rule may still be appropriate.

---

Connector Health and Table Plans

Silent ingestion failure is the most dangerous failure mode in a SIEM — the dashboard looks calm because nothing is arriving. Monitor for it:

• The SentinelHealth table records connector, analytics rule, and automation health events. Enable health monitoring on the workspace and build analytics rules on it.
• Build a simple volume-anomaly rule per critical table: alert when today's row count for SecurityEvent or CommonSecurityLog falls far below the trailing average.
• Watch agent heartbeat data for forwarders and critical servers.

Table plans shape what you can do with data once ingested:

Interactive retention on Analytics tables extends up to 730 days, with long-term retention available well beyond that for archival lookback. Choose the plan per table deliberately: putting a verbose proxy log on the Analytics plan is one of the fastest ways to exhaust a security budget without improving detection coverage.