Meno di due ore dopo, i sistemi interessati sono già stati isolati, il nostro piano di risposta agli incidenti è stato attivato e le analisi forensi sono in corso. Sebbene l'attacco vero e proprio sia durato relativamente poco, la gestione delle sue conseguenze ci avrebbe impegnati per quasi tre settimane.

La notizia più importante è stata che i nostri sistemi di produzione utilizzati dai clienti hanno continuato a funzionare durante l'intero incidente. Al termine delle analisi forensi, non sono emersi elementi che indicassero un coinvolgimento dei dati dei clienti, del codice sorgente o dei database di produzione. Ciononostante, la nostra azienda ha attraversato quasi tre settimane di gestione della crisi, durante le quali abbiamo dovuto affrontare contemporaneamente sfide tecniche, organizzative e legali.

Oggi abbiamo deciso consapevolmente di condividere pubblicamente questa esperienza. Non per raccontare una storia di successo senza imperfezioni, ma per offrire una testimonianza sincera di un attacco che ci ha ricordato come anche le aziende con una solida esperienza nel campo della sicurezza informatica possano avere vulnerabilità e commettere errori.

Ciò che conta, quindi, non è essere completamente immuni dagli errori, ma essere preparati ad affrontare un'emergenza. Una buona preparazione può limitare la diffusione di un attacco, ridurre i danni e aiutare un'azienda a mantenere la propria operatività anche durante una crisi. Altrettanto importante è analizzare successivamente l'accaduto con trasparenza e trarre insegnamento dall'esperienza.

I primi 120 minuti

Mentre gli aggressori cercano ancora di esercitare pressioni telefoniche sui nostri collaboratori, le prime misure di emergenza sono già in corso. Tutte le persone coinvolte vengono riunite in una videoconferenza, il piano di risposta agli incidenti viene attivato e vengono assegnate le responsabilità relative alle analisi forensi, al ripristino tecnico, agli aspetti legali e alla comunicazione.

Contemporaneamente, i nostri team tecnici iniziano ad arrestare in modo controllato alcune parti dell'infrastruttura e a scollegare sistematicamente dalla rete i sistemi interessati. Viene avviata una prima analisi forense, mentre le successive misure necessarie per contenere l'attacco vengono coordinate in parallelo.

In una situazione del genere, rimane pochissimo tempo per lunghe discussioni sulle responsabilità fondamentali. Occorre decidere rapidamente quali sistemi devono essere arrestati, chi documenterà gli interventi tecnici effettuati e chi si occuperà di informare collaboratori, clienti e soggetti esterni. Allo stesso tempo, bisogna valutare eventuali obblighi di notifica e informazione e organizzare la collaborazione con specialisti di analisi forense e consulenti legali.

Molte di queste domande possono sembrare scontate durante le normali attività aziendali, almeno fino al momento in cui diventa necessario trovare delle risposte sotto una pressione considerevole. Il fatto che ruoli e responsabilità fossero già sostanzialmente definiti nella nostra organizzazione non ha impedito l'attacco, ma ha evitato che all'incidente tecnico si aggiungesse anche una crisi organizzativa.

Lunedì: i servizi ai clienti funzionano, ma le attività interne sono compromesse

Il sollievo più importante arriva già il lunedì successivo: i nostri sistemi di produzione destinati ai clienti continuano a funzionare regolarmente. Le piattaforme SaaS rimangono disponibili e, sulla base delle informazioni raccolte fino a quel momento, non emergono indicazioni di una compromissione dell'ambiente di produzione.

La continuità dei servizi ai clienti non è frutto del caso, ma il risultato di un'architettura di sicurezza progettata consapevolmente. I nostri sistemi di produzione e quelli amministrativi sono rigorosamente separati. Internamente definiamo questo approccio il nostro «principio del sottomarino», nel quale compartimenti tecnici isolati hanno lo scopo di impedire che un incidente di sicurezza in un'area possa propagarsi senza controllo alle altre parti dell'infrastruttura.

Questa separazione si è dimostrata particolarmente preziosa durante l'attacco. Ciononostante, le ripercussioni sulle nostre attività interne sono state notevoli. I sistemi amministrativi erano disponibili soltanto in misura limitata, diversi processi interni hanno dovuto essere riorganizzati temporaneamente e, parallelamente, erano in corso le indagini tecniche, le valutazioni legali e la comunicazione con clienti e collaboratori.

