Listen to this Post
Introduction:
Detection engineering is not a one-time project—it is a continuous operational discipline. Many SOC teams onboard a SIEM, migrate rules, tune noise, and then stagnate, watching Mean Time to Detect (MTTD) climb as the environment evolves. By implementing three process changes—automating triage enrichment, tightening the detection-to-prevention feedback loop, and redefining metric boundaries (MTTD vs. MTTA vs. MTTR)—a security team processing 1.2 TB/day reduced MTTD by 47% without buying a new platform.
Learning Objectives:
- Distinguish between MTTD, MTTA, and MTTR to measure SOC performance accurately.
- Automate analyst triage enrichment using Python scripts and SIEM API calls.
- Build a feedback loop that converts confirmed detections into proactive prevention controls (e.g., application whitelisting, network policies).
You Should Know:
- Measuring What Matters: MTTD, MTTA, and MTTR – How to Stop Cherry‑Picking Metrics
The first operational change was redefining metrics. Many teams claim MTTD improvements but measure only the time from event to alert generation – ignoring the delay between alert firing and analyst acknowledgment (MTTA). In this environment, the 47% improvement targeted the combined window from event occurrence through alert generation to initial triage confirmation. MTTR was measured separately from confirmed threat to containment.
Step‑by‑step guide to implement metric segmentation:
- Tag each event with timestamps – `event_time` (log entry), `alert_time` (SIEM rule fires), `ack_time` (analyst clicks “acknowledge”), `triage_time` (verdict assigned), `contain_time` (threat contained).
- Calculate MTTD =
alert_time - event_time. MTTA =triage_time - alert_time. MTTR =contain_time - triage_time. - Create a SIEM dashboard visualizing these three metrics over time (e.g., Splunk query:
index=security | eval mttd=alert_time-event_time, mtta=triage_time-alert_time | stats avg(mttd) as AvgMTTD, avg(mtta) as AvgMTTA). - Set SLAs – MTTD < 2 minutes, MTTA < 5 minutes, MTTR < 30 minutes.
- Automate MTTA reduction – use enrichment scripts (see Section 2) to pre‑resolve IP reputation, user context, and asset criticality before the analyst opens the alert.
-
Automating Triage Enrichment – The Real Driver of the 47% Reduction
The 47% reduction came not from faster alert generation but from eliminating manual triage steps. A Python script that runs every 60 seconds polls the SIEM API for new alerts, enriches them with VirusTotal, Active Directory group membership, and asset inventory, then updates the alert’s custom fields. Analysts see a fully contextualized alert from the first click.
Step‑by‑step enrichment automation (Linux / Windows compatible):
enrich_alerts.py – polls SIEM API, adds threat intel
import requests, json, time
SIEM_API_URL = "https://your-siem/api/alerts/new"
VT_API_KEY = "your_virustotal_key"
HEADERS = {"Authorization": "Bearer SIEM_TOKEN"}
def enrich_ip(ip):
vt_url = f"https://www.virustotal.com/api/v3/ip_addresses/{ip}"
resp = requests.get(vt_url, headers={"x-apikey": VT_API_KEY})
return resp.json().get("data", {}).get("attributes", {}).get("last_analysis_stats", {})
def get_ad_user(hostname):
Windows PowerShell equivalent: Get-ADComputer -Identity hostname -Properties MemberOf
return "Domain Admins" placeholder for LDAP query
while True:
alerts = requests.get(SIEM_API_URL, headers=HEADERS).json()
for alert in alerts:
ip = alert.get("source_ip")
if ip:
vt_stats = enrich_ip(ip)
alert["enrichment"] = {"vt_malicious": vt_stats.get("malicious", 0), "ad_group": get_ad_user(alert["hostname"])}
Update alert in SIEM via PUT
requests.put(f"{SIEM_API_URL}/{alert['id']}", json=alert, headers=HEADERS)
time.sleep(60)
To run on Linux: `python3 enrich_alerts.py &` (background service).
To run on Windows: Create a scheduled task that triggers every minute.
- The Feedback Loop – Turning Detections into Prevention Controls
Every confirmed alert must trigger a question: Could a control upstream have prevented this entirely? The team documented a concrete example: after detecting internal port scans from service accounts, they pushed a Palo Alto policy blocking `nmap.exe` execution from non‑admin accounts. The detection became redundant. MTTD for that pattern dropped to zero.
Step‑by‑step feedback loop implementation:
- After each incident, the analyst fills a two‑field form: `detection_rule_id` and `prevention_control_candidate` (e.g., “block nmap via AppLocker”).
- Weekly review meeting – SOC lead reviews the list and assigns prevention tasks to the infrastructure team.
- Implement Windows prevention – AppLocker or WDAC rule:
`New-AppLockerPolicy -RuleType Exe -User NonAdmin -Path “C:\Tools\nmap.exe” -Action Deny`
Apply via GPO or Intune.
- Implement Linux prevention – use `fapolicyd` or `auditctl` to deny execution:
`sudo auditctl -a always,exit -F path=/usr/bin/nmap -F uid!=0 -k block_nmap`
5. Track the “detection graduation rate” – percentage of detection rules that led to a prevention control each quarter. A mature SOC aims for >15% graduation annually. -
Linux & Windows Commands for Detection Engineering and Log Analysis
To replicate the 47% improvement, you need hands‑on commands for log parsing, rule tuning, and kill‑chain analysis.
Linux commands (ingest and parse 1.2 TB/day logs):
Real‑time tail with filter – detect port scans from service accounts
tail -F /var/log/auth.log | grep -E "Failed password|nmap" | while read line; do echo "$(date) ALERT: $line"; done
Parse JSON logs with jq – extract source IPs with high freq failures
cat /var/log/secure.json | jq 'select(.event_type=="ssh_failed") | .source_ip' | sort | uniq -c | sort -nr | head -20
Watch for new processes from non‑interactive users (service accounts)
ps aux | awk '$1!~/root|user/ && $8=="R" || $8=="S" {print $1, $11}' | sort -u
SIEM forwarder performance – check logstash queue saturation
curl -s localhost:9600/_node/stats | jq '.pipeline.events.out' Output events per second
Windows commands (PowerShell) for triage automation:
Get recent Windows Event Logs for suspicious process creation (Event ID 4688)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688; StartTime=(Get-Date).AddHours(-1)} |
Select-Object TimeCreated, @{n='Process';e={$<em>.Properties[bash].Value}}, @{n='User';e={$</em>.Properties[bash].Value}} |
Where-Object {$<em>.User -like 'service' -and $</em>.Process -like 'nmap'}
Enrich with AD group membership
Get-ADComputer -Identity $env:COMPUTERNAME -Properties MemberOf | Select-Object -ExpandProperty MemberOf
Block an executable via Defender ASR rule (prevention)
Add-MpPreference -AttackSurfaceReductionRules_Ids 'D4F940AB-401B-4EFC-AADC-AD5F3C50688A' -AttackSurfaceReductionRules_Actions Enabled
Rule ID above blocks executable from running if written to common risky paths (e.g., Temp)
- Continuous Validation with Atomic Red Team – Stop MTTD from Creeping Back
Without regular testing, detection rules degrade as environments change. The team integrated Atomic Red Team into their CI/CD pipeline, running weekly simulations against their own alerts.
Step‑by‑step to set up Atomic Red Team for MTTD validation:
1. Install on Linux (Ubuntu):
`git clone https://github.com/redcanaryco/atomic-red-team.git`
`cd atomic-red-team && pip install -r requirements.txt</h2>
2. Run a specific technique (e.g., T1046 – Network Scanning):
<h2 style="color: yellow;">python3 atomic_red_team/atomic_red_team.py –technique T1046</h2>
<h2 style="color: yellow;">This will executenmap -sP 192.168.1.0/24`.
2. Run a specific technique (e.g., T1046 – Network Scanning):
<h2 style="color: yellow;">
<h2 style="color: yellow;">This will execute
3. Measure the time from test execution to alert generation in SIEM – that’s your active MTTD.
4. Automate weekly measurement – write a script that launches an atomic test, queries SIEM API for the corresponding alert, and logs the delta.
5. Alert if MTTD exceeds baseline by >20% – triggers a rule review.
- Cloud Hardening & API Security Monitoring – Extending the Playbook to SaaS
The same feedback loop applies to cloud workloads. When a detection fires on an overly permissive IAM role, push a prevention control via infrastructure as code.
Commands for AWS CloudTrail detection and prevention:
AWS CLI – search for `AssumeRole` without MFA (detection rule)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
--query 'Events[?CloudTrailEvent.contains(@, <code>"mfaAuthenticated":"false"</code>)]'
Enrich with AWS Config to get the role’s last used info
aws iam get-role --role-name MaliciousRole --query 'Role.RoleLastUsed'
Prevention: attach a service control policy (SCP) denying non-MFA assume role
aws organizations create-policy --name "EnforceMFA" --content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"sts:AssumeRole","Condition":{"Bool":{"aws:MultiFactorAuthPresent":"false"}}}]}'
Windows / Linux hybrid for API security monitoring:
- Use `curl` to poll REST APIs for anomalies (e.g., 429 rate limit errors indicate potential abuse).
- Example watch script: `while true; do curl -s -o /dev/null -w “%{http_code}\n” https://api.yourservice.com/health; sleep 5; done | grep -v 200`
What Undercode Say:
- Metrics must be segmented – conflating MTTD with MTTA hides the real bottleneck (analyst acknowledgment delay). Always publish separate numbers.
- Automation before headcount – simple enrichment scripts (Python + SIEM API) can cut triage time by nearly half without adding staff.
- Prevention is the ultimate detection – every confirmed alert is a blueprint for a proactive control. Mature SOCs track “detection graduation rate” as a key performance indicator.
The 47% reduction was not achieved by buying a next‑gen SIEM or hiring more analysts. It came from closing the loop between detection, triage automation, and prevention engineering. The provided Python enrichment script, Windows AppLocker policies, and Linux audit rules are production‑ready templates. The most overlooked step is the weekly feedback meeting where detections become prevention tasks. Start there.
Prediction:
Within 18 months, SOC metrics will shift from MTTD/MTTR to “prevention coverage percentage” and “detection‑to‑prevention conversion rate”. AI‑driven enrichment (e.g., LLMs summarizing alert contexts) will further collapse MTTA to near zero. However, the core challenge will remain: transforming detection outputs into infrastructure‑as‑code prevention policies. Teams that treat detection engineering as a continuous feedback loop, not a one‑time project, will reduce MTTD asymptotically toward zero for entire classes of attacks. Those that don’t will drown in alert volume as data ingestion grows beyond 10 TB/day.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Girimaji Saiteja – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
