Add JA4+ Network Traffic Fingerprints

[Aniak5]

Related Issue:

#834

Description of changes:

• Added ja4_fingerprint objects.
• Added ja4_fingerprint_list as a list of ja4_fingerprint objects.
• Added ja4_fingerprint_list to base network event class.

[Aniak5]

@zschmerber @mikeradka @pagbabian-splunk we have had many discussions about this in the past, please let me know what y'all think.

[zschmerber]

Do we want to add a way to represent the a,b,c and d sections in the OCSF

https://blog.foxio.io/ja4+-network-fingerprinting

[Aniak5]

Do we want to add a way to represent the a,b,c and d sections in the OCSF

https://blog.foxio.io/ja4+-network-fingerprinting

I was wary of adding a, b, c, d to the dictionary... We could add a component_id and define those there as enums. What do you think?

[zschmerber]

@Aniak5 I think Component enum makes sense. component_id will be a sorta strange as the enums will be as 1=a 2=b 3=c 4=d

[floydtree]

@Aniak5 @zschmerber I think we should flatten it a bit. I favor adding ja4_component_a (string) ja4_component_b (string) and so on, as that would be simpler approach for analyst usecases. With the current approach we would be adding an array of ja4_component objects, which then would necessitate an analyst to first deal with array of objects, which is not ideal and then lookup an enum within those object just to know which component they are dealing with. I feel this complicates a simple lookup usecase.

[zschmerber]

@floydtree I am not sure flattening would work as there are currently 9 types of Ja4+ hash:

This would mean ja4H_component_a, ja4Server_component_a...... would have to exist.
unless you are saying the ja4H_component_a is just a name for a and we should have 4 objects to represent that?

[zschmerber]

#834

I thinks calling it sections makes more sense and it seems to be what the creators call the peaces of JA4. I also like just a,b,c,d but not sure how it affects the dictionary. @rickmode any thoughts on this ?

{
   "type_id": <enum for different JA4 fingerprints>,  // required
   "type": <string form of enum>,                     // optional
   "value": <string -- the actual fingerprint>,       // required
   "section": {                                  // 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]

No, @zschmerber that's not what I meant. The type of JA4 is anyhow represented by the type_id enum in the ja4_fingerprint object. All I am saying is, the component/section values themselves can be stored in the flattened fields ( I leave the naming to you, no strong preference there) in the ja4_fingerprint object. Each object is anyhow coupled with one ja4 type.

Perhaps better to discuss this in a call.

[zschmerber]

{
   "type_id": <enum for different JA4 fingerprints>,  // required
   "type": <string form of enum>,                     // optional
   "value": <string -- the actual fingerprint>,       // required
   "section_a": <string>, // a section of JA4,      // optional
   "section_b": <string>, // b section of JA4,     // optional
   "section_c": <string>, // c section of JA4,     // optional
   "section_d": <string>, // d section of JA4,    // optional
}

@Aniak5 thoughts on this new format? @mikeradka @floydtree @rickmode and I like this format.

[Aniak5]

{
   "type_id": <enum for different JA4 fingerprints>,  // required
   "type": <string form of enum>,                     // optional
   "value": <string -- the actual fingerprint>,       // required
   "section_a": <string>, // a section of JA4,      // optional
   "section_b": <string>, // b section of JA4,     // optional
   "section_c": <string>, // c section of JA4,     // optional
   "section_d": <string>, // d section of JA4,    // optional
}

@Aniak5 thoughts on this new format? @mikeradka @floydtree @rickmode and I like this format.

Great suggestion, I like that a lot! Will make these changes.

[mikeradka]

Looks good

[floydtree]

looks good, thanks!