This tradeoff also works in the opposite direction on the precision-recall spectrum. A detection engineer can deploy an atomic rule that is so precise it becomes brittle. It may never generate an alert because the fields it tries to capture are so specific that they offer low operational value.

The answer to combat these types of detections is to increase the context around the attack itself. This means capturing more threat activity to group atomic detections together, as well as increasing the context of the environment to differentiate benign and malicious activity. Composite detections, also known as correlated or stateful detections, increase the context and, therefore, complexity of writing and maintaining the rule.

This field manual post covers (ha!) the pros and cons of composite detection rules and begins to explore strategies to expand context around threat activity.

Detection Engineering Interview Questions:

• What is the MITRE ATT&CK?

• What is a composite detection rule?

• Explain a threat activity scenario where a composite detection rule helps reduce false positives?

• How do composite rules increase operational complexity for a detection engineer?

MITRE ATT&CK

MITRE ATT&CK (pronounced “MY-ter AT-ack”) is the industry standard for modeling threat activity. According to their main website:

“MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.”

There is no modern detection engineering and incident response without MITRE ATT&CK. It serves as a lexicon for security engineers across red and blue teams to standardize on how a specific attack occurs and the telemetry it generates.

Tactics are along the X axis and represent the stages an attacker traverses to achieve an objective, such as exfiltrating sensitive data, deploying ransomware, or causing a denial-of-service attack. Ransomware deployment is the end goal, but it requires a lot of steps to achieve that impact. For example, getting access to a victim machine, laterally moving to a domain controller, collecting secrets and cracking administrator passwords, and finally finding a way to deploy the ransomware.

The Techniques are the Y-axis under each Tactic. Techniques are the how: specific methods adversaries use within each tactic to achieve their objective. For example, Network Share Discovery under Discovery is used by attackers to find interesting files, folders and target machines connected to the current machine. They can leverage this to perform Collection of sensitive information and perform Lateral Movement to a higher privileged victim machine.

The beauty of MITRE ATT&CK is that it directly contradicts the adage “attackers only need to be right once, defenders have to be right 100% of the time.” Each technique listed above has associated telemetry, detection opportunities, and some even have threat groups that leverage the documented techniques.

What does this have to do with Composite Detections?

In my last post on Atomic Detections, I talked about how Atomic Detection rules lack context. These rules can use threat intelligence, such as malicious IP addresses, to generate alerts, but those IP addresses can be rotated, making the rule very noisy. So you wouldn’t want to write that rule unless it existed in the same window where the IP address remains malicious.

On a separate Atomic Detection rule, a detection engineer can write a rule to alert on Network Share Discovery. This is an obvious choice from my example before: the next logical step after Network Share Discovery is Lateral Movement. We want to detect that, right?

The problem here, again, becomes context. What if a legitimate process, such as a File Search or Data Backup tool, performs Network Discovery? You generate an alert, block the activity, and just killed productivity or a critical business process for one of your users. Does this mean you need to painstakingly investigate every Network Discovery alert? You could, but you would burn out, and the operational costs would be too high.

This is where Composite Detections can help, and where MITRE ATT&CK enables context via chains of events. By correlating Network Share Discovery with subsequent Lateral Movement attempts, we filter out benign activity and surface actual threats.

Composite Detections Tell a Story

Let’s continue to challenge the adage “attackers only need to be right once, defenders have to be right 100% of the time.” We know that writing one Atomic Detection rule can be noisy. So what if you write two? What if you write these rules across every single path along MITRE ATT&CK, under every Tactic? You would have high recall, but terrible precision, and a flurry of alerts that can’t discern between benign and malicious activity.

Let’s look at an example from our previous post on Atomic Detection Rules:

In this scenario, the Atomic Detection rule fires on administrator login activity. We are only looking at the event and ignoring sourceIP, timestamp, and location. These can help tell the story, but the story stops on the singular event. You could write some additional enrichment to tell the story that:

• The Admin is logging in from a risky location, let’s say outside the U.S. for the sake of example

• The Admin is logging in past business hours

