Come elaborare un piano di risposta agli incidenti partendo da zero

Un attacco informatico non si preannuncia. Una mattina scatta un allarme, qualcuno apre un ticket e, quando i vertici vengono messi al corrente, il danno si sta già diffondendo. Ciò che distingue le aziende che riescono a contenere una violazione nel giro di poche ore da quelle che rimangono bloccate nella fase di ripristino per mesi non è una tecnologia migliore. È la preparazione. Nello specifico: se esisteva un piano prima che qualcosa andasse storto.

Un piano di risposta agli incidenti (IRP) è una procedura documentata e collaudata volta a individuare, contenere e risolvere gli incidenti di sicurezza. Sembra una cosa burocratica. In pratica, però, fa la differenza tra una risposta controllata e il caos totale alle 2 del mattino.

Cosa si intende effettivamente per “incidente”

Non tutti gli avvisi costituiscono un incidente. Un tentativo di accesso fallito è un falso allarme. Il ransomware che crittografa un file server, invece, no. La distinzione è importante perché determina chi deve intervenire e con quale rapidità.

Categorie comuni che vale la pena definire prima che accada qualcosa:

• Violazione dei dati: accesso non autorizzato a dati sensibili o soggetti a regolamentazione
• Infezioni da malware: ransomware, spyware, wiper, trojan
• Attacchi “denial of service”: attacchi che compromettono il funzionamento dei sistemi o ne causano il blocco
• Minaccia interna: azioni dolose o accidentali da parte del personale o dei collaboratori esterni
• Compromissione della catena di approvvigionamento: attacchi che penetrano attraverso il software dei fornitori (SolarWinds ne è l’esempio più emblematico)
• Accesso non autorizzato: furto di credenziali, escalation dei privilegi, movimento laterale

Un’e-mail di phishing su cui si è cliccato ma che non ha installato nulla è diversa da una che ha installato un beacon di Cobalt Strike. Il piano deve tenere conto di entrambe le eventualità e comunicare rapidamente al team quale è quale.

Perché la maggior parte dei piani in realtà non funziona

Molte organizzazioni dispongono di un documento sulla risposta agli incidenti. Molto meno numerose sono quelle in cui qualcuno lo abbia effettivamente letto. E ancora meno sono quelle che lo hanno testato in uno scenario che assomigli anche solo vagamente a una situazione reale.

I soliti problemi: il documento risale a tre anni fa, riporta i recapiti di persone che hanno lasciato l’azienda, fa riferimento a strumenti che sono stati sostituiti e nessuno dei membri dell’attuale team di risposta lo ha mai visto. A quanto pare, c’è una differenza sostanziale tra avere un documento programmatico e disporre di un manuale operativo. Il primo soddisfa i revisori. Il secondo è ciò che si usa quando il sistema di produzione è inattivo alle 3 del mattino e nessuno sa chi sia autorizzato a disconnettere un server compromesso.

Le sei fasi e il loro significato nella pratica

Il quadro di riferimento NIST SP 800-61 suddivide la risposta agli incidenti in sei fasi. Il SANS adotta una logica simile, pur utilizzando denominazioni diverse. In entrambi i casi, la struttura rimane invariata.

Preparazione

Tutto ciò che precede un incidente. È qui che si svolge il vero lavoro: definire cosa si intende per incidente, costituire e formare il team di risposta, predisporre l’infrastruttura di registrazione e di allerta, condurre esercitazioni teoriche. Un dettaglio che viene costantemente trascurato: l’autorizzazione preventiva delle azioni. Durante un incidente in corso, attendere l’approvazione legale per isolare un server comporta una perdita di tempo che non ci si può permettere. Decidete in anticipo cosa può essere fatto immediatamente e da chi, senza bisogno di escalazione.

Identificazione

È successo qualcosa. La domanda è: cosa, esattamente? Questa fase consiste nel trasformare gli avvisi in incidenti confermati, correlare i segnali tra gli strumenti SIEM ed EDR, determinare l’ambito dell’incidente e ricostruire la cronologia degli eventi. La rapidità in questa fase è direttamente legata alla qualità della registrazione dei log impostata durante la fase di preparazione. Log di scarsa qualità comportano un’identificazione lenta. Un’identificazione lenta comporta meno opzioni.

Contenimento

