Il 19 dicembre 2024 l’Agenzia di Cybersicurezza Nazionale (ACN) ha pubblicato un documento intitolato “Ransomware. Caratteristiche, preparazione e risposta agli attacchi ransomware” avente lo scopo di definire una buona prassi per la gestione e la risposta ad una minaccia molto nota e pericolosa del dominio informatico. All’interno del documento sono spiegate le attività conseguenti ad una infezione, sia dal punto di vista dell’attaccante, sia dal punto di vista delle attività di difesa. Il presente articolo rappresenta una riflessione critica su quanto descritto dall’Agenzia.
Nel documento, inoltre, è riportato un processo incaricato di indicare le attività necessarie alla mitigazione del rischio: l’analisi, il contenimento, il ripristino, il contrasto e la comunicazione da attuare. Tale processo è stato creato a partire dallo standard NIST IR 8374 “Ransomware Risk Management77“ e dal framework NIST SP 800-61 Rev.278 “Computer Security Incident Handling Guide“.
L’attività svolta dall’ACN s’inserisce in un quadro di cybersecurity molto serio, in cui gli attacchi hacker mediante ransomware, rappresentano un problema di rilevante impatto per le aziende e le pubbliche amministrazioni italiane. Un attacco cyber comporta danni reputazionali ed economici per svariate migliaia di euro e sovente l’impossibilità di ripristinare completamente l’operatività antecedente l’attacco. È quindi ovvio che un processo di questo tipo è assolutamente fondamentale, oltre che atteso dalle aziende italiane che cercano una risposta di supporto istituzionale.
La lettura del documento di ACN ha acceso una serie di osservazioni critiche in merito alla effettiva sostenibilità e attuazione del processo, soprattutto in un paese composto da piccole e medie imprese e da pubbliche amministrazioni locali che spesso non dispongono di risorse (umane ed economiche) adeguate. In alcuni casi, ad esempio, per far fronte alla minaccia cyber, alcuni comuni hanno dovuto intaccare le voci di bilancio dell’anno successivo per pagare professionisti e aziende in grado di contrastare le minacce per loro conto. È quindi lecito domandarsi il valore di un processo che, per quanto ottimo, risulti poi difficilmente applicabile per indisponibilità di risorse e competenze. La presente analisi nasce da questo punto di osservazione: quanto è effettivamente sostenibile il processo prodotto da ACN e riportato di seguito.
Processo di gestione della minaccia ransomware
Il processo consta di 17 fasi appartenenti ad attività di analisi, contenimento, recovery (ripristino), hardening (personalizzazione delle misure di sicurezza) e comunicazione. Di seguito si riporta la tabella completa.
| Fase | Descrizione | Tipologia |
| 0 | Un sospetto incidente per attacco ransomware s’innesca per una o più delle seguenti condizioni: Rilevazione su parco macchine di ransom note e/o impatti di fermo o prestazionali su un insieme esteso del parco macchine;Notizia su leak sites pubblici e/o comunicazioni ricevute direttamente che indicano una possibile compromissione di informazioni;Notifica da parte dei sistemi di detection | Contenimento |
| 1 | L’Incident Manager da inizio alle attività di risposta all’incidente in base ai piani predisposti, valutando l’impatto, anche potenziale, dell’attacco in termini di servizi erogati ed in termini di conseguenze sugli asset. Si attiva, se necessario, il piano di business continuity. L’IM organizza, inoltre, il team di risposta, assegna le responsabilità e monitora l’implementazione delle procedure e delle strategie. Ogni implementazione di nuova tecnologia viene sospesa dall’IM fino alla chiusura dell’incidente. | Contenimento |
| 2 | Distribuire o completare la copertura dell’EDR ed istituire un servizio minimo di monitoraggio laddove non presente. | Recovery |
| 3 | Avviare le attività di analisi al fine di confermare l’eventuale incidente di sicurezza raccogliere i primi parametri relativi all’estensione anche temporale dell’evento cyber. | Analisi |
| 4 | Analizzare le informazioni a disposizione, identificando i sistemi, applicativi ed account coinvolti nell’incidente nonché le aree di rete particolarmente impattate. Analizzare inoltre il meccanismo di propagazione e di comunicazione con l’esterno (per esfiltrazione e controllo). | Analisi |
| Raccogliere le informazioni necessarie alla notifica dell’incidente in linea con le normative vigenti, effettuando anche una valutazione degli impatti sui servizi erogati. | Comunicazione | |
| 5 | Se possibile, avviare attività di contenimento immediate per disinnescare il meccanismo di propagazione. | Analisi |
| Avviare il processo di segnalazione esterna verso gli organi istituzionali competenti (Polizia Postale, CSIRT Italia, Garante per la Protezione dei Dati Personali e altri enti in base alle normative vigenti) inviando aggiornamenti secondo quanto definito. | Comunicazione | |
| 6 | Avviare le attività di analisi. I dati provenienti dall’analisi devono essere utilizzati per alimentare i meccanismi di monitoraggio e risposta. Dare anche inizio all’attività di analisi forense predisponendo il supporto alle autorità per l’acquisizione, la conservazione conforme e l’identificazione di tracce in immagini di dischi, memoria, logs e altri artefatti. | Analisi |
| Avviare, secondo le strategie di comunicazione preposte, i processi di comunicazione interni e esterni (stakeholder, fornitori, clienti e dipendenti). | Comunicazione | |
| 7 | In caso di ransomware human-operated: disabilitare ove possibile le utenze compromesse;verificare la consistenza dei backup dei domain controller e di eventuali altri servizi critici in un ambiente isolato;effettuare il reset di tutte le credenziali amministrative e di quelle coinvolte nell’incidente, resettare il ticket Kerberos (due volte) al fine di invalidare tutti i token emessi utilizzando l’account compromesso. Nel processo, assicurarsi di mantenere l’accesso all’utenza amministrativa; procedere, infine, con l’applicazione di MFA sui sistemi esposti e condurre attività di hardening dei servizi di accesso remoto (quali VPN e tool di accesso remoto). In caso di ransomware automatizzato: valutare se è possibile contrastare la propagazione del malware inibendo il meccanismo di replicazione, ad esempio isolando la rete, o distribuendo patch o regole sul sistema EDR;bonificare eventuali account compromessi; verificare la possibilità di chiudere in compartimenti separati aree logiche differenti di rete. Nell’impossibilità di eseguire azioni più specifiche disconnettere immediatamente i dispositivi infetti dal network, dall’internet e da altri dispositivi. Se non risulta possibile disconnettere i dispositivi infetti dal network, l’ultima opzione rimane quella di spegnerli, rischiando tuttavia di compromettere la possibilità di recuperare informazioni utili. | Contenimento |
| 8 | Condurre attività di patching dei sistemi critici, quali ad esempio firewall e domain controller | Contenimento |
| 9 | Salvare tutte le ulteriori informazioni acquisibili sul malware e sulle modifiche eseguite dall’attaccante. Assicurarsi che le definizioni antivirus siano aggiornante. Prima di rimuovere qualsiasi malware identificato, assicurarsi di registrarne le caratteristiche. | Analisi |
| 10 | Identificare e rimuovere ogni presenza dell’attaccante, nonché eventuali meccanismi di persistenza, canali di esfiltrazione e canali di controllo dall’esterno che gli attaccanti potrebbero aver creato per assicurarsi di poter riaccedere e controllare la rete e/o il sistema colpito. | Recovery |
| 11 | Procedere con il deployment o rifacimento dei client amministrativi dedicati assicurandosi l’installazione dell’EDR, il patching all’ultima versione e la navigazione limitata. | Recovery |
| 12 | Ripristinare i servizi in base alle priorità del business partendo da una fotografia affidabile antecedente alla prima traccia di compromissione. Applicare ai server ripristinati tutte le misure definite durante il contenimento. Condurre test circa il corretto funzionamento degli asset e dei servizi erogati. | Recovery |
| 13 | In base alle attività di emergenza adottate, valutare un ritorno progressivo alle configurazioni di partenza, ad esempio la navigazione internet o la chiusura della VPN. | Recovery |
| 14 | Effettuare il monitoraggio degli asset per un periodo di tempo definito (ad esempio almeno 24 o 48 ore), applicando controlli stringenti e consentendo attività limitate al fine di verificare che siano effettivamente privi di minacce. | Recovery |
| 15 | Opzionale: valutare la necessità di svolgere nuovamente alcune delle attività di contenimento, quali ad esempio il reset delle credenziali. | Recovery |
| 16 | Avviare le attività di hardening post incidente. Esse includono: Migliorare la postura di sicurezza dei servizi infrastrutturali critici, ad esempio virtualizzazione, backup, systems management, patching;Consolidare le soluzioni di monitoring e definire le procedure di SOC;Revisionare le policy di networking, ad esempio regole firewall e segmentazione di rete;Consolidare ed eventualmente reingegnerizzare i servizi implementati in emergenza, assicurandosi la documentazione e scalabilità deiservizi implementati;Implementare gradualmente il principio di Least Privilege;Sostituire tutti i sistemi obsoleti e/o fuori supporto;Revisionare i processi di gestione delle raccomandazioni provenienti dalle autorità. | Hardening |
| 17 | L’Incident Manager dichiara concluso l’incidente, prepara un report evidenziando le lesson learned e informa le autorità competenti. | Comunicazione |
Elementi di attenzione
L’idea di adottare (e rivedere) un processo basato su standard NIST non è sbagliata ma potrebbe essere di difficile adesione su strutture che:
- Potrebbero non avere le risorse economiche adatte per dotarsi degli strumenti necessari.
- Potrebbero non avere le risorse umane disponibili per far fronte alla crisi secondo le modalità espresse dalla metodologia.
- Potrebbero non avere le risorse tecnologiche richieste dal processo per via della carenza delle due risorse precedenti o per il dimensionamento dell’infrastruttura.
Sorge quindi la domanda in merito a quante realtà organizzative siano in grado di dispiegare attivamente ed efficacemente le 17 fasi suggerite dall’ACN e quanto di questo processo, invece, non rischi di rimanere lettera morta a causa dell’indisponibilità delle risorse. Proviamo ad esaminare qualcuno di questi aspetti:
“Distribuire o completare la copertura dell’EDR ed istituire un servizio minimo di monitoraggio laddove non presente.” (Fase 2)
Già la fase due pone un accento sul fatto che il target colpito abbia a disposizione un sistema di Endpont Detection and Response che non sono annoverabili ad antivirus ma a vere e proprie piattaforme per il monitoraggio, l’individuazione ed il contrasto della minaccia. Non è detto che tale risorsa sia presente in un piccolo comune, in una ASL o in un’azienda del tessuto imprenditoriale italiano. Un’altra fase che dovrebbe meritare particolare attenzione è la numero 6.
“Avviare le attività di analisi. I dati provenienti dall’analisi devono essere utilizzati per alimentare i meccanismi di monitoraggio e risposta. Dare anche inizio all’attività di analisi forense predisponendo il supporto alle autorità per l’acquisizione, la conservazione conforme e l’identificazione di tracce in immagini di dischi, memoria, logs e altri artefatti” (Fase 6)
Secondo questa fase la struttura colpita dovrebbe riuscire a sviluppare un’adeguata capacità di analisi e offrire supporto alle autorità per le attività di analisi forense. Non è affatto scontato che una realtà abbia le conoscenze, le risorse, gli strumenti adatti a compiere queste azioni che, il più delle volte, sono complesse e sono ad appannaggio di figure ben precise. Si tenga a mente, ad esempio, quanto prescritto dalla ISO 27037 in merito alle figure incaricate di intervenire in ambito forense. Lo standard ci parla chiaramente di due profili: il DEFR e il DES:
Digital Evidence First Responder (DEFR): individual who is authorized, trained and qualified to act first at an incident scene in performing digital evidence collection and acquisition with the responsibility for handling that evidence.
Digital Evidence Specialist (DES): individual who can carry out the tasks of a DEFR and has specialized knowledge, skills and abilities to handle a wide range of technical issues.
In entrambi i casi si parla di professionisti specializzati, con particolare formazione e in grado di usare specifici strumenti atti a favorire l’isolamento, l’acquisizione e l’analisi degli elementi probatori e d’interesse. D’altro canto, se un operatore tecnico, per quanto bravo, non disponesse delle corrette conoscenze in ambito forense, potrebbe compromettere irrimediabilmente la prova e/o peggiorare la condizione operativa in cui verte il sistema. Anche in questo caso, volendo ottemperare a queste specifiche, nasce il dubbio di cosa potrebbe accadere se non ci fossero le risorse economiche disponibili per finanziare un’attività esterna di analisi forense. Senza risorse e indicazioni, cosa accadrebbe a quegli elementi probatori?
Conclusioni e suggerimenti
L’ACN ha realizzato un documento tecnicamente sicuro e completo ma probabilmente inapplicabile da molte realtà di dimensioni ridotte e ciò apre un fronte di analisi interessante: cosa si può fare in un momento di emergenza, se non si possiedono i requisiti descritti in quelle 17 fasi?
Un primo suggerimento potrebbe essere quello di realizzare checklist più brevi, indirizzate a gestire nell’immediato un’emergenza di alto livello. Documenti atti a contenere attività certamente realizzabili da chi non dispone di un EDR, ad esempio, o di chi non ha competenze di informatica forense all’interno del proprio organico o di chi deve tirare su una linea di difesa e gestione senza le risorse economiche sufficienti per richiedere aiuto esterno. Insomma, checklist di emergenza di prima linea.
Un secondo suggerimento potrebbe essere quello di descrivere le modalità di “come” effettuare determinate operazioni. Se un sistema è infetto ed è necessario intervenire all’acquisizione di informazioni di base, è importante farlo in sicurezza e senza compromettere altri dispositivi/supporti di memoria. Riportare dei suggerimenti è veramente rilevante, ad esempio: usare la fotocamera dello smartphone/tablet per catturare le ransom note può essere una risposta alla portata di tutti i soggetti e non è così tanto scontata come si pensa. Bisogna riflettere sul fatto che molti operatori di settore non si sono mai trovati faccia a faccia con la necessità di gestire una crisi informatica.
Un terzo suggerimento è quello di esprimere meglio le modalità con cui svolgere queste attività: non sempre la consequenzialità è l’azione migliore. Lavorare in parallelo, magari individuando uno o più “delegati all’azione” che svolgano una sola azione (elementare ma importante) può cambiare radicalmente l’impatto dell’incidente sull’infrastruttura. Così come mantenere aggiornata e di facile accesso la lista dei contatti esterni a cui rivolgere le richieste di supporto.
Un quarto suggerimento riguarda la gestione delle credenziali (più specificamente le fasi 7 e 15) poiché nel processo si raccomanda di sostituire le credenziali di amministrazione “effettuare il reset di tutte le credenziali amministrative e di quelle coinvolte nell’incidente“. In nessuna parte di questa procedura si menziona il termine dwell-time con cui l’hacker potrebbe aver sottratto le credenziali di sistemi ma anche di servizi (anche esterni all’infrastruttura). Il cambio delle password non può quindi limitarsi alle credenziali amministrative coinvolte nell’incidente ma anche ai principali servizi/piattaforme in uso apparentemente rimasti illesi.
In definitiva ciò che si suggerisce è di semplificare il metodo di approccio, creando delle checklist e specificando meglio quelle azioni “basilari” da compiere nel momento di emergenza, senza dare per scontata la presenza di risorse (umane, economiche, tecnologiche) che potrebbero essere insufficienti se non addirittura assenti. È chiaro che una realtà in grado di soddisfare il processo sopra descritto, non avrà grandi difficoltà a rialzarsi dopo l’impatto. Ma cosa accade a coloro che non riescono a seguire quelle 17 fasi? Creare documenti “di primo soccorso” può davvero fare la differenza tra un impatto di severa entità e uno più contenuto.