But these enrichment points can also be part of legitimate business activity. This is where context comes into play.

Let’s say you have two other rules that capture potential threat activity of an Administrator creating a second account and attaching an Administrator policy or profile to it. It’s riskier (it’s further along the ATT&CK chain), but it lacks context. But what if you combine the threat scenarios and create a story?

Here’s the story: an Administrator account gets compromised, and an attacker runs a script to log in to your AWS portal automatically. They are smart cookies and believe in another adage, “two is one, and one is none,” and create a second account to achieve Persistence on your account. They then leverage their Administrator privileges to attach an Administrator policy. Smart, if you reset the original Administrator password, they have a backdoor back into your environment!

By combining the three scenarios via the following rule, in pseudocode:

if user contains 'admin'
AND CreateUser action is called
AND AttachUserPolicy is called and the Policy = 'Admin'
THEN alert

You’ve told your SIEM quite a compelling story to look out for, and it found it!

There are some key questions from the above rule, and they emerge from the other data I’ve omitted from my diagram:

• What is a legitimate amount of time between logging on and calling CreateUser?

• Is calling CreateUser then attaching an Administrator policy malicious?

• Does this Admin typically CreateUser and attach policies?

These questions are what adds complexity and cost to writing and maintaining a ruleset. So, a detection engineer must weigh the cost of this complexity versus the cost of false positives from Atomic rules.

In this specific Composite rule, we used Windowing. Windowing is a technique in which we capture activity in time windows and assume that any Composite detection that captures events within that window must be the result of threat activity. The rule assumes that if an Administrator account logs in, creates a secondary account, and attaches a privileged policy to it, it must be malicious. This reduces false positives by:

• Combining three Atomic rules into one rule

• Creates a story where these three actions together means something malicious is happening, or requires investigation

• Assumes threat actors will try to do this quickly as their access may be revoked within a few minutes

Stories increase complexity

I linked a chart in my previous post about the trade-off between context, operational cost and false-positive reduction.

In this Windowed Composite Detection Case, there are several costs that detection engineers incur:

• Does my SIEM technology support Windowing?

• Does the combination of these detection rules capture the threat activity that I want? For example, should I also have a separate atomic rule for CreateUser to catch persistence attempts that don’t fit the 5 minute window? This can lead to false negatives if you only rely on composite rules.

• Does the window period give me the best value? If I increase it to 15 minutes, what costs do I incur on server usage, indexing and other infrastructure components?

I will say that Detection Engineers I’ve hired, worked with, and spoken with at other companies spend as much time researching cost trade-offs as they do performing pure security research. This is the Engineering component of threat detection, and to me, these types of problems are what make the field exciting. You are part security researcher, part engineer, and part data scientist!

Conclusion

Composite detections shift detection engineers’ focus to reduce false positives by creating stories of attack chains. MITRE ATT&CK is the de facto industry standard for documenting how an attacker progresses through a breach to achieve an objective. Detection engineers can use ATT&CK to build atomic and composite rules to capture threat activity.

Atomic rules lack context by design, but when combined with other atomic rules via composite detections, you can start building a story of an attack. This story is the context you want to decide on whether you should investigate an alert. This story also reduces false positives by capturing the logical progression an attacker may take in your environment, and reduces the likelihood of alerting on benign activity.

The complexity of creating and maintaining composite detections stems from technological capabilities, such as windowing, as well as the hidden costs of assumptions made by the detection engineer. For example, combining three distinct events into a composite detection may miss other alerting scenarios within those events, leading to a false negative.

In the next Field Manual post, we'll explore different alerting mechanisms for composite and atomic detections outside of windowing.

Finding attacks is the core value proposition of what detection engineers do, and it’s what makes this field technically challenging. Although difficult, this work has an art and aesthetic that is hard to find anywhere else in security. This is because you aren’t solving a machine-to-machine problem, but a human-to-human problem, and the other human is unwilling to cooperate with you. To me, detection engineering and blue teaming, overall, are studies of behavior.

In this post, we’ll begin looking at how rules detect threat activity through atomic detections.

