After Lab 4.4 — Recap
After Lab 4.4 — Recap
You enabled Microsoft Sentinel on your Log Analytics workspace and explored the Sentinel workspace. You turned on the Azure Activity Log connector and discovered the security operations layer that sits on top of your collected logs.
What You Should Understand
Sentinel Is Not a Data Store
Sentinel is a security operations layer, not a storage layer. It reads from the Log Analytics workspace using KQL. This is why Sentinel is free — it has no infrastructure of its own.
Sentinel Features Overview
For the full list of Sentinel features (Analytics Rules, Hunting Queries, Workbooks, Incidents, Automation Rules, Notebooks), see Before Lab 4.4 — Microsoft Sentinel.
Sentinel Incidents
When an analytics rule matches data, it creates an incident:
| Field | Purpose | Example |
|---|---|---|
| Title | Summary of the detected threat | "Multiple failed login attempts detected" |
| Severity | Risk level (High, Medium, Low, Informational) | High |
| Incident Number | Unique identifier | #42 |
| Entities | IP addresses, hosts, accounts involved | IP: 203.0.113.5, Host: app-backend-api |
| Evidence | KQL query results that triggered the alert | 15 matching rows |
| Status | Open, Closed, or Suspicious | Open |
Reflection Questions
Why doesn't Sentinel have its own data store? What are the advantages of using Log Analytics as the storage layer?
Shared infrastructure, lower cost, unified querying:
- Cost: Sentinel is free because it doesn't maintain separate storage. You only pay for Log Analytics ingestion and retention.
- Unified querying: All data (application, platform, management) is in one Log Analytics workspace. Sentinel can query everything with one language (KQL).
- Simplified operations: One workspace to manage, one retention policy, one billing.
Trade-off: If you need data from multiple tenants or subscriptions, you can connect multiple Log Analytics workspaces to a single Sentinel workspace. This is called "multi-workspace Sentinel."
Why is the Azure Activity Log connector not enabled by default? Why must you turn it on manually?
Data volume and cost awareness:
- The Azure Activity Log captures every management operation in the subscription — resource creation, RBAC changes, deployments, policy evaluations.
- This can generate significant data volume, especially in active subscriptions.
- Enabling it without understanding the implications could lead to unexpected costs.
Intentional design: Sentinel requires manual activation of data connectors to ensure operators understand what data is being ingested. This is a security best practice: know what you're collecting before you start collecting it.
If Sentinel is free, what stops an organization from enabling analytics rules for every possible threat and overwhelming the system?
Analytics rules query Log Analytics, which has costs:
- Each analytics rule runs a KQL query on a schedule. If a query matches millions of rows, the query volume increases.
- KQL queries are billed based on data scanned. More rules = more queries = more cost.
- Incidents created by rules are stored in Log Analytics, adding to retention costs.
Best practice: Start with a small set of high-value analytics rules. Monitor query volume and incident rate. Add rules gradually based on your threat model. Don't enable every rule from the Content Hub — select the ones relevant to your environment.
What is the difference between a Sentinel analytics rule and a hunting query?
| Aspect | Analytics Rule | Hunting Query |
|---|---|---|
| Execution | Scheduled (runs automatically) | Manual (run on demand) |
| Output | Creates incidents when triggered | Returns query results only |
| Use case | Known threat patterns | Unknown threats, proactive search |
| Response | Automated incident creation | Analyst-driven investigation |
| Schedule | Every 5 minutes to 24 hours | One-time or periodic manual run |
| Example | "Flag if > 5 failed logins in 10 minutes" | "Show all requests to /admin endpoints" |
Think of analytics rules as automated sentinels and hunting queries as detective work.
Common Issues
| Issue | Symptom | Cause | Fix |
|---|---|---|---|
| Sentinel shows "No data" after enabling | Empty Sentinel workspace | Log Analytics has no data yet | Run the pipeline to generate telemetry, wait 15-30 minutes |
| Azure Activity Log connector not visible | Cannot find the connector in Sentinel | Connector names changed in Defender portal | Search for "Azure Activity Log" in the data connectors page |
| No incidents after enabling Activity Log | Sentinel is on but nothing triggers | No analytics rules configured | Create a simple rule (e.g., "high-severity Azure Activity events") |
| Daily cap reached | Logs stop appearing after midday | Cap too low for traffic volume | Increase cap in Log Analytics settings (Settings → Quota) |
Bridge to Lab 4.5
You have enabled Microsoft Sentinel and explored the security operations layer. Now you have the data flowing into Log Analytics — the next step is to investigate that data using KQL queries. You will hunt through application and infrastructure events, trace requests across services, and identify patterns that indicate suspicious activity.