microsoft-sentinel

Microsoft Sentinel

When to Use

• Implementing cloud-native SIEM for threat detection in Azure environments
• Connecting data sources via Sentinel data connectors
• Writing KQL analytics rules to detect security threats
• Investigating and managing security incidents
• Automating threat response with Logic App playbooks
• Preparing for SC-500 (Cloud and AI Security Engineer) or AZ-500 exam

Core Jobs

1. Architecture: Sentinel on Log Analytics

• Microsoft Sentinel = cloud-native SIEM/SOAR built on Log Analytics workspace
• All data ingested into Sentinel is stored as Log Analytics tables (queryable with KQL)
• Key tables: SecurityEvent, SigninLogs, AzureActivity, CommonSecurityLog, Syslog, OfficeActivity
• Workspace design: dedicate a Log Analytics workspace to Sentinel (separate from monitoring workspace)
• Multi-workspace Sentinel: query across workspaces with workspace manager

2. Data Connectors

Connector Type	Examples	Cost
Azure-native	Entra ID, Azure Activity, Defender for Cloud, Microsoft 365	Free ingestion
Microsoft 365 Defender	Defender for Endpoint, Office 365, Teams	Free ingestion
Partner connectors	Palo Alto, Cisco, Fortinet (via CEF/Syslog)	Log Analytics ingestion cost
REST API	Custom applications, ITSM, threat intelligence	Log Analytics ingestion cost
Syslog / CEF	Linux syslog, network devices	Log Analytics ingestion cost

• CEF (Common Event Format): standardized syslog format; Sentinel parses into structured fields
• Connector setup: enable connector → configure source → data flows into workspace tables

3. Analytics Rules

Rule Type	How it Works	Customizable
Scheduled	KQL query runs on schedule (every 5 min to every 24h)	Yes (KQL, threshold, grouping)
Near-real-time (NRT)	KQL query runs every ~1 minute; low latency	Yes
Microsoft Security	Forward alerts from Defender products as incidents	Partially (filter by severity)
Fusion	ML correlation of multi-stage attack signals	No (always-enabled ML)
Anomaly	ML baseline behavior; detect deviations	Partially (threshold tuning)

• Scheduled rule anatomy: KQL query → alert grouping → incident creation → tactics/techniques mapping
• MITRE ATT&CK mapping: tag rules with tactics (Initial Access, Lateral Movement) and techniques (T1078)
• Alert grouping: group multiple alerts into one incident by entity (account, IP, host)

4. Incidents

• Incident = auto-created from analytics rule alerts (one or more alerts grouped)
• Incident lifecycle: New → Active → Closed (True Positive / False Positive / Benign)
• Investigation graph: visual entity relationship map; pivot from incident to related entities
• Entity pages: timeline of activity for specific user, IP, or host
• Triage workflow:
  1. Review incident details (severity, entities, alerts, evidence)
  2. Run investigation graph
  3. Check related incidents and bookmarks
  4. Assign to analyst; add comments
  5. Close with classification

5. Workbooks

• Visual dashboards built on Sentinel data (Log Analytics tables)
• Built-in workbooks: Azure AD Sign-in logs, Azure Activity, Defender for Cloud alerts
• MITRE ATT&CK workbook: visualize coverage of analytics rules across tactics and techniques
• Custom workbooks: combine KQL queries with charts, grids, and parameters
• Use for: executive security dashboard, SOC analyst daily overview, compliance reporting

6. Playbooks (Logic Apps)

• Playbook = Logic App triggered by Sentinel alert or incident; automated response
• Common automations:
  • Block user in Entra ID (disable account)
  • Isolate VM from network (Defender for Endpoint response action)
  • Create ITSM ticket (ServiceNow, Jira)
  • Send Teams/email notification to SOC
  • Enrich incident with threat intelligence (VirusTotal lookup)
• Trigger options: Incident trigger (on incident creation) or Alert trigger (on each alert)
• Use Incident trigger when you need access to all grouped alerts; Alert trigger for per-alert automation

7. UEBA (User Entity Behavior Analytics)

• Establishes behavioral baseline per user and host
• Detects anomalies: unusual sign-in location, abnormal data access volume, atypical process execution
• UEBA insights appear on Entity pages and in Investigation graph
• Enriches incidents with behavior score (anomaly level)
• Requires enabling UEBA in Sentinel settings; syncs Entra ID user data

Key Concepts

• Sentinel — cloud-native SIEM/SOAR; built on Log Analytics; all data in KQL-queryable tables
• Data connector — integrates log source into Sentinel workspace tables
• Analytics rule — KQL query that fires alerts and creates incidents when threat pattern matches
• Incident — grouped alerts with investigation context; assigned to analyst; closed with classification
• Playbook — Logic App automated response; triggered by alert or incident
• Fusion — always-enabled ML rule correlating multi-stage attack signals across products
• MITRE ATT&CK — threat framework; map rules to tactics/techniques to measure detection coverage

Checklist

• Dedicated Log Analytics workspace created for Sentinel (separate from operational monitoring)?
• Azure-native connectors enabled (Entra ID, Azure Activity, Defender for Cloud) as baseline?
• Analytics rules created for high-priority scenarios (impossible travel, mass download, privilege escalation)?
• MITRE ATT&CK workbook reviewed to identify detection coverage gaps?
• Incident triage workflow defined (severity SLA, assignment process, closure classification)?
• Playbooks created for top 3 incident types (user block, VM isolation, ticket creation)?
• UEBA enabled and behavioral baselines established?

Output Format

• 🔴 Critical — no analytics rules enabled (Sentinel ingests data but generates no alerts)
• 🔴 Critical — Fusion rule disabled (only way to detect ML-correlated multi-stage attacks)
• 🟡 Warning — too many rules with low threshold generating alert fatigue (tune alert grouping)
• 🟡 Warning — no playbook for high-severity incidents (manual response only; slow reaction time)
• 🟢 Suggestion — map all analytics rules to MITRE ATT&CK; use MITRE workbook to find coverage gaps

Exam Tips

• Sentinel is built on Log Analytics workspace — all ingested data stored as Log Analytics tables; KQL is the query language throughout
• Analytics rules generate alerts → incidents — tune grouping window and entity grouping to reduce alert fatigue while maintaining fidelity
• Playbooks = Logic Apps triggered by Sentinel — automate: block user in Entra ID, isolate VM via Defender API, create ITSM ticket
• Azure-native connectors are free; 3rd-party connectors incur Log Analytics ingestion cost — plan data volume carefully for cost management
• Fusion rule = ML-based multi-stage attack detection — cannot be customized; always enabled; correlates low-severity signals into high-confidence incidents
• MITRE ATT&CK mapping in analytics rules — tracks detection coverage across tactics and techniques; use MITRE workbook to visualize gaps