L'incidente ci ha dimostrato chiaramente che un attacco informatico può compromettere una parte significativa delle attività aziendali anche quando i servizi destinati ai clienti continuano a funzionare. La disponibilità dei sistemi di produzione non significa necessariamente che il resto dell'organizzazione possa proseguire le proprie attività senza interruzioni.

La prevenzione rimane l'obiettivo. Ma quando la prevenzione fallisce, è la resilienza a fare la differenza. Un'architettura di sicurezza ben progettata deve quindi concentrarsi non soltanto sulla prevenzione degli attacchi, ma anche sulla capacità di limitarne il più possibile le conseguenze qualora si verifichi un incidente.

La domanda più difficile: di quali sistemi possiamo ancora fidarci?

In determinate circostanze, un sistema compromesso può essere ripristinato relativamente in fretta utilizzando un backup esistente. La questione decisamente più complessa, però, è stabilire se quel sistema possa essere considerato nuovamente sicuro dopo il ripristino.

Durante le operazioni di recupero, abbiamo quindi dovuto verificare non solo quali sistemi e dati fossero stati coinvolti, ma anche se alcuni account utente fossero stati compromessi, se fossero stati creati accessi aggiuntivi o se determinate autorizzazioni fossero state modificate a nostra insaputa. Soltanto dopo aver chiarito adeguatamente questi aspetti è possibile decidere responsabilmente quali sistemi possano essere ricollegati alla rete e rimessi in servizio.

È proprio questa una delle difficoltà più spesso sottovalutate dopo un attacco informatico. Ripristinare correttamente i dati non significa automaticamente aver ripristinato anche il livello di sicurezza originale dell'infrastruttura. Per raggiungere questo obiettivo sono necessarie verifiche tecniche approfondite e, in alcuni casi, la ricostruzione completa dei singoli sistemi.

Il punto d'ingresso era un dispositivo periferico apparentemente insignificante

Le nostre analisi forensi hanno rivelato che una vulnerabilità presente in un dispositivo di rete periferico aveva rappresentato il primo punto d'ingresso per gli aggressori. Da quel dispositivo erano riusciti a spostarsi all'interno dell'ambiente amministrativo e a ottenere privilegi aggiuntivi.

Questa scoperta è stata particolarmente importante per noi, perché ha evidenziato quanto possa essere estesa la reale superficie di attacco di un'azienda. Quando si parla di protezione dell'infrastruttura informatica, l'attenzione si concentra spesso su server, computer aziendali e firewall. È quindi facile dimenticare che anche i dispositivi di rete meno appariscenti dispongono di software propri, account utente e accessi alla rete.

Se questi dispositivi non vengono aggiornati regolarmente, segmentati in modo adeguato e monitorati con continuità, possono diventare il punto di partenza di un incidente di sicurezza molto più grave. La nostra esperienza ha quindi dimostrato chiaramente che un'architettura di sicurezza completa deve considerare anche i componenti che, a prima vista, potrebbero sembrare poco importanti.

Esfiltrazione di dati nell'ambiente amministrativo, mentre i sistemi dei clienti rimangono operativi

Durante l'attacco si è verificata un'esfiltrazione di dati dal nostro ambiente amministrativo. Sono stati coinvolti dati aziendali interni e informazioni relative ai collaboratori. L'incidente ha quindi avuto conseguenze concrete, nonostante i nostri sistemi di produzione destinati ai clienti siano rimasti disponibili.

Al termine delle indagini forensi non sono emersi elementi che indicassero una compromissione dell'ambiente di produzione o dei dati dei clienti. Questa distinzione è stata fondamentale sia per la nostra valutazione interna sia per la comunicazione verso l'esterno.

Dall'esterno, un attacco informatico viene spesso riassunto con una semplice affermazione: un'azienda è stata hackerata. In realtà, però, le conseguenze tecniche e aziendali possono essere molto diverse. Esiste una differenza sostanziale tra un incidente che coinvolge i sistemi amministrativi e un attacco in cui i criminali informatici riescono ad accedere agli ambienti di produzione utilizzati dai clienti.

