I completely agree with Jasonâs points below.
I would also add that as we discussed in the mini-group.
The ability to âversionâ observable objects in STIX2.0, prior to these changes we are making in STIX2.1, was
only supported by versioning the containing ObservedData object. That continues to be an *option* for versioning.
So if anyone has actually implemented STIX2.0 for observed data versioning then that method *still* works.
However, with the introduction of SCO in 2.1, the options to consider how SCO are used and referenced have been expanded.
I suggest that interested parties should not hold up adoption of the agreed SCO changes in 2.1 because of this use case as it was not possible in STIX2.0 other than the method I describe.
Suggest that a SEP or similar approach to proving out the versioning workflow with SCO is appropriate while we continue with STIX2.1 adoption of SCO as soon as possible.
LookingGlass Cyber Solutions
From: "email@example.com" <firstname.lastname@example.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, April 24, 2019 at 5:56 AM
To: Bret Jordan <Bret_Jordan@symantec.com>
Cc: "email@example.com" <firstname.lastname@example.org>
Subject: Re: [cti] Working Call Recap and action items
I still think versioning of SCOs is not being fully thought through. RE the breaking changes on the meaning of "created"
and "modified" on several SCOs and how to deal with this. I don't see a clear solution proposed.
Another aspect I don't see fully thought-through here is that SCOs do not exist in isolation, they still "live" inside one or more observed-data SDOs. Those SDOs *themselves* have full versioning
If we are going to allow versioning of SCOs, then someone needs to come up with a clear explanation of the workflows expected:
* When would someone version the SCO vs the SDO? Why can I not do "the email use case" by versioning the observed-data SDO? This makes a lot more sense to me because what I am doing is re-reporting
the observation with more information, I am not changing the email itself.
* What happens when an SCO is versioned but the SDO is not, or vice-versa, creating a conflict? Does that make any sense? What happens when the version dates become mis-aligned?
Lead Architect - IBM Security Connect
"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."
- Thomas J. Watson
From: Bret Jordan <Bret_Jordan@symantec.com>
To: "email@example.com" <firstname.lastname@example.org>
Date: 04/23/2019 06:23 PM
Subject: [cti] Working Call Recap and action items
Sent by: <email@example.com>
We had a good working call today, thanks to everyone for joining the discussion. The things we talked about were (sorry this is a bit long):
1) Release Train. The consensus on the call was to wait on releasing working draft 04 until the TC has had a chance to review the mini-group proposals for Infrastructure and COA. These
will be scheduled for an upcoming working call. Just so everyone understands, this will push the completion of Milestone 2 out to mid or late May at the earliest. If you disagree with this, please speak up on the list. The alternate proposal is to release
Working Draft 04 now, and when we do Working Draft 05 include Infrastructure and COA at that point, since it may take several weeks or a month to get that done. This way the broader TC can start reviewing Working Draft 04 now.
2) JSON and I-JSON references. We talked through this and seemed to have solid consensus if not unanimity on making these changes. The editors will get this implemented in the documents.
If you have questions or issues with this, please speak up.
3) We had a good but short discussion on the SCO relationships and which are being deprecated and being moved to external relationships. Just so everyone fully understands, here are
the relationships that are being deprecated and moved to external:
a) Domain Name Object: resolves_to_refs
b) IPv4 Address Object: resolves_to_refs, belongs_to_refs
c) IPv6 Address Object: resolves_to_refs, belongs_to_refs
d) Network Traffic Object: encapsulates_refs, encapsulated_by_refs
For a, b, and c the rational is that an external relationship will allow you to time box the resolution so you can say that it resolved to foo.com from 2015 to 2016 and bar.com from 2017 to 2018. Embedded relationships do not
I am not sure how to explain d though. Maybe someone can speak up and explain why that one is being deprecated and what the use case is. If not, then maybe that one should be left as embedded.
Action Item: Jason and John-Mark are going to work on some text that describes what it means to be "deprecated"
4) We started the long discussion on what it means for a SCO to be versioned. While we did not get consensus on the call, we semi-mostly stayed civil in our discussion. We will need
to pick this up again next week to try and resolve this with the broader TC. We also need to remember that a proposal from a Mini-Group is not TC Consensus. It may have achieved consensus in the Mini-Group, but we need the whole TC to agree, regardless of
the amount of time and effort that went in to the Mini-Group. Some times mini-groups produce proposals that sail right through, sometimes the TC as a whole wants more input, and that is okay.
The major points on this topic today were:
a) Often when we talk about these use cases, we respond with the "IP Address is a fact" use case. However, we need to be thinking about this from the Email Message or File / Artifact use case.
b) Having the ability to do data markings on a SCO seems like a super critical use-case that people need and want. But by doing this, this kind-of forces having some of the other properties.
c) Some people want the ability to have a revoked property on SCOs, some think revoking is not really going to work so why have it.
b) Can you version an object if you do not have a created_by_ref. Some think you can and think that it will enable you to know who versioned it, others think this is a bad idea as it will prevent re-use. If the created_by_ref
is found and the object ID is deterministic, you should be able to de-dup and aggregate the data.
e) Can SCOs have translations? Should you be able to say that an email was written in language FOO or language BAR or that a translation to JP is being provided?
f) There is a difference between calling something out in the spec as "optional" and allowing it via "custom properties". We have been down this road many many times in the past. They are not the same thing.
I personally believe that everyone agrees that SCOs, at this time (2.1-2.x), are NOT going to be the same thing as SDOs and SROs. However, there seems to be some requests for a bit more than what came out of the mini-group and
The mini-group work did not have any of the common properties other than "type" and "id". However, at the last F2F, there was a push to add data markings and "created" and "modified". What was agree is they would be "optional"
and not "required". Later in the F2F there was also a desire to add "spec_version", but we could not get agreement on it being required and thus it went in as "optional" (even though that might be weird from an interoperability standpoint).
Now it seems like the last hurtle that people are looking to address is to possibly add a few more of the common properties as optional. This could be as simple as just saying we will add:
a) "revoked" and "lang"
b) "created_by_ref", "revoked", and "lang"
c) Just add all of them but as optional to make things easier
The fundamental options I see are:
I) Do nothing more than what we have right now
II) Add a few more properties (TBD which)
III) Add the rest of the properties
IV) Remove all versioning from SCOs (not that I agree with this, but adding it for completeness)
If you read this far, thank you. We will pick this critical topic up again next week.