I approached detection engineering from both directions: business risk and threat scenarios define what matters, while the technology estate and its telemetry determine what the SOC can observe. I helped connect those views through detection use cases, recording the attack behaviour, required data and investigation context before treating a rule as coverage.
I built a detection and tuning workflow with priorities, stages and named owners. The Use Case Pipeline took work through business justification, log prerequisites, KQL implementation, review, release and tuning, then post-release testing. I also supported version control for Sentinel rule logic so changes had a recoverable history.
That work fed into the wider Detection and Response framework I co-developed. The proposed Azure DevOps model connected threat scenarios, attack paths, use cases, telemetry, parsers, rules and tests. It placed ownership, priority, approval and delivery tracking in work items, with detailed detection logic and engineering artefacts in Git.
I established a central Planner workflow for detection, telemetry and control gaps, and helped organise the working group around the framework. The delivered workflow and versioned rules were foundations for the longer-term coverage model: tracing a business risk through usable data, a detection and a test result, with the remaining dependencies visible.
I delivered the detection/tuning workflow and contributed to Sentinel rule versioning in Git. The wider linked Azure DevOps schema and live coverage view remain the next engineering direction.
Closer to the work
Two inputs meet at the use case
Threat scenarios and business impact define the behaviour a detection needs to recognise. Source systems, identity and network context, parsers and data quality determine whether that behaviour is observable. My telemetry work included DNS source attribution and understanding cloud and on-premises traffic; the framework used these dependencies to connect a use case to the data it needs.
Open this detail ↗A delivered lifecycle for detection work
The documented Use Case Pipeline covers justification, source-log prerequisites, KQL implementation, logic review, release and tuning, followed by a test trigger and deeper analysis. I introduced priorities, stages and ownership for new detections and tuning requests, and supported a repository containing versioned Sentinel rule logic.
Open this detail ↗Logic in Git; ownership and approvals in work tracking
The Azure DevOps design separated work management from executable content: owners, priorities, approvals and delivery status belonged in work items; KQL, schemas and mappings belonged in Git. I supported the versioned-rule work and co-developed the proposed ten-type work-item model, connecting detection delivery to telemetry, tests, tuning and coverage assessment.
Open this detail ↗Coverage is an evidence relationship
The proposed coverage model linked a threat scenario to its telemetry requirements, detection rule and validation evidence. A central Planner backlog gave gaps an intake, triage/refinement, delivery and closure lifecycle. The intended coverage view would use those relationships to distinguish available data, implemented detection logic and tested behaviour.
Open this detail ↗Skills established through this work