5.4.3. Microsoft Sentinel: Data Connectors and Analytics Rules

💡 First Principle: Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) platform. It provides a single pane of glass for security operations, deconstructing silos between different log sources through standardized normalization and AI-driven correlation.

Data Connector Types

⚠️ Exam Trap: Missing permissions for Azure Functions connectors. If you can add other connectors but not an Azure Functions-based connector, you need read and write permissions for Azure Functions (not just the Log Analytics workspace).

Standardized Account Entities (2026 Focus)

💡 First Principle: Effective threat detection requires a common language for identifying the "actors" and "targets" of an attack. Sentinel uses standardized entity logic to ensure that an "Account" or "Host" discovered in Entra ID logs can be perfectly correlated with the same entity found in firewall or endpoint logs.

• Improved Consistency: Common schema (ASIM) across analytics and automation rules.
• Entity Types: Account, Host, IP, URL, File, Process, Registry, Cloud Application, etc.
• Entity Mapping: Custom analytics rules must map log fields to these standard types to enable advanced features like UEBA.
• Cross-Entity Correlation: Identifying that a specific IP (origin) is attempting to brute-force a specific Account (target) which then successfully logged into a sensitive Host.
• Benefits: Drastically reduces investigation time by grouping all related alerts under a single unified incident based on shared entities.

Scenario: An analyst investigating a suspected breach can pivot from a suspicious IP address to see all Accounts associated with that IP, and then see which Files those accounts accessed across different storage platforms.

Microsoft Sentinel Model Context Protocol (MCP) Server

💡 First Principle: Modern security operations require AI to "understand" the context of logs, not just the text. The MCP server acts as an intelligent bridge, enabling Sentinel to interact with large language models and specialized security AI.

• Role in AI Security: Facilitates the exchange of context between security logs and AI reasoning engines.
• Centralized Collection: Improved architecture for aggregating logs from distributed environments.
• AI/ML Integration: Automates the initial triage of alerts by providing AI-generated summaries and risk scores.
• Proxy Configuration: Essential for hybrid environments where logs must traverse restricted network segments.
• Data Routing Optimization: Dynamically directs high-value security data to Analytics tiers while routing noise to more cost-effective tiers.

Sentinel Architecture with MCP and Data Lake

Integrated Microsoft Sentinel Data Lake

💡 First Principle: Security data value changes over time. An integrated data lake allows for a multi-tiered storage strategy that balances high-speed query performance for active investigations with low-cost retention for long-term compliance.

• Azure Data Explorer (ADX) Integration: Seamlessly extends KQL query capabilities from the primary workspace to a massive long-term data lake.
• Cost Optimization Tiers:

  Tier	Retention Focus	Cost	Query Speed
  Analytics	Recent active data (0-90 days)	Highest	Instant
  Basic	High-volume "noisy" logs (e.g., Netflow)	Lower	Near-real-time
  Archive	Compliance data (Up to 7 years)	Lowest	Minutes/Hours (Search Jobs)

• Querying Across Tiers: Using the adx() function in KQL to join live security alerts with historical data stored in the lake.
• Disaster Recovery: Native multi-region replication of security logs for mission-critical audit requirements.

⚠️ Exam Trap: Keeping high-volume logs (like VPC flow logs or firewall "permit" logs) in the Analytics tier indefinitely. This leads to massive cost overruns. Route these to the Basic or Archive tiers once the immediate investigation window has passed.

Advanced UEBA (User and Entity Behavior Analytics)

💡 First Principle: Attackers use valid credentials. UEBA focuses on identifying "anomalous behavior" rather than "static signatures." It builds a baseline of "normal" for every user and entity to detect the subtle deviations that signal a compromise.

• Behavioral Baselines: Learning that "User A" typically logs in from New York at 9:00 AM.
• Peer Group Analysis: Identifying if an account is performing actions that no other member of its department (e.g., HR) has ever performed.
• Impossible Travel: Detecting a login from London and another from Tokyo within 2 hours.
• Lateral Movement: Identifying an account hopping between servers using different protocols (RDP -> SMB -> SSH).

UEBA Detection Flow

💡 Key Insight: UEBA requires a 30-day learning period to establish behavioral baselines. During this window, expect higher false positives as the system calibrates what's "normal" for each entity.

Advanced Hunting with KQL

💡 First Principle: Don't wait for an alert. Proactive hunting assumes an attacker is already present and uses KQL to search for indicators of compromise (IoCs) that haven't triggered a formal rule.

• Essential KQL for Hunting:

  // Detect failed sign-ins followed by successful sign-in
  SigninLogs
  | where ResultType != 0
  | summarize FailedAttempts = count() by UserPrincipalName, bin(TimeGenerated, 1h)
  | where FailedAttempts > 5
  | join kind=inner (
      SigninLogs | where ResultType == 0
  ) on UserPrincipalName
  

• Custom Detection Rules: Converting successful hunting queries into automated Analytics rules.
• Investigation Bookmarks: Saving specific log entries and findings during a hunt to be used as evidence in an incident.

SOAR Automation with Playbooks

💡 First Principle: Minutes matter. Playbooks use Azure Logic Apps to automate repetitive response tasks, ensuring that high-confidence threats (like a confirmed malware host) are isolated in seconds without human intervention.

• Incident Enrichment: Automatically querying VirusTotal or Whois when an IP is flagged and adding the results as a comment to the incident.
• Remediation: Automatically disabling a user account or blocking an IP in the Azure Firewall when a specific alert is triggered.
• Orchestration: Syncing Sentinel incidents with external ITSM tools like ServiceNow or Jira.

Visual: Sentinel Incident Lifecycle

💡 Key Insight: Incident classification at closure feeds back into Sentinel's analytics. Marking false positives helps tune detection rules, while true positives with documented response steps become templates for future automation.

Sending Logs to External SIEM

• Use Event Hubs: Configure diagnostic settings to send logs to Event Hub
• External partner consumes: Partner SIEM reads from Event Hub
• Note: Azure Storage does not enable real-time export to external partners

⚠️ Exam Trap: Sending logs to Storage Account for external SIEM integration. Storage doesn't enable real-time streaming. Use Event Hubs for real-time export to external systems.