This article was co-authored by Gary Katz and Jason Deyalsingh
Recent studies have shown that genAI is commoditizing the creation of detection rules. This elevates the minimal qualifications of the detection engineer from simply creating detections to identifying where to focus efforts, implementing more robust detection capabilities and performing the research and tooling to support them. This article will focus on the first of these skillsets, identifying opportunities to create detections which align to your organization’s needs.
In the previous article, Critical Asset Analysis for Detection Engineering, we looked at one approach for prioritizing tasking for a detection engineering team. In this article, we will expand upon that analysis to examine four information sources of detection engineering and how they each can be either a starting point or a filter mechanism for prioritization. In the follow on article, we will identify different detection approaches, their limitations, and their data sources. This provides a guide for starting either from the data source perspective or from the detection mechanism perspective to prioritize tasking which aligns to your organization, skillset or detection capabilities. Teams should take a balanced approach across each of these options, using the right tool in the toolbox to achieve their goal.
In general, there are four information sources or categories of inputs to consider when building out a detection.
- Visibility: These are the logs or events which we build the detection from. We can consider the logs currently ingested into your SIEM, EDR, etc. The logs which are not ingested but could, and logs which we could have our custom software create. (When considering the third group, keep in mind the time or effort required to have your software team respond to your request)
- Detections: What existing detections does the team have or what third party detections can the team repurpose for their need?
- Environment: What is the infrastructure, network, systems, operating systems, individuals, etc. which you are protecting?
- Threat Intelligence / Research: Within this article, we cover the differences and value of strategic, operational and tactical threat intelligence. Our most relevant threat intelligence is as anything which tells us about how the adversary has previously implemented a procedure or how an adversary could implement a procedure. The information might come from a 3rd party threat intelligence source, internal forensic analysis of previous attacks, or research into how an attack has previously been, or could be, performed.
These four sets of data can be used to determine the importance of building a detection, the effort required to build it and the potential robustness of the resulting detection. Your analysis will most likely start with one of these four categories and pivot to the others. Let’s consider each starting point and the value and limitations associated with the approach.
In each case we start with gathering that type of information and then filtering down what is important based on the other three categories of data. This allows the analyst to then pivot or research to identify the additional knowledge required to create the detection.
Starting with Visibility:
As mentioned above, visibility is your access to events or logs which are the basis for building detections. In some circumstances, these events were created explicitly for detecting malicious activity and thus can be an easy starting point for building detections. One resource is Microsoft’s documentation which commonly provides guidance on events-to-monitor for specific infrastructure.
For example, if you were tasked to protect Active Directory, one valid place to start would be examining what events Microsoft has provided specifically for that purpose.
Thus, we are starting with which events would easily provide detection opportunities, informed by our environment / infrastructure. We can then use our existing detection capabilities and intel into techniques used by our adversaries to help prioritize whether to create new detections based upon this information.
Example Filters:
Environment: Which of the events are applicable to the network, software, platforms, etc. and how can detections based on them be tuned to not overlap with non-malicious activity
Threat Intelligence: How do the events align to expected malicious activity? What types of attacks have been recently performed against the systems these events provide visibility for?
Detections: What is the gap or overlap between what this visibility allows you to detect and the existing detections. Can they be made more robust? Will this visibility provide a different way to detect the activity and therefore provide additional detection-in-depth?
Once we have used the filters to inform where to prioritize our detection engineering efforts, we can begin researching the information required to build the detection. Creating a robust detection is outside the scope of this article, but many of the same data sources will inform this work. For example, detections created by third parties may provide starting points for your own detections. The intelligence, or red-team information, should provide additional details on how adversaries have previously implemented the attack.
Starting with Detections:
Plenty of open-source detection repositories available. SIGMA is the most well-known but github contains many repositories maintained by single users, or commercial SIEM vendors. In addition, some websites are devoted to detection-sharing. While SIGMA is designed to transform detections from their common format to specific rule engines, many genAI tools can perform a similar function, easing the reuse across providers. The difficulty here is not in finding detections, it’s in finding which detections to use. In this approach, we may start by tracking updates in repositories that prioritize quality over quantity. We then can filter by our environment, adversaries and existing detections to determine which updates are applicable and align with our visibility. While this can seem arduous, a simple agentic loop can perform the initial triage for your team, removing much of the daily burden.
This triage step only identifies potential detections to use by your organization. Nothing is truly free though, additional steps still remain to tune the detection and integrate it with your detection landscape.
Example Filters:
Threat Intelligence: Which adversaries that target environments or organizations similar to your own use the associated malicious procedures that are identified by these detections.
Visibility: Does the organization have the necessary events or logs for the detections to work?
Environment: Does the detection align to the environment which you are focused on protecting?
Starting with Environment:
In the article mentioned above, ‘Critical Asset Analysis for Detection Engineering’, we look at protecting critical assets, but one limitation of this approach is that many organizations either do not know what their critical assets are or do not distinguish between which assets are more important to protect. We can still use the approach, even without identifying our critical infrastructure by applying it to broader types of infrastructure, for example, building detections for your exchange server, or LLM coding agents.
There’s no exact approach for prioritizing what infrastructure to focus on, but a good start is to look at what infrastructure is important to your organization but is not protected by existing detections or third-party capabilities. (Starting with Infrastructure, filtering by existing detection capabilities) For example, your organization might have a large deployment of windows devices, but writing detections for a technique such as process hollowing can be lower priority since your EDR provider should identify those attacks. Instead, POS devices might also be prevalent but a current blind-spot in your detection capability.
Once we determine what infrastructure to focus on, we can examine the software, threat models, etc. to identify what types of attacks are relevant. Separately, we identify what types of telemetry we currently ingest, or could ingest, to provide visibility.
This telemetry could be used to identify known malicious activity or more generally identify indications of malicious activity by profiling the environment system, software, user type, etc. and then identifying anomalies in their activity.
In some circumstances the DE may not find sufficient or any telemetry useful for detecting malicious activity. In this circumstance, it is the responsibility of the DE to create the events required to build detections to identify malicious activity in the environment. A great example occurring today are the eventing capabilities being developed to provide visibility into agentic tooling. DEs started with how do I detect malicious activity in a genAI agentic capability, identified the lack of visibility and built capabilities to fill that gap.
Filtered by:
Threat Intelligence: How do adversaries achieve these objectives in other circumstances and how can those techniques or procedures be adapted to this environment? Additionally, which threat actors are actively targeting companies that match your company’s profile.
Detections: What is the gap between existing detections and new ones? How can existing detections be updated, or how can logging from the environment (for example, custom software) be updated to align to work with existing detections?
Visibility: How can the identified malicious activity be identified based upon the visibility? How can the environment’s (ex: custom software) logs be updated to provide the necessary visibility?
Starting with Threat Intelligence:
Threat intelligence is often the starting point for developing a new detection, yet many reports contain surprisingly few actionable insights that can be translated into detection logic. This is partially because a large portion of threat intelligence is not designed for that purpose. There are three types of threat intelligence which are worth quickly reviewing to distinguish their individual value.
Strategic reporting focuses on high level business risks and trending. For example, the yearly investigations or breach report from most large cyber security or infrastructure providers. This reporting can help determine where to focus but will not provide details on what to do. The report might state, ‘This year we are seeing a larger influx of ransomware attacks bypassing two-factor authentication’. It is not giving you direct data to write a detection on, but your team probably wants to review two-factor bypass methods and ensure you have detections in place to identify them.
Operational threat intel focuses on the adversaries, what campaigns they are conducting, who those campaigns are targeting and what TTPs they are using. This data is commonly used for tactic and technique prioritization in detection engineering. Identify which threat actors target your industry (or have previously targeted your company directly) and focus on the techniques used by those adversaries. Prioritize reviewing reporting about new campaigns from these adversaries and build detections around the tactical intelligence associated with the intel.
Tactical intel should describe how the adversary is executing their attacks. In many cases the reporting will include the IPs, domains, hashes associated with the attacks While these still provide value, they are usually not the data required for a robust detection.
One reason why it is difficult to find good threat intelligence in which to build your detections is that a large portion of tactical intelligence focuses on atomic indicators or procedure-instance information. Many open-source threat intelligence articles concentrate on what they saw, vs. deeper analysis into how the individual procedures within the attack are conducted. This provides a starting point for creating your detection but may require additional internal research or combining information from across sources to create a robust detection.
The open-source repository, Tired-Labs, is an example of deeper analysis of how specific techniques can be implemented by an adversary and the events required to identify them.
There is a second type of tactical threat intelligence which commonly is discussed separately but we will include here, red-team articles. Red-team documentation explains how to perform an attack and usually provides example commands or code for tools. This information can provide that next-level detail that is sometimes missing from basic intelligence reporting.
Now that we have defined these distinct types of threat intelligence, let’s examine how they become starting points for creating new detections.
Starting Point: Strategic Threat Intelligence
Filtered by:
Operational Threat Intelligence: How aligned is the strategic intelligence to my organization based upon which adversaries are targeting my organization or similar types of organizations?
Detections: What gaps do we have in identifying this type of activity?
Visibility: What visibility do we have in identifying this type of activity?
Environment: Does the strategic intelligence align to the infrastructure we are trying to protect?
Starting Point: Operational Threat Intelligence:
Filtered by:
Tactical Threat Intelligence: How do these new campaigns or changes in relevant threat actor activity differ from our existing knowledge of their procedures?
Detections: What gaps do we have in identifying this type of activity?
Visibility: What visibility do we have in identifying this type of activity?
Environment: Are these campaigns or actors targeting the infrastructure we are trying to protect?
Tactical / Red-Team Threat Intelligence:
Filtered by:
Strategic and Operational Threat Intelligence: Does this malicious procedure align to the adversaries currently targeting my organization or align to the types of attacks commonly being performed right now?
Detections: What gaps do we have in identifying this type of activity?
Visibility: What visibility do we have in identifying this type of activity?
Environment: Do these malicious procedures align to the infrastructure we are trying to protect?
It can be tempting to continuously identify new tactical threat intelligence which address gaps in coverage, build new detections and repeat. Work is being performed, detections are being created, gaps are being filled. But there is a reason why Strategic and Operational threat intelligence exists and there is a reason why we focused on threat intelligence last as a starting point. Attempting to respond to every piece of threat intelligence can lead to burnout without understanding if you are making a meaningful impact on your organization’s defenses, just as blindly converting every detection from an open-source repository would be unsustainable as well. Analysts are continuously bombarded on social media or threat intel sites with new flashy headlines, and it will get worse as AI both increases the attacker’s ability to build new capabilities and for articles about those attacks to be written. Some of this intelligence is crucial and must be quickly responded to, but the reporting must also be filtered to what is relevant to your organization and prioritized against other efforts which could lead to a more sustainable defense.
For each category of input, we started with a primary type of information and used the other types to filter or prioritize whether that data should be used to create a detection. In practice, you will continuously pivot between these data sources as you gain additional knowledge. In the second part of this article, we will provide an alternative mapping, starting with the type of detection you wish to create and mapping it to the types of sources which would inform that detection type.
Next we examine Choosing the Right Detection Approach
Where do Detection Ideas Come From? was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://detect.fyi/where-do-detection-ideas-come-from-21dc281aebb9?source=rss----d5fd8f494f6a---4