Listen to this Post
Introduction:
In the high-stakes world of Security Operations Centers (SOCs), a common misconception persists: that simply installing a SIEM or EDR solution will automatically yield perfect security alerts. The reality is far more complex. Detection Engineering is the critical discipline that transforms raw telemetry into actionable intelligence. Without deliberate engineering, a SOC is merely a noisy log repository, reacting to fires rather than preventing them.
Learning Objectives:
- Understand the core principles of Detection Engineering and its role in a mature SOC.
- Learn how to map attacker TTPs using the MITRE ATT&CK framework to specific log sources.
- Gain practical knowledge on writing, testing, and tuning detection rules to balance false positives and true positives.
You Should Know:
1. The Foundation: Mapping TTPs to Log Sources
Detection engineering does not begin with writing a query; it begins with understanding the adversary. Before you can detect an attack, you must know what it looks like in your specific environment. This involves studying the MITRE ATT&CK framework to identify relevant Techniques, Tactics, and Procedures (TTPs).
Step‑by‑step guide explaining what this does and how to use it:
1. Identify a Relevant Technique: Select a common technique, such as T1059.001 (Command and Scripting Interpreter: PowerShell).
2. Determine Required Telemetry: Ask, “What log sources capture PowerShell execution?” On Windows, this is typically Event ID 4104 (Script Block Logging) and Event ID 4688 (Process Creation) with command-line logging enabled.
3. Verify Log Source Availability: Check if these logs are being ingested into your SIEM.
– Linux/macOS equivalent: For detecting command-line activity (T1059.004), you might rely on auditd logs or process accounting. A command to verify auditd status is:
sudo systemctl status auditd
– Windows Command (PowerShell) to check logging: Run this as an administrator to ensure PowerShell logging is enabled:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" | Select-Object -ExpandProperty EnableScriptBlockLogging
If this returns 1, logging is enabled. If `0` or null, you must enable it via Group Policy.
- Writing the Detection Logic: From Concept to Query
Once you have confirmed the log source exists, you translate the adversary behavior into a machine-readable format. This could be a Splunk query, an ELK KQL statement, or a Sigma rule (which is vendor-agnostic).
Step‑by‑step guide explaining what this does and how to use it:
Let’s create a detection for a suspicious PowerShell download command often used in initial access (T1105: Ingress Tool Transfer).
1. Conceptualize the Behavior: Attackers often use `Invoke-WebRequest` or `Invoke-Expression` (IEX) to download and execute payloads from the internet.
2. Write the Sigma Rule (Example): Sigma rules are a standardized format that can be converted to various SIEM backends.
title: Suspicious PowerShell Download status: experimental logsource: product: windows service: powershell definition: 'Requirements: PowerShell Script Block Logging (Event 4104) must be enabled.' detection: selection: EventID: 4104 ScriptBlockText|contains: - 'Invoke-WebRequest' - 'Invoke-Expression' - 'IEX' - 'http://' - 'https://' condition: selection falsepositives: - Legitimate administrative scripts downloading tools level: medium tags: - attack.t1105
3. Convert to a SIEM Query (Splunk example): Using a tool like sigmac, this rule could be converted to:
“`bash-spl
index=windows source=”WinEventLog:Microsoft-Windows-PowerShell/Operational” EventCode=4104
(ScriptBlockText=Invoke-WebRequest OR ScriptBlockText=Invoke-Expression OR ScriptBlockText=IEX OR ScriptBlockText=http:// OR ScriptBlockText=https://)
| table _time, host, UserID, ScriptBlockText
<ol> <li>Testing the Detection: Atomic Red Team Exercises A rule is useless if it doesn't fire on actual malicious behavior. Testing validates your logic and ensures you are detecting the right things.</li> </ol> Step‑by‑step guide explaining what this does and how to use it: 1. Install Atomic Red Team (Windows): This is an open-source library of tests mapped to MITRE ATT&CK. ```bash IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); Install-AtomicRedTeam -getAtomics
2. Execute a Test: Run the test corresponding to your detection rule. For our PowerShell download example, we can use Atomic Test T1059.001-7.
Invoke-AtomicTest T1059.001 -TestNumbers 7
3. Verify Alert Generation: Check your SIEM or logging platform. Did the test trigger your newly created detection rule? If not, investigate why. Was the log source misconfigured? Is the query logic flawed?
4. Tuning: Reducing the Noise Floor
A detection that fires hundreds of times a day is just noise. Security analysts will begin to ignore it, leading to alert fatigue. Tuning is the process of filtering out false positives while maintaining detection efficacy.
Step‑by‑step guide explaining what this does and how to use it:
1. Analyze Triggering Events: Review the output of your alert for a week. You will likely see common administrative scripts or approved tools triggering it.
2. Identify Allow-Listable Entities: For the PowerShell download rule, you might see a specific internal admin server (ADMIN-SRV-01) running legitimate update scripts.
3. Implement an Exception: Modify your detection logic to exclude this source.
– Modified Sigma Rule Snippet:
detection: selection: EventID: 4104 ScriptBlockText|contains: - 'Invoke-WebRequest' filter: Hostname: 'ADMIN-SRV-01' Exclude the admin server condition: selection and not filter
4. Re-test: Run the Atomic test again, but this time from the ADMIN-SRV-01. The alert should not fire. Run it from a different workstation; it should fire.
5. Measuring Coverage and Identifying Gaps
Detection engineering is a continuous cycle. You must visualize where you have coverage and where you are blind. This is often done with a heatmap based on the MITRE ATT&CK framework.
Step‑by‑step guide explaining what this does and how to use it:
1. Create a Matrix: Use a tool like MITRE’s Navigator (attack.mitre.org) or a simple spreadsheet.
2. Map Existing Detections: Color-code each technique based on your detection status.
– Green: Full detection coverage (rule exists and is tuned).
– Yellow: Partial coverage (logs exist but no rule, or rule needs work).
– Red: No coverage (no logs, no rule).
3. Prioritize Gaps: Focus your engineering efforts on the “Red” techniques that are most relevant to your industry or threat landscape (e.g., Ransomware TTPs for a financial institution). This turns detection engineering from a random task into a strategic project.
What Undercode Say:
- Detection is Proactive Engineering, Not Reactive Configuration: The key takeaway from this deep dive is that effective security monitoring is built, not bought. A mature SOC dedicates resources to continuously engineering its detection logic, moving beyond the “set it and forget it” mentality.
- Balancing Act: The discipline is a constant balance between fidelity and coverage. Over-engineering for zero false positives can create massive blind spots, while casting too wide a net drowns analysts in noise. The true skill lies in navigating this spectrum to build a resilient and responsive security posture.
Prediction:
As enterprise environments grow more hybrid and complex, manual detection engineering will become unsustainable. We will see a significant shift toward Automated Detection Engineering, where AI and machine learning models will not only tune existing rules but also generate new detection logic based on real-time adversary behavior observed across global sensor networks. This will transform the SOC analyst’s role from a rule writer to a strategic threat hunter overseeing an AI-driven detection pipeline.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Inaam Kabbara – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
