Detection engineering nel Security Operation Center: come si costruiscono le regole

La detection engineering è la disciplina che progetta, costruisce e mantiene le regole con cui un Security Operation Center (SOC) rileva le minacce. Non è il lavoro visibile dell’analista che risponde a un alert: è il lavoro silenzioso che decide quali alert vengono generati, con quale accuratezza e per quali scenari di attacco. In un Security Operations Center, la qualità della detection engineering determina la qualità di tutto il resto.

Cos’è e cosa non è la detection engineering

Una regola di rilevamento è un’istruzione che dice al SIEM: "quando vedi questa combinazione di eventi, genera un alert". Scrivere una regola è semplice. Scrivere una regola che rileva attacchi reali senza generare centinaia di falsi positivi è un’attività ingegneristica complessa.

La detection engineering non è un’attività di routine di L1. Si colloca tra il security engineering — che gestisce l’infrastruttura del SOC — e l’analisi operativa. Uno dei risultati del 2025 State of Detection Engineering di Anvilogic mostra che in molte organizzazioni non è ancora riconosciuta come ruolo autonomo, ma viene inclusa nelle responsabilità del security engineer insieme ad altre attività come monitoring, incident response e amministrazione dei sistemi (Anvilogic, 2025).

Come si costruisce una regola di detection

Il processo parte sempre dall’identificazione di una minaccia reale da rilevare, tipicamente mappata su una tecnica del framework MITRE ATT&CK. Ogni tecnica ha un codice univoco — per esempio T1055 (Process Injection) o T1078 (Valid Accounts) — che descrive il comportamento dell’attaccante indipendentemente dagli strumenti che usa. Progettare detection basate sui comportamenti, non sulle firme di malware specifici, rende le regole più durature e difficili da eludere (Palo Alto Networks, 2025).

Le fasi operative di costruzione di una regola seguono tipicamente questa sequenza:

Definizione dell’obiettivo. Quale tecnica di attacco si vuole rilevare? Quali sono le fonti di log necessarie per rilevarlo? Sono già onboarded nel SIEM o richiedono un’attività di log onboarding preliminare?

Scrittura della logica di detection. La regola viene scritta nel linguaggio di query del SIEM (SPL per Splunk, KQL per Microsoft Sentinel, ecc.) o in formato Sigma: uno standard aperto che può essere convertito per diversi SIEM. La regola deve essere abbastanza specifica da non generare rumore, abbastanza ampia da non perdere varianti dell’attacco.

Test e validazione. La regola viene testata su dati storici e, dove possibile, su simulazioni controllate dell’attacco che si vuole rilevare. L’obiettivo è verificare che scatti nei casi corretti e non scatti nei casi normali.

Tuning continuo. Una regola non è mai definitiva. Man mano che cambia l’ambiente, cambiano i comportamenti normali degli utenti e dei sistemi, e la regola va ricalibrata. I falsi positivi non sono solo un fastidio operativo: distraggono il team da minacce reali e, se ignorati sistematicamente, creano blind spot.

Il problema dei falsi positivi

Un falso positivo è un alert che il SIEM genera per un’attività legittima, non per un attacco. In un SOC attivo, i falsi positivi consumano una quota significativa del tempo degli analisti: secondo ricerche di settore, i security expert spendono il 27% del loro tempo a gestire falsi positivi (Trend Micro, citato in ACM Computing Surveys, 2025).

Il processo di tuning si basa sul feedback sistematico degli analisti L1 e L2, che nel lavoro quotidiano di triage accumulano la conoscenza empirica di quali alert sono rumorosi e perché. Molti SOC organizzano cicli settimanali di revisione tra il team di detection engineering e il team operativo proprio per trasferire questo feedback nelle regole (Sumo Logic, 2025).

Elaborazione su Anvilogic, Sumo Logic, Sprinto, 2025

Perché il SOC Manager deve presidiare la detection engineering

La detection engineering non è solo un tema tecnico: è una leva di governance del servizio. Un SOC Manager che non presidia questo processo si trova a gestire un team che risponde agli alert sbagliati, o che non rileva le tecniche di attacco più rilevanti per i propri clienti.

Le metriche chiave da monitorare includono il tasso di falsi positivi per regola, la copertura delle tecniche MITRE ATT&CK rispetto all’esposizione dell’ambiente, il backlog di regole da creare o aggiornare e il tempo medio di risposta a un alert reale. Monitorare la copertura ATT&CK nel tempo — passare, per esempio, dal 45% al 68% di tecniche rilevate tra un trimestre e l’altro — è uno degli indicatori di maturità SOC più comunicabili verso il management del cliente (CyberDefenders, 2026).

FAQ

Cos’è una regola di detection in un SIEM?

È un’istruzione che definisce quando il SIEM deve generare un alert, basandosi su una combinazione di eventi nei log. Una buona regola rileva comportamenti di attacco reali con il minimo di falsi positivi. La scrittura e il mantenimento di queste regole costituiscono la disciplina della detection engineering.

Cosa sono i falsi positivi e perché sono un problema?

Un falso positivo è un alert generato per un’attività legittima, non per un attacco. Oltre a sprecare tempo degli analisti, un volume elevato di falsi positivi provoca alert fatigue: gli analisti smettono di fidarsi degli alert e rischiano di ignorare quelli reali. Il 76% dei SOC cita l’alert fatigue come sfida operativa principale (Cybersecurity Insiders, 2025).

Come si usa MITRE ATT&CK nella detection engineering?

MITRE ATT&CK è un catalogo delle tattiche e tecniche usate dagli attaccanti, basato su osservazioni reali. In detection engineering viene usato per progettare regole che rilevano comportamenti specifici degli attaccanti — indipendentemente dagli strumenti che usano — e per visualizzare quali tecniche sono già coperte e quali rappresentano gap da colmare.

Quanto spesso vanno aggiornate le regole di detection?

Non esiste una frequenza fissa, ma le regole vanno aggiornate ogni volta che cambia significativamente l’ambiente monitorato, quando si identificano falsi positivi ricorrenti, quando emergono nuove tecniche di attacco rilevanti, o quando un incidente reale rivela un gap nella copertura. MITRE ATT&CK rilascia aggiornamenti periodici del framework che tipicamente guidano una revisione della copertura.

Chi si occupa di detection engineering in un SOC?

In SOC maturi è un ruolo dedicato, spesso chiamato Detection Engineer o Security Engineer con focus sulla detection. In strutture più piccole l’attività è svolta dagli analisti L2/L3 o dal SOC Manager stesso. In entrambi i casi è fondamentale che ci sia un processo strutturato e non solo attività reattive.

Potrebbe interessarti anche

• CYBERSECURITY DIRECTOR
• HEAD OF CYBERSECURITY
• SECURITY OPERATIONS CENTER MANAGER 
• SOC MANAGER 
• Come un Cyber Security Manager riesce a coordinare un team eterogeneo su più sedi
• Cybersecurity Director: ruolo, responsabilità e competenze
• Cybersecurity: quali aree un profilo Senior deve presidiare?
• Palo Alto, Fortinet, Cisco: come orientarsi in questo ambito
• Tecnica e commerciale: come un Cybersecurity Manager gestisce questi 2 domini
• Come il SOC Manager comunica un incidente al Chief Information Security Officer senza perdere credibilità