Last Update: 2023-03-19

I want to better understand the industry landscape and emerging practices in Detection Engineering. These are my notes on DE perspectives, frameworks, processes, tools, and people to learn from.

What is Detection Engineering?

Detection engineering is the process of identifying threats before they can do significant damage. Detection engineering is about creating a culture, as well as a process of developing, evolving, and tuning detections to defend against current threats. – CrowdStrike

Detection engineering transforms information about threats into detections…. Detection engineering transforms an idea of how to detect a specific condition or activity into a concrete description of how to detect it. – Florian Roth

Detection engineering is by no means limited to the detection of events (activity). It also includes detecting conditions (states), often used in digital forensics or incident response. – Florian Roth

A Threat Detection Engineer is someone who applies domain knowledge on designing, building or maintaining detection content in the form of detections generating alerts; or interfaces in the form of dashboards or reports supporting the security monitoring practice within an organization. – Alex Teixeira

Detection engineering is a process—applying systems thinking and engineering to more accurately detect threats. The goal is to create an automated system of threat detection which is customizable, flexible, repeatable, and produces high quality alerts for security teams to act upon. – Laura Kenner, uptycs

Detection engineering functions within security operations and deals with the design, development, testing, and maintenance of threat detection logic. – Mark Stone, panther

Detection engineers design and build security systems that constantly evolve to defend against current threats. – Josh Day, gigamon

Threat hunting and detection engineering are different specializations, but are closely related. They have common goal of finding attackers using available data, whether its the attackers that got past your detections (threat hunting) or the next ones through (detections). – Mark Simos


Can I get certified as a Detection Engineer?

Maybe. I never thought about that before.

How can I learn more about Detection Engineering?





Listening (Podcasts)

Watching (Videos)


Events (Conferences)

What are the core Detection Engineering Processes?

TODO. See articles above for now.

What tasks should a Detection Engineering Program document?

Appendix C.3 of the MITRE book 11 Strategies of a World-Class Cybersecurity Operations Center outlines a framework for Detection Engineering/SOC Systems Administrator documentation. In a past job, I worked together with a SOC Syadmin, collaborated on documentation that was similar. I was delighted when I read this appendix and found it was a strong match for what we did. It drove new effeciencies, supported better understanding by incident handlers, and ensured our systems were well maintained and worked.

This key document types for SOC Engineering are:

  • Monitoring Architecture
  • Internal Change Management Processes
  • Systems and Sensors Maintenance and Build Instructions
  • Operational, Functional, and Systems Requirements
  • Budget and current spending (capital and operational expenditures)
  • Unfunded Requirements
  • Sensor and SIEM Detections/Analytics/Content Lists(s)
  • SOC System Inventory
  • Network Diagrams

I like to focus more on the documentation of use-case development. In the MITRE book that would be “Sensor and SIEM Detections/Analytics/Content List(s)” as well as “Internal Change Management Processes” primarily. Below is my own framework for the medium-grained tasks a Detectin Engineer would carry out. You can think of each item below as being an artifact or task documented in Jira or Confluence etc.

  • Document use-case – Taking as input some need, define the use-case so that it maybe reviewed and prioritized and added to the backlog
  • Develop use-case – Input is a documented need for the use-case. Perform in-depth requirements analysis, data wrangling, iterative development of detection and data sources, and full documentation. Output is a test detection in non-production ready to be reviewed for acceptance by stakeholders, and for final implementation.
  • Implement use-case – Input is an developed use-case that has passed acceptance. Implement it in production and remove it from the backlog.
  • Monitor use-cases – Input is all production use-cases. Monitor use-cases and periodically review them for relevancy and effectivness. Output is requests to retire, enhance, or maintain the use-cases
  • Retire use-case – Input is a request from monitoring of all use-cases. Ensure the use-case is disabled tracking anything that has dependencies on the use-case. If necassary create a new use-case to replace this one if others depend on it but it needs to be retired. Output is confirmation that retirement has not caused adverse impact.
  • Plan threat-hunt – Input is demand for a new use-case. Generate a hypothesis and test plan. Describe data sources needed, effort and resources required and a schedule. Output is a plan and schedule ready for approval.
  • Execute threat-hunt – Input is a threat hunt plan that has been approved. Gather the required team, and on schedule execute the hunt. Output is documented findings, and possibly escalation to incident response.
  • Develop metric – Input is a deman from a stakeholder or a documented use-case ready for development. Develop a way to measure the effectiveness of a use-case, or some aspect of the DE program. Output is the logic/process for a scheduled report dashboard or some data.
  • Implement metric – Input is a developed metric. Implement it and remove it from the backlog.
  • Report metrics – Input is all developed, implemented metrics. Operationize reporting. Output is feedback into the use-case development process or advise to stakeholders outside DE.
  • Document datasource
  • Implement datasource
  • Monitor datasource