Abbiamo quindi deciso di informare tempestivamente clienti e collaboratori, adottando una comunicazione trasparente. Abbiamo spiegato quali aree risultavano coinvolte sulla base delle informazioni disponibili nelle diverse fasi, per quali sistemi non erano emersi indizi di compromissione e quali misure erano già state avviate per contenere e analizzare l'incidente.

Questa trasparenza non è stata sempre facile, ma era necessaria. Invece di lasciare che l'incertezza aumentasse a causa di informazioni incomplete, volevamo fornire elementi concreti e comprensibili sui quali clienti e collaboratori potessero basare la propria valutazione della situazione.

Perché il ripristino ha richiesto quasi tre settimane

I nostri backup hanno funzionato e i dati interessati erano archiviati in forma cifrata, con una separazione sia logica sia fisica dai sistemi coinvolti. Il semplice recupero dei dati non rappresentava quindi la nostra sfida principale.

Il compito decisamente più impegnativo consisteva nel bonificare accuratamente l'infrastruttura interessata e garantire che i sistemi potessero essere nuovamente utilizzati in condizioni di sicurezza. Per questo motivo, i sistemi coinvolti sono stati ricostruiti oppure ripristinati a partire da backup verificati e successivamente sottoposti a ulteriori misure di rafforzamento della sicurezza prima di essere rimessi in esercizio.

Parallelamente, abbiamo controllato le strutture critiche di autenticazione e gestione degli accessi, alcune delle quali hanno dovuto essere ricostruite. A titolo precauzionale, abbiamo inoltre sostituito tutte le password per ridurre i potenziali rischi associati a credenziali compromesse.

Proprio questa sostituzione generalizzata delle password si è trasformata in una sfida organizzativa che spesso viene sottovalutata nella quotidianità aziendale. Per riuscire a modificare in modo affidabile tutte le credenziali rilevanti dopo un attacco, un'organizzazione deve sapere quali account esistono, chi ne è responsabile e quali sistemi dipendono gli uni dagli altri.

In particolare, gli account amministrativi dimenticati o gli account di servizio possono complicare inutilmente queste operazioni di bonifica. Se manca una panoramica completa degli accessi, non aumenta soltanto il carico di lavoro, ma anche il rischio che alcune autorizzazioni compromesse rimangano attive senza essere individuate.

Il periodo di ripristino, durato quasi tre settimane, ci ha dimostrato che backup funzionanti costituiscono una base indispensabile per garantire la continuità operativa, ma da soli non assicurano un ritorno rapido e sicuro alla normalità.

Sei decisioni che hanno contribuito a limitare i danni

Ripensando all'accaduto, sono state soprattutto sei decisioni e misure predisposte in anticipo ad aiutarci a contenere le conseguenze dell'attacco e a ripristinare gradualmente le normali attività.

1. Segmentazione rigorosa

La separazione rigorosa tra sistemi amministrativi e ambienti di produzione ha limitato la diffusione dell'attacco e impedito che le sue conseguenze si estendessero senza controllo all'intera infrastruttura. Le indagini forensi non hanno rilevato elementi che indicassero una compromissione dei nostri sistemi di produzione destinati ai clienti.

2. Backup separati e affidabili

I nostri backup erano cifrati, separati logicamente e fisicamente dai sistemi coinvolti e concretamente ripristinabili. Questo ci ha fornito una base affidabile per ricostruire l'infrastruttura senza dipendere da un eventuale pagamento del riscatto.

3. Responsabilità chiaramente definite

Grazie alla definizione preventiva delle responsabilità, il ripristino tecnico, le indagini forensi, le valutazioni relative alla protezione dei dati e la comunicazione hanno potuto essere coordinati contemporaneamente. Questa preparazione ha permesso di risparmiare tempo prezioso e ha ridotto il rischio che decisioni importanti venissero trascurate durante le prime ore critiche.

4. Comunicazione proattiva

Invece di attendere il completamento di tutte le indagini, abbiamo informato tempestivamente clienti e collaboratori delle conseguenze note dell'incidente. Per noi era fondamentale comunicare esclusivamente informazioni verificate e distinguere chiaramente tra i fatti confermati e le questioni ancora aperte.

