Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

No one (or at least I wasnât) suggesting any change of any cardinalities.

 

Secondly, I was raising the issue that we should fix the real problems with the examples.

 

The certificate example was a perfect example. Inserting text on fallback UUIDv4 would not have fixed those examples and guiding the community to better sharing of certificates has a much bigger impact than folks sharing certificates without
 them.

 

Finally, I would say that actually fixing examples is a non-normative change whereas inserting this fallback text *is* a normative change.

 

Allan

 

From: Sean Barnum <>

Date: Wednesday, August 21, 2019 at 7:14 AM

To: Bret Jordan <>, Paul Patrick <>, "Piazza, Rich" <>, Jason Keirstead <>

Cc: Allan Thomson <>, "" <>

Subject: Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

I concur with the UUIDv4 fallback.

I would strongly reject changing cardinality of properties from what they semantically should be on an object just to force the presence of contributing properties to deterministic ids. That would significantly damage the practicality of
 STIX for real-world data.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: 

 

From: <> on behalf of Bret Jordan <>

Date: Wednesday, August 21, 2019 at 9:40 AM

To: Paul Patrick <>, "Piazza, Rich" <>, Jason Keirstead <>

Cc: Allan Thomson <>, "" <>

Subject: Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

I think a fall-back option makes sense.  What we do not want is there to be holes in the standard and have developers not know what to do.

 

Bret

 

From:  <> on behalf of Paul Patrick <>

Sent: Wednesday, August 21, 2019 7:31:30 AM

To: Piazza, Rich <>; Jason Keirstead <>

Cc: Allan Thomson <>;  <>

Subject: Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

Rich,

 

Default to UUID4 is exactly what we had to do in those cases where none of the properties necessary were not provided vs rejection of the object.

 

Paul Patrick

 

 

From: 
<> on behalf of "Piazza, Rich" <>

Date: Wednesday, August 21, 2019 at 9:26 AM

To: Jason Keirstead <>

Cc: Allan Thomson <>, "" <>

Subject: Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

There are others â I mentioned Email Message. User account and Registry Key are another two.  UUIDv4 is explicitly suggested for Process â but not even with a
SHOULD.

 

I agree that some objects make no semantic sense without certain properties being present.  However, if some properties should be required is not the issue I am trying to address here.

 

I am just suggesting that some âstop-gapâ normative text about the case where all of the contributing ids are optional and not present should be added to section 2.9.

 

BTW, falling back to a UUIDv4 is what python-stix2 will do.

 

From: 
Jason Keirstead <>

Date: Tuesday, August 20, 2019 at 3:12 PM

To: Rich Piazza <>

Cc: Allan Thomson <>, "" <>