Naming Conventions

  • From LASCON talk by – Primary Key:SCOPE:TTP:Short name – Scope is servers, workstations, or something more granular –

Detection Specification Languages/Formats

  • Sigma
  • YARA
  • Splunk SPL
  • Microsoft KQL
  • Snort Rules
  • GraphQL
  • YAML

Managing a Backlog of Work

  • JIRA


  • Agile Use Case Detection Methodologies
  • DevOps CI/CD


  • Sigma


  • Wazuh
  • CrowdStrike
  • Microsoft Defender for Endpoint


  • Microsoft Sentinel
  • Splunk Enterprise Security


  • Splunk SOAR
  • LogicHub
  • Palo Alta Cortex
  • CrowdStrike Fusion


Data Sources (Event Logs)

  • MITRE ATT&CK datasource mapping
  • Sysmon
  • Linux auditd
  • Filebeat
  • Windows Events
  • syslog
  • Firewall Logs
  • Zeek (network events)
  • DNS logs
  • Anti-virus Alerts
  • Active Directory changes
  • AWS CloudTrail

Malware Analysis

  • VirusTotal
  • Hybrid Analysis
  • Cisco Malware Analytics
  • IDA Pro

Who are the leaders in Detection Engineering?

What is the relationship between Detection Engineering and Incident Response?

What is the relationship between Detection Engineering and Threat Hunting?

Threat Hunting and Detection Engineering go hand-in-hand. Threat Hunting methods are used by Detection Engineers to validate their detection logic, data sources, and measure effectiveness. That said, Threat Hunting has additional outcomes unrelated to Detection Engineering goals, and may trigger incident response.

Most Detection Engineering use-cases begin with a Threat Hunt to validate and priorize the use-case. If the threat hunt proves difficult, it helps estimate the effort of developing the use-case for detecting that threat. If the threat hunt yeilds few false positives, it indicates that the use-case could be highly effective and should get higher priority. If the threat hunt fails due to lack of data, it may indicate that developmen to the use-case should be deferred until the datasource can be developed.

What is the relationship between Detection Engineering and Threat Intelligence?

The need for new detections is often driven by threat intelligence. We want to detect threats before they become incidents and the earliest needs may come from threat intelligence analysis. For example, if Qakbot has changed their methods but your organization has not yet encountered them, threat intelligence may be able to provide information on how to detect the new methods days before you are attacked.

A good detection engineer reads threat reports differently than a malware or TI analyst. He/she discovers detection opportunities, pivots and writes rules for any trace the reported threat may have left. – Florian Roth

What is the relationship between Detection Engineering and Offensive Security?

What is the relationship between Detection Engineering and IT Asset Inventory?

Detection Engineering both consumes and produces asset inventories. Detection Engineering crucially requires quality inventory of assets, identifies, and configurations.

If you want to measure the converage of your detections for an specific threat, you will need to have an inventory of assets targeted by, exposed to, or vulnerable to the threat. If you don’t have a good inventory, you will not know how effective your detection will be. For example, if you have a detection for exploitation of a vulnerability in MS SQL Server, but you don’t know how many SQL Servers you have, or their addresses, you cannot determine if your detection will actually work.

Detection Engineers often have specific inventory requirements that others do not. For example, knowing which security agents are present, knowing how assets are configured, knowing what permissions an identity has. These all can be used to enrich detections to priotize alerts by priority of the asset or severity of the detected threat. Without this additional information, you can detect a threat, but not detemine how urgent a response to that threat is.

What is the relationship between Detection Engineering and Malware Analysis?