The event reaches the queryable telemetry pipeline.
Research notebook / 01 · Thesis in progress
THE TIME
BETWEEN DETECTION
AND ACTION.
Automated incident response on Microsoft Azure.
An experiment in making security workflows measurable.
01 / The question
A fast action is only
part of the story.
Can an automated cloud workflow reliably turn a failed-login signal into network containment? And when the response itself is quick, what accounts for the rest of the delay?
My thesis explores automated incident response in the context of Zero Trust. I built a controlled lab to follow an event across ingestion, detection and response, rather than reporting a single opaque timing.
02 / The implemented system
One signal.
A complete chain.
- 01 ↗
Collect
Ubuntu + Azure Monitor AgentAuthentication syslog flows into Log Analytics through a data collection rule.
- 02 ↗
Detect
Microsoft Sentinel + KQLA scheduled rule evaluates a five-minute window at five-minute intervals, using a five-failure threshold grouped by source.
- 03 ↗
Decide
Incident + entity mappingIP and host entities carry the context into the automated response workflow.
- 04 ↗
Contain
Logic Apps + NSGThe workflow applies a network security group deny rule to block the source in the lab.
Terraform provisions the environment for repeatable deployment and teardown. This diagram describes the implemented workflow; it does not run an attack or connect to live infrastructure.
03 / Initial evidence
Five runs.
Follow the time.
Select a trial to inspect its stages.
Measured data, not a live simulation.
IngestionDetectionResponseSeconds / shared scale 0–650
Trial 01 / Stage breakdown
The scheduled Sentinel rule evaluates the failed-login signal and creates the incident.
The automated response applies the network containment action.
Total: 501.2 seconds. Stage timings are rounded individually; their sum may differ by 0.1 seconds.
Read all measurements as a table
| Trial | Ingestion | Detection | Response | Total |
|---|---|---|---|---|
| 1 | 61.9 | 426.2 | 13.1 | 501.2 |
| 2 | 76.8 | 300.7 | 12.5 | 390.0 |
| 3 | 85.9 | 424.3 | 10.3 | 520.5 |
| 4 | 74.9 | 532.6 | 13.0 | 620.5 |
| 5 | 77.9 | 288.1 | 13.4 | 379.3 |
Median response stage
10.3–13.4 seconds across the five trials. The response stage was short and relatively consistent.
Median total containment
379.3–620.5 seconds end to end. Detection latency contributed most of the delay and variation.
Sources blocked in the lab
All five attack trials reached containment. Four of five finished within ten minutes.
04 / What this tells us
Evidence with
boundaries.
These are initial observations from one monitored host, one SSH brute-force scenario, one deployment and a fixed configuration. Five successful trials do not establish production reliability.
A benign burst of three failed logins stayed below the configured threshold and did not alert. That is a sanity check, not a broad false-positive evaluation.
The research originally targeted a 60% improvement in response time. Without a comparable manual baseline, these measurements do not establish that improvement. The medians above are calculated separately and should not be added together.
Source: the project’s experiment summary dated 3 September 2026, cross-checked against its documented implementation. This public page contains aggregate timings only; infrastructure identifiers and raw security logs are omitted. Thesis presentation and final evaluation are still ahead.
05 / The next experiment
Question the
bottleneck.
Vary the detection cadence and threshold. Compare near-real-time detection. Repeat across more hosts and scenarios. Establish a manual baseline before making an improvement claim.
Let’s talk about the research ↗