Threat actors are constantly updating their tactics, techniques and procedures (TTPs). In response, security teams must also continue to evolve their ability to detect the latest threats to avoid exploitation of security gaps that can result in costly breaches. This process, called detection engineering, refers to the method of fine-tuning security technologies to better detect malicious activity.
Detection engineering is still a relatively new discipline within cybersecurity—even the most mature security teams are still figuring out how to get started or how to hit their stride in developing a sustainable, integrated detection engineering program. Luckily, there are technologies that can be helpful in establishing and streamlining the workflow for detection engineering. Specifically, many enterprise security organizations are turning to the complementary capabilities of breach and attack simulation (BAS) to optimize their detection engineering efforts and enhance the efficacy of their overall security program.
Below, we will discuss the purpose and importance of detection engineering as a means of reducing cyber risk and exposure to known threats. We will also highlight how BAS can be used to evolve and improve detection capabilities, enhance alert systems, and improve incident response workflows and efficiency. Finally, we will cover which types of organizations will benefit the most from BAS as a part of their detection engineering programs.
Many adversaries today are increasingly using living-off-the-land (LOTL) and fileless attack methodologies. The Crowdstrike 2024 Global Threat Report noted that 75% of the attack campaigns it observed in 2023 were fileless attacks. That’s up from just 35% in 2019. The Sophos 2024 Threat Report tracked LOTL attack campaigns at 86%.
LOTL and fileless attacks use built-in administrative utilities like SMB, binaries like Rundll32, and dual-use administrative and penetration testing tools like PsExec and Cobalt Strike. These tools have allowed adversaries to improve their ability to evade security controls—bypassing endpoint detection and response (EDR) solutions and endpoint controls—and then fly under the radar using LOTL and fileless attack behaviors.
While this behavior is tracked as TTPs, the real battleground is procedures. They are in a constant state of flux as adversaries innovate—and security teams are struggling to keep up. One example of this is the way both nation-state and financially motivated adversaries are using residential proxies to hide the source of traffic during their attacks in order to appear legitimate. The abuse of legitimate resources like this is a significant problem that makes detection incredibly difficult.
That’s why many security organizations are investing more resources in detection engineering teams that are focused on implementing tools, processes, and procedures to identify unusual or suspicious behavior that may indicate a breach or the presence of concealed threats within their computer networks and systems. Detection engineering has a general lifecycle that is comparable to that of the software development process but is specifically focused on developing detections, as noted below.
General Detection Engineering Lifecycle
Source: Snowflake
Throughout this lifecycle, detection engineers work in tandem with other cybersecurity specialists to examine and evaluate identified threats, refine algorithms and rules for detection, and continually enhance the overall security posture of their company. Specifically, detection engineers refine monitoring tools like intrusion detection systems (IDS), intrusion prevention systems (IPS), and security information and event management (SIEM) systems, amongst others, to monitor system logs, network traffic, and other data sources for warning signs of malware infections, data exfiltration, and other security gaps.
The process of detection engineering involves customizing deployed security controls with detections to identify advanced threats. Building and validating these custom detections is often a highly manual and time consuming process. When dealing with a small number of custom detections (think 10 to 20), the manual nature of these activities is manageable. However, as mature organizations begin to develop more sophisticated capabilities with hundreds of custom detections, the manual requirements quickly become tedious and time consuming.
Detection drift also becomes a serious problem when managing a large number of detections. We have seen organizations experience significant cybersecurity issues due to the fact that the detections they thought they had in place were no longer working as expected or that their alert pipeline—designed to promptly deliver alerts from security controls to incident responders—had broken in an unknown and undiscovered way. In order for a detection engineering program to be successful, it comes down to operational efficiency. Organizations need an automated and continuous way to monitor and test their detections, alert pipelines, and incident response processes at scale.
Breach and attack simulation (BAS) is quickly becoming a critical component within mature detection engineering programs based on its ability to support and enable the “Monitor” and “Continuous Testing” phases of the detection engineering lifecycle. BAS platforms leverage the TTPs used by cyber adversaries to continuously simulate real attack scenarios that proactively test the effectiveness of an organization’s security controls. When extended to detection engineering, BAS solutions like the SafeBreach platform can help enhance and optimize a program in a number of ways.
BAS enables detection engineers to more easily run advanced attacks or create custom attacks that can serve as a functional test of security controls to validate that detections are working as expected. Rather than reading a security control manual, creating a policy, creating detection logic, and hoping it works, detection engineers can leverage the 30,000+ attacks in the SafeBreach Hacker’s Playbook to simulate the behavior they are trying to detect to see how controls perform. SafeBreach Studio also provides the ability to modify existing attacks, create custom attacks, or utilize tools like threat intelligence, packet capture (PCAP), and Python scripting. These attacks can be run automatically, continuously, and at scale, reducing the manual effort previously required.
Once simulations are complete, integrations allow the SafeBreach platform to gather system logs from deployed security controls and display results directly in the SafeBreach console. As a result, detection engineers have a comprehensive view of how controls performed against the attacks—whether they logged them, alerted on them, etc.—without having to manually gather results from the individual controls. They are then able to understand if existing detection logic needs to be refined or if new logic needs to be created. Attack simulations can then be re-run to test updates once they have been implemented.
SafeBreach simulations test the entire alert cycle—validating controls function properly, logs are sent to the SIEM, tickets are issued to incident responders when appropriate, and all integrations are active—to detect issues that can create false positives or delay necessary response. The continuous nature of SafeBreach attack simulations means health checks can be run as often as desired and performance can be tracked over time, so breakdowns never go undiscovered and the entire pipeline is ready if a security incident occurs.
Within an enterprise IT environment, different zones, locations, and subsidiaries can have different policies or even completely different controls. Ideally, an organization’s alerts will work everywhere throughout that environment, but oftentimes that isn’t the case. SafeBreach enables continuous testing in multiple places within the environment and keeps track of all the data and results, allowing team members to focus on the parts that truly require their specialized skills.
There are a number of different ways BAS can be leveraged as a part of a detection engineering program. While any large organization or enterprise would do well to include BAS as a part of their process, some may find it to be more critical.
Some organizations may want to build a detection engineering program, but are daunted by the amount of time and investment it takes to stand it up. Many of these organizations rely on the out-of-the-box alerts that come with their security controls. These alerts tend to be one-size-fits-all detections that may not be relevant in all environments across the organization. In some cases, these detections might not even be enabled.
If an organization has these basic alerts set up and is looking now to fine-tune their detections to not only work with the equipment and the applications in their environment, but also for some of the activity in different zones, taking that next step into detection engineering is essential. Similarly, if the security team is looking to increase the fidelity and accuracy of an alert to the SOC, detection engineering is the primary way to do that. Finally, if the threat team is assessing posture or preparing to defend against particular threats, custom detections are a fantastic way to do that.
BAS can alleviate some of the workflow challenges that may otherwise prevent security teams from taking the important step to enable all of this functionality within the organization.
Even when a detection engineering process is fairly well-established, the continuous testing and validation that BAS provides enables detection engineering teams to focus on what’s important. Many large enterprises have hundreds and hundreds of alerts that their teams must manage on a daily basis. With such a high volume of alerts, teams may end up spending a large amount of time with maintenance and validation to ensure all alerts are still working. As a result, they have very little time to actually create new detections.
Enterprises and larger organizations whose environments are constantly changing often find that the alerting process breaks more frequently than expected. Once a team knows a break has occurred, it can take a week or more to identify the issue behind the break and fix it.
With SafeBreach, teams can run weekly or even daily tests to make sure their alerts are functioning as intended. If an alert is broken, teams can quickly find the issue leveraging the platform’s dashboards, allowing them to address the problem much more quickly.
Healthcare, finance, oil and gas, and other heavily regulated industries need to be able to detect and address security issues very quickly, or they risk losing sensitive data or control over important processes. This is particularly true in organizations that have converged IT/OT environments.
For these organizations, it can be hugely impactful to integrate BAS into their detection workflow. The SafeBreach platform has a wide range of integrations that can help enable this. These integrations are customizable and designed to be adjusted as needed to a particular team’s needs so effectively.
SafeBreach thought leaders recently sat down to discuss detection engineering and highlight how leading enterprises are leveraging BAS to optimize and enhance their existing detection engineering programs. Catch the full discussion below to gain valuable insight on leveraging SafeBreach Studio’s red teaming capabilities to prepare your organization against today’s evolving threats:
Ready to see how the SafeBreach platform can benefit your detection engineering program? Check out our detection engineering resources or connect with a SafeBreach expert today.