Detection Engineering Interview Questions:

• What is the Pyramid of Pain?

• What is an atomic detection rule?

• Compare and contrast scenarios where an atomic detection rule can be effective or ineffective.

• What is environmental context?

David Bianco’s Pyramid of Pain

Some attacks generate telemetry that is easy to identify as an attacker on your system or networks. Many attacks, however, require logic that depends on telemetry availability, environmental context, index windows of logs arriving at the SIEM, and understanding of attacker tradecraft or behavior.

Much as detection engineers must consider operational costs when writing rules, threat actors incur costs when carrying out attacks. This cost-versus-cost battle helps frame attack and defense so you can impose as much cost as possible on an attacker’s operations, so they’re in so much pain they deem a tactic or technique not worth their time. This is where the “Pyramid of Pain” by David Bianco becomes a valuable exercise for security teams.

At its core, the Pyramid of Pain challenges defenders to focus on imposing as much pain on attackers. As you traverse the pyramid, operational cost to your efforts increases, but the amount of pain you cause to an attacker also increases. Each layer of the Pyramid represents an operational complexity for the threat actor to consider when staging an attack. The ideal state of detection is at the top: if you detect Tools executing in your environment, your detections are more robust because the order and context of the tool’s execution become irrelevant.

The best state is under “Tactics, Techniques and Procedures” (TTPs). This layer focuses on the behavioral aspect an attack. If you detect behavior of an attack, every layer below the pyramid become less relevant in your detection (for the most part), and the detection is robust enough to catch changes in Tools, Artifacts, Domains, IP addresses and hashes.

Imagine this: you write a rule that helps detect a known Command-and-control (C2) server you read from a blog post. You deploy that rule and it doesn’t find anything. Great, you aren’t compromised, and you’ll have great coverage for the future if there is a compromise.

Here’s the problem: threat actors are well aware that we find C2 servers, build rules, share with the community and blog about them. A C2 server is typically either an IP Address or a Domain. Have you ever rented a droplet on Digital Ocean, or bought a domain from Namecheap? You can spend a few dollars to rent more droplets or buy new domains. This requires minimal pain on the threat actor’s side, and defenders no longer block your new C2 server until it is discovered again.

Even worse, the IP address you wrote a rule for is now leased to a benign client, and it is now alerting on benign traffic, causing pain to you and your team.

So, how effective is your detection rule now? Not too effective! This is because detecting on a singular value, such as an IP address or a domain, is an Atomic Detection. Atomic Detections are narrowly defined rules that detect activity at a point in time with little to no context. Let’s dive into them in the next section.

Atomic Detections Lack Context

Atomic Detections are tactical in nature. They may seem precise in practice, but because they lack context from the environment and incur little pain for attackers, they become brittle and prone to false positives. As soon as an attacker changes their infrastructure or flips one bit in a new build of their malware, which changes the cryptographic hash value, your rule diminishes in quality.

Atomic Detections also exist for computer or network activity. The point here is that ignoring context in an environment, such as rules that don’t evaluate time signatures, environmental context, or regular activity, makes atomic rules risky to deploy.

Let’s look at a basic alerting example with Amazon AWS Administrator login activity.

The rule is in purple and only alerts on Log activity where the user field value is admin. The SIEM correctly identities the user field containing admin three times . The 11AM alert is a true positive: the administrator credentials were compromised. The other two are false positives, indicating normal administrative work. To make things worse, the compromised login was during normal business hours.

So how do you differentiate between the three alerts?

You differentiate them by spending incident response cycles investigating each one. Now imagine 100s or 1000s of these being generated. The atomic rule strategy doesn’t work because there is little to no context on the event.

The same thing can be said for IP-based C2 alerting.

In this example, the detection engineer wrote an atomic detection rule for a known C2 IP address. Perhaps they read a blog some time around December 10 and added it quickly to find exposure. Log 1 enters the SIEM; the rule checks the destination field and generates a true-positive alert.

Fantastic! Let’s keep the rule!

