Object IDs are optional at the moment. This restriction is fine if the object is always embedded within another Object, but this becomes problematic if the Object needs to be referenced at a later date. This could be due to a mistake being made and the wish to revoke something published, sudden awareness that a small outbreak is bigger than first thought (so need to reference Object originally embedded) or similar.
With the present optionality of Object ID it is difficult to always be sure that objects can be referenced in the future, which impacts their reusability.
POTENTIAL ANSWER
A large number of the solutions proposed in this document rely on an Object having a referenceable the Object ID, that Object ID staying the same through the lifecycle of the Object, and the Object ID containing a namespace that resolves to a domain name in some way so that consumers can ‘lookup’ objects based on their IDs (if permitted).
Object IDs are essential to enable the piecing together of the sequence of events, or to do analysis focussing on the way that attackers operate. This is key to understanding the Tactics, Techniques and Procedures that attacker’s use, which in turn is highly useful for linking malware with the Threat Actors who create and use them. If a consumer does not require an Object ID they can simply ignore it. The impact of a consumer to not ingest the Object ID is far less than the impact of not having the Object ID in the first place.
There is one place that I’ve heard ID shouldn’t be required – and that is the STIX_Package itself. Since STIX v1.2 the STIX_Package is effectively a container that all the other STIX objects are contained within, then it is effectively a ‘throwaway’ object, meaning that we should require an ID if we are just throwing the object away. That said – if we do pursue the idea of the STIX Request/Response object as described in section 6 then we will need to identify the STIX Request so that the Responses can be matched to it – so maybe keeping STIX_Packages with an ID is acceptable if we are allowing STIX Request/Responses.
PROBLEM
Object IDs are optional at the moment. This restriction is fine if the object is always embedded within another Object, but this becomes problematic if the Object needs to be referenced at a later date. This could be due to a mistake being made and the wish to revoke something published, sudden awareness that a small outbreak is bigger than first thought (so need to reference Object originally embedded) or similar.
With the present optionality of Object ID it is difficult to always be sure that objects can be referenced in the future, which impacts their reusability.
POTENTIAL ANSWER
A large number of the solutions proposed in this document rely on an Object having a referenceable the Object ID, that Object ID staying the same through the lifecycle of the Object, and the Object ID containing a namespace that resolves to a domain name in some way so that consumers can ‘lookup’ objects based on their IDs (if permitted). Object IDs are essential to enable the piecing together of the sequence of events, or to do analysis focussing on the way that attackers operate. This is key to understanding the Tactics, Techniques and Procedures that attacker’s use, which in turn is highly useful for linking malware with the Threat Actors who create and use them. If a consumer does not require an Object ID they can simply ignore it. The impact of a consumer to not ingest the Object ID is far less than the impact of not having the Object ID in the first place.
There is one place that I’ve heard ID shouldn’t be required – and that is the STIX_Package itself. Since STIX v1.2 the STIX_Package is effectively a container that all the other STIX objects are contained within, then it is effectively a ‘throwaway’ object, meaning that we should require an ID if we are just throwing the object away. That said – if we do pursue the idea of the STIX Request/Response object as described in section 6 then we will need to identify the STIX Request so that the Responses can be matched to it – so maybe keeping STIX_Packages with an ID is acceptable if we are allowing STIX Request/Responses.