You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the v2 validation API attempts to validate if the name property of an observable is "legitimate". However, the definition of what a legitimate name is, is a bit tricky for observables. Consider cases, where we have observables in an array type attribute. The name in such cases, can be represented in multiple ways by different producers.
This basically says variation 1 is what is intended. The documentation for the observable object's name attribute doesn't actually say how to handle arrays.
The full name of the observable attribute. The name is a pointer/reference to an attribute within the OCSF event data. For example: file.name.
I debated this at the time with @pagbabian-splunk and we decided to just "support" the notation without square brackets.
I'd be fine with supporting the three common variations. We just need to run this by Paul and others since it's a small change in direction. (Plus, obviously, a bit of extra work in the validator.)
We would also want to update the Defining and Using Observables document, and the description of the observable object's name attribute.
Currently, the v2 validation API attempts to validate if the
name
property of anobservable
is "legitimate". However, the definition of what a legitimate name is, is a bit tricky for observables. Consider cases, where we have observables in an array type attribute. Thename
in such cases, can be represented in multiple ways by different producers.e.g. Consider the following snippet in an event -
In here, resources.uid is an observable property and depending on the capability of a producer,
name
can be populated in one of the many ways -resources.uid
resources[].uid
resources[0].uid
The current validator fails for anything but case (1), I would consider all 3 to be legitimate choices for the
name
attribute.I would suggest, either removing the check for
name
or allow representation for all 3 cases listed. Happy to discussThe text was updated successfully, but these errors were encountered: