ocsf-server
ocsf-server copied to clipboard
[Validation API] - observables.name validation issue
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.
e.g. Consider the following snippet in an event -
"resources": [
{
"owner": {
"account": {
"uid": "111122223333"
}
},
"type": "AWS::KMS::Key",
"uid": "arn:aws:kms:us-west-2:111122223333:key/example1"
},
{
"owner": {
"account": {
"uid": "111122223333"
}
},
"type": "AWS::KMS::Key",
"uid": "arn:aws:kms:us-west-2:111122223333:key/example2"
}
],
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.uidresources[].uidresources[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 discuss
These variations are discussed in Appendix 1 of the Observables document: https://github.com/ocsf/ocsf-docs/blob/main/Articles/Defining%20and%20Using%20Observables.md#appendix-1-attribute-paths
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
nameis a pointer/reference to an attribute within the OCSF event data. For example:file.name.
From: https://schema.ocsf.io/objects/observable
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.