Il contenimento a breve termine è rapido e drastico: isolare gli host infetti, bloccare gli indirizzi IP degli autori degli attacchi, disattivare gli account compromessi. Il contenimento a lungo termine è più mirato: soluzioni temporanee, riconfigurazione dei sistemi, monitoraggio rafforzato di comportamenti specifici. Una decisione che si presenta costantemente: disconnettere immediatamente o osservare prima l’autore dell’attacco? La disconnessione limita i danni. Il monitoraggio rivela la portata completa dell’attacco. Esistono validi motivi a favore di entrambe le opzioni. Questa scelta dovrebbe essere discussa in anticipo, non improvvisata sotto pressione.

Eradicazione

Eliminare completamente la minaccia. Applicare le patch alle vulnerabilità sfruttate, eliminare il malware e i meccanismi di persistenza, cambiare le credenziali e ripristinare i sistemi compromessi a partire da immagini pulite. Saltare questo passaggio o affrettarlo è il motivo per cui le organizzazioni vengono nuovamente compromesse attraverso lo stesso vettore due settimane dopo. Succede più spesso di quanto si pensi.

Ripresa

Ripristinate i servizi in ordine di priorità. Verificate che i sistemi siano puliti prima di ricollegarli. Monitorate attentamente eventuali ricorrenze. E adempite agli obblighi di notifica: il GDPR prevede 72 ore di tempo per notificare alle autorità di controllo qualsiasi violazione dei dati personali. Il termine non si sospende solo perché il ripristino è ancora in corso.

Esperienze acquisite

La fase che la maggior parte dei team salta perché è esausta. Ed è proprio per questo che è importante. Entro due settimane dovrebbe essere effettuata un’analisi post-incidente: cosa è successo, cosa ha funzionato, cosa no, quali lacune sono emerse, quali modifiche vengono apportate e entro quando. Documentatelo. Aggiornate il piano. Poi attuate effettivamente le modifiche; altrimenti, è stata solo una riunione.

Strumenti che rendono un piano realizzabile

L'IRP descrive cosa fare. Gli strumenti sono ciò che permette di agire rapidamente anche sotto pressione.

• SIEM: Splunk, Microsoft Sentinel, IBM QRadar per la correlazione dei log su larga scala
• EDR: CrowdStrike Falcon, SentinelOne, Microsoft Defender per il rilevamento comportamentale e l'isolamento degli endpoint
• SOAR: Palo Alto XSOAR, Splunk SOAR per l'esecuzione automatizzata dei playbook
• Informazioni sulle minacce: MISP e Recorded Future per contestualizzare le TTP degli autori degli attacchi
• Analisi forense: Velociraptor, Magnet AXIOM, Volatility per le indagini e la conservazione delle prove

Gli strumenti contano meno della capacità delle persone di utilizzarli sotto pressione. Un’istanza Splunk con 400 dashboard e senza runbook non è di alcuna utilità.

Allineamento normativo: cosa c’è da sapere

A seconda del settore e dell’area geografica, un IRP non è facoltativo, ma costituisce un obbligo di legge. Quadri normativi principali:

• NIST SP 800-61 Rev. 2: lo standard di riferimento per gli ambienti federali statunitensi e per la maggior parte delle aziende
• ISO/IEC 27035: norma internazionale per la gestione degli incidenti
• Articolo 33 del GDPR: obbligo di notifica delle violazioni entro 72 ore per i dati personali nell’UE
• Direttiva NIS2: obblighi di segnalazione degli incidenti per gli operatori dei servizi essenziali in tutta l’UE
• DORA: requisiti di resilienza del settore finanziario dell’UE in vigore dal gennaio 2025, con obblighi espliciti in materia di test di resilienza
• PCI DSS v4.0: documentazione relativa al settore dei pagamenti e requisiti relativi ai test annuali

NIS2 e DORA sono le normative che stanno attualmente colendo di sorpresa le organizzazioni. Entrambe inaspriscono notevolmente i requisiti in materia di documentazione, frequenza dei test e tempistiche di rendicontazione.

Fornitori da prendere in considerazione

Alcune organizzazioni sviluppano le proprie capacità in materia di IR interamente al proprio interno. La maggior parte, però, non dispone del personale né dell’esperienza necessaria per farlo in modo adeguato, soprattutto per quanto riguarda la simulazione e i test. Ecco un breve elenco:

DXC Technology offre un servizio completo per lo sviluppo di programmi di risposta agli incidenti (IR): progettazione del piano, esercitazioni teoriche e servizi gestiti di rilevamento e risposta. L’azienda vanta una competenza particolarmente solida nei settori regolamentati (energia, sanità, servizi finanziari), comprese le soluzioni software per il settore energetico, in cui l’allineamento alla conformità è integrato nell’incarico sin dall’inizio.

