Re-name Fingerprint to Hash in OCSF as well as change ja3s_fingerprint to be a string

[JasonKeirstead]

We propose to re-naming "Fingerprint" to "Hash".

Logic is as follows:

• Everyone in the cybersecurity space especially in the EDR and SIEM spaces, refer to this as a hash. It is therefore the "expected term". People will therefore do things like type "hash" and expect it to auto-complete to the possible values. No one is going to be typing "finger" when looking for a hash. It is simply not what is expected. It therefore makes OCSF harder to use than necessary.
• If you look at the "Fingerprint" object - it is just a literal list of hashing algorithms. Even the Description of the object, says it is a hashing algorithm. So why name it Fingerprint?
• If this is not changed before 1.0, it is likely never going to change. It is certainly a large breaking change for one, and re-naming a core object, is unlikely to get support. So if we don't change this now, we will be stuck with "fingerprint" pain forever.

In addition, we notice the current "ja3s_fingerprint" property in the TLS objects, is misleading. JA3S only allows a single hash method - It's an MD5. It's in the spec, it can't be anything else without breaking JA3S matching. So this should not even point at a Fingerprint object, it should just be a string.

What would be done if this proposal is approved

• The "Fingerprint" object would be re-named "Hash"

• The "fingerprint" property in the following objects would be re-named "hash":

Container Object, Digital Certificate Object, HASSH Object

• The "fingerprints" property in the following objects would be re-named "hashes":

Digital Signature Object, File Object,

• The "ja3s_fingerprint" property in the following objects would be changed to be a string

SMTP Transport Layer Security Object, Transport Layer Security (TLS) Object

[rroupski]

A hash function is something which assign a shorter bit string for each item in a large pool of items. For practical purposes, the hash values for different items should seldom to collide but there is no guarantee they won't collide at all. A fingerprint is supposed to be something that uniquely identifies the original item for all practical purposes.

[LeszekAdamiak]

@jp-harvey We see a lot of vendors calling file hash just a hash, or naming it by algorithm like "md5=" or "sha256=". Every security product that talks about files would call it hash. I haven't seen a security product that would use "fingerprint" as a parameter in logs used for security analytics. If we go with fingerprint we would be asking all these vendors to rename.
For PKI Linux /var/log/secure would capture SSH logs with fingerprint/hash in it, as here:
Jun 13 15:31:09 hostname sshd[22293]: Accepted publickey for root from X.X.X.X port 55943 ssh2: RSA cd:33:39:38:f7:e3:49:b1:a6:3f:8d:8f:cc:69:d7:c3

X.509 would have PKI and some agent based proxy or network traffic analysis vendors may reference it, but I couldn't find anything.

[jp-harvey]

@LeszekAdamiak I don't think we're in disagreement? I'm suggesting leaving fingerprint as fingerprint for attribute names in the PKI related classes / objects, but change the underlying object and the other attribute names to hash.

[pagbabian-splunk]

@jp-harvey that is similar to an approach suggested by @mr-splunk this afternoon. The fingerprint object has a value attribute of type String. He suggested changing the name of that attribute from the standard value to hash. In either case, this will be a breaking change (I marked as such in the category tag). If @LeszekAdamiak had searched the dictionary for hash he would have found an attribute that was part of the fingerprint object, but all of the other references to that object would not change, just the underlying value attribute (becoming hash).
However, I find the generic Caption for fingerprint to be misleading: it may very well imply a biometric fingerprint, not a digital fingerprint as hash.
Given that either approach is breaking, I would favor being more straightforward and using the name hash and the caption Hash (although it could be confused with HASSH).
Lastly to @JasonKeirstead's point about the JA3 MD5, we could add to the description of the ja3_fingerprint (ja3_hash) algorithm_id must be set to MD5. Otherwise, when searching across all hashes, it would not be returned from hash.value as would other hashes. Even if we had a String attribute for ja3_fingerprint (or ja3_hash) we would still need to document its description has having to be a MD5 hash.
Notwithstanding the value-to-hash attribute option called out here I can vote in favor of the change, but I don't want to make ja3_fingerprint a String value documented to be an MD5 hash, but rather would keep it as a Hash object, documented to be a MD5 hash.

[JasonKeirstead]

Some of these discussion points make some sense.

My question is, do I need to open a new poll ? :)

I am not sure I agree with the JA3 part. JA3 is a spec that says it is a string. The fact it is using MD5 is "under the covers" - in fact, it could change at some point, who knows. I don't know why we would point this at a hash object.

[pagbabian-splunk]

This one is interesting - in fact when I search on JA3 I come back with JA3 fingerprinting :-) from a number of sources, including Salesforce and Cloudflare. Even when I search on 'JA3 hash' I can come back with fingerprint, signature etc. In general, I see it in context of 'TLS fingerprinting' and we only use it within the TLS object (https://schema.ocsf.io/objects/tls).

e.g. from Cloudflare:
What is ja3s fingerprint?
A JA3 Fingerprint Open external link helps you profile specific SSL/TLS clients across different destination IPs, Ports, and X509 certificates. Note. JA3 Fingerprints are only available to Enterprise customers who have purchased Bot Management.

Also, to your point @JasonKeirstead that it is defined as a String, note that there is another pair of attributes, ja3_string and ja3s_string defined as String, that are referenced in the TLS object (https://schema.ocsf.io/objects/tls), along with ja3_fingerprint and ja3s_fingerprint (the latter two of type Fingerprint). We say one is the JA3 string, and the other is the 'fingerprint of the JA3 String' etc. (Maybe we need to re-examine the TLS object).

Hence, my suggestion is that the proposal keeps the object name as fingerprint, change its caption to 'Digital Fingerprint' and change value to a new attribute hash defined as String, so we can cover both ways of describing it, and it will come up in browser search either way.

[JasonKeirstead]

In the interest of getting to a decision point - we propose closing this proposal in < 7 days. The poll will be closed on March 3.

[irakledibm]

"Hash" makes sense to me. Especially we have "Digital Signature" object for wider definition.

[JasonKeirstead]

Closing this discussion as resolved, changes are now merged.

Issue #515
Issue #516
Issue #500