Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[Validation API] - observables.name validation issue #127

Open
floydtree opened this issue Feb 6, 2025 · 1 comment
Open

[Validation API] - observables.name validation issue #127

floydtree opened this issue Feb 6, 2025 · 1 comment

Comments

@floydtree
Copy link
Contributor

floydtree commented Feb 6, 2025

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 -

  1. resources.uid
  2. resources[].uid
  3. 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 discuss

@rmouritzen-splunk
Copy link
Contributor

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 name is 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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants