OpenSearch 2.4, uscita il 15 novembre 2022, porta un plugin sperimentale, Security Analytics, che ingerisce log di sicurezza, valuta regole Sigma e produce findings e alert dentro lo stesso cluster che già conserva log e dati di observability (note di rilascio 2.4.0). La documentazione lo dichiara sperimentale e ne sconsiglia l’uso in produzione a questa versione (docs 2.4).

Contesto

OpenSearch nasce nel 2021 come fork delle ultime versioni Apache 2.0 di Elasticsearch e Kibana (la linea 7.10), dopo il cambio di licenza di Elastic del gennaio 2021. La prima release stabile, OpenSearch 1.0, è del 12 luglio 2021, sotto licenza Apache 2.0. Il cluster eredita index, query e plugin di Open Distro for Elasticsearch, fra cui Alerting.

Fino alla 2.4 un cluster OpenSearch poteva conservare i log di sicurezza e definire monitor con il plugin Alerting, ma tradurre una regola di detection in una query restava lavoro manuale dell’operatore. Chi importava il corpus di regole Sigma doveva fare la conversione fuori dal cluster, con un backend sigmac, e gestire a mano la mappatura fra i campi del log e quelli attesi dalla regola. Security Analytics porta questo passaggio dentro OpenSearch.

Architettura

L’unità centrale è il detector. Un detector è legato a un indice di log, a un tipo di log e a un insieme di regole; a ogni intervallo pianificato valuta le regole sui documenti in arrivo e, quando una regola corrisponde, genera un finding (docs 2.4).

La 2.4 copre otto categorie di sorgenti già configurate: Netflow, log DNS, Apache access log, log Windows, AD/LDAP, log di sistema, AWS CloudTrail e Amazon S3 access log. Ogni categoria porta con sé un sottoinsieme delle regole pre-pacchettizzate, attivato a seconda del tipo dichiarato nel detector.

Il corpus pre-pacchettizzato è dichiarato in oltre 2.000 regole Sigma open source (note di rilascio 2.4.0). Sigma è un formato YAML per regole di detection indipendente dal backend, pubblicato in open source da Florian Roth e Thomas Patzke nel 2017; una regola descrive la sorgente di log e la logica di match, e lascia a un converter la traduzione nel linguaggio di query del SIEM di destinazione. Security Analytics importa la regola e la traduce in query OpenSearch; accetta anche regole Sigma personalizzate, da Dashboards o via API.

Il finding è la corrispondenza fra regola, tipo di log ed evento, con la sua severity. L’alert è l’escalation del finding: il detector si appoggia al plugin Alerting già presente nel cluster e manda notifiche su canali configurabili — Slack, Amazon Chime, email — secondo condizioni su match di regola, soglie di severity e tag (docs 2.4).

Punto critico

La parte fragile è la mappatura dei campi. Una regola Sigma è scritta contro nomi di campo logici — per esempio EventID o CommandLine per un log Windows — mentre l’indice OpenSearch contiene i campi così come li ha prodotti la pipeline di ingest, che possono avere tutt’altro nome. Se i due insiemi non coincidono, la regola viene valutata ma non corrisponde mai, e l’assenza di finding diventa indistinguibile dall’assenza di minacce.

Alla creazione del detector, Security Analytics propone una mappatura fra i campi che le regole del tipo di log scelto si aspettano e i campi presenti nell’indice. La parte automatica copre i casi noti; il resto resta all’operatore, che deve controllare la mappatura prima di fidarsi dei findings. È il punto in cui detection-as-code si scontra con schemi di log eterogenei: un detector mal mappato dà un falso senso di copertura.

Implicazioni

Conversione e mappatura finiscono dentro il cluster, e fra il corpus di regole della community e i log già indicizzati resta poco. Chi usa OpenSearch per log e observability tratta la detection come un’estensione dello stesso cluster, non come un secondo sistema da alimentare con copie dei dati.

Poi c’è la licenza: OpenSearch e il plugin sono Apache 2.0, approvata OSI. Per chi ha vincoli sull’uso di componenti con licenze non-OSI dopo il cambio di Elastic del 2021, Security Analytics è una base self-hosted senza ambiguità di licenza. E chi ha già monitor e canali di notifica configurati sul plugin Alerting ne riusa l’infrastruttura.

Limiti

Il plugin è etichettato sperimentale nella 2.4 e la documentazione ne sconsiglia l’uso in produzione: schema delle API, comportamento dei detector e formato dei findings possono cambiare nelle release successive (docs 2.4).

Sul piano funzionale, la 2.4 valuta le regole su un singolo tipo di log per detector: non c’è correlazione fra findings di detector diversi, quindi le catene di attacco che attraversano più sorgenti — per esempio un accesso CloudTrail seguito da attività su un endpoint Windows — il plugin non le ricostruisce. La copertura dipende poi dal corpus Sigma: una tecnica senza una regola corrispondente non genera findings, e le oltre 2.000 regole pre-pacchettizzate sono un punto di partenza, non un inventario completo delle tecniche MITRE ATT&CK. Resta il lavoro di tuning per tagliare i falsi positivi sul contesto specifico di ogni sorgente.

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/insights/opensearch-security-analytics/

Immagine di copertina: Schermata di una dashboard Kibana con grafici, istogrammi e pannelli per la visualizzazione e l’analisi di dati di log indicizzati — schermata di Klapi, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Kibana_demo_screenshot.jpg