Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
Describe the issue:
I am trying to understand how OpenSearch Security Analytics detectors analyze incoming documents internally and match them against detection rules to generate findings, specifically around case sensitivity.
I created a detector on a custom index and added a Sigma-based detection rule that uses |contains on a field mapped as text. Based on my understanding of OpenSearch, text fields are analyzed and therefore should behave in a case-insensitive manner.
However, in practice, the detector only triggers when the value matches the exact case used in the rule. If the same logical value appears in a different case (for example, uppercase path segments), the detector does not create a finding.
This makes it look like Security Analytics detectors are treating text fields as case-sensitive for contains matching, which contradicts my understanding.
I want to clarify:
- Is this the expected behavior of OpenSearch Security Analytics detectors?
- How exactly does the detector evaluate documents internally when applying Sigma rules?
- Is there a supported way to make detectors perform case-insensitive matching at rule evaluation time, without modifying or normalizing the ingested data?
Configuration:
Index Mapping
I created an index with aliases for Sigma-style fields. The relevant mapping is shown below:
{
“EventId”: {
“type”: “alias”,
“path”: “eventName”
},
“EventType”: {
“type”: “alias”,
“path”: “log.attributes.EventType”
},
“Image”: {
“type”: “alias”,
“path”: “log.attributes.Image”
},
“TargetObject”: {
“type”: “alias”,
“path”: “log.attributes.TargetObject”
},
“log”: {
“properties”: {
“attributes”: {
“properties”: {
“EventType”: {
“type”: “keyword”
},
“Image”: {
“type”: “text”,
“fields”: {
“keyword”: {
“type”: “keyword”
}
}
},
“TargetObject”: {
“type”: “text”,
“fields”: {
“keyword”: {
“type”: “keyword”
}
}
}
}
}
}
}
}
TargetObject is intentionally mapped as a text field (with a keyword subfield) because I want case-insensitive behavior while preserving the original value for display.
Detection Rule:
id: 07bdd2f5-9c58-4f38-aec8-e101bb79ef8d
logsource:
product: xdr_windows
title: Terminal Server Client Connection History Cleared - Registry
description: Detects the deletion of registry keys containing the MSTSC connection history
level: high
status: test
detection:
selection1:
EventType: DeleteValue
TargetObject|contains: \Microsoft\Terminal Server Client\Default\MRU
selection2:
EventType: DeleteKey
TargetObject|contains: \Microsoft\Terminal Server Client\Servers
condition: 1 of selection*
I indexed the following document:
POST registry_delete_key/_doc
{
“traceId”: “31978fb5522c4e609d5e672aa8a6fa09”,
“eventName”: 40001,
“log.attributes.EventType”: “DeleteKey”,
“log.attributes.TargetObject”: “\REGISTRY\USER\MICROSOFT\TERMINAL SERVER CLIENT\SERVERS\Users”,
“log.attributes.Image”: “C:\Program Files\Microsoft Office\root\Office16\SDXHelper.exe”,
“time”: “2025-12-09T13:05:38.611Z”
}
This value logically matches the rule condition:
\Microsoft\Terminal Server Client\Servers\
but the detector does not trigger because the case differs (MICROSOFT, TERMINAL SERVER CLIENT, SERVERS).
If I index the same value using the exact same case as in the rule, the detector triggers correctly.
Expected vs Actual Behavior
Expected
Since TargetObject is a text field, |contains matching should be case-insensitive.The detector should generate a finding regardless of case differences.
Actual
The detector only matches when the case exactly matches the rule string.This makes text fields behave like case-sensitive fields for contains matching.
Questions:
- Is this case-sensitive behavior for text fields expected in OpenSearch Security Analytics detectors?
- How does the detector internally evaluate Sigma contains conditions against analyzed fields?
- Is there any supported way to make detectors perform case-insensitive matching at rule evaluation time, without:
- modifying ingested documents
- lowercasing values at ingest
- or switching to keyword fields with normalizers?
I want to preserve the original field values exactly as received (for customer visibility), while still allowing case-insensitive detection logic.