MITRE ATT&CK for ICS: come usarlo per costruire regole di detection concrete

Cos'è MITRE ATT&CK for ICS e perché non basta leggerlo

MITRE ATT&CK for ICS è una knowledge base strutturata di tattiche, tecniche e procedure (TTP) documentate negli attacchi reali contro sistemi di controllo industriale. Non è una lista di vulnerabilità, non è uno standard normativo: è un catalogo di comportamenti offensivi osservati, organizzati in una matrice che copre l'intero ciclo di un attacco ICS, dall'accesso iniziale fino alla manipolazione del processo fisico.

Il framework esiste dal 2020 e viene aggiornato con cadenza regolare incorporando le analisi di campagne documentate come INDUSTROYER, TRITON, Sandworm e attacchi più recenti. Oggi conta decine di tecniche distribuite su undici tattiche.

Il problema non è la qualità del materiale: è come viene usato. Molte organizzazioni lo trattano come una checklist di consapevolezza, lo leggono una volta, magari lo usano per un assessment, poi lo archiviano. Questo non produce nessuna capacità di detection. La domanda utile non è "quali tecniche usa il framework?" ma "quali di queste tecniche sono rilevabili nella nostra rete, con gli strumenti che abbiamo, adesso?"

Rispondere a questa domanda richiede un lavoro di mappatura che parte dall'analisi delle proprie capacità di visibilità, non dal framework.

Le tattiche più rilevanti per le PMI manifatturiere

Non tutte le undici tattiche hanno la stessa rilevanza per un impianto manifatturiero di medie dimensioni. Alcune richiedono livelli di sofisticazione che storicamente si osservano in attori state-sponsored contro infrastrutture critiche nazionali. Altre sono invece presenti in quasi tutti gli incidenti documentati, inclusi quelli che coinvolgono organizzazioni industriali di dimensioni medie.

Initial Access (TA0108) è il punto di ingresso. Le tecniche più frequenti nell'industriale sono l'abuso di connessioni di accesso remoto legittime (T0822), come VPN vendor, sistemi di teleassistenza e jump server esposti, e il compromise di software supply chain (T0862). Lo spearphishing verso personale IT che poi è il trampolino verso OT non ha una tecnica dedicata in ICS ma viene modellato nella fase IT del framework ATT&CK Enterprise che precede la lateralizzazione.

Lateral Movement (TA0109) include tecniche come Default Credentials (T0812), ancora enormemente diffuse negli ambienti OT, dove molti dispositivi mantengono le credenziali di fabbrica, e Program Download (T0843), che descrive la modifica della logica di controllo attraverso connessioni di programmazione legittime.

Impair Process Control (TA0106) e Inhibit Response Function (TA0107) sono le tattiche finali degli attacchi più distruttivi. Tecniche come Spoof Reporting Message (T0856) o Manipulate I/O Image (T0835) sono difficilmente rilevabili senza visibilità profonda sul processo, ma alcuni precursori, come l'accesso insolito a funzioni di scrittura di un PLC, sono rilevabili a livello di rete.

Discovery (TA0102) è spesso la fase più visibile: gli attaccanti, dopo essere entrati nella rete OT, eseguono operazioni di ricognizione per capire la topologia e identificare asset critici. Questa attività genera traffico anomalo rilevabile: scansioni ARP, richieste a dispositivi con cui un host non comunicava prima, enumerazione di registri PLC.

Cosa si può rilevare con il monitoraggio passivo del traffico di rete

Il monitoraggio passivo, cioè catturare e analizzare tutto il traffico in transito senza inviare nessuna sonda attiva, offre una copertura sostanziale su diverse tecniche MITRE ATT&CK for ICS, ma non su tutte.

Le tecniche rilevabili dal traffico di rete includono:

• Nuove comunicazioni tra host che non avevano mai interagito: indica possibile lateral movement o discovery.
• Accesso a function code critici nei protocolli industriali (Modbus write coils, DNP3 direct operate, OPC-UA write): rilevabile decodificando il payload applicativo, non solo le intestazioni TCP.
• Connessioni verso indirizzi remoti non noti da dispositivi OT: campanello d'allarme per C2 o esfiltrazione.
• Download di programmi su PLC tramite protocolli di programmazione (S7comm, EtherNet/IP CIP): la firma del traffico di programmazione è distinguibile dal traffico operativo normale.
• Variazioni nel timing e nei volumi di comunicazione rispetto alla baseline: alcune tecniche di manipulation introducono ritardi o variazioni nei cicli di polling che si manifestano a livello di rete.
• Presenza di strumenti di scansione: pattern di traffico che indicano ricognizione attiva della rete OT.

