Incidente di phishing ai sensi di NIS 2
Come il phishing supera la soglia di incidente significativo, cosa richiede la cascata di segnalazione e cosa gestisce in parallelo un tipico playbook.
Cosa copre questa pagina
Il phishing non è una categoria regolamentare separata ai sensi di NIS 2. La direttiva tratta un tentativo di phishing riuscito come uno dei possibili incidenti significativi tra gli altri. Il test qualitativo dell'articolo 23(3) NIS 2 è lo stesso che ogni altro tipo di incidente deve superare. Il Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR) nomina categorie nell'Allegato Sezione 11.6 che, per i soggetti delle infrastrutture digitali, contano come significative per impostazione predefinita.
Il fattore scatenante che la maggior parte degli operatori trascura è la compromissione delle credenziali. Un'email di phishing che cattura un set funzionante di credenziali per un account critico non è un quasi incidente. È un evento di accesso non autorizzato riuscito. Se poi soddisfi la soglia dell'articolo 23(3) dipende da cosa l'account può raggiungere, cosa è stato estratto e quali servizi sono stati colpiti.
Questa pagina espone le meccaniche, non la consulenza legale. Descrive gli orologi del preallarme, della notifica dell'incidente e della relazione finale ai sensi dell'articolo 23(4) NIS 2, come un tipico playbook SOC gestisce contenimento e conservazione delle evidenze e dove l'articolo 33 GDPR corre in parallelo quando sono coinvolti dati personali.
Direttiva NIS 2 (UE) 2022/2555, Art. 23(3)
Un incidente è considerato significativo se: (a) ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato; (b) si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.
Questa è l'unica definizione generale di incidente significativo nel diritto dell'UE. Entrambi i punti usano 'è in grado di causare', quindi il danno potenziale conta tanto quanto il danno effettivo. Un evento di phishing che ha compromesso le credenziali di un account privilegiato può soddisfare il punto (a) ancor prima che un servizio si sia effettivamente fermato.
CIR (UE) 2024/2690, Allegato Sezione 11.6
Un incidente è considerato significativo qualora causi o sia in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato, oppure qualora si sia ripercosso o sia in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.
La Sezione 11.6 elenca categorie che si qualificano sempre come significative per i soggetti delle infrastrutture digitali coperti dal CIR: ransomware, esfiltrazione di dati personali o sensibili, denial-of-service contro servizi essenziali e perdita di riservatezza o integrità di asset critici. Un caso di phishing che si conclude in una qualsiasi di queste ha superato la soglia per definizione. Per i settori al di fuori del CIR, il test qualitativo dell'articolo 23(3) governa da solo.
§32 BSIG (Germania)
I soggetti essenziali e importanti notificano al Bundesamt gli incidenti significativi senza indebito ritardo, al più tardi entro i termini indicati all'articolo 23(4) della Direttiva (UE) 2022/2555.
La Germania riprende la cascata della direttiva così com'è e instrada la segnalazione attraverso il portale del BSI all'indirizzo meldung.bsi.bund.de. Il §32 BSIG è l'ancoraggio tedesco. I termini sostanziali restano quelli dell'articolo 23(4) NIS 2: un preallarme entro 24 ore, una notifica dell'incidente entro 72 ore e una relazione finale entro un mese.
Triage e decisione sulla soglia
L'orologio parte quando il soggetto viene a conoscenza dell'incidente. La conoscenza è quando una persona competente all'interno dell'organizzazione ne sa abbastanza da sospettare un incidente significativo, non quando l'indagine si conclude. Il triage risponde a tre domande: quali account sono stati compromessi, cosa quegli account possono raggiungere e se si applica una qualsiasi categoria dell'Allegato Sezione 11.6 del CIR. In caso affermativo, la questione della soglia è chiusa e il preallarme viene preparato.
Contenimento ed evidenze
Un tipico playbook SOC reimposta le credenziali compromesse, revoca le sessioni attive, blocca il dominio del mittente, isola dalla rete gli endpoint colpiti e conserva la casella di posta, l'immagine del disco dell'endpoint e i log di autenticazione prima di qualsiasi reimmagine. Cancellare una macchina vittima di phishing prima di acquisirne l'immagine distrugge il registro forense che in seguito risponde a cosa l'attaccante abbia effettivamente raggiunto.
La cascata di 24 ore / 72 ore / 1 mese
L'articolo 23(4) NIS 2 fissa tre termini a partire dal momento della conoscenza. Entro 24 ore il soggetto presenta un preallarme che indica se si sospetta che l'incidente sia causato da atti illeciti o malevoli o abbia impatto transfrontaliero. Entro 72 ore una notifica dell'incidente aggiorna il preallarme con una valutazione iniziale, gli indicatori di compromissione e la gravità. Entro un mese una relazione finale descrive la causa radice, la mitigazione ed eventuale impatto transfrontaliero.
È la portata del danno a rendere significativo il phishing
L'articolo 23(3) non si cura della tecnica. Si cura dell'effetto. Un'email di phishing aperta da un solo impiegato dell'amministrazione non è significativa. La stessa email, se ha catturato credenziali funzionanti che consentono l'accesso al sistema di fatturazione, al libro paga o a un database clienti, può soddisfare il punto (a) sulla potenziale perturbazione operativa o il punto (b) sul danno a persone fisiche o giuridiche. La domanda sulla portata è: cosa avrebbe potuto raggiungere la credenziale compromessa prima di essere revocata, e cosa è stato raggiunto durante la finestra di accesso.
La rapidità batte la completezza
La posizione del BSI è 'Schnelligkeit vor Vollständigkeit'. Il preallarme delle 24 ore è concepito per il momento in cui il quadro è incompleto. Il modulo chiede una classificazione iniziale e i fatti noti, non un'analisi finale della causa radice. Trattenere il preallarme finché tutto è noto fa mancare il termine; il termine non può essere recuperato successivamente, anche se l'incidente in seguito si rivela non significativo.
BSI: segnalazione NIS 2 su meldung.bsi.bund.de
Il BSI gestisce il canale unico del §32 BSIG per la segnalazione degli incidenti NIS 2. Il portale prestruttura le presentazioni a 24 ore, 72 ore e un mese e conserva la traccia di audit. La guida pubblica del BSI ripete la formulazione dell'articolo 23(3) e conferma 'Schnelligkeit vor Vollständigkeit'. Gli incidenti causati da phishing che soddisfano il test qualitativo passano attraverso questo canale, indipendentemente dal fatto che riguardino anche dati personali.
BfDI / DPA statale: parallelo dell'articolo 33 GDPR
Se l'evento di phishing ha esposto dati personali, l'articolo 33 GDPR corre accanto a NIS 2. La notifica in materia di protezione dei dati va all'autorità di controllo competente entro 72 ore dalla conoscenza, salvo che sia improbabile che la violazione presenti un rischio per le persone fisiche. La segnalazione NIS 2 e la notifica GDPR sono documenti separati ad autorità separate; i fatti sottostanti si sovrappongono, i canali formali no.
ZAC LKA: denuncia penale come decisione separata
Un attacco di phishing riuscito è di solito un atto penalmente rilevante ai sensi del §202a, §202b o §263a StGB. La Zentrale Ansprechstelle Cybercrime (ZAC) del Landeskriminalamt competente è il punto di accesso per la denuncia penale. Presentarla è una decisione gestionale separata dalla segnalazione regolamentare e non sospende alcun orologio.
'Era solo un utente, non è significativo'
Il test dell'articolo 23(3) chiede se l'incidente sia in grado di causare una grave perturbazione operativa o un danno considerevole a terzi. Un set di credenziali funzionanti per un account privilegiato nelle mani di un attaccante è in grado di fare entrambe le cose, indipendentemente da quanti utenti siano stati vittime di phishing. La significatività è decisa da cosa la credenziale può raggiungere, non dalle dimensioni della popolazione che ha cliccato.
'Reimmagina subito il portatile per sicurezza'
Cancellare l'endpoint prima che ne venga acquisita un'immagine forense distrugge l'unico registro di ciò che l'attaccante ha effettivamente fatto durante la finestra di accesso. La notifica dell'incidente delle 72 ore e la relazione finale del mese chiedono entrambe gli indicatori di compromissione e la causa radice. Senza l'immagine, quelle risposte sono congetture. Un tipico playbook isola per primo, acquisisce l'immagine dell'endpoint e della casella di posta colpita e solo allora reimmagina.
'Il silenzio è più sicuro, non dirlo a nessuno internamente'
L'articolo 23(1)(h) NIS 2 obbliga il soggetto, ove opportuno, a comunicare ai destinatari dei suoi servizi potenzialmente colpiti. Il silenzio sul lato interno ritarda la seconda ondata di rilevamento: altro personale che ha ricevuto la stessa email, altri account che potrebbero essere già compromessi. Una breve nota interna, fattuale, nelle prime ore è parte della risposta, non un comunicato stampa.
La cosa più utile che un piccolo team può provare prima dell'evento reale è la decisione sulla soglia. Mettete per iscritto, in anticipo, quali account sono 'critici' per il soggetto (console di amministrazione, sistemi di pagamento, fornitore di identità, database clienti, controllo OT). Un evento di phishing che cattura uno qualsiasi di questi è, per vostra stessa definizione, un candidato della Sezione 11.6 e l'orologio delle 24 ore parte.
La seconda cosa più utile è il modello di relazione. Il portale del BSI chiede un insieme strutturato di fatti. Redigere il preallarme per la prima volta durante un incidente reale spreca le prime due ore. Un modello precompilato con identificativi aziendali, settore, canali di contatto e una sezione narrativa vuota può essere presentato entro trenta minuti una volta che i fatti sono noti.
Il modulo incidenti apre un caso da un'unica marca temporale di 'conoscenza' e ancora tre orologi: 24 ore, 72 ore, un mese. Ogni orologio ha il proprio modello, precompilato con i campi che l'articolo 23(4) e l'Allegato Sezione 11.6 del CIR richiedono. Voi inserite ciò che è noto, la piattaforma mostra cosa manca ancora. Un timer separato per l'articolo 33 GDPR si attiva se sul caso vengono segnalati dati personali.
Il registro del caso conserva la catena di marca temporale di conoscenza, azioni di contenimento, comunicazioni e presentazioni. Quel registro è l'evidenza di audit che il portale del BSI non può generare al posto vostro e il documento che un revisore chiederà in una verifica ai sensi del §61 BSIG.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 23 (segnalazione degli incidenti), Articolo 21(2)(g) (formazione di sensibilizzazione alla sicurezza), Considerando 101 (fattori di significatività). EUR-Lex.
- Regolamento di esecuzione (UE) 2024/2690 della Commissione del 17 ottobre 2024, Allegato Sezione 11.6 (categorie di incidenti sempre considerati significativi per i soggetti delle infrastrutture digitali). EUR-Lex.
- BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik), §32 (segnalazione degli incidenti al BSI). gesetze-im-internet.de.
- Regolamento (UE) 2016/679 (GDPR), Articolo 33 (notifica di una violazione dei dati personali all'autorità di controllo entro 72 ore). EUR-Lex.
- BSI, guida pubblica sulla cascata di segnalazione NIS 2 e sul principio 'Schnelligkeit vor Vollständigkeit'. bsi.bund.de.
- Strafgesetzbuch (StGB) §202a Ausspähen von Daten, §202b Abfangen von Daten, §263a Computerbetrug. gesetze-im-internet.de.