This post is a mirror of the one I wrote for the Detect.fyi publication on Medium. Please go read it over there and give a follow/kudos if you can!
Detection Engineering is a relatively new practice within blue teams and MSSPs, which has only recently garnered popularity amongst the infosec community in the last few years. This rise in popularity can partly be attributed to projects like Sigma and the MITRE team to make detections and their taxonomy more standardised and accessible. Detection engineering in short terms is the research, development, testing, deployment, and ongoing management of detections within a given environment.
One of the key reasons an organisation may choose to spin up their own detection engineering capability (or rely on an external security provider) is the ability to develop bespoke detections that are directly relevant to their business processes, systems, and even industry vertical.
The reason I'm writing this series is, because of the relative newness of this practice in the infosec mainstream, there wasn't a ton of resources out there that covered how to go about building a detection development capability, and I had to gather notes from a swath of sources. Each section will include some of these sources for additional reading.
In this part I'll cover at a high-level the different components you need to get up and running with an effective detection engineering capability in practical terms.
I also want to shoutout right at the top the wonderful book ‘Practical Threat Detection Engineering’ by Megan Roddie, Jason Deyalsingh and Gary J. Katz. This book touches on every topic here in good detail and is a fantastic resource in general. You can buy it here.
1. You need a place to develop your detections
At the core of it, detection engineering strongly mirrors a standard software development lifecycle. You will want a backlog, a place to store detection ideas and requirements your team gathers from different sources. These sources might be client requests, threat intelligence reports, or even just a tweet. You will also want a staging To-Do step, where backlogged ideas are promoted to a real ticket for your team to work upon.
This is also a solid injection point for mature teams to introduce Scrum or other project management ceremonies into the process.
You'll want to then track the detection process from development, to testing, to validation, to eventually documentation and deployment. The granularity you go to in these steps is generally up to you and your team, and what works best for how you work. This will be covered more in depth in the next part where I’ll provide some example workflows, and ways you can create a workflow in Notion or any other Kanban software.
Additional Reading: - Alex Teixeira (@ateixei) - JIRA Workflow for Detection Engineering teams
2. Building a Testing Environment
So you have a detection idea and you want to build it. What do you do? You might choose to use a tool like Sigconverter to take a relevant sigma rule and convert it to your query language of choice. But, if you're building rules intended for production, you'll really want some real-world data to work with. To do this, you'll need a lab.
How you construct your lab is going to depend on your goals and the environments you’re building detection for. In general, you should strive to create an environment with similar services and OS’s and connect the logs up to a non-production version of your SIEM (or put the test logs in a separate index, at the very least). There’s a lot of crossover with Detection Engineering and threat emulation processes, which is an area I intend to expand upon later.
Additional Reading: (Threat Emulation has a lot of crossovers with this topic) - Kostas (@Kostastsale) - Threat Hunting Series: Using Threat Emulation for Threat Hunting - Touches on lab considerations in a threat hunting context. Can be adapted for DE purposes. - MalwareMayCry - Beginner Malware Analysis: Setting Up Your Lab - John Hammond - Active Directory Lab Build Playlist - Look into vulnerable AD environments such as Game of Active Directory (GOAD) and automated threat emulation scripts like Splunk Attack Range if you wish to automate some of the process.
3. A Code Repository / Knowledge base
Once you have detections that have been created and deployed, you’ll need a system to track where they’ve been deployed, variations between them, any changes done over time, and procedures for how you might want an analyst to investigate the detection.
A code repository can make tracking changes easy, and a knowledge base is great for centralising all the documentation. Some teams though, depending on their size and complexity, might choose to just go with one or the other. How you do this is really down to team preference. Just like the other parts though, this is a serious rabbit hole which will be expanded upon in a future part.
Additional reading: (There is some cross-over between this topic and the below deployment mechanism section) - 0x4D31 - Github Repo: Detection and Response Pipeline - Trevor Miller (@Cyb3rDefender) - https://x.com/cyb3rdefender/status/1623710231250497536?s=61&t=PRiN6mihRITSC_DhTvxPOwa - A useful thread courtesy of Alex Teixeira (@ateixei) - https://x.com/ateixei/status/1695017908278034806?s=61&t=PRiN6mihRITSC_DhTvxPOw
4. A Deployment Mechanism
While considering your codebase options, you might also want to think about how you’re going to deploy and consequently manage each detection in your environment. This is wholly dependent on your use-case for detection engineering in the first place - if you have one SIEM and one environment, you might choose to eschew this step altogether in favour of updating it manually in the tool.
However, if you’re much larger or have multiple environments and different versions of detections all at once, you might want to embrace CI/CD software development practices and opt for taking a ‘Detections as Code’ approach. This is once again dependent on your platform and tool as to how this solution works, but I’ll leave some useful links below for how you can do this in a few popular tools.
Additional Reading: - Gijs Hollestelle (FalconForce) - Deploying Detections at Scale — Part 0x01 use-case format and automated validation - David French (@threatpunter) - From soup to nuts: Building a Detection-as-Code pipeline - Brendan Chamberlain - Practical Detection-as-Code
5. Full Visibility
At this point, you may have an idea of how you can create, deploy, document and manage detections. This is great! But, critically, you need a way to track the performance of your detections and most importantly false positives.
Like the above step, this is going to vary wildly between organisations and use-cases, and bleeds heavily into SecOps and SOC management territory. Depending on your role and SOC structure, this may not entirely be within your scope. But I find that having a way to interactively drill into detections and most importantly their trigger and false positive rates is deeply important for a detection engineer. This is something you’ll want to consider when building the greater detection engineering capability.
Wrap Up
Hopefully this high-level rundown of a detection engineering capability has inspired you and spurred on some ideas for how you can implement them yourself in your organisation. Please consider following me on Twitter (@rcegann) or subscribing to my blog’s RSS feed at https://rcegan.xyz to get notified of updates.
Any feedback and comments is also appreciated! My DMs are open on Twitter as well. :)