In detection engineering, moving from a detection hypothesis to a working analytic is the heart of the process. It’s where ideas are transformed into rules that capture malicious behaviors in action. In this post, we’ll look at how to develop these analytics systematically, covering the essentials of transforming a hypothesis into concrete analytics, defining data requirements, and iterating for accuracy.
1. From Hypothesis to Abstract Analytics
A detection hypothesis is your starting point—a prediction about behaviors an adversary might exhibit. For instance, let’s say you’re focusing on the use of scheduled tasks for persistence. You might hypothesize: “Scheduled tasks with command line arguments indicating remote execution could signify adversarial activity.”
Once the hypothesis is clear, the next step is creating an abstract analytic:
- Identify data sources: Determine what data you need to validate this hypothesis, such as process creation logs, command line arguments, or remote scheduling details.
- Define event types: Establish which specific events (e.g., process creation, network traffic) are relevant to this hypothesis.
- Set conditions: Specify criteria for the analytic, like “remote task creation detected via RPC” or “task created with high privileges.”
2. Converting to Concrete Analytics
With your abstract analytic defined, it’s time to turn it into concrete analytics. This means taking platform specific considerations into account whether it’s Splunk, Elastic, or another SIEM.
- Query Development: Write queries that capture the events and conditions defined in your hypothesis. For example, in Elastic, you might filter for process creation events with specific command line arguments.
- Syntax Adjustments: Adapt the analytic to the quirks of each platform. For instance, Elastic and Splunk have unique ways of handling special characters or filtering null fields. Familiarize yourself with these platform specific requirements to avoid misinterpretations.
Example:
- Hypothesis: “Remote scheduled task creation.”
- Elastic Query:
event_id:1 AND command_line:*\\ScheduleRPCRegisterTask*
The goal is to create a query that captures the expected behavior precisely. But keep in mind: your first version will rarely be perfect.
3. Testing and Iteration
Once the initial analytic is created, the real work of fine tuning begins. Testing your analytic in a live environment (or a test setup) is critical to ensure it works as intended and doesn’t drown the SOC team in false positives.
- Run the Analytic: Deploy it in a small scale environment or within a limited scope to see what kind of events it captures.
- Adjust for Noise: Review the output, filtering out expected benign events by adding exclusions or adjusting thresholds.
- Iterate: Repeat until your analytic reliably captures the malicious behaviors you’re targeting without generating too many irrelevant alerts.
4. Documenting for Future Improvement
Documentation helps ensure that future analysts understand your detection logic and any adjustments made along the way. Key points to document include:
- Original Hypothesis: Describe the reasoning behind the analytic.
- Conditions and Filters: Outline any specific fields or filters used.
- Known False Positives: Include likely benign activities that may resemble the malicious behavior.
- Thresholds: Note any thresholds used, so they can be reviewed or adjusted as the environment changes.
Conclusion
Developing detection analytics is about translating hypotheses into actionable alerts that deliver precise, meaningful insights. By defining clear data requirements, writing efficient queries, and iterating with real world data, you’ll be able to build effective detection rules that cut through noise and reveal true threats. In the next post, we’ll dig into how to interpret analytic results by focusing on context and identifying genuine malicious activity amid outliers.
0 Comments