As cyber threats grow more sophisticated, the need for a robust defense strategy becomes paramount in an attempt to stay one step ahead of threats. This is the world detection engineers live in, moving beyond traditional security measures and engineering strategies to detect advanced adversaries. Whether a seasoned professional or a beginner to the field, it’s important to understand detection engineering and its proactive approach to resilient defense in an organization.
What is Detection Engineering?
At its simplest form, detection engineering is the creation of sets of threat detection rules that define specific patterns, behaviors, and Indicators of Compromise (IoCs) that may indicate malicious activities. A lot of SIEMs these days come prepackaged with sets of rules for popular log sources that are ready to go out of the box. Many organizations use that to “check their box” and go on assuming all should be covered. But it’s not that simple, I can tell you that much. If it were that simple, there wouldn’t be news of organizations getting hacked every single week. That’s why there’s still adversaries out there that exist, malware continues to be a consistent threat, and why the SOC is bombarded with false positives every single day. As a detection engineer, you need to put yourself in the mind of a hacker in order, and use your knowledge to set up rules, policies, and playbooks to help defend your organization. Here are some processes I use for identifying and engineering these detections:
Data Collection & Analysis
One of the simplest ways to begin developing your detections is to analyze the logs you are collecting (likely into your SIEM). This takes some deep thought and purposefully diving into the logs to analyze the different columns and understand what is happening in the environment. What behaviors are triggering these logs? What specific activities are being picked up? Is there anything an attacker may be attempting to accomplish that could trigger one of these logs? These are some questions you need to be asking yourself as you’re gaining a deeper understanding of your environment. Think about what an advanced threat may be trying to accomplish and how you can catch them slipping up.
Documentation
Another way is to dig into the log source documentation. This will provide a high level analysis of what the logs may look like, and can provide guidance when digging into ingested logs. However, I’ve found it to really only be helpful for just that. While a good starting place, I’ve found it difficult to develop meaningful detections just from online documentation.
Threat Hunting
Threat Hunting is an advanced technique that moves beyond the traditional security measures and reliance on simple, predefined rules. As a detection engineer, threat hunting is an exercise of actively seeking out potential threats that may have evaded detection, but is also a proactive process aiming to uncover and identify vulnerabilities or gaps in monitoring. This deep dive introduces a dynamic element to detection engineering by actively seeking out both known and unknown threats. Integrating this exercise into your detection lifecycle fosters a more resilient and proactive cybersecurity posture.
Threat Modeling
Threat Modeling is a more systematic approach to identifying and evaluating security risks in your environment. It involves analyzing the different components of a system, how the data flows between them, and identifying gaps of knowledge in the attack surface. The goal of this exercise is to proactively design security measures for different systems based on the evaluation of the current configurations. This is an advanced exercise that generally involves a deeper understanding of the systems in place and a lot of collaboration, but the byproduct of these discussions often point to opportunities for additional detections.
Why do I need Detection Engineering?
Detection engineering is the backbone for organizations in decreasing attack surface through proactive threat identification. The idea is to catch any security threats before they can escalate into major incidents. Every company, especially online first companies, are in danger of cyber threats. Every organization dealing with valuable data of any sort NEEDS detection engineering, and it is crucial not to ignore it.
Disregarding detection engineering would be equivalent to being blind folded, spun around in a circle 10 times, and then being told to point and shoot a target… while still blindfolded!
As I mentioned before, basically every SIEM on the market comes preloaded with detections and rules that are ready to go as soon as this system is deployed into your environment. I’m not going to claim that these are useless, because they’re not, but they’re going to provide you with very basic monitoring of your attack surface. These are going to be detections that could be spotted from a mile away, and can likely be identified by a quick skim of the SIEM documentation. Advanced attackers are going to know about these rules and decipher ways to evade them. Not only that, but in my experience, these detections are not tuned very well, and some trigger way too many false positives to be valuable. Often, a lot of these get to the point where you even disable them. Or, if they are not useful by themselves, you can always opt to downgrade them to informational to use as a “context alert” to craft more advanced detections. But sometimes, you just find yourself wondering “Who the hell wrote this and why?”
Seeing as detections are the first line of defense for your organization, employing detection engineers to build detections is essential for creating custom tailored alerts for your environment, and to tweak existing ones to fit better. Detection engineering provides early threat detection, resulting in reduced dwell time if a threat actor is found in your environment. Not only that, but experienced detection engineers can employ tactics to protect against those advanced threats when those adversaries evade your traditional software.
It’s important to consider that the “easy” part is infiltrating a company - there are so many avenues to approach this and as an attacker, and you only need to find one hole and you’re in. The difficult part is defending the company. Not only do you need to cover up these holes, but you need to employ tactics and processes to find all of them too. Not only that, but you never know if all of the holes are covered, if new ones are popping up that you’re unaware of, or if there’s one that was just plain missed. Detection engineering is a never ending process to make sure all avenues are being considered and mitigated.
What comes after the Rules?
Iterative Process
Detection engineering doesn’t just stop after writing the baseline logic and deploying to production. Nope. Just like anything, you have to give it time to run and make sure it’s behaving as expected. The logic needs to be tested a bit and ensure that the logic isn’t producing too many false positives, especially in those complex use cases. Detection engineering, in the simplest terms, is an iterative process. It’s important to constantly make note of how rules are performing, tuning to reduce false positives and combat alert fatigue, making sure they’re directly tailored to your environment.
SOAR
More advanced detection engineering teams will integrate SOAR development into their Detection Lifecycle. It’s here where you can begin to give analysts full context around alerts that do trigger, providing them with automated workflows to kick off their initial triage process. I’ve covered some basics about SOAR in previous articles, and will be covering more in the future, as it is a complex process of its own inside the detection lifecycle. But, its value truly cannot be overstated.
Incident Response
The last piece to the puzzle would be Incident Response planning and playbooks. With every detection, comes a documented triage process to ensure that no malicious activity is actually occurring. Having a document to reference is helpful in ensuring swift mitigation, but also for onboarding new members to the team. A successful Incident Response playbook will detail the triage steps to take, document queries to run, list relevant teams to communicate with, give the basic criteria that should be met to mark the ticket closed, and record how to escalate the ticket in the case of an incident. Although some may overlook playbooks, thinking it may be trivial to know what to do, it’s an integral part of triaging alerts, and should be an interwoven process in detection engineering.
What do I get from Detection Engineering?
Detection Engineering is a sometimes overlooked sector of cybersecurity, but nonetheless, important in fortifying organizations. This iterative and proactive approach addresses the complex issues of understanding malicious actors, identifying the attack surface, and mitigating threats. Detection engineering has cemented itself as the backbone of Security Operations teams, and plays an instrumental role in protecting sensitive data for organizations, and at the end of the day, protecting the overall reputation of your brand.
Thanks for joining us in the Cybersec Cafe to learn more about the benefits detection engineering brings to organizations! Subscribe below to stay tuned to continue to learn more about the ever-evolving cybersecurity landscape and more exciting things coming from the Cybersec Cafe!
Comments