Does x_mitre_attack_spec_version need to be tracked on every object and every Workbench Mongo document?

[seansica]

Proposal:

• Stop tracking x_mitre_attack_spec_version on all objects
• Instead, only track x_mitre_attack_spec_version on either (A) the collection bundle, or (B) the collection index object

Tangential to this: is it necessary to track x_mitre_attack_spec_version on documents in the Workbench database? Even if we remove it from the attack data model, perhaps we can still benefit from updating the Mongoose models in Workbench.

---

Case for Keeping x_mitre_attack_spec_version on all documents:

• It is convenient for every object to be mapped (to x_mitre_attack_attack_spec_version) at the object level. You don't need the collection or bundle to glean which attack spec version the object is compliant with.

• Allows STIX/collection bundles to be more flexible by allowing objects to be heterogenous with respect to attack spec (i.e., objects may span more than one attack spec version)

• Aligns with the idea that Mongo documents should be STIX compliant at rest. They are easier to interpret, offer to end-to-end compliance, thus resulting in a more predictable data pipeline. In addition, the REST API getter endpoints would implicitly serve STIX-compliant data, and the compliance-enforcement/maintenance complexity would be more evenly distributed across the Workbench code base, thus reducing the complexity of the STIX export service(s)

---

Case for Removing x_mitre_attack_spec_version from all documents:

• ADM and other spec-sensitive software are highly dependent on the collection bundle. ADM cannot determine the attack version of a random object in a vacuum; it can only be inferred by conducting a spec validation test. This is inefficient.

• Object bloat: one could argue that we shouldn't specify a property that can be implied through a higher-order relationship.

• The majority of Workbench services/DAOs need not worry about maintaining spec compliance -- leave it to the STIX export service(s)!

• Forces each exported STIX/collection bundle to contain a homogenous set of objects with respect to attack spec: all objects in a given bundle will be pinned to the same attack spec version, making them cleaner, more predictable, more consistent, etc.

---

Other considerations:

• One of the chief benefits of using MongoDB is that documents are just JSON objects, and are therefore capable of being interoperable with STIX. This is a benefit specifically afforded from using NoSQL. By not keeping the docs compliant at rest, we're failing to take full advantage of MongoDB.

• On the other hand, if we migrate to RDBMS then DB compliance becomes irrelevant. If we think we might migrate away from NoSQL in the future, then we should avoid expending effort making DB docs compliant, since that will just be nullified upon migrating platforms.