-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MITRE ATT&CK mapping issues with current MISP-galaxy implementation - uuid not unique #308
Comments
The origin is pretty simple MITRE ATT&CK CTI. As MITRE decided to move to a STIX 2.0 model (which is a mistake IMHO), we basically converted the STIX files from the CTI repository into the separate clusters. Regarding the UUIDs, this is also another issue. We wanted to be sure that UUID will be kept consistent among the various export of the MITRE ATT&CK. They promise to do so. I fully agree that the common techniques should be kept together, I suppose the pivot ID should be more "TXXXX" external id than the UUID. Looking at the recent discussion in OASIS CTI TC about UUIDs in STIX 2.0, I'm becoming more reluctant to do what we did in the past: Assuming that data providers will provide consistent UUID over the long-run/term... IMHO, it was a mistake I won't do again. Maybe we should have a quick chat on how we should proceed with ATT&CK modelling especially ensuring safe transition between old/new release of the models, techniques and potentially new sub-techniques. |
Looking at it, it seems the easier would be to just consider the entities |
Following our call here was our current approach:
|
TODO:
|
I am currently working on a new version of the MITRE ATT&CK to MISP-galaxy convertor.
(which should be in one script and should also suppor the relationships natively)
The issue I'm encountering is with the
enterprise-attack
,pre-attack
andmobile-attack
common entities. They are included in each "domain/phase", but are referred by the sameuuid
. (as they are the same object)For example uuid
bef4c620-0787-42a8-a96d-b7eb6e85917c
. In the MITRE ATT&CK they are used in different bundles. (see below where count > 2)However MISP seems to have included this same object, split over different 'clusters':
This gives the impression that these objects are not identical, and will also break automagic correlations (and data-validation of unique uuids)
This was caused by the switch of the
mitre-intrusion-set
to separate clusters forenterprise-attack
,mobile-attack
.My question is therefore: why exactly was everything moved to those 3 sub-clusters?
Shouldn't some "common" things be kept together? (like: malware, tool, intrusion-set)
While we could still split some others?
I know such a change would require implementation changes in MISP. But right now this seems wrong as we are breaking the UUID concept. Now you can't rely on a UUID to be unique.
The text was updated successfully, but these errors were encountered: