[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> 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> 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> 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> Is Certificates the only place this is a problem? 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 <athomson@lookingglasscyber.com> 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) From: "Piazza, Rich" <rpiazza@mitre.org> 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:
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 From: Allan Thomson <athomson@lookingglasscyber.com> 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) From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org> 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ââ
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]