We need to rework how collections fit into a post release track Workbench world. "Collections" as a concept are a Workbench-ism. They are essentially a loose analog for STIX bundles that contain a custom SDO of type x-mitre-collection.
Workbench will continue supporting the x-mitre-collection object. Bundles exported via snapshot retrievals and graph manifests will contain x-mitre-collection objects at index 0 of the bundle's x_mitre_contents array.
Beyond this, there are many existing collection things that are now supplanted by release tracks.
Workbench coins the dichotomy between "Imported Collections" and "My Collections".
"Imported Collections" are essentially just STIX bundles that have been imported either via STIX bundle upload or via Collection Index. These are read-only, though objects contained in such collections can be added to native/local collections."My Collections" refer to STIX bundles that were initialized by Workbench itself. These are not read-only — users can add/edit/remove objects as they please. These are essentially statefully tracked STIX bundles that have a loose set of change control/release management functionality sprinkled on top.
Workbench must preserve the following features:
- Import STIX bundles: Workbench should be able to import STIX bundles into Workbench. There are two scenarios that require consideration:
- STIX bundles that have a valid
x-mitre-collection object.
- STIX bundles that do NOT contain (or contain an invalid)
x-mitre-collection object.
Without the x-mitre-collection object, Workbench must infer certain metadata characteristics about the incoming content. For example: Does the bundle have any lineage with other bundles that have been imported? Without the x-mitre-collections id and x_mitre_version, Workbench cannot intuit this. Thus, we need to decide whether non-collection-annotated bundles will be supported.
Incoming bundles map to the aforementioned "Imported Collections" concept. Workbench should track these collections in a central interface/section of the frontend. In practice this will translate to a backend call to the GET /api/collections/ and GET /api/collections/:id endpoints to retrieve a list of bundles that were imported and their member objects. Such objects should be write-protected. New revisions can be created, but the original imported instance should be read-only. Users can delete them by deleting the entire collection from Workbench.
There already exists a new release track endpoint, POST /api/release-tracks-create-from-bundle. It parses a STIX bundle and creates a new release track with member objects extracted from x_mitre_contents. This is analogous to converting an imported collection to a "My Collection" instance. This new workflow needs to be fully integrated into the frontend. Under the hood, what should happen is similar to the "imported bundle": contained objects should be write protected — with one specific caveat: the objects should be added to a new release track, meaning that the objects' workspace.release_tracks membership metadata will be modified to reflect their membership in the new release track. Once the object becomes cooked into the release track's members tier, it is no longer possible to delete the collection as doing so would break the release track's snapshot lineage. Thus, if a user wishes to purge the collection at some point after the POST /api/release-tracks-create-from-bundle operation, they would first need to delete the release track. Additional thought needs to go into the specifics of how the release track gets bootstrapped. For example, should the incoming objects get added to the new release track's candidates tier and leave the rest up to the user, or should they be added straight to members and a tagged v1.0 snapshot created to lock them in? We can possibly support both workflows by supplying query parameters and/or request body options. This will need to be workshopped.
Lastly, there is the collection index. This will remain supported. It is just a remote tracker for how/where to download STIX bundles. The downstream actions for downloading collections from the collection index will need to be remapped, and we will need to add an option to instantiate new release tracks from any of the indexed bundles. However, it's not exactly clear how the collection lineage will map. The official MITRE ATT&CK collection index tracks a distinct collection/STIX bundle for every official ATT&CK release. Because they all share lineage through a common x-mitre-collection identity, one can make the argument that importing them should translate to a single, unified release tracks with precisely one tagged snapshot per indexed bundle. How this will work in practice will require further workshopping.
We need to rework how collections fit into a post release track Workbench world. "Collections" as a concept are a Workbench-ism. They are essentially a loose analog for STIX bundles that contain a custom SDO of type
x-mitre-collection.Workbench will continue supporting the
x-mitre-collectionobject. Bundles exported via snapshot retrievals and graph manifests will containx-mitre-collectionobjects at index 0 of the bundle'sx_mitre_contentsarray.Beyond this, there are many existing collection things that are now supplanted by release tracks.
Workbench coins the dichotomy between
"Imported Collections"and"My Collections"."Imported Collections"are essentially just STIX bundles that have been imported either via STIX bundle upload or via Collection Index. These are read-only, though objects contained in such collections can be added to native/local collections."My Collections"refer to STIX bundles that were initialized by Workbench itself. These are not read-only — users can add/edit/remove objects as they please. These are essentially statefully tracked STIX bundles that have a loose set of change control/release management functionality sprinkled on top.Workbench must preserve the following features:
x-mitre-collectionobject.x-mitre-collectionobject.Without the
x-mitre-collectionobject, Workbench must infer certain metadata characteristics about the incoming content. For example: Does the bundle have any lineage with other bundles that have been imported? Without thex-mitre-collectionsidandx_mitre_version, Workbench cannot intuit this. Thus, we need to decide whether non-collection-annotated bundles will be supported.Incoming bundles map to the aforementioned
"Imported Collections"concept. Workbench should track these collections in a central interface/section of the frontend. In practice this will translate to a backend call to theGET /api/collections/andGET /api/collections/:idendpoints to retrieve a list of bundles that were imported and their member objects. Such objects should be write-protected. New revisions can be created, but the original imported instance should be read-only. Users can delete them by deleting the entire collection from Workbench.There already exists a new release track endpoint,
POST /api/release-tracks-create-from-bundle. It parses a STIX bundle and creates a new release track with member objects extracted fromx_mitre_contents. This is analogous to converting an imported collection to a "My Collection" instance. This new workflow needs to be fully integrated into the frontend. Under the hood, what should happen is similar to the "imported bundle": contained objects should be write protected — with one specific caveat: the objects should be added to a new release track, meaning that the objects'workspace.release_tracksmembership metadata will be modified to reflect their membership in the new release track. Once the object becomes cooked into the release track'smemberstier, it is no longer possible to delete the collection as doing so would break the release track's snapshot lineage. Thus, if a user wishes to purge the collection at some point after thePOST /api/release-tracks-create-from-bundleoperation, they would first need to delete the release track. Additional thought needs to go into the specifics of how the release track gets bootstrapped. For example, should the incoming objects get added to the new release track'scandidatestier and leave the rest up to the user, or should they be added straight tomembersand a taggedv1.0snapshot created to lock them in? We can possibly support both workflows by supplying query parameters and/or request body options. This will need to be workshopped.Lastly, there is the collection index. This will remain supported. It is just a remote tracker for how/where to download STIX bundles. The downstream actions for downloading collections from the collection index will need to be remapped, and we will need to add an option to instantiate new release tracks from any of the indexed bundles. However, it's not exactly clear how the collection lineage will map. The official MITRE ATT&CK collection index tracks a distinct collection/STIX bundle for every official ATT&CK release. Because they all share lineage through a common
x-mitre-collectionidentity, one can make the argument that importing them should translate to a single, unified release tracks with precisely one tagged snapshot per indexed bundle. How this will work in practice will require further workshopping.