Loki does not handle condition lists in the manner other backends do

[jamesc-grafana]

Within the Sigma specification, conditions can be both a string or a list of string which is fine.

However, pySigma-backend-loki does not exhibit consistent behaviour with other backends breaking out a list of strings into multiple queries, instead pysigma-backend-loki creates multiple queries but groups all of the query terms into the first query.

Taking this Sigma Rule for example:

title: Title
id: 8bcaaeff-3fe4-4793-9fcc-9a61acec6290
description: Short Description
author: Your Name
date: 2023/06/27
logsource:
    category: application
detection:
    selection:
        - Detection Rule
    keywords:
        - Word1
        - Word2
    others:
        - Test
    condition: 
      - selection
      - keywords
      - others

With a Splunk SPL backend we get the following result:

"Detection Rule"

"Word1" OR "Word2"

"Test"

Whilst the Loki backend produces the following queries

{job=~".+"} |= `Detection Rule` |~ `Word1|Word2` |= `Test`

{job=~".+"} 

{job=~".+"} 

[jamesc-grafana]

This appears to be to do with the handling of lists within the backend as a dict will work as expected. The issue is likely that the lists are being pulled up to the top query rather than residing in their own query.

The below snippets support this theory

detection:
  sel1:
    fieldA: valueA
  sel2:
    - valueB
  sel3:
    - valueC
  sel4:
    fieldD: valueD
  condition:
    - sel1
    - sel2
    - sel3
    - sel4

Yields

{job=~".+"} |~ `(?i)valueB` |~ `(?i)valueC` | logfmt | fieldA=~`(?i)valueA`
{job=~".+"} 
{job=~".+"}
{job=~".+"} | logfmt | fieldD=~`(?i)valueD`

[kelnage]

Turns out it was an upstream issue! But the backend will need to be updated to incorporate the upstream fix anyway.