Secureworks (Atlanta) offre servizi di assistenza IR integrati alla propria piattaforma Taegis XDR. La sua Counter Threat Unit pubblica costantemente informazioni sulle minacce che vengono integrate direttamente negli aggiornamenti dei playbook, utili per i team che desiderano disporre di funzionalità di rilevamento e risposta in un unico ambiente.

WithSecure (Helsinki) adotta un approccio consultivo allo sviluppo dei programmi di risposta agli incidenti (IR), in stretta conformità con i requisiti normativi europei. È più adatta alle organizzazioni che stanno sviluppando per la prima volta le proprie capacità di risposta agli incidenti rispetto a quelle che cercano un servizio gestito in senso stretto.

Trustwave (Chicago) combina servizi di sicurezza gestiti con consulenza in materia di risposta agli incidenti (IR) attraverso SpiderLabs, un red team interno che negli ultimi dieci anni ha prodotto alcuni dei rapporti sulle minacce più approfonditi del settore.

Orange Cyberdefense (Francia) gestisce contemporaneamente il coordinamento transfrontaliero delle risposte agli incidenti (IR) in diverse giurisdizioni dell’UE. È una soluzione utile per le multinazionali che devono gestire parallelamente gli obblighi previsti dalla direttiva NIS2 e dal GDPR in diversi paesi.

Gli errori che si ripetono ogni volta

Anche i team meglio preparati commettono errori prevedibili. Quelli che si ripetono più spesso sono:

• Non testare il piano: un documento che non è mai stato messo alla prova in condizioni di stress simulate è pura congettura
• Nessun protocollo di comunicazione definito: chi parla con la stampa, chi contatta l’autorità di regolamentazione, chi avvisa i clienti
• Dare per scontato che i backup siano integri senza verificarli
• Escludendo le terze parti: i fornitori di servizi cloud, i fornitori SaaS e gli MSP devono essere coinvolti nel processo, non semplicemente informati a posteriori
• Considerare la gestione degli incidenti (IR) come una funzione esclusivamente informatica: gli uffici legale, delle comunicazioni, delle risorse umane e la dirigenza hanno tutti un ruolo da svolgere in caso di incidente grave

E l’errore più grave: considerare il piano come un progetto una tantum. Le minacce cambiano. I sistemi cambiano. Le persone se ne vanno. Un IRP che non viene aggiornato attivamente risulta obsoleto prima ancora di essere necessario.

Domande frequenti

Quanto tempo ci vuole per realizzare da zero un IRP funzionante?

È possibile redigere un piano di base in un arco di tempo compreso tra quattro e sei settimane. Un programma ben strutturato, completo di manuali operativi, esercitazioni collaudate e integrazioni di strumenti, richiede realisticamente da tre a sei mesi.

Con quale frequenza dovrebbe essere sottoposto a controllo?

Almeno una volta all'anno. Il DORA e la maggior parte dei framework aziendali raccomandano ora di svolgere esercitazioni teoriche due volte all'anno, con simulazioni complete almeno una volta. Dopo ogni incidente grave o modifica significativa al sistema, effettuare immediatamente una revisione.

Qual è la differenza tra un’esercitazione da tavolo e un’esercitazione “red team”?

Una sessione teorica si basa sulla discussione; si analizzano gli scenari senza entrare nel merito dei sistemi. Un’attività con il “red team” simula attivamente le tecniche degli aggressori contro un’infrastruttura reale. Entrambe le attività sono preziose e mettono alla prova aspetti diversi.

Qual è la prima cosa da fare quando si conferma un incidente?

Attivare la squadra di intervento, documentare l’ora e gli indicatori iniziali e avviare le misure di contenimento già autorizzate. Non intervenire sui sistemi infetti per la pulizia prima che siano state preservate le prove forensi; sono proprio quelle informazioni a rivelare la portata completa di quanto accaduto.

• Informazioni su
• Ultimi messaggi

Milena Baghdasaryan

Specialista dei contenuti presso PowerDMARC

Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.

Ultimi messaggi di Milena Baghdasaryan (vedi tutti)

• Come elaborare un piano di risposta agli incidenti partendo da zero - 8 settembre 2026
• Il nuovo metodo con cui gli hacker ingannano gli assistenti finanziari basati sull’intelligenza artificiale - 7 settembre 2026
• Migliori pratiche di sicurezza DNS: una checklist completa per il rafforzamento della sicurezza - 7 settembre 2026