The C2 was removed by the leasing company that owns it on December 11 due to the blog post. On January 15, a content delivery network leases an IP address, and network traffic logs flow through the SIEM, triggering an alert. Each subsequent network log afterward is a false positive.

The context from both of the graphs above is under the UNUSED field in the purple box. Associated domains, timestamps and physical location are all useful fields to add into the atomic rule to increase robustness of the rule and remove false positives. It would make sense, then, to start including all of these in your detection rule. Detection engineers need to understand the relationship between detection context and cost.

Imposing cost on ourselves

As we progress the Pyramid of Pain and add context to your ruleset, the cost increases. Cost can depend on time, resources, maintenance, or the technology needed to add context, such as threat intelligence. The following graph tries to explain this causal relationship:

At the bottom left, you could deploy a rule similar to the examples above. Because the operational cost of matching on a single value is low, the context is low. And because the context is low, the risk for false positives is high. As you add context (move to the right), the cost increases, but the false-positive rate decreases.

This is why not every rule can be perfectly accurate. There is a cost-benefit tradeoff, as well as information asymmetry from attacker behavior, that detection engineers must consider. The only way a rule can catch all threat activity is to alert on every piece of activity. That seems costly!

Conclusion

Atomic detection rules generally focus on low-context events or values. They can certainly help a blue team function, such as a SOC or a Detection & Response team, and they have a place in security operations. They risk generating many noisy alerts when the detection engineer fails to account for a threat actor’s behavioral patterns.

The Pyramid of Pain and imposing cost are industry-accepted concepts that help contextualize the competing objectives of blue teamers and threat actors. Writing rules to alert on the bottom parts of the pyramid, which primarily involve threat intelligence indicators (IP addresses, domains, hash values), imposes a greater cost on defenders than on threat actors. Defenders impose more pain on threat actors by climbing The Pyramid and writing rules that detect tools and TTPs.

For the next few parts of this series, I’ll explain the different ways detection engineers can write rules to capture threat actor behavior and the associated operational complexity.

If the SIEM returns results, how do you determine whether it’s malicious activity or not?

Should a SIEM only ever return malicious results?

How do you design rules so analysts aren’t wasting time responding to the dreaded “false positive”?

This blog helps answer these questions through the lens of Detection Rule Efficacy.

Detection Engineering Interview Questions:

• What are the four types of labels an alert can have — and what’s your criteria for assigning each one?

• What are the tradeoffs of optimizing for TP/TN/FP/FNs?

• From a Detection Rule Efficacy perspective, what makes a good rule versus a bad rule?

Security Operations is a Funnel

One of the most impactful pieces of security operations work I’ve ever read is Jared Atkinson’s research into the “Funnel of Fidelity” for alerts - link to the post here.

The basic premise of the Funnel of Fidelity is that security teams have limited capacity based on the number of humans reviewing alerts. For each new alert pushed into the analyst’s queue, some level of cost is imposed on the analyst as a function of time to investigate that alert. Therefore, as detection engineers, we must consider the fidelity of our alerts in terms of their associated costs.

Jared’s post captured this with his concept of the Funnel of Fidelity, and forewarned readers to “Never clog the Funnel”

In Issue 2, while describing the function of detection rules, we explored the idea that these rules help scale human operations, so we aren’t consistently stuck issuing queries against a SIEM to look for maliciousness.

We rely on both rules to capture our human intuition and querying services to find logs that may indicate maliciousness. This is the same argument Jared discussed in his post: with limited resources (time to triage alerts and the number of humans triaging them), how can we prevent alert fatigue?

We define alert fatigue as the degradation of human efficacy in triaging alerts, which can result in malicious telemetry bypassing our human investigations, thus leading to a security incident or, worse, a security breach. The concept of the Funnel helps prevent alert fatigue by focusing detection efforts on this cost function; we can’t do that without understanding the four types of alerts that can reach the “Triage” portion of Jared’s Funnel.

Scaling Security Operations is an optimization problem

I never really understood the purpose of mathematics through my schooling and college until I realized that most problems in security aren’t solved, but optimized. A Detection Engineering team focuses on Detection Rule Efficacy, which is the cost function of generating alerts via their rules relative to the capacity they can handle without clogging the funnel.

