Ivan,
Could some ideas from JSON-LD help us here?
Disclaimer: I'm not sure JSON-LD allows embedding objects like this or extending a context, like I've done.
Also, there's a "@vocab" thing in JSON-LD. But once we start using vocabularies, we're heading down the road toward Ontologically-Correct Disunity (OCD).
{
"@context": "http://cybox.example.com/mycybox++",
"@type": "Observable",
"file" : {
"@type": "File",
"hashes" : [
{
"hash": "3773a88f65a5e780c8dff9cdc3a056f3",
"@type": "md5" # default type defined in CybOX
},
{
"hash": "f49125dac3:352bb35ffrca2:a123dc4599245",
"@type": "superhash" # new type from my cybox++
},
]
}
}
JSA
From: Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, November 2, 2015 10:54 AM
To: John Anderson; cti-cybox@lists.oasis-open.org
Subject: Re: CybOX 3.0: HashType Refactoring
Sent: Monday, November 2, 2015 10:54 AM
To: John Anderson; cti-cybox@lists.oasis-open.org
Subject: Re: CybOX 3.0: HashType Refactoring
It makes sense, and I can definitely see the parallels to the IP Address refactoring :)
My main concern is that if the “type” field is intended to capture a set of default hash types and also support custom values, then it will likely need to use a controlled
vocabulary, which gets us back to the original HashType implementation and its corresponding complexity:
{
"file" : {
"hashes" : [
{
"hash": "3773a88f65a5e780c8dff9cdc3a056f3",
"type": {"vocabulary":"HashNameVocab-1.0", "value":”md5"}
},
{
"hash": "f49125dac3:352bb35ffrca2:a123dc4599245",
"type": "superhash" # A "custom" hash type.
},
]
}
}
A possible middle ground is to have the “type” field set to a hard-coded enumeration (with values of “md5”, “sha1”, “sha256” etc.), and have a separate “custom_type” field for custom hash values.
This negates the need for a controlled vocabulary driven approach, and thus would still be simpler. I think “custom_type” or “type” would always have to be specified though, as you can’t reliably infer the type of hash from a particular value (although you
can make educated guesses – if the value is 16 bytes in length, odds are it’s MD5):
{
"file" : {
"hashes" : [
{
"hash": "3773a88f65a5e780c8dff9cdc3a056f3",
"type":
”md5"
},
{
"hash": "f49125dac3:352bb35ffrca2:a123dc4599245",
"custom_type":
"superhash" # A "custom" hash type.
},
]
}
}
What do you think?
Regards,
Ivan
From: John Anderson
Date: Monday, November 2, 2015 at 10:19 AM
To: Ivan Kirillov, "cti-cybox@lists.oasis-open.org"
Subject: Re: CybOX 3.0: HashType Refactoring
Date: Monday, November 2, 2015 at 10:19 AM
To: Ivan Kirillov, "cti-cybox@lists.oasis-open.org"
Subject: Re: CybOX 3.0: HashType Refactoring
This Hash refactoring seems to parallel the IP Address refactoring. Would it make sense to treat hashes the same way we treat IP Addresses?
{
"file" : {
"hashes" : [
{
"hash": "3773a88f65a5e780c8dff9cdc3a056f3",
"type": "md5"
},
{
"hash": "f49125dac3:352bb35ffrca2:a123dc4599245",
"type": "superhash" # A "custom" hash type.
},
{
"hash": "12343773a88f65a5e780c8dff9cdc3a0"
# Default is "md5", if it's not specified.
}
]
}
}
Whadayathink?
JSA
From:
cti-cybox@lists.oasis-open.org <cti-cybox@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, November 2, 2015 10:07 AM
To: cti-cybox@lists.oasis-open.org
Subject: [cti-cybox] CybOX 3.0: HashType Refactoring
Sent: Monday, November 2, 2015 10:07 AM
To: cti-cybox@lists.oasis-open.org
Subject: [cti-cybox] CybOX 3.0: HashType Refactoring
All,
As I mentioned on last week’s call, we’ve got another proposal related to CybOX 3.0 to get your feedback on: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-HashType-Refactoring
|
|
CybOXProject/schemas
schemas - CybOX Schemas and Schema Development
|
This one is around refactoring the way hashes (especially common ones like MD5 and SHA1) are currently captured. Accordingly, we’d love to get your general thoughts on the proposal as well as on the related questions:
- Does it make sense to have two disparate types for capturing hashes in CybOX, one for more common hashes and one for esoteric/custom hashes?
- As far as the list of hashes in the new HashesType – are there any that are missing? Are there any that should be pruned?
- Are there any fields that should be added to the new CustomHashType?
Regards,
Ivan and Trey