SubSubTechnique, Procedures and Mitigations/Detections

[catpipeless]

Wondering if it's possible to either create SubSubTechniques to further expand on procedure variations and their associated detections. Or possibly change the procedure cards to allow for multiple detection options? As it is I have to create new Techniques and then new subTechniques (which are actually procedures) in order for them to be associated with granularly implemented detections.

[isaisabel]

Hi @catpipeless,

It's not possible to nest sub-sub-techniques under sub-techniques under the ATT&CK data model. In ATT&CK, procedure examples are modeled as relationships of type uses from groups/software to [sub-]techniques. Technique and sub-technique objects themselves do not represent procedures. The ATT&CK Design and Philosophy paper is be a good reference for these ATT&CK concepts and how they're laid out.

If you want additional granularity my recommendation is to encode that in the markdown of the description or detection field itself. The ATT&CK team already does this in a few cases, for example T1203 enumerates some specific examples of the technique without breaking them into sub-techniques themselves.

It's also worth saying that we're working on changing how data sources work, which is part of the "detection" of techniques. This should provide additional granularity and flexibility to the detection information of techniques by giving data sources and data components real descriptions. See the following for more information:

• Data sources refactor blog post: Part 1 and Part 2
• Data sources issues for workbench: https://github.com/center-for-threat-informed-defense/attack-workbench-frontend/milestone/8
• Data sources STIX beta: https://github.com/mitre-attack/attack-datasources-stix-beta/

Hope this helps!

[catpipeless]

I like where the activity is going with modelling data sources and detection techniques, seems like a good way to incorporate some of the knowledge from the d3fend project.

While I appreciate the suggestion of just using the detection field this doesn't solve my problem. I am looking to associate specific detections (sigma rules) to technique variations, potentially a many to many type relationship, similar to how sub/techniques can be associated with mitigations now. This is primarily for the purposes of gap analysis and SOC documentation. I would like to be able to do this and preserve the relationship to the ATT&CK model for ease of use and interoperability with other projects.

In my opinion attack workbench seems like it could be a great tool to help orient defensive strategy and help prioritize, track and document operations and their output (hunt a variation, fix a detection, track a new variation that isn't covered by existing detections etc.). The kind of extensibility I am asking for here would help with this, though not sure if that is a shared sentiment or others have found better/easier solutions.

[isaisabel]

The unfortunate fact of the matter is that we can't do a ton to the data model itself to adapt to community needs. At the end of the day, this project helps ATT&CK itself build and distribute the official dataset, so we need to match the data model required there exactly. Any changes to the data model on this project need to exactly match the needs of the ATT&CK team and the official data model.

You're always welcome to recommend changes to the official data model or dataset (I would recommend emailing attack@mitre.org if you have suggestions) but those sort of things often take a long time to change given the complexity of the knowledge base.

You're always welcome to create a fork of this application with the extensions you need. Both the front-end and rest-api are reasonably well compartmentalized for the various object types so it wouldn't be exceptionally difficult to make changes if you are proficient with this tech stack.