After Lab 4.6 — Recap
After Lab 4.6 — Recap
You converted a KQL query into an analytics rule, simulated the attack scenario, and investigated the resulting incident. You also set up Azure DevOps audit streaming and created a PAT detection rule.
What You Should Understand
The Detection Pipeline
Manual → Validated → Automated → Responded → Tuned. This is how every detection rule evolves — from a manual KQL query into a scheduled, validated, automated, and finally tuned control.
Analytics Rule Properties
| Property | Purpose | Example |
|---|---|---|
| Name | Human-readable rule identifier | "Direct access to internal backend" |
| Severity | Risk level (High, Medium, Low, Informational) | High |
| Tactics | MITRE ATT&CK tactic | Initial Access, Lateral Movement |
| Techniques | MITRE ATT&CK technique | T1190 — Exploit Public-Facing Application |
| Schedule | How often the query runs | Every 5 minutes |
| Time window | How far back the query looks | Last 5 minutes |
| Threshold | Number of matches to trigger | 1 or more |
The Incident Lifecycle
For the full diagram and theory, see Lab 4.6 — From Query to Detection.
What you saw in this lab:
- New: The analytics rule you created fired after simulating external access to the internal backend
- Review: You opened the incident in Sentinel, reviewed entities (IPs, URLs, HTTP methods), and traced the timeline
- True positive: The simulated attack matched the rule — confirmed by seeing the exact log entries
- False positive: If a rule fires for legitimate admin traffic, you return here to tune thresholds or add exclusions
- Remediate: You documented the findings — blocking the source IP and reviewing access controls
- Closed: You recorded the incident outcome and any rule tuning actions for future reference
MITRE ATT&CK Mapping
MITRE ATT&CK provides a standardised framework for classifying security incidents:
| MITRE Tactic | What It Means | Day 4 Example |
|---|---|---|
| Initial Access | Gaining entry to the environment | External IP accessing internal backend |
| Lateral Movement | Moving between systems | Internal backend accessing Key Vault |
| Collection | Gathering data | Accessing sensitive endpoints |
| Exfiltration | Removing data from the environment | Large response sizes, data download |
| Impact | Disrupting or destroying systems | HTTP 500 errors, resource deletion |
Each analytics rule should be mapped to the relevant MITRE tactic(s). This helps:
- Prioritise incidents: Tactics like Initial Access and Exfiltration are higher priority
- Identify gaps: If no rules cover a tactic, you may be blind to that attack phase
- Communicate with stakeholders: MITRE ATT&CK is a standard language for security reporting
DevOps Security Monitoring
In the mini-lab, you extended Sentinel to monitor Azure DevOps audit events. This is a critical addition because the pipeline is part of your infrastructure:
| DevOps Audit Event | MITRE Tactic | Why It Matters |
|---|---|---|
| PAT created | Credential Access | Persistent access even after password rotation |
| Service connection modified | Persistence | Attacker modifies service connections to maintain deployment access |
| Variable group created | Collection | Secrets and tokens added to pipeline variables for later exfiltration |
| Audit stream disabled | Defense Evasion | Attacker disables their own detection capability |
| Pipeline modified | Execution | Malicious code injected into the build process |
Rule Tuning: Reducing False Positives
Not every match is a real threat. Rule tuning is an ongoing process:
| Tuning Action | Effect | Risk |
|---|---|---|
| Increase threshold | Fewer incidents | May miss low-volume attacks |
| Narrow time window | More precise detection | May miss slow, distributed attacks |
| Add IP exclusions | Reduces false positives from known sources | May miss compromised internal hosts |
| Change severity | Adjusts incident priority | Does not reduce incident count |
| Add exclusions | Filter out legitimate patterns | May miss disguised attacks |
Example: An analytics rule that triggers on "any request to /admin" will fire for legitimate admin access. Tuning it to "external IP + request to /admin + status 403" reduces false positives significantly.
For a deeper dive into tuning strategies, see Alarm Fatigue & Sentinel Tuning.
Reflection Questions
Why do analytics rules have a schedule instead of running continuously?
Performance and cost trade-off:
- Running a KQL query continuously would consume unlimited resources. Scheduled execution (every 5 minutes to 24 hours) limits the query volume and cost.
- Security detection does not require millisecond precision. A 5-minute delay between an attack and detection is acceptable for most threats.
- Scheduled execution allows batched processing: instead of checking every single log entry in real-time, the query processes a window of data at regular intervals.
Trade-off: Scheduled rules cannot detect zero-day attacks in real-time. For real-time detection, you would need streaming analytics (e.g., Azure Stream Analytics), which is beyond the scope of this course.
If an analytics rule creates too many incidents, how do you decide which ones are real threats?
The incident investigation workflow:
- Review severity: Is this High, Medium, or Low? High-severity incidents take priority.
- Review the timeline: How many log entries triggered the rule? A single entry is less suspicious than many.
- Identify entities: IP addresses, accounts, hosts involved. Are they known or unknown?
- Check MITRE mapping: Which tactic and technique does this match? Does it align with your threat model?
- Correlate with other data: Check AppTraces and AppDependencies, other analytics rules, threat intelligence feeds.
- Determine next actions: Block IP, revoke credentials, isolate system, or close as false positive.
Key principle: Each incident requires human review until the rule is tuned. Automated responses (like blocking IPs) should only be enabled after the rule has been validated and tuned.
Why is it important to map analytics rules to MITRE ATT&CK tactics?
Three reasons:
- Prioritisation: Tactics like Initial Access and Exfiltration are higher priority than others. MITRE mapping helps triage incidents.
- Gap analysis: If no rules cover a particular tactic, you may be blind to that phase of an attack. MITRE mapping makes gaps visible.
- Communication: MITRE ATT&CK is a standard language. When reporting to management, auditors, or external parties, MITRE provides a common framework.
Example: "We have 3 rules covering Initial Access, 2 covering Lateral Movement, but 0 covering Exfiltration. We need to add detection for data exfiltration patterns."
The idea: Every network control you deploy in Day 2 should have a corresponding detection in Day 4. Controls stop attacks; detections catch the ones that slip through. Together they create defence in depth.
For example, an NSG rule that blocks unauthorized outbound traffic (Day 2) should have a hunting query that surfaces blocked connections (Day 4).
Common Issues
| Issue | Symptom | Cause | Fix |
|---|---|---|---|
| Analytics rule does not trigger | No incidents created after simulation | Query does not match any data | Test the KQL query manually against the data; adjust filters |
| Too many incidents (alert fatigue) | Sentinel creates dozens of incidents per hour | Rule is too broad (e.g., all requests to /admin) | Add exclusions, increase threshold, narrow time window |
| Rule triggers but incident is closed automatically | Incident appears and disappears immediately | Automation rule with auto-close configured | Check Sentinel automation rules; adjust auto-close settings |
| Rule shows "Inactive" status | Analytics rule not running on schedule | Workspace not connected or query error | Check Sentinel workspace connection; review query syntax |
| MITRE tactic not listed | Cannot select MITRE ATT&CK tactic when creating rule | Rule type doesn't support MITRE mapping (e.g., custom log queries) | Use a supported rule type; check Sentinel documentation for available tactics |
Bridge to Challenge
You have created an analytics rule, investigated the resulting incident, and explored the detection pipeline. You also set up Azure DevOps audit streaming and created a PAT detection rule.
In the final challenge, you will build your own monitoring dashboard — designing tiles that answer real operational questions, reviewing coverage across all nine data sources, and creating an analytics rule based on something you observed during Day 4.
Next step after the challenge: Learn about Sentinel Playbooks and SOAR — automated workflows that respond to incidents by blocking IPs, disabling accounts, and more.