OpenSearch 2.4, released on 15 November 2022, brings an experimental plugin, Security Analytics, that ingests security logs, evaluates Sigma rules, and produces findings and alerts inside the same cluster that already holds logs and observability data (2.4.0 release notes). The documentation declares it experimental and advises against production use at this version (2.4 docs).
Context
OpenSearch began in 2021 as a fork of the last Apache 2.0 versions of Elasticsearch and Kibana (the 7.10 line), following Elastic’s licence change of January 2021. The first stable release, OpenSearch 1.0, is dated 12 July 2021, under the Apache 2.0 licence. The cluster inherits the indices, queries, and plugins of Open Distro for Elasticsearch, Alerting among them.
Up to 2.4, an OpenSearch cluster could store security logs and define monitors with the Alerting plugin, but translating a detection rule into a query stayed manual work for the operator. Anyone importing the Sigma rule corpus had to run the conversion outside the cluster, with a sigmac backend, and hand-manage the mapping between log fields and the fields a rule expects. Security Analytics brings that step inside OpenSearch.
Architecture
The central unit is the detector. A detector is bound to a log index, a log type, and a set of rules; at each scheduled interval it evaluates the rules against incoming documents and, when a rule matches, generates a finding (2.4 docs).
The 2.4 release covers eight pre-configured source categories: Netflow, DNS logs, Apache access logs, Windows logs, AD/LDAP, system logs, AWS CloudTrail, and Amazon S3 access logs. Each category carries a subset of the pre-packaged rules, activated according to the type declared in the detector.
The pre-packaged corpus is stated at over 2,000 open-source Sigma rules (2.4.0 release notes). Sigma is a backend-agnostic YAML format for detection rules, open-sourced by Florian Roth and Thomas Patzke in 2017; a rule describes the log source and the match logic, and leaves translation into the target SIEM’s query language to a converter. Security Analytics imports the rule and translates it into OpenSearch queries; it also accepts custom Sigma rules, from Dashboards or through the API.
A finding is the match between rule, log type, and event, with its severity. The alert is the escalation of a finding: the detector relies on the Alerting plugin already present in the cluster and sends notifications over configurable channels — Slack, Amazon Chime, email — under conditions over rule matches, severity thresholds, and tags (2.4 docs).
The critical part
The fragile part is field mapping. A Sigma rule is written against logical field names — say EventID or CommandLine for a Windows log — while the OpenSearch index holds fields as the ingest pipeline produced them, which may carry entirely different names. If the two sets do not coincide, the rule is evaluated but never matches, and the absence of findings becomes indistinguishable from the absence of threats.
At detector creation, Security Analytics proposes a mapping between the fields the rules of the chosen log type expect and the fields present in the index. The automatic part covers the known cases; the rest is on the operator, who has to check the mapping before trusting the findings. This is where detection-as-code runs into heterogeneous log schemas: a badly mapped detector gives a false sense of coverage.
Implications
Conversion and mapping end up inside the cluster, and little stands between the community rule corpus and the logs already indexed. Anyone running OpenSearch for logs and observability treats detection as an extension of the same cluster, not a second system to feed with copies of the data.
Then there is the licence: OpenSearch and the plugin are Apache 2.0, OSI-approved. For those constrained against using components under non-OSI licences after Elastic’s 2021 change, Security Analytics is a self-hosted base with no licensing ambiguity. And whoever already has monitors and notification channels configured on the Alerting plugin reuses that infrastructure.
Limits
The plugin is labelled experimental in 2.4 and the documentation advises against production use: the API schema, detector behaviour, and finding format may change in later releases (2.4 docs).
Functionally, 2.4 evaluates rules against a single log type per detector: there is no correlation across findings from different detectors, so attack chains spanning multiple sources — for instance a CloudTrail access followed by activity on a Windows endpoint — the plugin does not reconstruct. Coverage then depends on the Sigma corpus: a technique without a matching rule produces no findings, and the 2,000-plus pre-packaged rules are a starting point, not a complete inventory of MITRE ATT&CK techniques. The tuning work to cut false positives against each source’s specific context remains.
https://opensearch.org/blog/opensearch-2-4-is-available-today/ https://docs.opensearch.org/2.4/security-analytics/index/ https://docs.opensearch.org/2.4/security-analytics/sec-analytics-config/index/ https://github.com/opensearch-project/security-analytics https://github.com/SigmaHQ/sigma https://www.noze.it/en/insights/opensearch-security-analytics/
Cover image: Screenshot of a Kibana dashboard with charts, histograms and panels for visualizing and analyzing indexed log data — screenshot by Klapi, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Kibana_demo_screenshot.jpg