Subject: Re: [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

Is Certificates the only place this is a problem?

Maybe both of these things should not be optional for certificate?

Is anyone really sharing around certificates in STIX without serials? Whats the value in it...

-

Jason Keirstead

Chief Architect - IBM Security Threat Management

www.ibm.com/security

"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:        "Piazza, Rich" <>

To:        Allan Thomson <>, "" <>

Date:        08/19/2019 01:59 PM

Subject:        [EXTERNAL] [cti] Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section
 2.9 of the STIX specification

Sent by:        <>

 

Hi Allan,

 

Iâm not defending that example â especially since I didnât write it.  I just found it as it was â and it would be impossible to generate a deterministic id from it.  

 

In general, if all of the contributing ids are optional and not present â and such objects *will* be created â the spec should describe how to handle it.

 

My suggestion for changing section 2.9 is not a semantic issue â but then âbest practicesâ are not part of the specification per se.  However, itâs probably true that the examples should exhibit best practices, if possible.

 

The example was âfixedâ for WD05 so I could at least generate the deterministic id.  If you think it would be better to add a hash, we can do that too.  

 

                Rich

-- 

Rich Piazza

The MITRE Corporation

781-271-3760

 

 

 

From: Allan Thomson <>

Date: Sunday, August 18, 2019 at 8:24 PM

To: Rich Piazza <>, "" <>

Subject: Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

Rich â the example you highlighted is exactly my point. 

 

Why do those X509 certificates examples *not* include at least one hash?

 

For many practical uses, having a hash be shared to match on the certificate as-is, is very helpful. It helps identify that the certificate has not been modified if you are using the hash and also allows the recipients to avoid having to do
 field matching on the content of the hash to determine problems.

 

So I would rather fix these examples cause that shows best practices more than fixing UUIDv4 fallback text that would like not have fixed the intel issue.

 

Allan Thomson

CTO (+1-408-331-6646)

LookingGlass Cyber Solutions

 

From: "Piazza, Rich" <>

Date: Sunday, August 18, 2019 at 7:46 AM

To: Allan Thomson <>, "" <>

Subject: Re: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

HI Allan,

 

The critical word in the text Iâm suggesting is âcontributingâ.  This is the name we gave the collection of properties that should be included in a deterministic id.  For example, here is the text from the X509 certificate table:

 

 

ID Contributing Properties

hashes,
serial_number 

 

If the hashesproperty is present, include only one hash. The selected hash
SHOULDcome from this ordered list (based on the following order of preference) [ MD5, SHA-1, SHA-256, SHA-512 ].

 

If you look at the definitions of those two properties, they are both listed as âoptionalâ.

 

As it turns out, when I was creating deterministic ids for the examples in the spec â here was one for X509 certificates:

 

Examples

Basic X.509 certificate

{

  "type": "x509-certificate",

  "spec_version": "2.1",

  "issuer": "C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=",

  "validity_not_before": "2016-03-12T12:00:00Z",

  "validity_not_after": "2016-08-21T12:00:00Z",

  "subject": "C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/[email protected]

}

 

Notice that neither the hashes or serial number property is present.  So how could I create a deterministic id for this example?

 

For the sake of getting the working draft out â I just added the serial_number property â and therefore I was able to create the deterministic id for it.  Here is what this example now looks like in the working draft.

 

Examples

Basic X.509 certificate

{

  "type": "x509-certificate",

  "spec_version": "2.1",

  "id": "x509-certificate--463d7b2a-8516-5a50-a3d7-6f801465d5de",

  "issuer": "C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=",

  "validity_not_before": "2016-03-12T12:00:00Z",

  "validity_not_after": "2016-08-21T12:00:00Z",

  "subject": "C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/[email protected]",

  "serial_number": "36:f7:d4:32:f4:ab:70:ea:d3:ce:98:6e:ea:99:93:49:32:0a:b7:06"

}

 

There are several other SCOs where the contributing properties are all optional (e.g., email_message).  In most SCOs, it is highly unlikely that all of the contributing properties will be omitted.  

But the original example from the spec shows that is could happen.  The new normative text is to handle this case.

 

                Rich

-- 

Rich Piazza

The MITRE Corporation

781-271-3760

 

 

From: Allan Thomson <>

Date: Friday, August 16, 2019 at 4:31 PM

To: Rich Piazza <>, "" <>

Subject: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

Rich â I think we need an example because on the surface your suggestion makes sense but I want to understand the following.

 

What object has is worth conveying if *all* the properties are optional *and* *all* of them are
empty. What exactly is that object conveying then? It sounds like an empty object with no actual content.

 

I question the definition of the object in the 1st place so I assume thereâs a specific example that helps show that your change is helping.

 

But my concern about adding the language you are suggesting is actually more on what object has this problem.

 

Allan Thomson

CTO (+1-408-331-6646)

LookingGlass Cyber Solutions

 

From: "" <> on behalf of "Piazza, Rich" <>

Date: Friday, August 16, 2019 at 11:45 AM

To: "" <>

Subject: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification

 

As MITRE was incorporating deterministic ids into cti-python-stix2 API, the implementer came across the issue that I mentioned on one of the working calls.  That is â what if the contributing properties are all optional, and none of them are present in the
 object?  What should the ID be?  

 

The most obvious answer (to me) is that a UUIDv4 should be used in these cases.  However, no text exists in the specification to clarify this.  Iâm suggesting the following be added to section 2.9 as the fourth bullet point of the paragraph which begins
 âSTIX Cyber-observable Objects SHOULDuse UUIDv5ââ

 

If the contributing properties are all optional, and none are present on the SCO, then a UUIDv4
SHOULD be used.

  

Bret and I discussed this, and even though it is a new normative statement, we feel that it is not really a substantive change.

 

This will be discussed on the next working call.

 

                Rich

-- 

Rich Piazza

The MITRE Corporation

781-271-3760

 

 

CAUTION: This email originated from outside of FireEye from a third party. Please take extra precaution clicking on any embedded links or downloading and opening file attachments. If you feel this is a suspicious email, please use the
 âReport Phishingâ button in your Outlook toolbar. 

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
 strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

CAUTION: This email originated from outside of FireEye from a third party. Please take extra precaution clicking on any embedded links or downloading and opening file attachments. If you feel this is a suspicious email, please use the âReport
 Phishingâ button in your Outlook toolbar. 

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
 strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.