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
