Address new JA4 hashes

[Aniak5]

Per @zschmerber Looks like JA3 is static, with JA4 coming out how do we want to accommodate the new fingerprints? https://blog.foxio.io/ja4-network-fingerprinting-9376fe9ca637.

In the network sync we discussed creating a new generic JA*/JA*S fingerprint object to eventually replace the JA3 fingerprint object. This object would have a type identifier specifying the version (JA3 or JA4). The version could potentially go into the algorithm/algorithm_id field as @zschmerber suggested

JA4 — TLS Client JA4S — TLS Server Response JA4H — HTTP Client JA4L — Light Distance/Location JA4X — X509 TLS Certificate JA4SSH — SSH Traffic

Or we could add a type/type_id field to this new JA*/JA*S fingerprint object.

[zschmerber]

According to john JA3 is no longer supported so we can just make a JA4 and deprecate JA3 at some time ?

[mikeradka]

I would be careful with deprecating JA3 in OCSF. Is JA3 only no longer supported for SSH? Reason I ask - I recently ran into a couple of webapps that are using JA3 for their APIs, so it may still be a valid attribute under other scenarios beyond SSH.

[zschmerber]

Yes we can have both JA3 and JA4 together for years and eventually when it is not longer relevant remove JA3.

[Aniak5]

I also feel like we should preempt future JA versions so that we don't have to continue deprecating as new versions come out. What do y'all think of making just a generic JA object w/the version number specified.

[zschmerber]

@rickmode proposed this new object be made to support JA4 and the unique values it contains. Thoughts ?

{
   "type_id": <enum for different JA4 fingerprints>,  // required
   "type": <string form of enum>,                     // optional
   "value": <string -- the actual fingerprint>,       // required
   "ja4_sections": {                                  // optional -- split on underscore (_) and put in object
      "a": <string>, // a section of JA4
      "b": <string>, // b section of JA4
      "c": <string>, // c section of JA4
      // etc...
   }
}

[floydtree]

@zschmerber @rickmode Continuing the discussion from the slack thread, this looks good. 1 thing to note though, the nested ja4_sections need not be called ja4_sections. It adds the redundancy - ja4.ja4_sections. It can simply be called sections instead.

[mikeradka]

If we take the new object route, what is proposed for a ja4 object looks good, with the removal of ja4_ from sections as long as we are okay with accepting that this deviates from using the existing fingerprint object. If taking this approach, are we clear on where the object would be referenced in classes?

With that all said, now that we have abundant info on how ja4 is constructed, we could either:

1. Model ja4 100% to spec now and have the extra object, or
2. Tactically observe ja4 outputs - hold off on adding to OCSF and model it after what gets outputted to production. Maybe this does not have to go into 1.1.

[Aniak5]

If we take the new object route, what is proposed for a ja4 object looks good, with the removal of ja4_ from sections as long as we are okay with accepting that this deviates from using the existing fingerprint object. If taking this approach, are we clear on where the object would be referenced in classes?

With that all said, now that we have abundant info on how ja4 is constructed, we could either:

1. Model ja4 100% to spec now and have the extra object, or
2. Tactically observe ja4 outputs - hold off on adding to OCSF and model it after what gets outputted to production. Maybe this does not have to go into 1.1.

I support the second approach @mikeradka.

[zschmerber]

So with the ja4_sections changed to just sections it would look like this:
Any more thought on the object name?

{
   "type_id": <enum for different JA4 fingerprints>,  // required
   "type": <string form of enum>,                     // optional
   "value": <string -- the actual fingerprint>,       // required
   "sections": {                                  // optional -- split on underscore (_) and put in object
      "a": <string>, // a section of JA4
      "b": <string>, // b section of JA4
      "c": <string>, // c section of JA4
      "d": <string>, // d section of JA4
   }
}

[floydtree]

I think ja4 as a name is fine, considering the specific nature of it.