To understand Detection Rule Efficacy, you must have a foundational understanding of the four labels in any prediction-based system: True Positives, False Positives, True Negatives and False Negatives. These labels are useful for almost any binary classification system. Don’t worry, we aren’t going deep into Statistics or Machine Learning, instead we are going to use these labels as a way to understand the risk of clogging the funnel.

There are two realities to any alert:

• What an alert is, such as the traffic or log, is whether it is malicious or benign

• What we interpreted what the alert was, which is malicious or benign

So, to be explicit on the four labels:

• True Positive: There was malicious traffic, and we labeled (alerted) that traffic as malicious

• False Positive: There was benign traffic, and we labeled (alerted) that traffic as malicious

• False Negative: There was malicious traffic, and we did not label (alerted) that traffic as malicious

• True Negative: There was benign traffic, and we did not label (alerted) that traffic as malicious

In the ideal state, all of our rules alert on true positives and do not alert on true negatives. However, if you recall any of your statistics classes (I certainly didn’t, but I’ve read a lot since then), it’s never that easy. In fact, it’s probably impossible in any classification system. Let me explain.

Precision and Recall make our rules Brittle and Broad

My favorite way to describe the issues of Detection Efficacy is through Brittle and Broad rules, also coined by Jared Atkinson. Broad Rules capture a wide range of malicious telemetry, but are prone to false positives. Brittle Rules capture a particular type of malicious telemetry, but are susceptible to false negatives. In the statistics world:

• Brittle Rules measure Precision, which is the ratio of TP/TP+FP

  • It answers the question: Of the set of alerts, how many are relevant (malicious) events?

• Broad Rules measure Recall, which is the ratio of TP/TP+FN

  • It answers the question: Of the relevant (malicious) events, how many were alerts?

Let’s get visual with these concepts, shall we?

In the above visual:

• There are 22 logs (N=22)

• 8 logs are malicious

• 14 logs are benign

You deploy a detection rule, and you alert (the decision threshold on the line at the top) on 5 of those malicious logs, and 1 benign log. The Precision (Brittleness) of your rule is calculated as:

• 5 malicious alerts / (5 malicious alerts + 1 benign alert) = 83%

83% is not bad! For every 100 logs, you alert correctly on 83 of them. But there’s a catch to this Brittleness. Let’s calculate the Recall (Broadness) of your rule:

• 5 malicious alerts / (5 malicious alert + 3 malicious events you missed) = 62.5%

For every 100 malicious events, your detection catches about 62 of them. Is that good or bad?

I’ll be lame and propose the “Allen’s Rule of Detection Efficacy” (I’ve always wanted to have something named after me, so give me this one, okay?)

You can’t have a detection rule that’s both perfectly precise and fully comprehensive unless you already know the answer.

This is a perfect shoe-in for Atkinson’s “Clogging the Funnel” concept. He never proposed making all of your rules high precision (brittle) or having high recall (broad). He suggested that we consider the efficacy of our rules to avoid overwhelming the SOC. It’s an optimization issue.

Detection teams combat this optimization in various ways, including threat and breach emulation, threat hunting, detection-as-code testing, detection tuning, and integrating rules into live traffic, which we’ll explore later in this series. We have numerous strategies to optimize efficacy, but what does efficacy mean in the context of a good rule?

Good Rules Provide Operational Value

A SIEM alert is a unit of work for a SOC analyst, a detection and response engineer, and a security engineer. At its minimum value, it’s a hedge to the downside cost of a security incident. You’d rather alert and contain a suspicious process that executes malicious code on a company asset than miss the attack, which could lead to a full-scale security breach. So, when you are asked what makes a “good” rule versus a “bad” rule, it comes down to how much cost are you willing to incur for responding to that alert.

To drive this point home, let’s look at a larger population of security events, this time with low precision and high recall:

