Written by Sam0x90

Which detection rules for my SOC?

Throughout my (young) career, I’ve seen many different SOC projects and I thought I should share what approaches have more chance of success. So here are some approaches that might apply well in your environment… or not.

  1. The “collect everything” approach
  2. The Business case approach
  3. The MITRE ATT&CK coverage approach
  4. The Intelligence-driven approach

I also wanted to share some great resources to build use cases, which you can find at the end of this post.

The “Collect everything” approach

By far the least effective I’ve encountered. After implementing their SIEM and (over)confident in their solution, many think that it’s finally time to collect logs. Unfortunately, it very often ends up with a big database of logs and very poor detection capabilities. Oh yes you’re filling in your SIEM, so that the vendor can charge you with the correct licence price but this is not helping you improving your detection. In fact, being overwhelmed with logs can often lead SOC analysts to fail in their job, in particular Tier 1 analysts. What use case should I create first? Shall I start hunting in those logs, but which data source? etc.

Definitely not the approach I would recommend as I’ve seen many SOC failed because they were focusing on collection instead of risk mitigation. In the end, security is pure risk management.

The “Business case” approach

A very good approach to start building a SOC is to focus on business case. Yes it sounds a bit like a consultant bullshit approach and you will have to wait before digging into logs. However, it’s one of (if not) the best approach you can use to build SOC capabilities.

Depending on what has been sold to Management, you should start by defining business cases or risk scenarios that you want to be covered by the SOC. Those scenarios should preferably be an output of your risk management practice. For example, audit findings can help. Try to stay high-level and define the data sources you’ll need. The following is an example of what should be defined

PriorityScenarioGoalExampleData source
1Data exfiltrationDetection of potential exfiltration of confidential data that may lead to loss of confidentialityExfiltration of client data via DNSDNS logs, NIDS, etc.
1SabotageDetection of sabotage activity that may lead to loss of availabilityRansomware hitting the critical file serverObject access Windows logs, etc.
2Unauthorized accessDetection of potential unwanted access that may lead to a loss of confidentiality, integrity and/or availabilityBruteforce on external VPNVPN logs, etc.
Business cases definition

As we can see here, we already have defined the priority of implementation as well as the data sources needed to cover those scenarios. Adding the dimension of effort required may be a good idea (NIDS vs. windows logs might not required the same effort) to adjust priority in addition to the imposed deadlines.

With this approach you can quickly demonstrate the value of the SOC and from there you can build maturity by adding use cases that are covering your scenarios.

The MITRE ATT&CK framework coverage

Thanks to MITRE, SOC have now a way of demonstrating the coverage of their detection capabilities. The killchain model is now well understood and has been split into techniques by MITRE. This framework is helpful to understand and demonstrate your detection maturity level.

Use the ATT&CK navigator to define what tactics and more specifically what techniques you are covering within your SOC: https://mitre-attack.github.io/attack-navigator/enterprise/

Let’s take the example below where:

  • Green cells represent techniques covered with advanced use case(s)
  • Blue cells represent techniques covered with mature use case(s)
  • Yellow cells represent techniques covered with basic use case(s)

We can observe here that the Data Exfiltration tactic is not covered at all, so the focus for Threat Content Developers should be on this tactic first.

Though this is a good way to ensure you are covering the different tactics, it’s easy to reach a step where you have to prioritize techniques between each others and the simple “coverage” approach doesn’t help you in that way. In addition, you could end up focusing on very specific technique very rarely used by attacker and missing more important ones.

The Threat Intelligence-driven approach

Still based on the MITRE ATT&CK framework, this approach helps to tackle the problem of the previous one, where techniques shall be prioritized between each other. By using threat intelligence (the true one, not just IoC), you could prioritize, for example, techniques that are the most used by hacker tools (Cobalt Strike, mimikatz, Impacker, etc.) or the most used by top 10 malwares (Qakbot, Agent Tesla, Emotet, etc.).

This approach requires a certain level of threat intelligence maturity, therefore it’s not an easy approach to start with.

Some tips and resources to start

Here some quick tips that might help you

  • Use Git and a KB for storing use cases and their documentation. In the end documentation is more important than the detection itself
  • Make backups!
  • Use metadata whenever you can while creating use cases
  • Tag your rules with MITRE ATT&CK techniques
  • Add description or external reference to add context for the SOC analysts when an alert triggers
  • Define a maturity score for your use cases based on the Pyramid of pain
  • Start simple even if not perfect. (Better to detect a file named “mimikatz.exe” than waiting 12 months to detect lsass.exe dump)

Here are some useful resources for creating detection use cases (Updated June 2022):

Leave a Reply