Re: CybOX 3.0: HashType Refactoring

[John Anderson <janderson@soltra.com>]

This Hash refactoring seems to parallel the IP Address refactoring. Would it make sense to treat hashes the same way we treat IP Addresses?

By applying that idea to the example on the page, we get something like this:

{

  "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

 

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 Read more...

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:

1. 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?
2. As far as the list of hashes in the new HashesType – are there any that are missing? Are there any that should be pruned?
3. Are there any fields that should be added to the new CustomHashType?

Regards,

Ivan and Trey