Principi della detection-as-code

Detection-as-Code (DaC) applica i principi dell'ingegneria del software alle detection di sicurezza. Anziché modificare manualmente le regole nella console di un SIEM, le detection risiedono in file di testo sotto controllo di versione e vengono distribuite tramite una pipeline.

I vantaggi sono concreti:

• Revisionabili tramite pull request
• Riproducibili in ambienti diversi
• Testabili prima di raggiungere la produzione
• Verificabili tramite audit, con lo storico di chi ha modificato cosa e perché

Una detection diventa un artefatto di cui è possibile confrontare le differenze, fare rollback e comprendere il funzionamento, come per qualsiasi altro codice.

Ogni detection viene archiviata come file autonomo, in genere YAML o in un linguaggio di query del fornitore, con commit in un repository Git. La struttura del repository rispecchia il modo in cui è organizzata la copertura.

Una struttura comune separa le regole per piattaforma e tattica:

Ogni detection nuova o modificata passa attraverso una pull request. Un secondo ingegnere esamina la logica, il rischio di falsi positivi e la mappatura ATT&CK prima del merge.

Chi effettua la revisione si chiede:

• La logica corrisponde alla minaccia descritta?
• Quale attività legittima potrebbe attivarla?
• La gravità e il riferimento ATT&CK sono corretti?
• I test coprono i veri e falsi positivi?

Questo permette di individuare errori che sfuggirebbero a un singolo analista mentre modifica il SIEM alle 2 di notte.

Una pipeline di integrazione continua viene eseguita automaticamente a ogni push. Impone controlli di qualità prima che una regola possa essere integrata.

Fasi CI tipiche per un repository basato su Sigma:

Una volta eseguito il merge, un job di distribuzione converte le regole portabili nel linguaggio di query di destinazione e le invia al SIEM o all'EDR tramite API.

Per Sigma, in genere si esegue un convertitore come sigma convert con un backend corrispondente alla piattaforma in uso (Splunk, Elastic, Microsoft Sentinel). La pipeline carica quindi le ricerche salvate o le regole analitiche generate.

Nessuno incolla query in una console. Lo stato distribuito corrisponde sempre a quello presente in main.

Una detection senza test è un'ipotesi. DaC associa ogni regola a dati di test: campioni di log che dovrebbero attivarla (veri positivi) e campioni benigni che non dovrebbero (falsi positivi).

I test vengono eseguiti in CI, quindi una modifica che compromette la copertura o reintroduce rumore interrompe la build prima del merge. È la principale fonte di affidabilità quando si effettua il refactoring delle regole su larga scala.

Consideri i metadati una componente di primo livello. Ogni detection registra il proprio status mentre attraversa il ciclo di vita:

• experimental — scritto di recente, da monitorare attentamente
• test — in esecuzione, ma non ancora considerato affidabile per gli alert
• stable — collaudato, con un basso tasso di falsi positivi
• deprecated — sostituito o ritirato

Monitorare lo status nel file consente di promuovere, declassare e ritirare le regole deliberatamente, anziché lasciare che una logica obsoleta rimanga in produzione.

Un vantaggio fondamentale di DaC è scrivere la logica di detection una sola volta in un formato indipendente dal fornitore, quindi compilarla per molti backend. Sigma è lo standard de facto per le detection basate sui log.

Lo stesso file di regola può essere destinato a Splunk SPL, Elastic Lucene/EQL, Microsoft Sentinel KQL e altri backend mediante mappature dei campi specifiche per pipeline. Si evita di riscrivere la stessa idea cinque volte e si evita il vendor lock-in.

Origini di log diverse danno nomi diversi agli stessi dati. Un evento di creazione di processo di Sysmon usa Image; un log Windows Security può usare NewProcessName. Le pipeline di elaborazione colmano questa differenza.

Le pipeline trasformano i nomi generici dei campi Sigma nei campi esatti utilizzati dai dati acquisiti, così una singola regola logica si adatta senza difficoltà a qualunque schema venga acquisito dal SIEM. Mantenere le pipeline in modo centralizzato significa correggere una modifica allo schema una sola volta, non per ogni regola.

Come il codice delle applicazioni, le detection passano attraverso gli ambienti prima di arrivare in produzione. Un flusso tipico va da dev a staging fino a prod.

• Dev — scrivere le regole ed eseguire i test unitari in CI
• Staging — distribuire su una copia della telemetria reale in modalità di audit
• Prod — promuovere quando il tasso di falsi positivi è accettabile

La promozione è un passaggio deliberato e sottoposto a revisione, legato allo status del ciclo di vita della regola, non un effetto casuale del merge. Questo rilascio graduale rispecchia la disciplina dell'avviso seguito dal blocco utilizzata con le detection inline.

Poiché le rilevazioni sono codice, è possibile misurare la copertura a livello programmatico. Colleghi ogni regola alle tecniche MITRE ATT&CK e generi una heatmap di ciò che è coperto e di ciò che non lo è.

Metriche utili da monitorare nel tempo:

• Tecniche coperte rispetto al totale previsto dal modello delle minacce
• Tasso di falsi positivi per regola
• Tempo medio dall'idea della regola alla produzione
• Numero di regole per ogni stato del ciclo di vita

Questi numeri trasformano la detection engineering da un insieme di aneddoti in un programma gestito.

Verifichi la propria comprensione dei fondamenti della Detection-as-Code.

La Detection-as-Code applica alle rilevazioni il rigore dell'ingegneria del software:

• Le regole sono archiviate come file versionati in Git
• Le modifiche passano attraverso la revisione delle pull request
• La CI esegue automaticamente il linting, la convalida e i test
• Le regole unite vengono distribuite tramite pipeline, mantenendo l'ambiente di produzione sincronizzato con main
• I test proteggono da falsi positivi e regressioni
• La portabilità (Sigma + pipeline) consente di utilizzare una sola regola con molti backend
• Metadati, ciclo di vita e metriche trasformano le rilevazioni in un programma gestito

Nel prossimo passaggio, verranno scritte le regole portabili vere e proprie con Sigma.