OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Review of working today's call


We will get some minutes send out soon from those that were able to take them, but I wanted to give a quick update on the outcomes of the call today.

We had 14 people on the call today: (John-Mark, Bret, Sarah, Trey, Emily, Allan, Oscar, Caitlin, Chris Lenk, Chris Ricard, David Girard, Emmanuelle, Ivan, Jeff).  

We spent 5 minutes reviewing our current status on where we are at

For 25 minutes we talked about Versioning SCOs.  The call had very strong support for doing Option 1 (either A or B) from my slides.  The people that supported that were Allan, Chris, Jeff, David, Caitlin, Sarah, Ivan, and John-Mark).  We did not have anyone really ask for option 2.  There was some discussion about doing option 2 for some SCOs but not others.  But the general idea was if we need to revisit in STIX 2.2 we can.  It is important to note that no one from FireEye or DHS was on the call.  FireEye and DHS have been the strongest supporters of option 2.

To keep things fully transparent and to make sure everyone has a chance to weigh in on this topic, we are bringing this up on the list for a final round of discussion.  Just to be clear the current proposal is that organizations that need to do versioning can, they would just use the custom properties constructs we have in STIX. Organizations would be able to use the exact the same names from the common properties if they wanted.  So they would not need to be "x_" based named. But these would not be called out as required or optional in the spec itself. So any organization that wanted to do versioning of SCOs could, but there would not be any mention of it in the spec itself since they would all be handled via the custom property constructs. 

We do need to decide if we are going to fix the name collisions on the SCOs that already have a "created" and/or "modified" property.  My personal opinion is that we should.  But this group needs to decide that. 

As Jason was not on the call, we skipped the patterning topics, and will do them next week.

The next 25 minutes was spent on discussing any inconsistencies in any of the objects.  Topics that were brought up were:

a) We should make either objects or objects_ref required on Observed_Data like we do else where in STIX when one of two properties must be used. Everyone agreed with this.

b) We talked about adding kill_chain_phases to campaign, but decided to punt that to 2.2.

c) We talked about what it would mean to make "name" required on the objects where it is optional.  Currently where name is a valid property it is required on all but three objects.  The group's opinion is we should not make a change at this time, even though there are some cases where it would really help end users and analysts.  We talked about adding some text specifically to indicator to say that a name or description really should be present.

d) There was also some concern about the way we have done motivations on Threat Actor and Intrusion Set.  Jeff and Sarah both had a concern with it.  I have asked them to put together a description of what the problem is and how they would suggest fixing it.   

Thanks all,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]