Detection engineering: il rilevamento come codice, non come artigianato del SOC

La detection engineering nasce per colmare uno squilibrio che il report M-Trends 2026 di Mandiant misura con precisione: nelle intrusioni analizzate l’accesso iniziale passa da chi lo ottiene a chi lo sfrutta in una mediana di ventidue secondi, e lo sfruttamento di vulnerabilità resta il primo modo per entrare, per il sesto anno consecutivo, con il 32 per cento dei casi. L’attaccante è veloce e industrializzato: ottiene l’accesso, lo cede, lo monetizza lungo una catena di operatori specializzati che si scambiano il lavoro in tempi che il difensore fatica anche solo a immaginare.

Il difensore, troppo spesso, lavora con un metodo che appartiene a un’altra epoca. Il problema, quasi sempre, non è la mancanza di strumenti. È il modo in cui le regole di rilevamento vengono prodotte: una alla volta, spesso in reazione all’ultimo incidente, scritte da chi capita di turno, senza versionamento, senza test, senza una misura di ciò che coprono davvero. La detection engineering parte da una premessa scomoda per molti reparti di sicurezza: una regola di rilevamento è software, e va trattata come software. Non come un appunto da incollare nel SIEM.

Dal SOC reattivo al rilevamento progettato

Per anni il lavoro di rilevamento è stato un’attività di reazione. Arriva un alert da un prodotto, l’analista lo gestisce, e quando un attacco sfugge si aggiunge una regola che lo avrebbe intercettato. Il risultato è un magazzino di regole stratificate, di cui nessuno conosce con precisione l’origine, la logica o il tasso di errore. Funziona finché il volume resta gestibile. Smette di funzionare quando le regole diventano migliaia e i falsi positivi seppelliscono i veri.

La detection engineering ribalta l’ordine delle operazioni. Non parte dallo strumento ma dal comportamento dell’avversario, e tratta ogni rilevamento come un artefatto che ha un autore, una motivazione documentata, dei test e un ciclo di vita. È la differenza tra accumulare regole e progettare un sistema di rilevamento. Questa logica non sostituisce il Security Operations Center, ma ne cambia il baricentro: meno tempo speso a smistare allarmi, più tempo speso a costruire e mantenere la capacità di rilevare ciò che conta.

Il punto di partenza è una domanda che il SOC tradizionale si pone di rado: cosa stiamo cercando di rilevare, e perché proprio quello. Non “quali regole abbiamo”, ma “quali comportamenti avversari vogliamo intercettare, e quanto bene li copriamo”.

Il bersaglio giusto: la piramide del dolore

La risposta a quella domanda ha una base concettuale precisa, formulata da David Bianco nel 2013 a partire dalla lettura del report APT1 di Mandiant. La sua piramide del dolore ordina gli indicatori in base a quanto costa all’attaccante cambiarli una volta scoperti. Alla base ci sono gli hash dei file, banali da modificare: bloccarli infastidisce l’avversario per pochi minuti. Salendo si incontrano indirizzi IP, nomi di dominio, artefatti di rete. In cima ci sono le tattiche, le tecniche e le procedure, cioè il modo in cui un attaccante opera. Costringerlo a cambiare quelle significa imporgli un costo reale, perché tocca riprogettare l’attacco, non semplicemente rigenerare un indicatore.

La conseguenza operativa è netta. Una regola che insegue hash e indirizzi IP invecchia nel giro di ore. Una regola che descrive un comportamento, per esempio l’uso anomalo di uno strumento di amministrazione legittimo per muoversi lateralmente, resta valida a lungo e fa male all’avversario. Per questo la detection engineering matura ancora la propria logica sulle tecniche, e usa come vocabolario condiviso il framework MITRE ATT&CK.

La versione 19, rilasciata il 28 aprile 2026, descrive per il dominio Enterprise quindici tattiche, oltre duecento tecniche e centinaia di sotto-tecniche, e viene aggiornata due volte l’anno: proprio in questa release la tattica Defense Evasion è stata divisa in due, Stealth e Defense Impairment, un cambiamento che obbliga chi mantiene rilevamenti a rimappare la propria copertura. Mappare ogni rilevamento a una tecnica di ATT&CK non è un esercizio formale: è il modo per sapere, in concreto, cosa si copre e cosa resta scoperto.

Detection engineering e detection-as-code: il ciclo di vita di una regola

Qui la detection engineering prende la forma che le dà il nome di disciplina ingegneristica. L’approccio detection-as-code applica alle regole le stesse pratiche con cui si sviluppa software di produzione. Ogni rilevamento vive in un repository sotto controllo di versione. Ogni modifica passa da una pull request e da una revisione tra pari. Ogni regola viene testata contro dati di riferimento in una pipeline di integrazione continua prima di arrivare in produzione, e può essere ritirata con un rollback se si comporta male.

