Attacchi DDoS ai sensi di NIS 2
Segnali di rilevamento, strati di mitigazione e la decisione di comunicazione ai sensi dell'articolo 23 NIS 2 e dell'articolo 11(6) CIR 2024/2690.
Perché il DDoS si colloca esattamente all'interno dell'articolo 23
Un attacco di tipo denial-of-service distribuito satura un bersaglio con traffico proveniente da molte sorgenti, così che gli utenti legittimi non possono più raggiungere il servizio. Ai sensi di NIS 2 la categoria tecnica è meno interessante dell'effetto. Una volta che un DDoS degrada o interrompe in modo misurabile un servizio che l'entità presta, l'articolo 23 NIS 2 lo trasforma in un evento da comunicare con una cascata fissa.
L'articolo 11(6) del Regolamento di esecuzione (UE) 2024/2690 della Commissione (il CIR) nomina esplicitamente il denial-of-service come una delle categorie che, per i fornitori di infrastrutture digitali e di servizi TIC, conta come incidente significativo. Per gli altri soggetti essenziali e importanti si applica il test generale di significatività dell'articolo 23(3) NIS 2. L'impatto sulla disponibilità del servizio è l'attivatore dominante in entrambi i casi.
Un'entità che gestisce un sito web, un'API, un portale online, un gateway di pagamento, un resolver DNS o qualsiasi altro servizio esposto su internet raggiunge tipicamente la soglia di comunicazione più rapidamente di quanto possa scalare le difese. La cascata giuridica inizia pertanto a decorrere in parallelo con la mitigazione, non dopo di essa.
Direttiva UE (vincolante in tutta l'Unione)
Gli Stati membri assicurano che i soggetti essenziali e importanti trasmettano al CSIRT o, ove applicabile, all'autorità competente: (a) senza indebito ritardo e comunque entro 24 ore da quando sono venuti a conoscenza dell'incidente significativo, un preallarme; (b) senza indebito ritardo e comunque entro 72 ore da quando sono venuti a conoscenza dell'incidente significativo, una notifica dell'incidente; (c) una relazione intermedia sui pertinenti aggiornamenti della situazione, su richiesta di un CSIRT o, ove applicabile, dell'autorità competente; (d) una relazione finale entro un mese dalla trasmissione della notifica dell'incidente di cui alla lettera b); (e) in caso di incidente in corso al momento della trasmissione della relazione finale di cui alla lettera d), gli Stati membri assicurano che i soggetti interessati forniscano una relazione sui progressi in quel momento e una relazione finale entro un mese dalla gestione dell'incidente.
Articolo 23(4) NIS 2. L'orologio della comunicazione parte nel momento in cui l'entità viene a conoscenza dell'incidente significativo, non quando la mitigazione inizia o termina. Un DDoS ancora in corso al traguardo di un mese attiva la variante della relazione sui progressi di cui alla lettera e).
Regolamento di esecuzione UE (dettaglio tecnico vincolante)
Un attacco denial-of-service o un attacco distributed denial-of-service è considerato un incidente significativo per i soggetti che prestano servizi di infrastruttura digitale e i soggetti che prestano servizi di gestione TIC, qualora l'attacco causi un'indisponibilità completa del servizio o un degrado significativo del servizio.
Articolo 11(6) del Regolamento di esecuzione (UE) 2024/2690 della Commissione. Il CIR si applica direttamente ai fornitori di servizi DNS, ai registri dei nomi di TLD, ai fornitori di servizi di cloud computing, ai fornitori di servizi di data center, ai fornitori di reti di distribuzione dei contenuti, ai fornitori di servizi gestiti, ai fornitori di servizi di sicurezza gestiti, ai fornitori di mercati online, ai motori di ricerca online e ai servizi di rete sociale. Per questi tipi di soggetto, un DoS o DDoS con indisponibilità completa o degrado significativo è, per definizione, significativo.
Esempio nazionale (Germania)
Wesentliche und wichtige Einrichtungen melden dem Bundesamt erhebliche Sicherheitsvorfälle. Die Meldung erfolgt unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung, innerhalb von 72 Stunden als Meldung mit erster Bewertung und innerhalb eines Monats als Abschlussbericht.
§ 32 BSIG (NIS2UmsuCG). Il recepimento tedesco rispecchia letteralmente la cascata dell'articolo 23(4). Le relazioni vanno al BSI tramite il Meldeportal. Altri Stati membri usano il proprio CSIRT nazionale o l'instradamento dell'autorità competente. La sostanza è identica.
Segnali di rilevamento a livello di SOC
Indicatori tipici intercettati dal monitoraggio di rete o da un SOC includono un picco improvviso nel volume di traffico in entrata, un calo nei rapporti di richieste andate a buon fine, conteggi di connessione anomali sui dispositivi di frontiera, un'impennata di user agent o schemi di query identici, latenza o perdita di pacchetti accresciute sui collegamenti perimetrali e allarmi di saturazione dai fornitori a monte. Combinati con un calo misurabile della disponibilità del servizio, questi indicatori trasformano un evento in un incidente ai sensi dell'articolo 6(6) NIS 2.
Strati di mitigazione di uso comune
Schemi di mitigazione comuni includono il filtraggio del traffico a monte presso il fornitore di servizi internet, lo scrubbing tramite un servizio di protezione DDoS di terzi, il rate limiting e il throttling delle connessioni alla frontiera, anycast e distribuzione geografica, il blackholing o il null-routing delle sorgenti di attacco a livello di operatore e protezioni a livello applicativo come il bot management. La difesa a strati è qui descritta, non raccomandata; la combinazione proporzionata dipende dalla valutazione del rischio dell'entità ai sensi dell'articolo 21 NIS 2.
Decisione di comunicazione ai sensi dell'articolo 23
Una volta che la disponibilità del servizio è impattata in un modo che soddisfa l'articolo 23(3) NIS 2 o, per i soggetti di infrastruttura digitale, l'articolo 11(6) CIR, la cascata inizia: preallarme entro 24 ore, notifica dell'incidente entro 72 ore, relazione intermedia su richiesta, relazione finale entro un mese, relazione sui progressi se l'incidente è ancora in corso al traguardo di un mese.
L'impatto sul servizio, non il volume dell'attacco, è l'attivatore
L'articolo 23(3) NIS 2 definisce la significatività attraverso l'effetto sul servizio: grave perturbazione operativa, perdita finanziaria o danno materiale o immateriale ad altre persone fisiche o giuridiche. Un attacco da 500 Gbps interamente assorbito non è, di per sé, un incidente significativo. Un attacco da 5 Gbps che mette offline un portale per un'ora di solito lo è. Il test del CIR §11(6) per i soggetti di infrastruttura digitale è ancora più diretto: indisponibilità completa o degrado significativo.
Il DDoS spesso maschera un evento di seconda fase
Gli attacchi volumetrici sono talvolta usati come copertura per credential stuffing, esfiltrazione di dati o dispiegamento di ransomware. Il riesame post-incidente richiesto dall'articolo 23(4)(d) NIS 2 nella relazione finale distingue tipicamente tra l'evento visibile di disponibilità e qualsiasi evento secondario di accesso o di integrità rilevato durante o dopo l'inondazione di traffico.
BSI come CSIRT nazionale e punto di comunicazione
In Germania il BSI riceve le relazioni dell'articolo 23 tramite il Meldeportal ai sensi del § 32 BSIG. Il BSI pubblica anche orientamenti sulla gestione degli incidenti come il BSI-Standard 200-4 (BCM) e note tecniche operative; questi sono orientamenti, non ulteriori obblighi di comunicazione. Altri Stati membri hanno strutture parallele (NCSC-NL, ANSSI, NCSC-IE, e così via).
Cooperazione con gli ISP e filtraggio a monte
I fornitori di servizi internet possono assorbire o filtrare il traffico di attacco prima che raggiunga la frontiera del cliente. In Germania, i fornitori di comunicazioni elettroniche operano ai sensi del TKG e cooperano con il BSI nella risposta alle minacce; il BSI TR-03103 copre le interfacce tecniche per alcune categorie. Il punto per l'entità che comunica è che la mitigazione dell'ISP non rimuove l'obbligo di comunicazione dell'articolo 23 se il servizio era già impattato.
Orientamenti tecnici e panorama delle minacce di ENISA
ENISA pubblica la relazione annuale Threat Landscape e orientamenti sulla risposta agli incidenti ai sensi dell'articolo 18 NIS 2. Il Threat Landscape 2024 conferma il DDoS come una delle principali categorie di minaccia osservate nei settori dell'UE. I documenti di ENISA sono materiale di riferimento; non modificano la cascata dell'articolo 23.
Se ne occupa l'ISP, quindi non c'è nulla da comunicare
Il filtraggio lato ISP riduce l'impatto ma non cambia l'attivatore giuridico. Se il servizio era indisponibile o significativamente degradato tra l'inizio dell'attacco e la mitigazione dell'ISP, l'articolo 23(3) NIS 2 o l'articolo 11(6) CIR è attivato. La cascata di comunicazione corre in parallelo con la risposta a livello di operatore.
Trattare solo il sintomo è sufficiente
Il rate limiting e lo scrubbing fermano l'inondazione ma raramente identificano se il DDoS era un diversivo. Un riesame post-incidente che non controlla i log di autenticazione, le anomalie di traffico in uscita e le modifiche di configurazione durante la finestra dell'attacco lascia l'evento secondario non rilevato. La relazione finale ai sensi dell'articolo 23(4)(d) è il punto di controllo documentato per questo.
Una volta che il traffico si normalizza, l'incidente è chiuso
L'articolo 23(4)(d) NIS 2 richiede una relazione finale entro un mese dalla notifica dell'incidente. Quella relazione copre la causa principale, la mitigazione adottata e gli insegnamenti tratti. Un'entità che chiude il ticket nel momento in cui il traffico cala di solito non ha nulla da trasmettere, il che è esso stesso una non conformità documentata.
Due abitudini operative separano le entità che gestiscono il DDoS in modo pulito da quelle che si affannano. Primo, l'orologio della comunicazione e l'orologio della mitigazione sono tracciati separatamente. La mitigazione può richiedere ore; il preallarme di 24 ore ha un proprio responsabile e modello pronto prima dell'evento. Secondo, il riesame post-incidente è programmato nel momento del rilevamento, non alla fine dell'inondazione. Una casella in calendario 25 giorni dopo il rilevamento costringe a scrivere la relazione finale, anche in un incidente tranquillo.
La configurazione di DNS e di frontiera conta più delle decisioni prese al momento dell'attacco. Routing anycast, fornitori DNS autoritativi separati, un accordo testato di filtraggio a monte con l'ISP e un percorso di contatto documentato verso il NOC dell'operatore sono tipicamente in atto molto prima che arrivi il primo pacchetto di un attacco. Lo stesso vale per i modelli di relazione: i campi del preallarme e della notifica richiesti ai sensi del § 32 BSIG e dei portali nazionali equivalenti sono abbastanza statici da essere precompilati.
Il modulo incidenti in nisd2.eu porta la cascata dell'articolo 23(4) come flusso di lavoro strutturato: preallarme a 24h, notifica dell'incidente a 72h, relazione intermedia su richiesta, relazione finale a un mese, variante sui progressi se l'incidente è ancora in corso. La piattaforma marca temporalmente ogni passaggio rispetto al momento della conoscenza piuttosto che al momento dell'attacco, che è ciò che la direttiva misura.
I riferimenti agli asset sull'incidente collegano il servizio interessato alle voci nell'inventario degli asset costruito ai sensi di RSK 2.2, così che il riesame post-incidente possa tracciare quali asset, fornitori e processi sono stati coinvolti senza ricostruire il contesto da zero.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 6(6) (definizione di incidente), Articolo 21 (misure di gestione del rischio), Articolo 23 (comunicazione). EUR-Lex: eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione, Articolo 11(6) (denial-of-service nominato come incidente significativo per i fornitori di infrastrutture digitali e di servizi TIC). EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG (NIS2UmsuCG), § 32 (obblighi di comunicazione al BSI). gesetze-im-internet.de
- BSI Meldeportal e orientamenti operativi sulla comunicazione degli incidenti. bsi.bund.de
- ENISA Threat Landscape 2024, capitolo DDoS. enisa.europa.eu
- BSI-Standard 200-4 (Business Continuity Management). bsi.bund.de
- BSI TR-03103 (serie di linee guida tecniche). bsi.bund.de