Re: [EXT] [cti] Recap of Working Call

["Piazza, Rich" <rpiazza@mitre.org>]

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

 

I was trying to make a point about not adding a description to Marking Definitions, and explain my point of view about them in general, on the call.  I might not have been clear so I wanted to state my opinion in writing.

 

First, the original argument against including a description property on Marking Definitions was that it could contain text that contradicts the content of the definition property.  I still think this is valid.  Obviously, this is a data quality issue â but I think it becomes more important because marking definitions can be related to classification (S, TS, etc), and we want to make sure that there is no room for confusion.

 

Second, I am in favor of the optional name property.  Itâs useful to have a âhandleâ for a marking definition, other than its id.  Knowing that the marking definition you want to use is named âTLP:GREENâ will make it easier to assign a value to the marking ref properties of an object.   However, Iâm not sure why the TLP:GREEN marking definition object needs a description.  I donât think you should be learning about what TLP:GREEN means from a STIX object.  I could see adding an external_reference property to those objects â but that would require a change to the objects defined in the spec â so that could be an issue.

 

Third, IMHO â I donât see there being a large variety of different marking definition objects.

As stated previous there is one and only one marking definition object for each of the TLP âcolorsâ â and those MUST be used â according to the spec.  Statement marking definitions â related to copyrights or terms of use, would probably be relatively finite in number.

Iâm helping DHS develop a new type of marking definition for ACS â which is the standard markings used by the U.S. Government.  They are very complex, but there is probably a lot of reuse, so I would hope that there are no duplicate marking definition objects for a specific ACS marking.  The definition is explicit in the full definition of the marking, and shouldnât be âsummarizedâ in a description property.  Knowing how to interpret an ACS marking should not be based on a summary description in a STIX object.

 

The point is marking definition objects are not defining a marking â they are expressing pre-existing markings - in STIX.  Markings are external things â and should not be âdescribedâ in a STIX object.

 

            Rich P.

 

 

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, July 2, 2019 at 7:50 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] [cti] 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