Il formato aperto Sigma ha reso questo metodo praticabile su larga scala. Una regola scritta in Sigma, in sintassi YAML leggibile, descrive la logica di rilevamento in modo indipendente dalla piattaforma, e viene poi tradotta nel linguaggio del SIEM o dello strumento di destinazione. Il vantaggio non è cosmetico: la stessa logica diventa portabile, condivisibile, verificabile, e non resta prigioniera del prodotto che la ospita.

Una regola ha un ciclo di vita, non solo una nascita

Trattare il rilevamento come codice impone di pensare alle regole come a oggetti che vivono nel tempo. Una nuova regola entra in modalità di test, dove genera segnalazioni senza aprire incidenti. Segue un periodo di taratura in cui si misura il rapporto tra veri e falsi positivi e si affina la logica. Solo allora passa in produzione con la creazione di incidenti abilitata. E quando un comportamento non è più rilevante, o una tecnica cade in disuso, la regola va ritirata, non lasciata a generare rumore per inerzia. È la fase che quasi nessuno gestisce, e che spiega buona parte dell’alert fatigue che logora i team di sicurezza.

A dare struttura a tutto questo contribuiscono modelli pubblici come il framework ADS di Palantir, che impone a ogni strategia di rilevamento documentazione rigorosa, revisione tra pari, mappatura alle tecniche di ATT&CK e un principio guida esplicito: qualità prima della quantità. Non più regole possibili, ma regole giustificate, ciascuna con una ragione documentata per esistere.

Misurare invece di accumulare

La differenza tra un magazzino di regole e un programma di detection engineering è la misura. Quante delle tecniche rilevanti per la propria superficie di rischio sono effettivamente coperte. Quante regole producono più rumore che valore. Quanto tempo passa tra la pubblicazione di una nuova tecnica e la sua copertura. Senza queste metriche, l’aggiunta continua di regole dà l’illusione della sicurezza mentre erode la capacità di vedere: ogni falso positivo in più è un vero positivo in meno che qualcuno noterà. La copertura misurata su ATT&CK, e non il numero di regole attive, è l’indicatore che racconta lo stato reale del rilevamento.

Perché conta adesso: velocità degli attacchi e obblighi normativi

La tempistica non è neutra. Lo stesso report M-Trends 2026 documenta un ecosistema criminale industrializzato, in cui l’accesso iniziale viene ceduto ad altri operatori in tempi che si misurano in secondi. Quando lo sfruttamento di una vulnerabilità è il primo vettore e la finestra utile per intervenire si comprime, la capacità di rilevare lo sfruttamento prima che la patch sia disponibile diventa decisiva.

È esattamente il terreno della detection engineering: costruire ipotesi di rilevamento sui comportamenti post-compromissione, non attendere la firma del vendor. I cataloghi delle vulnerabilità sfruttate attivamente, come il KEV mantenuto dalla CISA, e i riepiloghi settimanali delle minacce diventano in questo schema non semplici bollettini, ma materia prima per nuove regole, da tradurre in logica di rilevamento nel giro di ore.

C’è poi la pressione normativa. NIS2 e DORA, ciascuna nel proprio perimetro, spostano l’asticella dalla semplice esistenza di strumenti alla dimostrazione di una capacità di rilevamento e risposta effettiva. Un’organizzazione che non sa misurare cosa copre, e non sa documentare come produce e mantiene i propri rilevamenti, si trova esposta non solo agli attacchi ma anche alla prova di adeguatezza che le autorità di vigilanza iniziano a chiedere. La detection engineering, con il suo impianto di documentazione e versionamento, produce per costruzione le evidenze che la conformità richiede.

Una disciplina, non un prodotto da acquistare

Conviene dire con chiarezza ciò che la detection engineering non è. Non è uno strumento da comprare, e nessun vendor la consegna chiavi in mano: è un modo di lavorare, fatto di processo, competenze e cultura del rilevamento. Richiede figure che sappiano leggere la threat intelligence e tradurla in logica, che conoscano i sistemi da difendere abbastanza da distinguere il normale dall’anomalo, e che accettino la disciplina meno gratificante di tutte, la manutenzione di ciò che già esiste. L’automazione e l’AI applicata alla generazione di regole, oggi in rapida diffusione, possono accelerare il lavoro, ma non sostituiscono il giudizio su cosa valga la pena rilevare e a quale costo.

Il vero cambio di paradigma è proprio qui. Finché il rilevamento resta artigianato, la sua qualità dipende dalla persona di turno e si degrada nel tempo. Quando diventa ingegneria, la qualità diventa una proprietà del sistema, misurabile e ripetibile. La detection engineering non promette di vedere ogni attacco, promessa che nessuno può mantenere. Promette qualcosa di più utile: di sapere, in ogni momento, cosa si è in grado di vedere e cosa no. In uno scenario in cui gli avversari si muovono in secondi e i difensori in giorni, ridurre quella incertezza non è un lusso metodologico, è la condizione per restare nel gioco.