In any security program, the fundamental goals are the same: increase the scale, predictability, and reliability of the program while maintaining security controls. But as your organization and security needs mature, investing limited resources in the right place can prove as challenging as setting a risk threshold.
In this blog, you’ll take a closer look at developing a dedicated detection engineering (DE) function within your security program. You’ll understand the business case for this role, how to support it, and how to know when your team is ready to prioritize dedicated DE.
It may seem like dedicated functions are reserved for larger businesses with more resources and greater need, but smaller security teams can actually benefit from implementing a dedicated detection engineering function, and its counterpart, incident response.
Why? Because scaling threat detection is a requirement by today’s standards. Teams must secure highly complex, distributed systems, and deal with the ever increasing velocity, volume, and variety of security data to identify and stop threats, and this is what a dedicated DE function does—builds systems that scale by applying software engineering best practices to threat detection.
This is also the reason why detection engineering began to differentiate about 3 – 4 years ago. While developing threat detection content is not novel in SOCs, DE is not quite the same. On top of developing and optimizing detection content, detection engineers implement automation that eliminates toil, develop reliable data pipelines, and refine the detection development lifecycle to reduce human error, enforce consistency, and speed up the cycle while maintaining accuracy.
Just like cloud took over on prem, DevOps paved the way for an Everything as Code (EaC) mindset, and best-in-class security tooling evolved over the years—from IDS, SIEM, SOAR, XDR, and now onto hyperautomation and AI—detection engineering is becoming a standard role necessary to keep up with increasing security needs.
So a dedicated DE function is not about if, but when.
Going over the difference and collaboration between three common roles in security will clarify DE and anchor later discussion.
A security engineer (SE) designs, implements, and maintains an organization’s security infrastructure, including firewalls, intrusion detection systems, and encryption protocols. They conduct security assessments, create policies, automate security systems, and continuously monitor and update systems to protect against breaches. A security engineer does work that’s broader in scope in comparison to DEs, though there can be overlap. On small teams, you’ll often find SEs doing both detection engineering and incident response work.
Detection engineers implement, automate, and optimize tools to identify security threats, working with the likes of SIEM, SOAR, and EDR. They set up data pipelines for log monitoring, write and maintain detection rules and alerts, and refine mechanisms to reduce false positives and negatives. They collaborate with incident response (IR) teams to ensure accurate and effective threat detection.
Security analysts typically work on IR teams that manage and mitigate security incidents. They contain, eradicate, and recover systems from breaches, conduct forensic investigations, and are knowledgeable in attacker tactics, techniques, and procedures. They rely on the infrastructure from security engineers and detection mechanisms from detection engineers.
Together, these roles form a feedback loop that enhances security measures and detection accuracy, creating a cohesive and proactive security strategy.
If you’re like most security teams, the reality is that you have 1–2 people doing the work of all three roles, and a dedicated DE role is not only unrealistic, it doesn’t meet the needs of your organization. This makes sense.
For larger teams or those reaching a growth phase, the simple answer is that your SOC would benefit from investing in a dedicated DE role sooner than later.
It’s too soon for a dedicated DE function if you do not have threat models for your environment with clear threat detection priorities. This is fundamental for coordinating work and making meaningful, incremental gains for your security program.
Otherwise, create a roadmap to a dedicated DE function and move along it:
The success of a dedicated detection engineering function is supported by a strategy that spans people, processes, and tech—also known as PPT, a classic framework for driving change and operational success. So let’s review each of these categories to understand how to support dedicated DE.
When it comes to developing a dedicated DE function, you can hire out or develop your current talent. When hiring from outside the org, the benefit is gaining a skilled worker, but a challenge is finding suitable talent given the skill shortage within cybersecurity. This can make upskilling staff a more realistic option that can have the positive benefits of boosting employee satisfaction and being more time and cost effective.
A detection engineer needs to draw from three skill sets, which are also typical feeder roles for DE: security analyst for understanding adversary behaviors, software engineer for coding best practices and GitOps, and cloud infrastructure engineers for scaling the threat detection platform.
When upskilling your staff, the conversation should not pit analysts against engineers in terms of who might be more qualified; it should be about upskilling across the board, plain and simple. It’s well known that there are a range of pathways into cybersecurity, and with DE this also holds true. Keep in mind these tips when upskilling your team:
Supporting a dedicated DE function is about defining reliable and repeatable processes that yield quality detections and scalable threat detection. Any process you define needs to include DE’s key partnerships, threat intelligence and incident response.
Threat intel is the input for detection engineering, including your threat models and any findings from threat hunting, red teaming, and compliance. Better defining threat intel inputs leads to detections that are easier to scope and develop. For example, defining a specification with up front information requirements eases translating threat intelligence into detection content.
Incident response and detection engineering work more closely together. DE needs to build detections with incident response in mind by developing detections with clear use cases and effective runbooks. Detection quality needs to be assured through consistent testing and requiring IR review and approval before shipping new detection content. Finally, IR experience of alert and detection quality in production needs to be tracked and returned to DE to optimize detections and close the feedback loop.
These partnerships and processes should be clearly captured in a repeatable detection development lifecycle that defines development across inception, management, and retirement. The lifecycle should identify collaboration with key stakeholders as well as key metrics to track across the lifecycle to drive detection planning and optimization.
A dedicated detection engineer can optimize detections, alert fidelity, and data pipelines, but the scalability of your threat detection is inherently limited by your tech. If your SIEM is inflexible, your threat detection will be as well. And if your SIEM doesn’t have SOAR capabilities built-in or your org doesn’t have a SOAR, you simply won’t be able to automate incident response.
For many, changing tech may not be realistic in the short term, even with less than perfect tech. Regardless, it’s important to regularly assess the tradeoff of sticking with what you have versus moving to tech that supports your team. So here’s what to look for when evaluating your SIEM:
For a more in depth treatment on each of these topics, read Jack Naglieri’s post 5 SIEM Capabilities for Detection Engineering. When all is said and done, choosing the right tech stack is about enabling the scalability and flexibility that allows teams to do more with less and stay agile in the ever changing cybersecurity landscape.
As major cybersecurity players move towards platformization with greater risks of vendor lock-in, others are responding by envisioning modular security architecture that frees security teams to pursue the best in class solutions, specific to their needs.
As these futures unfold, detection engineering will continue to evolve as a central role in building automated and scalable threat detection. With AI inching towards becoming a commodity, some are envisioning a future in which DEs train AI models to do complex threat detection and analysis. What do you see for the future of threat detection and response?
Panther is the leading cloud-native SIEM that enables detection engineers with code-driven workflows to automate detection and response at petabyte scale. Request a demo to see a proof of concept for your detection needs.