At face value, this rule might be deemed a “bad” rule. The precision here is 47%, which means that for every 100 alerts, only 47 of them are malicious. That means 53 false positive alerts incur an unnecessary cost on an analyst. The recall is very high: for every 100 malicious events, we catch 94 of them. So, is this a bad rule or not?

Here are some counterpoints to where this might be a good rule:

• The SOC is concerned about missing a specific attack that this rule aims to detect, so they build in the capacity to triage more false positives to ensure they don’t miss any malicious alerts.

• The rule is experimental and is being “baked” into the operational environment, so false positives are expected and welcomed to help tune the rule (move the orange line)

• This is a threat hunting rule where precision doesn’t matter, and the detection engineer wants to cast a wide net to find all kinds of events.

• The rule has a low criticality marking, or severity (INFO, LOW, MEDIUM, HIGH, CRITICAL). Based on SOC’s operational context, INFO/LOW/MEDIUMs aren’t triaged first, and could be used as a signal rather than an alert.

Given the four examples above, it is reasonable to conclude that this rule provides operational value and is a “good” rule. As long as you don’t clog the Funnel of Fidelity, then you should have an efficient security operation, and have more resiliency and flexibility in your set of rules than you would have if you only focused on Brittle rules.

Conclusions

Detection Efficacy is more than just tuning rules to generate true positives and avoid false positives. Efficacy provides operational value to the detection engineer and their customers, and sometimes that means generating alerts that may not be useful from a pure precision point of view.

Atkinson’s Funnel of Fidelity is an excellent way to model how you should run a security operations program. It allows flexibility in your ruleset and encourages conversations outside of the Detection Engineering bubble to understand what matters to your operational teams and the firm as a whole.

As we dig deeper into the technical aspects of Detection Engineering, we first need to explore how humans scale their threat expertise into logging systems.

Detection Engineering Interview Questions:

• What are detection rules?

• Why do detection rules matter for a security team?

• How does SIEM indexing work, and can you provide examples of how a SIEM processes and searches logs?

There is no rule without telemetry

A detection rule at its fundamental level is a search query against a logging system that contains logs. In the security industry, most threat detection teams operate a Security Information and Event Management (SIEM) logging system. Detection teams gather telemetry from Assets in the form of logs and send them to the SIEM.

Logs are typically generated when an Asset records an Event. In the Operating System world, such as Windows or Linux, an event can be:

• A new user is being added to the system.

• A process or a user created, modified, or deleted a file.

• A user runs or executes a file that creates a new Process.

Recording everyday activity can be cumbersome, so for threat detection, some events are more desirable than others. For example, Sysinternals’ Sysmon records 27 different types of security events that can happen on Windows. Event Tracing for Windows (ETW) providers can range in the 10s of thousands, and you need to subscribe to providers who can provide relevant security events to you.

When a log enters a SIEM, it is stored on disk and typically sent to an “index.” An index is a structured search layer built on top of stored logs, allowing for fast lookups by mapping field values (such as domains, IPs, or processes) to logs that contain them.

For example, in Splunk, if you specify your Assets to send a log to the “WebApp” index, it’ll store those raw logs alongs with some metadata. During indexing, the SIEM parses and enriches each log with structured fields. If that parsing fails, or there are errors on ingestion, some fields may be missing.

When you search a SIEM, you generally provide an index and a query. The query can contain basic strings, such as google.com , and the SIEM should send relevant logs that contain google.com. But we aren’t here to do simple things; we are here to find bad guys, so how do you create rules to do so?

Rules encapsulate Human knowledge

Remember, the primary function of a rule is to store a search query. This search query, when issued against the SIEM, MAY return results. If results are returned, it could be indicative of malicious activity.

The above example shows a simplified workflow on how this works. A Detection Engineer asks the SIEM to send them any logs that contain maliciousdomain.com on index:dns. The SIEM utilizes the index to identify relevant logs, thereby avoiding full storage scans. Once the SIEM and underlying indexing technology find matches, it retrieves them from storage along with the associated metadata.

But what’s the problem with this approach? It’s the human! Here’s why:

• Humans can’t possibly remember every search query needed to find malicious activity

