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: Recap of Working Call


All,


Today we were able to discuss and get working call consensus on the following items:


1) SCO that have conflicting property names with common properties. The consensus on the call was to rename the conflicting properties on the following objects: Directory Object, File Object, Process Object, and Windows™ Registry Key Object.  John-Mark pointed out that we may need to add some clarifying text to patterning to address this.  Christian from NewContext said he would help identify any changes that are needed.  


2) Language Content object and how it can be pinned to a specific version.  This was a somewhat controversial topic.  In the end we did a quick up/down vote. The choices were to remove the property or make it optional. The consensus on the call was to leave the property on the object, but make it optional.  The vote was 11-2.


3) Indicator to Observed Data relationship type. After talking about this for a few weeks, the consensus on the call today was to call this relationship "based-on". 


4) A few weeks back we started a discussion about some inconsistencies in some of the objects. We discussed more of these on today's call and had working call consensus to do the following:


  a) Leave the property name "is_family" with the prefix "is_" on the Malware Object

  b) Leave the name property optional on the Grouping Object

  c) Add description to the Sighting Object

  d) Leave the name property optional on the Marking Definition Object

  e) Add an optional name property to the Location Object


We did not have consensus one way or another on adding a description to the Marking Definition Object.  We will ned to bring this back up next week. 


We did not have consensus one way or another on whether spec_version should be required on SCOs.  We will bring this back up next week.  There seems to be a slight preference for making it required.  But there is also a strong view that the extra on-the-wire bloat is too significant. 


5) SCO external relationships. We had working call consensus to make the following SCO relationships (“resolves-to-refs” and “belongs-to-refs”) external on the following SCOs: Domain Name, IPv4 Address, IPv6 Address. The editors will need to do some work to make this happen.


6) The following text has been proposed for inclusion to section 3.4.  If you have changes or further suggestions please send them to the email list. 


Deterministic IDs (UUIDv5) in the example SCOs contained in this specification were computed using the algorithm defined in section 2.x.  Every attempt was made for these IDs to be accurate.  Certain IDs which were used in reference properties of the examples did not include the actual object, and therefore it was impossible to accurately compute the appropriate UUIDv5.  In these cases, a UUIDv4 was generated and the "version" character of the UUID was changed from a 4 to a 5



7) The following text has been proposed for inclusion to section 3.6.  If you have changes or further suggestions please send them to the email list.


In STIX 2.1, SCO do not explicitly have those three versioning properties. Therefore, a SCO cannot be versioned unless custom properties (discussed in section 11.1) are used. Producers who plan on doing this SHOULD use the property names created_by_ref, revoked, created, and modified. In the rest of this section "STIX objects" should be read to include SCOs customized in this way.




Thanks

Bret












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