10-day approach for Detection Engineering
The detection engineering field feels like it could be my next professional challenge. My reading and exercises about threat hunting, combined with my work in ML, have been really interesting, but I wanted to experiment some more. So I decided to gather as much information as possible about detection engineering. But what is it?
GitHub is usually a friend, I discovered a really great resource. This GitHub repo has a definition I wanted to report:
Detection Engineering is a tactical function of a cybersecurity defense program that involves the design, implementation, and operation of detective controls with the goal of proactively identifying malicious or unauthorized activity before it negatively impacts an individual or an organization.
I often look at recent commits, and one of the latest was a reference to SOCLabs. It is described as “A lab for blue teamers and detection engineers, with real threat data and support for popular SIEM query languages, enabling hands-on learning and practice in detection rule writing and threat hunting”. It got my attention right away.
10-day plan
Here’s what I did: my plan was to spread the studying and training across 10 days. Then, I created a GitHub repo called detection-sigma-exercises where I uploaded all the exercises I completed.
The website offered two options: the Learn and DetectionHub module. I went straight first to the DetectionHub because my main goal was to learn Sigma (the website also supports other languages, such as SPL, KQL, EQL etc.). So, how do you learn Sigma?
The website proposes detection challenges, in which you are given a description, challenge objective and a sample log. Then, you have to write your Sigma rule and test it against a private dataset with an acceptable TPR (True Positive Rate) and FPR (False Positive Rate). These metrics are key for a detection engineer.
The Sigma rule I uploaded had (almost all of them) 100% TPR and 0% FPR. This is because the dataset of events is relatively small, that said, I wouldn’t claim those are production-ready rules, but I think those are a good starting point for my learning experience. Surely the first were more challenging than the others, this is why I think the learning curve is not that steep.
What I learned
These challenges were really interesting, I learned a ton doing them. Here’s a list of the 10 challenges I did:
- Attempting to Disable AppArmor Service
- Attempting to Disable the Syslog Service
- Potential Linux Backdoor User Account Creation
- Data Transfer Size Limits
- AWK System Function for Executing Shell Commands
- Find Command Shell Code Execution Exploitation
- Using chattr to Remove Immutable File Attributes
- Reverse Shell Connection Detection
- Potential Linux credential file access
- Using DD to Overwrite Files in Linux
The first 7 were tagged as easy, they were good exercises to learn a new markup language such as Sigma. The other three were a bit more challenging. I frequently used LLMs in order to help me, but the key prompt was “do not reveal the solution” included in each chat. This was essential to develop an intuitive understanding of the nuances of the Sigma rules.
Conclusion
I’m really proud and my journey just started. Having “proof-of-knowledge” like this blog post and the repo, helps me a lot dealing not just with motivation, but also with the long-term view, building what I consider a personal portfolio of things I’ve studied.
A while back, I ambitiously set out on a “30 Days of ***” challenge. I tried to stay on track, but I quickly realized that format wasn't for me. Instead, the 10-day format will probably continue with other topic, perhaps some blue-team CTF or Detection-as-Code project I’m cooking in the background. We’ll see for now.
See you again soon!