• Even if the above bullet were true, if the list is N long, are you going to search N queries for results sequentially?

• When your query returns a malicious result, do you stop querying to investigate? What if more malicious activity is occurring?

To scale this problem, we store queries associated with threat actor activity as Rules.

In the simplified example above, a ruleset is a set of rules built by a Detection Engineer. A querying service retrieves the set of rules and executes the queries within it.

Detection rules can execute on a fixed schedule (e.g., every 5 or 30 minutes) or in near real-time as logs are ingested. This varies by the SIEM technology the organization uses.

The same steps happen in the SIEM; if the query contains valid search parameters, such as an index that exists, it’ll look for it in storage. Once retrieved, results are sent to the analyst. This can be an alert if results are available, or it can be nothing if no results are found.

Conclusion

Understanding why rules matter as a scaling mechanism for a security team is an essential concept in threat detection. Encapsulating human knowledge inside dozens to hundreds of detection rules helps relieve analysts of the operational burden of searching for malicious activity. Additionally, it frees up analysts so they can orient themselves, tune their knowledge, and share it with others.

A SIEM is a critical component to many blue team functions, and seeing how logs are stored in a technology that can ingest logs, perform fast searches, and present other necessary metadata makes finding threat actor activity nearly instantaneous.

No system is perfect, though, and in the upcoming issues we’ll be studying types of rules (with some real-world examples) and comparing and contrasting alerting strategies.

Stay tuned!

Icon attribution

https://www.flaticon.com/free-icon/log_1960242?term=log&page=1&position=1&origin=search&related_id=1960242

https://www.flaticon.com/free-icon/database-storage_2906206?term=database&related_id=2906206

https://www.flaticon.com/free-icon/index_6639076?term=index&page=1&position=1&origin=search&related_id=6639076

https://www.flaticon.com/free-icon/user_456212?term=user&page=1&position=1&origin=search&related_id=456212

https://www.flaticon.com/free-icon/prescription_4864896?term=rule&page=1&position=25&origin=search&related_id=4864896

In my opinion, without understanding the context of where this field fits into a broader cybersecurity strategy, you won't necessarily understand what it takes to be successful.

Still, by the end of this post, whether you are a seasoned professional or want to break into the field, you should have a good idea of how a Detection Engineer can help bolster security operations teams big and small.

So what is a Detection Engineer?

Detection Engineering is a relatively new name for a concept that has evolved over decades in cybersecurity. Blue teaming has been a core tenet in cybersecurity defense and has remained largely unchanged in its function for the business. When you are concerned about threat actors attempting to gain malicious access to your network, you want a blue team to defend against such an attack.

A Detection Engineer works in defense alongside a broader blue team, but with a special focus on detecting when a threat actor infiltrates and moves within a network. You may read or hear this in other terms, such as “Threat Detection”. This infiltration can be the result of any number of attacks, such as:

• Phishing for credentials and logging into an internal email client

• A user downloads a malicious file to their device after searching for a "pirated" version of the software

• A corporate device listening on the Internet has a vulnerability that a threat actor exploits

Once the attacker is "in," that's where Detection come into play. Each of the three scenarios I listed contains three parts: An asset, an attack, and a circumvented control. A Detection Engineer should know:

• The assets they are tasked to protect

• The set of controls on that asset

• The attack surface once that control is bypassed

The best way I like to explain Detection is through the broader lens of the NIST Cybersecurity Framework (CSF) model.

At the core of any cybersecurity function, you'll be operating in a series of states and functions within the above model.

• Identify: what assets do we own, and who owns them internally?

• Protect: What controls do we have in place to protect those assets?

• Detect: How do we detect when a threat actor circumvents our controls?

• Respond: How quickly can we respond, contain, and eradicate the threat we detected?

• Recover: How do we become operational and return to Identify, Protect, Detect, and Respond?

• Govern: How healthy is our program?

The modern Detection Engineer primarily focuses on the "Detect" function within NIST CSF. There are cases where a team is small, and the Detection Engineering team is under "DART," Detection and Response Team, so you'll mostly see them operating in these two phases of the lifecycle. There are cases where a Detection Engineer is part of a large security organization and delivers their detections to a Security Operations Center.

