In 2014 I'd written an article on the hard question of "Which SIEM use cases has most value/effect for the organization?" during my years in security I learned the answer to this question has been always "it depends".
Yes.. but what does it really depend on? well on:
- Business Context
- Business Content
Okay but how do I translate this to the use cases I want to built? Well you use:
- Your Threat model or models of choice
- Use case Management Process
- Use case Framework
To bring this all together I've created a diagram that proposes a 3-step approach that tries to answer the question "Which Prevention, Detection and Deception use cases have the most value/effect for the organization in terms of risk coverage?".
Proposed 3-step approach
- Collect, Identify and Prioritize Risks, Attackers, Software and Assets.
- Decide and Apply a “Threat Modeling Strategy” based on Attacker, Software, Asset or Risk-Centric Threat Models.
- Identify, Prioritize and Operationalize: Use Cases and Integrations.
Following these steps will help make your Prevention, Detection and Deception use cases a success.
The following diagram comes with a few caveats:
- Not all information might be available in the organization where you apply this approach to (all is best effort), it can also be the other way around some organizations might have even more information then currently described in the diagram (more information is always better).
- The threat models divided in the four major categories are an oversimplification as some models are combinations of different functions causing overlap between categories in some cases. The goal of every category is to emphasize the model's inherent primary bias.
- The definition of the Use Case Framework is stretched over Prevention, Detection and Deception Technologies.
- The Technology list is limited and is probably missing lots of additional technologies that didn't fit on the diagram (there for the "...*")
The attacker-centric Threat model bias
One of the key reasons I've created this diagram is that there seems to be an industry level bias emerging where an "attacker-centric" model (in specific Mitre ATT&CK) is the end-all and be-all of all detection use cases. Which creates a Asset, Software and Risk-centric blindspot. To tackle this, I recommend deciding on a "threat Modeling Strategy" to avoid such blind spots. I propose choosing a combination of "centric's" that tries to cover the threat landscape as best as possible (know your yourself and know your enemy is definitely a key strategic start point).
Some key points on choosing a threat model:
- No single Threat Model Methodology covers all dimensions of importance to it's maximum level.
- The quality and scope of threat identification differs among classes of Threat Model Methodologies.
- Not every Threat Model Methodology is equally well suited for finding all types of threats.
- Threat Model Methodologies exhibited substantial trade-offs among reported threats, potential false positives, and frequency of reporting in terms of complexity, time to execute and ability to automate.
For merging any type of Threat modeling combination into a Use Case Framework I recommend using The SPEED SIEM Use Case Framework. This specific framework use Mitre ATT&CK as attacker-centric threat model and for asset, software or risk-centric there is a directory structure that can facilitate any of the chosen threat models.
If you want in-depth comparisons of the different threat modeling methodologies please look at the following resources:
- Mitre - Cyber Threat Modeling: Survey, Assessment, and Representative Framework
- Carnegie Mellon University - Threat Modeling: A Summary of available methods
- Selin Juuso - Evaluation of Threat Modeling Methodologies
- International Journal of Pure and Applied Mathemati - Profiling Threat Modeling Approaches and Methodologies for IT and Cloud Computing
- Carnegie Mellon University - Evaluation of Competing Threat Modeling Methodologies
- Practical DevSecOps Awesome Threat Modeling List on Github
1. Make sure you do enough contextual and content based data collection before you start threat modeling.
2. watch out for the attacker-centric bias when choosing a threat model.
3. Use a combination of threat models that fit the organization and your cyber security objectives the best.