Add Data Security Finding event class & Data Security object

[jonrau-at-queryai]

Related Issue:

NaN

Description of changes:

BLUF: Add a new Finding category event class: Data Security Finding, add a new object: Data Security to support normalization and standardization of Data Loss Prevention (DLP), Data Security Posture Management (DSPM), and similar findings

Data Security Finding was modeled on Detection Finding and Datastore Activity events, appropriate objects from each were pulled into the finding along with other top-level objects to support a wide amount of normalization. Several objects were added at the top level such as databucket, database, table, file, actor and others to account for the different places that a finding can trigger from and keep track of who owns the datastores or who triggered the finding.

The Data Security object will contain information about the relevant policy(s), the lifecycle of the data (rest/use/transit), the type of tool, the type of detection technique, as well as string values to include the name of the specific detections (or the regex) and the source of the pattern match.

[jonrau-at-queryai]

Based on feedback from @zschmerber will make the following changes

• Add confidentiality to data_security
• Expand enums in confidentiality to include: Private, Restricted, Compartmentalized, Special Access
• Change data_classification_category_uid and data_classification_category to data_type_uid and data_type, respectively.

[zschmerber]

I am wondering if the file object in this class belongs in here?: https://schema.ocsf.io/1.1.0/objects/evidences?extensions=

I'm not sure you need the evidence object but that is how Detections finding has it so I thought I would pose the question.

[jonrau-at-queryai]

I am wondering if the file object in this class belongs in here?: https://schema.ocsf.io/1.1.0/objects/evidences?extensions=

I'm not sure you need the evidence object but that is how Detections finding has it so I thought I would pose the question.

In my initial design that is how I had it, but my thoughts to not use it are twofold:

• Easier searches: If the finding only ever is 1:1 with certain objects, such as src_endpoint and actor.user it can be easier to search against that as a semi-structured object in upstream sources like Amazon Athena or Snowflake, no need to using CROSS JOIN UNNEST or similar computationally hungry operators
• Readability: There are other objects such as databucket and database at the base_event / "top-level" of this finding and not under evidence

Of course, there can be a multitude of data sources implicated by a specific finding too. I guess in that case, when it comes to ETL/ELT systems, is the argument that it is easier to add multiple types of evidence or is it easier to create multiple events and use metadata.correlation_uid to have them all tied together under the same source event.

In the case of multiple sources implicated, no issue adding evidence in favor of actor, src_endpoint, dst_endpoint, et al but I'll need to update it to add databucket, database, table and a few other objects.

I guess this is another case of balancing the data engineering effort (mapping) against the data analysis effort (search, detections, etc.)

[pagbabian-splunk]

This looks really good overall - a couple of things though: enums should be _id not _uid: there are a few that need to be tweaked. Also, some of the new enums are fully defined in the dictionary, and then it seems overloaded exactly the same in the class and object. If the values are unlikely to be overridden, they can be fully defined in the dictionary - otherwise only the 0-Unknown and 99-Other as well as the sibling need be defined in the dictionary, and the class/object can extend or override.

[jonrau-at-queryai]

This looks really good overall - a couple of things though: enums should be _id not _uid: there are a few that need to be tweaked. Also, some of the new enums are fully defined in the dictionary, and then it seems overloaded exactly the same in the class and object. If the values are unlikely to be overridden, they can be fully defined in the dictionary - otherwise only the 0-Unknown and 99-Other as well as the sibling need be defined in the dictionary, and the class/object can extend or override.

Thanks @pagbabian-splunk , just made the required changes. Forgot that the objects and event would inherit from dictionary.json

[floydtree]

@jonrau-at-queryai One quick note, can you add relevant entries in the unreleased section in CHANGELOG.md file? You can refer to the previous entries for reference.

[jonrau-at-queryai]

@jonrau-at-queryai One quick note, can you add relevant entries in the unreleased section in CHANGELOG.md file? You can refer to the previous entries for reference.

Done!

[jonrau-at-queryai]

@floydtree @mikeradka put in both changes you folks wanted

[floydtree]

Thank you! This is great.

[zschmerber]

Nice work!

[Aniak5]

Looks great!

comments are addressed