Re: [cti-cybox] Hashes of Files on File Object

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

What if you are a system that is not able to compute the hash, for whatever reason, as computing a hash is not a noop? I can see scenarios where a system may make a File object with a byte stream but without a hash. 

I also do see value in having file objects with lots of meta such as name, size, exif, etc.  without hashes. I disagree that there is no value in file names. The amount of logs where you will see the name of a file is an order of magnitude greater than those where you will see the hash. 

Yes without the hash or the bytes, you can't be 100â?? certain it's the same file, but it's still an important data point.

I don't think Hashes should be mandatory...

Sent from IBM Verse

Jordan, Bret --- Re: [cti-cybox] Hashes of Files on File Object ---

From:	"Jordan, Bret" <bret.jordan@bluecoat.com>
To:	"Terry MacDonald" <terry.macdonald@cosive.com>
Cc:	cti-cybox@lists.oasis-open.org
Date:	Thu, Aug 25, 2016 7:12 PM
Subject:	Re: [cti-cybox] Hashes of Files on File Object

---

You may not actually have a filename, in the case of an octet-stream being downloaded..  But you should always have a hash.  I really question if a CybOX File Object without a Hash is of any value.  What value is there to send me some Observed Data in STIX with a CybOX File Object that does not have a hash?  What am I supposed to do with that...????

I feels like you would be sending my useless information that people will just throw away.  

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Aug 25, 2016, at 15:32, Terry MacDonald <terry.macdonald@cosive.com> wrote:

Bret,

I don't think we can make this required. It is often the case that an analyst knows that a file was dropped but they only have the filename. We cannot force it so that you can only describe a file object in CybOX if you have the full binary captured so that you can take a has of it. It will stop people being able to describe the file object at all in CybOX.

IMHO CybOX is not STIX. We need to allow people to describe as little or as much information as they are willing to do. We need to work out what is the smallest possible thing that is an absolute necessity to make the object understandable and make only that required.

For the fully object i would suggest that this only the filename. Even the path should be optional IMHO as it's not always apparent where a file was linked to on a drive if it was disassociated from the directory structure.

Cheers
Terry MacDonald
Cosive

On 26/08/2016 08:55, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

Right now on the File Object we have the "hashes" property as optional.  I am really worried about this... I just do not think it makes sense to pass around a File Object that does not have at least one hash.  

I would also suggest that we should have a property on the base object called "primary_hash or file_hash or something" and define it in CybOX 3.0 as SHA256.  Then have the "hashes" object extension be for "extra" hashes that you might want to provide above and beyond the base hash.  

But every File Object MUST have at least an SHA256 hash in the "primary_hash" field.  Then in future versions of CybOX we can rev that to the hash-of-the-day once SHA256 is considered "broken".

The one thing I do not like about the generic Hashes extension is for something as important as a file hash, there is no predictability in this File Object.  There is nothing you can count on from a Hash stand point.  I think we should really fix this.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."