Security Tools: Coverage vs Detection Engineering Gaps

Let’s assume that the SOC has built a SIEM with a core set of data sources to provide security alerts. The SOC is now likely seeing a plethora of alerts from EDR and NGFW stating that the security controls identified and blocked malicious or suspicious behavior. The SOC processes dozens of these alerts like this a day, with similar outputs: closed and resolved by the reporting security tool.

Security tool product managers are incentivized to minimize False Positives (FP) and False Negatives (FN). This creates a reality for the SOC where, if a tool alerts on something with a high enough confidence level then the tool can take a response action. What is the next step from here? We have to look at “telemetry,” which we define here as: logs, metrics, or events from IT and security tools that provide insight into the operations of a system. This is where we find visibility into the coverage gaps left by security tool alerting.

As we discussed in the previous blog, many attackers are utilizing defense evasion techniques and “Live-off-the-Land” (LotL) tactics to maximize their effectiveness and minimize the chance of being detected. Many sophisticated MDR services have learned how to identify these techniques:

• Crowdstrike noted 75% of their detections were malware-free, meaning the attacker used LotL Techniques (Crowdstrike 2024 Global Threat Report)

For Security Operations centers without a team of event and intelligence analysts it is possible to provide some of the same insight and detections as the well resourced MDRs.

The process is straightforward, but it does take some experience and understanding of Cybersecurity Threat intelligence (CTI) and the MITRE ATT&CK Flow tool can provide an effective starting point. Here we will provide an overview of the approach and in the next blog we will do a deep dive on a specific use case from Threat Modeling to detection engineering. The steps are as follows:

1. Use Case: Identify a Use Case (Business Email Compromise - BEC) or Threat Attack to model

2. Infrastructure: Understand the infrastructure that would be affected (For a BEC use case the focus would be email infrastructure, e.g., M365 or Gmail)

3. MITRE ATT&CK Flow: Utilize the MITRE ATT&CK Flow or MITRE ATT@CK Navigator - tool to model a BEC attack (Example of StarBlizzard) 

4. MITRE Defend: Translate the enumerated techniques and tactics to security tools (MITRE D3FEND) 

5. Identify Detections: Identify security tool detections

6. Telemetry: Identify useful security telemetry (logs, events, and data)

7. Utilization of Telemetry: Consider ways of isolating the relevant telemetry

1. Correlation: a series of events

2. Contextualization: events on specific applications or systems

3. Behavior: Unique or unusual conditions in the event

8. SIEM Implementation: Develop and codify those events in SIEM platform

9. Playbook Information: Develop playbooks for monitoring and reviewing those events, in some cases human review will be required.

This is an esoteric process to improve the alerting and detection for techniques specifically designed to evade detection or LotL. In the next blog we will dive deep into a scenario and take it through detection engineering for implementation.