On the point raised by @mikeradka - my concern is if do not have real world logs/events to ensure our modeling of ja4 in OCSF is sufficient and we release it in v1.1 we’ll have to risk a potential breaking change down the road to retrofit the object with real world usage, which is unnecessary. I reckon, if there’s no strong need to release the object today, we can get it into OCSF but not release it with 1.1. We can wait, revise if necessary & release the object in a future version.

[mikeradka]

To gather where we landed:

• We can continue to track ja4, but not add it to OCSF 1.1.
• We will give ourselves the space to tactically observe ja4 in production.
• Since there is not an urgency to release a ja4 object today, we have the opportunity to refine the OCSF implementation of ja4 as the algorithm(s) manifest into production output.
• If a single organization ends up with an urgent need for ja4, there is always the option of adding it to an extension. Extensions are great proving grounds for schema additions that aren't initially as straightforward.
• The bonus is that we have a great deal of info captured on ja4 for when the time is right.

If anything was missed or needs extra clarification on the derived path, please feel free to add to this thread.

[rmouritzen-splunk]

@mikeradka

@zschmerber @rickmode Continuing the discussion from the slack thread, this looks good. 1 thing to note though, the nested ja4_sections need not be called ja4_sections. It adds the redundancy - ja4.ja4_sections. It can simply be called sections instead.

Wouldn't this create an entry in the global data dictionary called sections that would be specific to the JA4 object?

Looking at other OCSF object fields, it does look like an object's fields are not part of the overall data dictionary, so this object can (and should) use sections. So I'm in agreement with what was said above.

[rmouritzen-splunk]

@Aniak5

I also feel like we should preempt future JA versions so that we don't have to continue deprecating as new versions come out. What do y'all think of making just a generic JA object w/the version number specified.

Two points:

1. We should not deprecate the existing JA3 fields. Data sources that include JA3 fingerprints can continue to use these fields as long as data sources that include JA3 are generating events.
2. About future JA versions, it's unclear how a future JA fingerprint would be structured. Maybe it's the same as JA4 (but then, why wouldn't they continue to add new JA4 "methods"), but it may be different. I worry that we would be over-engineering if we attempted this.

I feel this new object should be JA4 specific. Indeed it should be called "JA4+ Network Fingerprint", which is the name the creators gave it. The field in the data dictionary can then be ja4, and if an event needs multiple, ja4_array. (I'd avoid using the plural ja4s since that is a specific kind of JA4 fingerprint, or "method" in JA4 terminology.)

See also: https://github.com/FoxIO-LLC/ja4

[john-althouse]

Hello! Hopefully I can help out here.

1. Yes, Salesforce has basically EOL'd JA3 as stated at the top of their ja3 repo. However, it's still built into most tools so it will probably be years before we see it go away, and therefor it should remain in OCSF for now.
2. The current methods are JA4, JA4S, JA4H, JA4L, JA4X, and JA4SSH. There will be more in the future, JA4W, JA4HS, etc. as I work on them. But you could place them all under the name "JA4+" to keep it simple.
3. All JA4+ fingerprints have an a_b_c ... format and if we came up with a new way to identify something, we could add that on as a _d section. This allows us to add features without invalidating historical fingerprints or needing to maintain version control.
4. A common use case will be to just look at one section of a fingerprint rather than all at once. For example, a web app engineer may want to just look at JA4H_c (the cookie fields section) and see what cookies do not match their format. Or a security engineer may want to look at JA4H_d (the user cookie section) to track a user's activity through the web app. Greynoise may want to look at JA4_ac (ignoring section b) to track a malicious actor that keeps changing their ciphers.

Let me know if you have any questions.

[zschmerber]

@john-althouse this is super helpful thanks! Also do you know where we can find some example logs with JA4+ so we can start mapping the Object into the Schema?

[john-althouse]

Yes, you can download the JA4 binaries as described here: https://github.com/FoxIO-LLC/ja4/blob/main/README.md#binaries
And feed it pcap from here: https://github.com/FoxIO-LLC/ja4/tree/main/pcap
Use option -j to output the logs in json format.

I'm working on the Zeek scripts but it's going to be a few weeks.
We're also working on the Wireshark plugin but that doesn't really output logs.