Feature request: JSON support

[0xd13a]

Hello,

Are there plans to add JSON support to the spec? A lot of modern log sources contain not just fields of simple types, but also fields that are JSON documents. Matching values inside JSON documents is frequently needed, and currently the only available options are re and contains modifiers, which will be unreliable for this purpose.

I see 2 ways to support this - direct paths and path queries.

Suppose we are writing a Sigma rule for detecting sign-ins from a specific country in Azure. Azure SigninLogs log has LocationDetails field that is a JSON document. Here's an example:

{
  "city":"Pyongyang",
  "state":"Pyongyang",
  "countryOrRegion":"KP",
  "geoCoordinates":
    {
      "latitude":39.045334552789726,
      "longitude":125.76170735387343
    }
}

1. Direct path could be implemented using a simple . notation. For example, to match country code in the example above we could have the following (note how we take the log field name and then proceed to match fields inside the JSON document):

detection:
    selection:
        LocationDetails.countryOrRegion: 'KP'

2. A path query would be a more versatile way to achieve the same (and would complement the 1st proposal to handle more complex cases). JSONPath could be used for this purpose. The same condition could be rewritten as:

detection:
    selection:
        LocationDetails|jsonpath('$.countryOrRegion'): 'KP'

Of course one could come up with more advanced examples of using paths, but hopefully the idea is clear.

Comments/thoughts?

Thanks!

Dmitriy

[nasbench]

cc @thomaspatzke

[thomaspatzke]

Sigma itself doesn't conducts any field extraction and it's up to the log backend to provide these extractions. Usually this ends up in the dotted notation and it's already used in the SigmaHQ repo, e.g. in the cloud logs. So we can consider the dotted notation as already given. Perhaps we should add it more explicitly in the taxonomy specification as general rule for Jon-based logs.

I wouldn't go so far to allow path specifications in rules with JSONPath because such rules wouldn't be generic anymore but require that the backend supports the path query language.

[Res260]

For discussion's sake:

I wouldn't go so far to allow path specifications in rules with JSONPath because such rules wouldn't be generic anymore but require that the backend supports the path query language.

Doesn't this thinking also apply to the fieldref modifier?

[thomaspatzke]

Doesn't this thinking also applies to the fieldref modifier?

Partially yes. It's a feature missing in some backends. It also applies to correlations and likely others. The main reason I see here is that JSONPath expressions would be most likely unsupported by most backends while the other features mentioned above are only unsupported for some.