Le tecniche non rilevabili dal solo traffico di rete includono modifiche alla logica interna di un PLC effettuate attraverso un canale di programmazione già autorizzato (se le credenziali sono valide il traffico appare legittimo), manipolazione di parametri di processo all'interno di una sessione autorizzata, e tecniche che avvengono interamente all'interno di un singolo dispositivo senza generare traffico esterno.

Come costruire la mappatura delle proprie capacità di detection

L'approccio pratico è costruire una matrice di copertura: per ogni tecnica rilevante del framework, documentare se esiste una regola di detection attiva, su quale fonte di dati si basa e quale è il livello di confidenza.

Un template utile per ogni tecnica:

1. È rilevabile con le nostre fonti di dati attuali? (traffico di rete, log firewall, log del SIEM, log endpoint se disponibili)
2. Esiste già una regola di detection? Se sì, quando è stata testata per l'ultima volta?
3. Qual è il livello di confidenza? Alta confidenza: la tecnica genera un segnale inequivocabile. Media: richiede correlazione con altri eventi. Bassa: il segnale è debole o facilmente confuso con comportamenti legittimi.
4. Quali sono i falsi positivi attesi? Una regola con confidenza media ma alto tasso atteso di falsi positivi è meno utile di una regola con confidenza alta.

Questo esercizio rivela sistematicamente i gap: le tecniche per cui non c'è nessuna copertura, nemmeno teorica. Questi gap devono essere documentati e usati per guidare le decisioni di investimento nella visibilità: non per fare una lista della spesa di strumenti, ma per capire quali dati aggiuntivi (log endpoint, sonde specifiche, integrazione con sistemi di controllo) cambierebbero la copertura in modo significativo.

Prioritizzare le regole su cui investire primo

Con risorse limitate, la realtà delle PMI, non è possibile coprire tutte le tecniche del framework contemporaneamente. La prioritizzazione deve essere guidata da tre criteri:

Frequenza documentata: alcune tecniche appaiono in quasi tutti gli incidenti ICS documentati (abuso di accesso remoto, uso di credenziali predefinite, discovery della rete), altre in un sottoinsieme ristretto di attacchi sofisticati. Iniziare dalle prime.

Rilevabilità con le capacità attuali: a parità di importanza, dare precedenza alle tecniche per cui esiste già la fonte dati e manca solo la regola. È il modo più rapido per aumentare la copertura senza investimenti infrastrutturali.

Impatto potenziale sul processo: una tecnica che potrebbe portare all'arresto della linea di produzione o a un incidente di sicurezza fisica merita priorità rispetto a una che porta solo all'esfiltrazione di dati.

Il risultato di questo processo non è un documento teorico ma un backlog concreto di regole di detection da sviluppare, testare e mettere in produzione, ordinato per impatto atteso. Questo backlog deve essere rivisto ogni volta che il framework viene aggiornato con nuove tecniche o quando emergono campagne che usano TTP non ancora coperte.

Il ciclo di miglioramento continuo

Una cosa che il framework MITRE ATT&CK for ICS non dice esplicitamente ma che emerge dalla pratica: la detection non è uno stato da raggiungere ma un processo continuo. Le tecniche di attacco evolvono, le configurazioni degli ambienti cambiano, le regole di detection si degradano nel tempo perché la rete cambia e la baseline si sposta.

Un ciclo di miglioramento realistico per un'organizzazione industriale di medie dimensioni include: revisione trimestrale della mappatura di copertura, test periodico delle regole esistenti con simulazioni di comportamento anomalo, aggiornamento delle regole quando vengono pubblicati nuovi rapporti di threat intelligence su campagne ICS, e verifica che le fonti di dati su cui si basano le regole siano ancora attive e non degradate.

L'obiettivo non è raggiungere la copertura totale, che non esiste, ma avere visibilità chiara su cosa si riesce a rilevare, con quale confidenza, e su dove si trovano i punti ciechi. Questa trasparenza è la base di una postura di sicurezza onesta e migliorabile.

L'angolo MON5

La domanda chiave dell'articolo, quali tecniche sono rilevabili con gli strumenti attuali, ha per molte organizzazioni una risposta scomoda: poche, perché manca la visibilità sul traffico OT. MON5 copre proprio l'area dove il monitoraggio passivo rende di più: l'NDR fuori banda decodifica i protocolli nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) e rileva discovery, lateral movement e scritture anomale verso i PLC, mentre l'anomaly detection ML segnala le deviazioni dalla baseline.

Il risultato è una copertura di tecniche ATT&CK for ICS misurabile sui dati di rete. Per mappare la tua copertura attuale, pianifica un assessment OT.