Detection & Validation
Detection is the third part of this series and for a very important reason. Not because I saved the best for last (this post might not even be the last part!), but because the first two parts frequently get skipped over in favor of the question “what SIEM rules are available?” Detection helps describe what exists in the expansive grey area between alerts and general telemetry. Detection is incredibly powerful but requires a number of building blocks to even happen…some obvious and some less so.
Detection can potentially occur in a lot of different parts of your environment, such as creating behavior rules within EDR products, but those findings should generally roll up to a centralized data store such as a SIEM. As a general rule of thumb, it’s best to focus on the SIEM’s detective capabilities, rule language, and nuances only to expand and fill in gaps that might arise from performing that analysis. For example, it might not be reasonable to send all process execution logs from your EDR to your SIEM, so detection would necessitate utilizing EDR detection capabilities and sending the subset of alerts to a SIEM.
The activity described above aligns closely with the first part of this series: understanding visibility. Good detection will only occur where you have good visibility. Ultimately, like with visibility, the focus on what detections are created should be determined by the quality of the logs, which provides visibility into the most common types of attacks. And then work outward to other use cases. Organizations that only create detections based on the logs they have now and do not work to expand their visibility capabilities will truly only be creating detections for a subset of threats.
The next challenge is knowing what to detect. This was the most daunting challenge when I was starting out, and I believe it is a shared experience. Gaining knowledge of offensive security techniques and defensive capabilities presents a unique challenge for the industry as a whole. This is where I believe MITRE ATT&CK has provided the most impact on cybersecurity by creating a common language for these two groups to learn from each other. Instead of needing to learn about specific exploits, the behaviors of those exploits can now be broken down into specific techniques (MITRE ATT&CK keyword), which defenders can reference to begin making their detections.
Now that we have an idea of techniques we want to create detections for, how should we begin to do so? It is very simple and easy to start with the out of the box detections for your SIEM platform or other technology. The platform might offer good insight into what is already being detected and what tuning activities should be taking place. Beyond that, cybersecurity is in an exciting place right now where research is openly being shared at a level never before seen and defenders are teaming up to create platforms/frameworks which enable security detections to be shared, applied, and tested to many different products and services. Many of these platforms and frameworks were designed with capabilities to include MITRE ATT&CK in all facets (which many product vendors have begun to adopt as well!).
For detection purposes, it is important to have strong working knowledge in Sigma. One might look at Sigma as a cheat code for providing free detections, but that would be taking a far too narrow approach. In fact, the most successful users of Sigma won’t stop with just the rules available but will have created tons of more rules in Sigma’s format that are suited for their environment.
The project has excelled at creating a standard for the necessary information that should be included with each detection created and providing the means to translate that detection to the platform of your choice with its ‘Sigma Converter’ feature. This helps narrow the gap of knowledge between learning how to create new detections in a platform and what to create detections for. With a strong understanding of Sigma, some outlets to enable the creation of more rules include following security researchers on Twitter (recommendations at the bottom of this post) and utilizing the Elastic rules repository.
Now we have an understanding of detections, how to create detections, and where to source knowledge/detections of new techniques/common attacks. The final piece of a good detection program is testing detections. When a detection is written, it is very common for the intent behind the detection to either miss the behavior entirely or create a flood of false positives because the detection was too broad.
The cybersecurity community has again provided for this need! One of my favorite tools to test detections is Red Canary’s Atomic Red Team and associated Atomic Test Harnesses. The tool provides a way to easily emulate behaviors of MITRE ATT&CK techniques which you can use to test your detections. By running a number of these simulated attacks, you can validate that your rules are detecting the behaviors which you were expecting.
For further reading, check out MITRE’s walkthrough on adversary emulation: https://medium.com/mitre-attack/getting-started-with-attack-red-29f074ccf7e3.
Additional tools for testing detections include:
The ideas outlined across these three parts are the building blocks for utilizing parts of MITRE ATT&CK to supercharge your security program and drive effective focus for visibility, prevention, and detection. A solid understanding of some of the ideas presented here will make it easier to address areas that need the most attention. Additionally, the creation of processes that should be followed when an attack occurs should be much easier. Plus, the understanding of where an attacker is in the ATT&CK lifecycle will be more apparent than before.
Recommended Twitter follows:
Originally published at https://johntuckner.me.