Di Martina Oberto, Marketing Specialist & Pre-Sales presso Compet-e
I can’t stand it, I know you planned it, I’m gonna set it straight, this Watergate
I can’t stand rocking when I’m in here, ‘Cause your crystal ball ain’t so crystal clear
[…] Oh my God, it’s a mirage, I’m tellin’ y’all, it’s a sabotage.”
È difficile ascoltare “Sabotage” dei Beastie Boys senza percepire un senso di urgenza. Il basso distorto, la voce gridata e l’andamento da inseguimento poliziesco trasformano una tensione interna in un allarme continuo. Qualcosa sta accadendo. Qualcuno lo aveva pianificato. E non c’è tempo per discutere su chi avesse ragione prima che tutto cominciasse.
Il dietro le quinte di questa canzone è in realtà più ironico di quanto traspare dal muro di suono iniziale: il “sabotatore” era il produttore della band, accusato per gioco di ostacolare il lavoro del gruppo mentre, in realtà, cercava di portarlo a compimento.
Proprio questo equivoco rende il brano una buona metafora della gestione degli incidenti cyber.
Nel momento della crisi, la percezione e la realtà possono separarsi. Le informazioni sono incomplete, le responsabilità non sono ancora chiare e ciò che sembra un attacco può essere soltanto il primo frammento di una storia molto più complessa.
Il sabotaggio non comincia quando ce ne accorgiamo
Un incidente informatico raramente coincide con il momento in cui viene scoperto. Può iniziare molto prima: con una vulnerabilità non corretta, una credenziale compromessa, un accesso anomalo, un componente software esposto o un comportamento apparentemente innocuo. Quando compare il primo segnale evidente, l’attaccante potrebbe essere già dentro e il danno potrebbe essere in corso.
Improvvisamente non abbiamo più alcun controllo, ci sentiamo con le spalle al muro.
Why
Our backs are now against the wall?
La domanda decisiva, allora, è: “Sappiamo cosa fare adesso?”.
Quando parte il riff
“Sabotage” non concede una lunga introduzione. Il ritmo rapido, sincopato, assomiglia al momento in cui arriva la prima segnalazione: un servizio non risponde, un cliente comunica un’anomalia, un’attività sospetta compare nei log, una vulnerabilità risulta sfruttata attivamente.
Da quel momento inizia una corsa contro il tempo per limitare i danni. Ma la velocità, da sola, non basta. Dobbiamo chiederci: sono stati definiti ruoli, criteri di escalation, canali di comunicazione e procedure decisionali?
Altrimenti rischiamo di auto – sabotarci: l’urgenza è spesso una cattiva consigliera. Reagire ad un attacco cyber non permette improvvisazione.
Si isolano sistemi senza comprenderne le dipendenze, si cancellano tracce utili all’analisi. Si comunicano informazioni non verificate. Si aspetta troppo prima di coinvolgere chi dovrebbe decidere. Oppure si tenta di risolvere tutto in silenzio, sperando che l’incidente scompaia prima di diventare visibile.
La mancata comunicazione rischia di fare il gioco di chi ci attacca:
So, so, so, so listen up ‘cause you can′t say nothin’
Quindi, quindi, quindi, quindi state ad ascoltare perché non potete dire niente
You’ll shut me down with a push of your button?
Pensate che mi bloccherete spingendo un pulsante?
La risposta agli incidenti serve esattamente a evitare questo. Non promette che nulla andrà storto. Stabilisce come riconoscere l’evento, contenerlo, analizzarlo, ripristinare l’operatività e imparare da ciò che è accaduto.
NIS2: prepararsi prima dell’incidente
La Direttiva NIS2 porta la gestione degli incidenti fuori dalla sola dimensione tecnica. Per i soggetti essenziali e importanti, la capacità di gestire un incidente diventa parte della governance del rischio: non riguarda soltanto il reparto IT, ma l’organizzazione, i suoi vertici, i processi decisionali e la continuità delle attività.
La segnalazione deve seguire una progressione ben definita: un preallarme entro 24 ore dalla conoscenza di un incidente significativo, una notifica entro 72 ore e, di regola, una relazione finale entro un mese. Non viene richiesto di conoscere immediatamente ogni dettaglio. Viene richiesto di riconoscere il problema, attivare la risposta e aggiornare progressivamente il quadro informativo.
È una differenza importante. Durante un incidente, attendere la certezza assoluta può significare perdere tempo prezioso.
Ma comunicare senza un processo può generare contraddizioni, confusione e nuove conseguenze. Prepararsi serve a muoversi rapidamente senza smettere di essere affidabili.
CRA: il prodotto deve sapere reagire
Il Cyber Resilience Act osserva la stessa scena da un’altra prospettiva. Se NIS2 si concentra sulla resilienza dei soggetti e dei servizi, il CRA attribuisce responsabilità specifiche ai fabbricanti di prodotti con elementi digitali.
In questo caso la sicurezza non termina quando il prodotto viene immesso sul mercato: continua per tutto il periodo di supporto, attraverso la gestione delle vulnerabilità, gli aggiornamenti e la capacità di intervenire quando emerge un problema.
Dall’11 settembre 2026, i fabbricanti devono notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti interessati. Anche qui il ritmo è serrato: un preallarme entro 24 ore, una notifica completa entro 72 ore e una relazione finale secondo le tempistiche previste dal regolamento.
Il CRA introduce così una responsabilità che assomiglia molto alla lezione implicita di “Sabotage”: non basta costruire qualcosa che funzioni quando tutto va bene. Bisogna sapere cosa fare quando qualcuno prova deliberatamente a metterci I bastoni fra le ruote.
Non si improvvisa durante un sabotaggio
La preparazione alla risposta agli incidenti è fatta di elementi poco spettacolari: inventari aggiornati, classificazione degli asset, responsabilità chiare, contatti reperibili, criteri di gravità, procedure di escalation, esercitazioni e modelli di comunicazione; proprio per questo è facile rimandarla. Finché non si verifica un sabotaggio.
Quando l’incidente arriva, però, questi dettagli fanno la differenza tra una reazione coordinata e una sequenza di decisioni prese sotto pressione. Un piano non elimina l’incertezza, ma evita di dover inventare contemporaneamente la strategia, il linguaggio e la catena di comando. Evita di sentire la pressione del dover fare qualcosa ma non saper cosa fare:
Because I feel disgrace because you’re all in my face
Perché mi sento male, perché mi state tutti addosso
Prepararsi significa anche esercitarsi sulle sovrapposizioni normative. Chi valuta se l’evento è significativo ai sensi di NIS2? Chi verifica se riguarda un prodotto con elementi digitali e se ricorrono i presupposti del CRA? Quali informazioni possono essere condivise? Chi mantiene una cronologia unica delle decisioni e delle comunicazioni? Chi coordina eventuali notifiche ulteriori, per esempio quando l’incidente coinvolge dati personali?
La risposta è parte della resilienza
Nel linguaggio comune, la resilienza viene spesso confusa con la capacità di resistere. Ma in ambito cyber resistere non è sufficiente. Un’organizzazione e un prodotto resilienti devono anche riconoscere il deterioramento, limitare le conseguenze, recuperare le funzioni essenziali e trasformare l’incidente in conoscenza.
La vera lezione di “Sabotage”, allora, non è che ogni organizzazione debba vivere aspettandosi un nemico dietro ogni porta. È che, quando qualcosa interrompe il funzionamento previsto, negare il problema o cercare immediatamente un colpevole non restituisce il controllo.
Il controllo torna attraverso una risposta preparata: osservare, decidere, contenere, comunicare, correggere e imparare.
Il sabotaggio dopo il sabotaggio
Ogni incidente cyber contiene almeno due storie di “sabotaggio”.
La prima è quella dell’attacco: la sensazione di vulnerabilità e la rabbia quando non si capisce quale errore ha prodotto l’evento. La seconda è la storia di come l’organizzazione ha reagito.
La prima non è sempre evitabile. La seconda, invece, può essere preparata.
NIS2 e CRA ci ricordano che la gestione dell’incidente è parte integrante della sicurezza stessa. Un attacco può compromettere sistemi e prodotti, ma una risposta tardiva, disordinata o opaca può sabotare anche continuità operativa, fiducia e reputazione.
Quando parte il riff, non è più il momento di chiedersi chi avrebbe dovuto preparare il piano.
È il momento di sapere già come suonarlo.
Vuoi approfondire le novità normative introdotte dal Cyber Resilience Act? Iscriviti al nostro webinar