Add rule_violations to data_security object

[franspigel]

Related Issue:

#1635

Description of changes:

• create a new object: rule_violation
• rule_violation contains a rule object and an array of discovery_detail
• add an array of rule_violation to data_security

[github-actions]

Schema Description Review

Automated suggestions for improving description clarity for LLM consumption. These are advisory — not required changes.

Suggestions

1. Object/Class: rule_violation
   • Attribute: discovery_details
   • Issue: Typo in description affects clarity
   • Current: "Describes the circumstances of the rule violation ocurrences. For example, sensitive data being communicating, thus breaking some security rule."
   • Suggested: "Describes the circumstances of the rule violation occurrences. For example, sensitive data being communicated, thus breaking some security rule."

CHANGELOG Issues

1. Line "Added 'rule_violation' object..." uses single quotes instead of backticks around rule_violation - should be: "Added rule_violation object..."
2. Several CHANGELOG entries reference issue links (data_security object does not support multiple policy/rule infractions in one incident #1635) instead of PR links. CHANGELOG entries must end with PR reference links in the format [#NNNN](https://github.com/ocsf/ocsf-schema/pull/NNNN)

Summary

The descriptions are generally clear and well-structured for LLM comprehension. The main issues are a minor typo in the discovery_details description and CHANGELOG convention violations that need to be addressed for consistency.

[pagbabian-splunk]

Although I had suggested to structure things this way, there may also be an alternative depending on how you see the logs formatted from the various DLP products.

The PR approach pairs one rule with one discovery. If the same rule applies to other discoveries, the entire structure with the same rule is created as another element of the array.

Alternatively, each rule_violation could be a one-to-many object, with a single rule but an array of discovery_details. It is slightly more compact, and keeps the rule closely tied to the discoveries, but introduces an additional array, as there still needs to be an array of rule_violation objects either way.

[floydtree]

Here's a key concern with this approach -
(there are a few other minor issues - spellings, description issue and changelog issue - but I am ignoring those for now)
Adding rule_violations {rule, discovery_details} to the data_security object creates overlapping paths for the same attribute. discovery_details is already present in the data_security object i.e. -

• data_security.discovery_details[]
• data_security.rule_violations[].discovery_details[]

A simpler alternative to solve for the problem presented in #1635 is to add a rule (or rules[] if you anticipate more than one rule for the same discovery) to discovery_details. By doing this each discovery can be mapped to the rule/s in question without introducing redundancy.

Another thing that needs to be clarified is, relation between a policy and a rule especially in the context of data_security object. I would imagine policy being higher in the hierarchy, meaning a policy can contain multiple rules. But we need to update descriptions to be more prescriptive with the schema's intentions.

--
@franspigel If you want to discuss more, it would be great if you could join one of our weekly calls. (General call or the System/Findings call would be appropriate for this topic) Details of the call are in the #general slack channel. (https://github.com/ocsf#slack-workspace)