STIX 2.0 Specification Questions

Hey all,

In reading through some of the comments to the documents we surfaced a couple questions that need to be talked about more publicly:

Can you have a relationship with a source or target of a relationship/sighting? Or do relationships only really make sense between domain objects?

One of the use cases that was noted is if you want to say that one relationship is a duplicate of another relationship. You would then have a relationship, with a name of “duplicate-of” and a source/target of other relationships.

On the other hand, it seems to complicate things and might be nice to avoid, at least for 2.0 if we can help it. Is that use case (or any other) really strong enough to allow it?

Do we need a line in the specification to indicate that ID references between objects MUST always be resolved to the newest version of the object?

Right now, we have text in the IDs and References section which says this:

ID references resolve to an object when the value of the ID reference property (e.g., created_by_ref) is an exact match with the id property of another object. If an ID reference resolves to an object for which multiple versions exist, the reference MUST be resolved to the latest available version of the object. ID references MAY refer to objects to which the consumer/producer may not currently have. This specification does not address the implementation of ID reference resolution. (https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#)

Note the sentence in red. We added that a couple weeks ago because some people felt it was not fully specified to resolve an ID reference to an object…they felt that ID references should implicitly always resolve to the newest version of the object. On the other hand, Allan has said that resolving ID references within a tool is a function of that tool and we should not have normative requirements around it. Some tools may want to resolve it to all versions of an object and show the full history, others may show the newest, etc. His full comment is available in the google doc.

So the question is…should that sentence remain in the document? If so, is it a MUST requirement or a SHOULD requirement?

Is there an important distinction between a COA “mitigating” something and a COA “remediating” something, and is that distinction well-understood?

The initial COA proposal from DHS (and a follow-on proposal from an OpenC2 participant) suggested that rather than talking about a COA “mitigating” a malware or vulnerability as the ONLY option, we should talk about “mitigate” as a temporary fix and use “remediate” to mean complete fix. As it stands now, we use “mitigate” to refer to both.

Should we add “remediate” in as a distinct option from “mitigate”? Is the difference between those two terms well-understood, clean, and relevant for cyber threat intelligence sharing?

I have my own opinions on the above topics, but I’ll wait until we have some discussion first.

We also made one change based on feedback that I wanted to bring up on the list. We used to have a line saying that the created field on an object couldn’t change across versions of an object unless the object creator was correcting a created by date. Allan pointed out that in that case, you likely just want to create a new object because updating the created date might break many implementations and is just weird to change. So, we changed that line to say “The created property MUST NOT be changed.”

If you think that’s wrong, please let us know.

Thanks,

John

cti-stix message