This blog was originally published April 27, 2021 on humio.com. Humio is a CrowdStrike Company.
Just as threat actors evolve their attacks and techniques, so too must security teams evolve their detection content. Detection engineering, therefore, is a life cycle that requires continual effort. However, when done well, detection engineering can reduce the mean time to detect and respond to a threat, as well as recover from a threat.
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. It aligns content developers, threat hunters, threat intelligence, red teams, risk management, and so forth, to build a threat-informed defense system.
Detection engineering starts with threat modeling – identifying the threats that are relevant to your organization. You can use the MITRE ATT@CK framework and perform a gap analysis to discover what’s relevant, but it ultimately starts from asking the following questions:
- What do I need to detect?
- What threat actors, techniques, tools, etc., are relevant to us?
- How can I demonstrate the relevance to the business?
The answers to those questions can help you build a formula for the threats your organization should be concerned about.
From there, identify available log sources and determine what logs or data sources you’re missing that are necessary to detect the threats you’ve identified. Next, identify use cases, look at vulnerability reports and develop an understanding of the holes in your defense. Do your due diligence. Research and hypothesize about the threat. At that point you can begin writing your detection content.
In this phase, answer the questions:
- How can I detect X?
- What log or data sources do I need to do so?
- What detection logic should I use?
Those answers lead into the actual implementation where we talk about a life cycle and how you’ll manage that detection capability on an ongoing basis. Once you’ve written that specific piece of content for detection, you need to continuously tune it for false positives and other nuances that come up. You’re tuning and deploying, but you’re also consistently reviewing the detections that you’ve previously written. As part of this process, ask yourself:
- How can I automate detection?
- Is this detection more suitable as a dashboard, saved search, report, or rule?
The cyclical nature of detection engineering requires a supportive culture in the organization. Without a culture, you’ll fall short. The return on investment from this lifecycle is a reduced mean time to detect and mean time to respond to an incident. Of course, there will always be incidents that creep up that are not necessarily part of the detection lifecycle. That’s where threat hunting comes into play. If you’re interested in learning more, we dive further into threat hunting and forensics in Session 4 of the Advanced Log Management Course: Strategies, Techniques, and Tactics.