How does a Detection Engineer, well, detect?

The primary objective that any Detection Engineer should concern themselves with is: when control fails, what is the fastest way to Detect malicious activity? I like to think that malicious cyber activity adheres almost perfectly to Locard's Exchange Principle:

"Every Contact Leaves a Trace."

There is no detection without telemetry. Telemetry is data generated by the assets you've identified in the "Identify" phase of the NIST CSF. This telemetry is a record, or trace, according to Locard, of activity and is typically in Logs.

Every Detection Engineer should understand that there is no Detection without Telemetry.

If there is no detection without telemetry, then there is no telemetry without assets. A Detection Engineer is a specialist in obtaining, understanding, and integrating asset data and its associated telemetry to facilitate Detection and Response. In the context of the NIST CSF, you can see how the state of "Blue Team" affects how Detect & Response functions. I call these states "Loops".

• Loop 1 is the ideal state. A blue team function understands the assets in their environment and implements controls to eliminate classes of attacks and vulnerabilities.

• Loop 2 serves as a hedge against the failure of Loop 1. You may have the best lock on a door, but if the attacker has a sledgehammer, you'd want to set up security cameras and an alarm system as a hedge against that sledgehammer. This is the value proposition of what we do in Detection Engineering

• Loop 3 is executed only when Containment fails to mitigate the adverse impact of a threat on the business in a meaningful way. These learnings should feed back into Loop 1 & 2

My advice to Blue Teams: Stay in Loop 1 as much as possible, exit Loop 2 as quickly as possible, and use Loop 3 to learn as much as possible.

The beautiful thing about Detection Engineering is that you have the opportunity to influence every aspect of the Blue team's function, as listed above, and virtually every part of the business. You can dive deep into a class of assets or threats, or you can span the Loop spectrum to make sure you can bolster controls, identify new assets, or learn from your gaps to create a better detection function.

How does one become a detection engineer?

As the leader of an organization with nearly 50 Detection Engineers, Responders, Threat Intelligence Researchers, and Security Researchers, I am frequently asked this question. Like in most of security, no one path guarantees a destination. There are subjects and technical concepts that I'll be exploring deeply in this series to help you move in the direction of a Detection Engineer.

That being said, I've personally reviewed 1000s of resumes applying to Detection roles in my org. I've personally interviewed hundreds of people for these roles and designed interview loops and panels with my organization to identify what we consider a "Detection Engineer" for my firm. So I have some thoughts:

• A Detection Engineer is comfortable with coding. At best, they can ship production-grade code, and at a minimum, they are comfortable with building basic and deploying microservices to perform security tasks

• Detection Engineers have deep security expertise in one or more areas. I typically only care about them being good at one of those areas, because the skills it took to become an expert are transferrable to other areas. Areas included but not limited to:

  • Operating System Security

  • Cloud Infrastructure Security

  • Computer Networking Security

  • Red Teaming and Pentesting

  • Security Incident Response

  • SOC Analysts

  • Threat Intelligence

• Detection Engineers have a customer mindset and want to collaborate to solve hard security problems. Since they primarily focus on Loop 2, they want to return to Loop 1 as quickly as possible. So that could mean they:

  • Work closely with an IT team to understand their asset inventory

  • Inform the vulnerability management team how attackers are exploiting current vulnerabilities to bypass controls

  • Design the perfect alert experience for SOC analysts that are precise, actionable, and not false positive prone

  • Automate hunting and containment tasks for incident response so they can move to Containment as fast as possible

Conclusion

Detection Engineering is an exciting and rapidly evolving field that I've had the pleasure of seeing form since I started in security in 2012. Businesses and organizations are adding more products, assets, and functionality to their day-to-day operations, which means the attack surface grows linearly with these additions.

If you want to be a detection engineer, your job is to understand the fundamental truth of organizational growth and utilize your expertise, relationships, and curiosity to scale your blue team in tandem with that growth.