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: 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: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, August 21, 2019 at 9:40 AM
To: Paul Patrick <Paul.Patrick@FireEye.com>, "Piazza, Rich" <rpiazza@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Paul Patrick <Paul.Patrick@FireEye.com>
Sent: Wednesday, August 21, 2019 7:31:30 AM
To: Piazza, Rich <rpiazza@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; cti@lists.oasis-open.org <cti@lists.oasis-open.org>
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: <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Wednesday, August 21, 2019 at 9:26 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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 <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, August 20, 2019 at 3:12 PM
To: Rich Piazza <rpiazza@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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" <rpiazza@mitre.org>
To:        Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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:        <cti@lists.oasis-open.org>


 

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

 

signature_1179553494

 

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date:
Sunday, August 18, 2019 at 8:24 PM
To:
Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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" <rpiazza@mitre.org>
Date:
Sunday, August 18, 2019 at 7:46 AM
To:
Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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=server-certs@thawte.com",

  "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/emailAddress=baccala@freesoft.org

}

 

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=server-certs@thawte.com",

  "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/emailAddress=baccala@freesoft.org",

  "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

 

signature_1179553494

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date:
Friday, August 16, 2019 at 4:31 PM
To:
Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date:
Friday, August 16, 2019 at 11:45 AM
To:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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

 

signature_1179553494

 



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.


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