Una regola di detection scritta per un Security Information and Event Management (SIEM) non è portabile: la logica in Splunk Search Processing Language non gira su un cluster Elasticsearch, e una query Ariel Query Language per QRadar va riscritta per ArcSight. La stessa idea di rilevamento — “un processo whoami lanciato da un servizio di sistema” — esiste in tante implementazioni quanti sono i prodotti su cui deve girare. Sigma, pubblicato su GitHub da Florian Roth e Thomas Patzke, propone di scrivere quella logica una volta in YAML e di lasciare a un compilatore la traduzione verso il motore di ricerca di turno.

Contesto e problema

Il contenuto di detection vive più a lungo del prodotto che lo esegue. Un’organizzazione cambia SIEM per ragioni di costo o di contratto, un fornitore di servizi gestiti (Managed Security Service Provider, MSSP) deve servire clienti su stack diversi, un report pubblico su una minaccia descrive un comportamento osservabile su qualunque endpoint Windows. In tutti questi casi la conoscenza investigativa — quali campi guardare, quali valori correlare — resta la stessa, ma rimane intrappolata nella sintassi di un singolo motore.

Gli autori la spiegano per analogia con strumenti già consolidati: Snort descrive il traffico di rete, YARA descrive i file, e un equivalente per gli eventi di log mancava. Sigma riempie quella casella con un formato testuale, leggibile, versionabile, che descrive cosa cercare e lascia a un altro livello il come tradurlo.

Architettura del formato

Una regola Sigma è un documento YAML con poche sezioni. La parte identificativa contiene title, una description, l’autore e le references ai materiali pubblici da cui la regola deriva. Il campo status segnala se la regola è sperimentale o stabile.

Il lavoro vero sta in due sezioni: logsource e detection.

logsource dichiara la sorgente: quale prodotto (product: windows), quale servizio (service: security) o categoria di evento (category: process_creation). È una tassonomia astratta, non i nomi di campo del SIEM finale.

detection definisce uno o più blocchi di selezione e una condition booleana che li combina. Un esempio minimo:

logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\whoami.exe'
        ParentImage|endswith: '\services.exe'
    condition: selection

I nomi di campo (Image, ParentImage) sono quelli della telemetria normalizzata — per Windows, il modello dei record prodotti da Sysmon. La regola non sa nulla di come quel campo si chiami nello schema del SIEM di destinazione.

Il converter sigmac

La traduzione la fa sigmac, lo script Python incluso nel repository. Prende una regola, un backend di destinazione e una configurazione che fa da ponte fra i nomi astratti della regola e i nomi reali nell’installazione:

sigmac -t splunk -c splunk-windows rule.yml

Il file di configurazione (splunk-windows nell’esempio) contiene il field mapping: dice che Image, nel contesto Splunk-Windows, corrisponde a un certo nome di campo indicizzato, e così per gli altri. È il punto in cui un formato astratto incontra la realtà di un’installazione concreta, e da cui dipende se l’output sarà usabile o no.

I backend disponibili oggi coprono i motori più diffusi: Splunk, Elasticsearch (sia query string sia Query DSL), Kibana, Logpoint, QRadar, ArcSight, oltre a bersagli di servizio come grep per i test rapidi. Ogni backend è una classe Python che rende la struttura condition nella sintassi nativa.

Punto critico: la qualità sta nel mapping

Il formato YAML è la parte facile e visibile. Se Sigma funzioni davvero in produzione lo decide lo strato di mappatura fra il logsource astratto e lo schema reale. Una regola corretta tradotta con una configurazione sbagliata produce una query sintatticamente valida che non corrisponde a niente — o, peggio, una query che corrisponde a tutto.

Due dipendenze rendono il problema concreto. La prima è la normalizzazione dei log a monte: se la telemetria non raccoglie i campi che la regola assume (per Windows, una configurazione Sysmon che logghi process_creation con la riga di comando completa), la regola non ha materia su cui agire. La seconda è la correttezza del field mapping per quel SIEM: ogni installazione indicizza i campi con nomi propri, e il mapping va tenuto allineato allo schema effettivo.

In pratica Sigma sposta lo sforzo dalla riscrittura della logica alla manutenzione delle configurazioni di backend. Conviene quando le regole sono molte e gli ambienti pochi; conviene meno quando ogni ambiente ha uno schema di log a sé e nessuno mantiene il mapping.

Implicazioni operative

Per chi gestisce detection content, il formato abilita un paio di pratiche concrete. Le regole diventano artefatti di testo: stanno in un repository Git, si rivedono con una pull request, si versionano. Un report pubblico su una campagna può uscire accompagnato da una regola Sigma che chiunque applica al proprio stack, qualunque sia il prodotto.

Il riferimento alle tecniche di attacco catalogate — il modello MITRE ATT&CK, pubblico dal 2015 — si può annotare nei metadati della regola, e dà un vocabolario comune per ragionare su cosa una regola intende coprire, al di là dei dettagli del log.

Limiti

Sigma descrive condizioni su singoli eventi e correlazioni semplici, espresse come combinazioni booleane di selezioni. La logica di rilevamento che richiede stato, sequenze temporali estese o aggregazioni statistiche resta fuori dal modello: va espressa nativamente nel motore di destinazione, fuori da Sigma.

Il progetto è giovane. La copertura dei backend è disomogenea — alcuni motori traducono l’intero spettro delle condizioni, altri solo un sottoinsieme — e le configurazioni di mapping per gli ambienti reali ricadono in gran parte su chi adotta lo strumento. Il valore di Sigma cresce con la dimensione della libreria di regole condivise e con la cura messa nei file di configurazione; e nessuna delle due cresce da sé.

Immagine di copertina: Due operatori seduti davanti a una parete di monitor in un Security Operations Center, con dashboard e grafici di rete sugli schermi — foto di UMD-Eskin, pubblico dominio — https://commons.wikimedia.org/wiki/File:SOC_Security_Monitors.jpg