The other challenge with mandating a hash is which hash should we mandate? Bret suggested SHA256, but most of the reporting I get (and produce) still uses MD5. If we mandate a particular
hash I then may not be able to capture information that I have because I don’t have the
right hash.
Sarah Kelley
Senior CERT Analyst
Center for Internet Security (CIS)
Integrated Intelligence Center (IIC)
Multi-State Information Sharing and Analysis Center (MS-ISAC)
1-866-787-4722 (7×24 SOC)
Email: cert@cisecurity.org
www.cisecurity.org
Follow us @CISecurity
From:
<cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, August 26, 2016 at 6:43 AM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Cc: Terry MacDonald <terry.macdonald@cosive.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] Hashes of Files on File Object
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.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
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.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
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."
...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender
immediately and permanently delete the message and any attachments.
. . .
|