Detection engineering is the process of hypothesizing threats, intertwining controls, correlating sources, and alerting upon sequences of events within an enterprise. It enables organizations to identify malicious actors within their environment at specific instances, aiding in rapid identification and targeted eradication. Essentially, it's building intelligent alert systems that notify you when threat actors attempt to compromise your network.
Before We Start - The Cat and the Mouse
It is popular within cyber security to describe the entire process as a whole as a type of cat and mouse game. Most will compare this to direct vulnerabilities, exploits, and patches. How hackers are identifying vulnerabilities, making exploits, and then thwarted by patching. This does not capture the full picture. While vulnerabilities and exploits are a common theme in cyber security, a majority of breaches do not simply originate from an "exploit", and are performed through legitimate means such as phishing. In the modern day, the mouse is the hacker, developing malware and using tactics, techniques, and procedures (TTPs) to evade detection while persisting and laterally moving throughout a network. The cat is the defender, constantly setting "traps" in the environment that are borderline "invisible" to the mouse, and can only be inferred upon. An attacker might not know 9 password spray attempts will not trigger a detection, but 10 will (assuming that's the threshold). When discovered, the mouse will theorize and adjust their efforts, becoming more cautious or developing separate tooling to get around this detection - forcing the cat to change their tactics. So on, and so forth.
Hypothesizing Threats - Making A Threat Model
Any good detection engineering process will begin with the identification of the most probable profile of a would-be attacker for their particular environment. Threat modeling is important as it allows us as detection engineers to understand our adversary before spending cycles on developing and tuning defenses. An example would be that if your enterprise primarily uses entirely Mac machines, you probably don't need to make any Windows related detections or examine adversaries that use such tactics.
A threat model can be built of an entire Advanced Persistent Threat (APT) or Threat Actor's (TA) literal tactics, but it is best built off of existing truths within your enterprise. Questions about the industry of the organization, cloud footprint, technologies within, public sentiment, government relations, and more may come into play during this process.
- Does the organization exist within the cloud? Which one? AWS, Azure, GCP?
- Does the organization participate in political actions, making us a target for hacktivists or other nation state actors?
- What does the technology stack look like?
- Does the organization have a large public footprint?
- Is the organization's employees developers? Financial associates? A mix?
Intertwining Controls - A Heat Map of Coverage
Any proper detection engineer knows that relying on a single detection mechanism is a recipe for disaster. Detection engineering requires us to intertwine multiple controls, creating what we might call a "heat map" of coverage across an environment. It's not about having a perfect view of everything (which is impossible), but about ensuring that critical attack vectors have multiple overlapping detection mechanisms.
When controls intertwine, they compensate for each other's blind spots. This is why the MITRE ATT&CK framework has become such a staple in the detection engineering world - it provides us a common language to map our detection controls against known adversary tactics, showing us where we have strong overlapping coverage and where we've left ourselves exposed.
Consider a simple example: an attacker attempts to deploy malware through a phishing email. Your email security might miss it (first control), but your endpoint detection catches the suspicious PowerShell execution (second control), while your network monitoring identifies the unusual DNS request pattern (third control). The attacker needed to bypass all three controls to succeed - a significant challenge when they're properly implemented.
The process for building this intertwined control mesh includes:
- Cataloging your existing detection mechanisms across the environment
- Mapping each control to specific MITRE ATT&CK techniques or sub-techniques
- Identifying areas with multiple controls (hot spots) and areas with few or none (cold spots)
- Prioritizing development of new detections for critical gaps, especially in your likely attack scenarios
- Testing your controls through red team exercises or purple team engagements
The reality is that no organization has the resources to cover every possible attack vector with equal strength. The art of detection engineering is about making strategic decisions based on your threat model - focusing your strongest coverage on protecting your crown jewels against your most likely adversaries.
Correlating Sources - What Does Normal Look Like
Before we can detect the abnormal, we need to understand what normal looks like in our environment. This is where correlation of data sources becomes crucial in detection engineering. Every network has its own unique heartbeat - patterns of activity that represent business as usual. These patterns vary dramatically between organizations and even between different segments within the same organization.
Detection engineers need to become intimately familiar with these patterns by correlating data from multiple sources. We might examine authentication logs, network traffic, process execution, DNS queries, and cloud API calls - not in isolation, but as an interconnected ecosystem of activity. The goal is to establish baseline behaviors that represent legitimate business activities.
Consider a financial institution where large data transfers occur every night during automated batch processing. In another environment, this same pattern might indicate data exfiltration. Context matters tremendously, and it can only be understood by correlating multiple data points. An authentication from an unusual location might be suspicious, but when correlated with a VPN connection and a help desk ticket about an employee traveling, it transforms into an expected event.
Alerting On Sequences - What Do You Actually Do
The culmination of detection engineering is turning all our preparation into actual, usable alerts that tell us when something suspicious is happening. This isn't about generating thousands of alerts that overwhelm analysts - it's about creating meaningful, actionable notifications based on sequences of events that truly indicate malicious activity.
Detection engineers don't alert on single, isolated events. We alert on sequences and combinations that tell a story. A single failed login isn't interesting, but ten failed logins followed by a successful one might indicate credential stuffing. A PowerShell process isn't suspicious on its own, but when it's spawned by Microsoft Word, downloads an executable, and then connects to an unknown IP address - that sequence tells us something is wrong.
Modern attackers rarely compromise a system in a single step. They follow sequences - initial access, execution, persistence, privilege escalation, and so on. By understanding these attack chains, we can build detection logic that triggers at various points in the sequence. The earlier in the chain we can detect activity, the faster we can respond before serious damage occurs.
Building these sequence-based alerts requires both technical skill and a deep understanding of attacker behaviors. A detection engineer must translate threat intelligence about adversary techniques into specific, observable events within their environment, then create correlation rules that identify when these events occur in suspicious patterns or sequences.
The best detection engineers don't just create alerts - they create context-rich notifications that include the full sequence of events, relevant asset information, and potential next steps for investigation. When an alert fires, it should tell a story that an analyst can understand and act upon immediately.
How EpicDetect Helps Build Detection Engineers
At EpicDetect we try to bridge the gap between student and detection engineer, between analyst and detection, and really any other distinction. We believe more detection engineers directly means safer industries. Many folks learn the theory of of cyber security, but never directly get into the weeds. It isn't enough to just triage the alerts, you have to get your hands dirty and understand how they actually work. We have a dedicated platform with tons of problems for you to directly learn SPL by performing both incident response and detection engineering straight from a cloud-based SIEM. It's free too!
