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] ID Contributing Properties


Iâm happy either way.  We can nail it down on the call and the editors will fix the text.

 

From: <cti@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Tuesday, July 9, 2019 at 12:09 PM
To: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Re: [EXT] Re: [cti] ID Contributing Properties

 

It is an AND by design.

For a File, the hash will definitively identify the âbitsâ of the file (basically the part that can be represented also with an Artifact) but not the file as a file.

The same chunk of bits (with the same hash) that exists as foo/bar.exe and as alpha/zed.exe are two semantically DIFFERENT files. Correlating them to the same object would be a bad thing.

Hopefully that makes sense.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: "Piazza, Rich" <rpiazza@mitre.org>
Date: Tuesday, July 9, 2019 at 12:04 PM
To: Sean Barnum <sean.barnum@FireEye.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [EXT] Re: [cti] ID Contributing Properties

 

My impression was that the hash value by itself was definitive which is why it was an OR and not an AND of properties.

 

I donât think it matters â we just need to agree on the right text.

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Tuesday, July 9, 2019 at 11:11 AM
To: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] Re: [cti] ID Contributing Properties

 

That was definitely not the intended behavior. It looks like it is just a wording glitch.

The non-hash properties if listed should always be included as material for id generation.

 

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Thursday, June 20, 2019 at 9:19 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] ID Contributing Properties

 

(Apologies if you already saw this on the cti users list)

 

Iâm attempting to derive ârealâ deterministic ids for the examples in the spec.  Right now the SCO are expressed as âstand-insâ that look like âtype--00000000-0000-0000-0000-000000000000â.

 

Iâm writing a script that will generate the ids â but I have encountered some text in the spec which seems ambiguous.  They concern SCOs where a hash is one of the id contributing properties:

Here are the three uses:

 

For Artifact:

 

hashespayload_bin

Where

1.     if hashes exists only include 1 hash from this common ordered list (based on the following order of preference) [ md5, sha1, sha256, sha512 ]

2.       if no hashes are defined and payload_bin exists include only the payload_bin

 

For File:

 

hashesnameextensions

Where

1.     if hashes exists include 1 hash from this ordered list [ md5, sha1, sha256, sha512 ] only

2.     If no hashes

a.     Include defined extensions

b.     Include defined name

 

For X509 Certificates:

 

hashesserial_number

Where

1.     if hashes exists include 1 hash from this ordered list [ md5, sha1, sha256, sha512 ] only

2.     Include serial_number

 

The way I read this, Artifact and File only include other properties if there are no hashes available, but X509 Certificates always includes serial_number.

 

If that is the case, then I would probably want to clean up the text â but Iâm not sure that this is what was intended.

 

Can someone more explicitly describe the use of the contributing properties for these three types?

 

                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]