Detection Engineering Field Manual #1 - What is a Detection Engineer?

Why does Detection Engineering matter to a security org?

The purpose of this post is to describe the role of a Detection Engineer in cybersecurity. Instead of diving deep into things you've probably heard of, such as Rules, Alerting, False Positives, or Threat Hunting, I wanted to take a step back and describe the Why of a Detection Engineer.

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.