5. Capacità di ripristino senza pagare il riscatto

I backup integri e la rigorosa separazione dell'ambiente di produzione ci hanno permesso di procedere autonomamente al ripristino, senza versare alcun riscatto agli aggressori. Il fattore determinante è stato poter contare su misure tecniche e organizzative già esistenti.

6. Supporto di specialisti esterni

Abbiamo coinvolto specialisti esterni e consulenti in materia di protezione dei dati per supportare le analisi forensi e la valutazione giuridica dell'incidente. La loro esperienza ci ha aiutato a esaminare l'attacco in modo strutturato e a prendere decisioni importanti sulla base di informazioni affidabili. Una crisi in corso non è il momento adatto per iniziare a sviluppare procedure fondamentali attraverso tentativi ed errori.

Cosa avevamo sottovalutato e cosa facciamo diversamente oggi

L'attacco non ci ha mostrato soltanto quali misure di sicurezza avevano funzionato, ma ha anche messo in evidenza le debolezze ancora presenti. In particolare, avevamo sottovalutato l'importanza della protezione dei dispositivi di rete periferici e del monitoraggio degli ambienti amministrativi.

Da allora abbiamo adottato misure concrete per correggere queste carenze. Dopo l'incidente abbiamo iniziato a verificare con ancora maggiore rigore la segmentazione della nostra infrastruttura, le autorizzazioni esistenti, lo stato degli aggiornamenti e i processi di monitoraggio. Oggi utilizziamo anche tecnologie supportate dall'intelligenza artificiale per migliorare ulteriormente le nostre capacità di sorveglianza della sicurezza.

Questi miglioramenti, tuttavia, non rappresentano un progetto isolato che un giorno potrà essere considerato definitivamente concluso. Le infrastrutture informatiche cambiano continuamente, emergono nuove vulnerabilità e gli aggressori adattano costantemente i propri metodi. Per questo motivo, anche le strategie di sicurezza devono essere riesaminate regolarmente e adeguate alle nuove esigenze.

L'incidente ci ha soprattutto confermato che non è possibile eliminare completamente le vulnerabilità e gli errori umani. Diventa quindi ancora più importante creare in anticipo le condizioni tecniche e organizzative necessarie per contenere un attacco e gestirne le conseguenze.

Tra queste rientrano un'architettura di sicurezza attentamente progettata, responsabilità chiaramente definite, meccanismi di protezione efficaci e la disponibilità a mettere regolarmente in discussione i processi esistenti. È altrettanto essenziale analizzare apertamente gli incidenti dopo la loro risoluzione e integrare sistematicamente gli insegnamenti acquisiti nella strategia di sicurezza a lungo termine dell'azienda.

La preparazione fa la differenza prima che si verifichi un'emergenza

Un attacco informatico non termina automaticamente quando un server compromesso viene spento o quando un backup viene ripristinato con successo. La gestione dell'incidente può considerarsi davvero conclusa soltanto quando i sistemi interessati tornano a funzionare in modo affidabile e sicuro, gli accessi critici sono stati verificati e messi in sicurezza e collaboratori e clienti hanno ricevuto risposte chiare e attendibili alle proprie domande.

La nostra esperienza ha dimostrato che la cybersecurity va ben oltre la semplice protezione tecnica dei sistemi. Riguarda altrettanto la continuità operativa, le responsabilità organizzative, la trasparenza nella comunicazione e la capacità della direzione aziendale di prendere decisioni ponderate anche sotto una pressione considerevole.

Ogni azienda dovrebbe quindi porsi una domanda fondamentale: sareste oggi in grado di isolare rapidamente una parte della vostra infrastruttura informatica, ripristinarla utilizzando backup sicuri e mantenere operative le attività essenziali, senza dover prima stabilire chi è responsabile delle decisioni e quali misure devono essere adottate?

Noi abbiamo dovuto rispondere a questa domanda in condizioni reali e abbiamo sperimentato direttamente quanto possa essere preziosa una preparazione accurata.

Mi auguro che ogni azienda riesca a trovare la propria risposta prima di dover affrontare questa domanda sotto una pressione reale.