Incident Response: come rispondere agli attacchi informatici
Sei sotto attacco in questo momento?
Non spegnere i sistemi e non ripristinare i backup prima del triage: le due azioni più istintive sono anche quelle che distruggono le evidenze e reinfettano l'ambiente.
In sintesi
L'incident response è il processo con cui un'organizzazione rileva, analizza, contiene ed elimina un incidente informatico, ripristina i servizi e documenta quanto accaduto. Nexsys interviene in due modi: in emergenza, affiancando l'IT durante un attacco in corso, e in preparazione, costruendo e testando l'Incident Response Plan con ruoli, playbook, catena di escalation ed evidenze richieste da NIS2 e GDPR.
Un incidente informatico non si gestisce con la buona volontà del momento. Nelle prime ore contano tre cose: capire cosa è successo davvero, impedire che l’attaccante estenda il controllo, e prendere decisioni che non compromettano il ripristino e le verifiche successive. Chi improvvisa perde di solito proprio queste tre cose insieme.
Nexsys affianca le aziende in entrambi i momenti: quando l’attacco è in corso e quando c’è ancora tempo per prepararsi. Le due attività usano lo stesso metodo, ma hanno costi e risultati molto diversi: prepararsi costa una frazione di quanto costa reagire senza un piano.
Che cos’è l’incident response
L’incident response (IR) è il processo strutturato con cui un’organizzazione gestisce un evento di sicurezza dal momento in cui viene rilevato fino al ritorno alla normalità operativa e alla revisione finale. Il riferimento metodologico più diffuso è il ciclo del NIST, articolato in preparazione, rilevazione e analisi, contenimento, eradicazione e ripristino, e attività post-incidente.
Le fasi non sono un elenco da esibire in un documento: definiscono chi decide cosa, con quali informazioni e in quale ordine. È la differenza fra un’azienda che dopo tre giorni sa cosa è stato esfiltrato e una che dopo tre settimane sta ancora ricostruendo i log.
1. Preparazione
Asset critici mappati, telemetria attiva, ruoli assegnati, contatti e canali alternativi definiti, playbook scritti.
2. Rilevazione e analisi
Triage degli alert, ricostruzione del vettore di ingresso, perimetro reale della compromissione, classificazione della gravità.
3. Contenimento
Isolamento dei sistemi coinvolti, revoca di sessioni e credenziali, blocco dei canali di comando e controllo, preservazione delle evidenze.
4. Eradicazione
Rimozione di malware, account creati dall’attaccante, task pianificati, regole di inoltro e altre persistenze.
5. Ripristino
Rientro in produzione su ambiente bonificato, con verifica applicativa e monitoraggio rinforzato nelle settimane successive.
6. Post-incidente
Relazione finale, lezioni apprese, correzioni tecniche e aggiornamento del piano.
Cosa fa Nexsys durante un incidente
Interveniamo a fianco del team IT interno, non al suo posto. Il primo obiettivo è ricostruire i fatti prima di toccare la produzione: quali sistemi sono compromessi, da quando, con quali credenziali si muove l’attaccante e quali dati sono stati raggiunti. Solo dopo si decide come contenere.
Lavoriamo sulla telemetria già presente in azienda - EDR/XDR, log di dominio, SIEM, sistemi di posta e identità - e la integriamo dove è insufficiente. Se l’incidente coinvolge Active Directory o le identità cloud, il perimetro dell’analisi si estende a tutto il piano di controllo: un contenimento che lascia all’attaccante un account privilegiato non è un contenimento.
Negli scenari di cifratura dei dati, l’intervento prosegue con il servizio dedicato di ransomware recovery, che aggiunge backup immutabili, ambiente isolato per il restore e ripristino curato anti-reinfezione. La sequenza corretta è sempre la stessa: prima analisi e bonifica, poi ripristino. Il percorso completo è descritto nella guida su come gestire la crisi ransomware.
Non sei sotto attacco, ma non sai cosa fareste domani mattina
Partiamo da una sessione di assessment: asset critici, telemetria disponibile, ruoli, contatti e lacune del piano attuale.
Incident Response Plan: cosa contiene davvero
Un Incident Response Plan non è un documento di conformità da archiviare. È lo strumento che qualcuno dovrà aprire alle due di notte, in un momento in cui la posta aziendale potrebbe non essere disponibile. Per questo deve essere breve, operativo e reperibile anche fuori dai sistemi coinvolti.
Gli elementi che costruiamo insieme
1. Perimetro e asset critici
Quali servizi non possono restare fermi, con quali dipendenze e priorità di ripristino.
2. Ruoli e catena decisionale
Chi dichiara l’incidente, chi autorizza l’isolamento, chi parla con clienti, autorità e assicurazione.
3. Classificazione della gravità
Criteri per distinguere un evento gestibile dall’incidente che attiva la crisi.
4. Playbook per scenario
Ransomware, compromissione di account, esfiltrazione dati, frode via posta, indisponibilità di un fornitore.
5. Comunicazione
Canali alternativi, modelli di messaggio interni ed esterni, chi non deve parlare.
6. Evidenze e conservazione
Quali log servono, dove sono, per quanto tempo restano e come si preservano senza alterarli.
7. Rubrica di crisi
Contatti interni, fornitori, legale, assicurazione, CSIRT Italia e Garante privacy.
La differenza fra un piano vivo e un piano morto è una sola: il test. Un piano mai provato produce, nel momento peggiore, esattamente l’improvvisazione che doveva evitare.
Notifiche obbligatorie: cosa cambia con NIS2 e GDPR
Per i soggetti in perimetro NIS2, il D.Lgs. 138/2024 prevede una notifica in tre tempi verso il CSIRT Italia: una prima segnalazione entro 24 ore dalla conoscenza dell’incidente significativo, la notifica con la valutazione iniziale entro 72 ore, e la relazione finale entro un mese. Sul fronte protezione dei dati, il GDPR richiede la notifica al Garante entro 72 ore quando la violazione comporta un rischio per i diritti delle persone.
Il punto pratico è che quelle scadenze si misurano in ore, mentre le informazioni richieste — perimetro, impatto, indicatori di compromissione — arrivano dall’analisi tecnica. Senza un piano che assegni in anticipo chi raccoglie cosa, la notifica arriva incompleta o tardi. Per il quadro completo degli obblighi si può partire dalla guida NIS2 per le PMI.
Verifica la tua posizione sugli obblighi di notifica
La checklist operativa in 7 step copre governance, misure tecniche ed evidenze da produrre in caso di ispezione.
Simulazioni, formazione e prontezza del team
Le simulazioni servono a scoprire i punti di rottura quando costano poco. Una prova table-top con direzione e IT rivela in due ore quali decisioni non hanno un proprietario; una simulazione tecnica verifica se la telemetria che credete di avere esiste davvero e se qualcuno la sta guardando.
Il primo anello della catena, però, resta la persona che riceve il messaggio sospetto: la maggior parte degli incidenti inizia lì. Le campagne di phishing simulation misurano la reattività reale, mentre il corso di security awareness lavora sul comportamento di chi deve segnalare, non solo evitare.
Per il team tecnico, il corso Cybersecurity Incident Responder copre il ciclo completo, dal triage dell’endpoint alla memory forensics fino alla stesura dell’IRP; il corso Blue Team lavora invece sulla detection e sul threat hunting che precedono l’incidente.
Il piano lo esegue il tuo team, non il documento
Formiamo chi dovrà gestire l'incidente: triage, analisi forense, contenimento e gestione della crisi, con Open Badge digitale al termine.
Prima dell’incidente: ridurre superficie e tempi di rilevazione
La qualità di una risposta dipende quasi interamente da ciò che è stato fatto prima. Tre aree pesano più delle altre:
- Identità e Active Directory: la quasi totalità degli attacchi passa da credenziali e privilegi. Un assessment e hardening di Active Directory chiude i percorsi di escalation che l’attaccante userebbe, mentre l’identity security presidia autenticazione e accessi privilegiati.
- Rilevazione continua: un incidente scoperto dai backup falliti è un incidente scoperto tardi. Il SOC as a Service porta monitoraggio e triage degli alert su base continuativa.
- Capacità di ripristino: senza copie integre e separate non esiste ripristino, solo trattativa. Valgono la Data Protection as a Service e, per i servizi che non possono restare fermi, il disaster recovery.
Incident response, ransomware recovery e disaster recovery: le differenze
Tre termini spesso usati come sinonimi, che in un contratto e in un’emergenza significano cose diverse:
Incident response
Il processo di gestione dell’incidente in quanto tale - analisi, contenimento, eradicazione, coordinamento e documentazione. Si applica a qualsiasi tipo di attacco, anche senza perdita di dati.
Ransomware recovery
Lo scenario specialistico in cui i dati sono stati cifrati e va ricostruito un ambiente pulito da cui ripartire.
Disaster recovery
Il ripristino di infrastrutture e servizi entro RPO e RTO definiti, indipendentemente dalla causa, incluso un guasto o un evento fisico.
Costruiamo il tuo Incident Response Plan
Assessment del livello di prontezza, playbook per i vostri scenari reali, ruoli e catena di escalation, prova table-top con direzione e IT.
Perchè Nexsys
Lavoriamo sulla sicurezza da entrambi i lati: eroghiamo i servizi e formiamo le persone che li useranno. Il team porta certificazioni CEH, BTL1 e Microsoft (MCT, MS-500, AZ-500, SC-300), Nexsys è certificata ISO 9001:2015, Microsoft Solutions Partner per il Modern Work e socia Clusit.
Nella pratica questo significa che chi vi affianca durante un incidente è la stessa struttura che progetta l’hardening, verifica le difese con i penetration test e forma il vostro team. Nessun passaggio di consegne fra fornitori diversi nel momento in cui contano le ore.
Domande frequenti sull’incident response
Che cos’è l’incident response?
È il processo con cui un’organizzazione rileva, analizza, contiene ed elimina un incidente di sicurezza informatica, ripristina i servizi e documenta quanto accaduto. Segue in genere il ciclo NIST: preparazione, rilevazione e analisi, contenimento, eradicazione e ripristino, attività post-incidente.
Qual è la differenza fra incident response e disaster recovery?
L’incident response gestisce l’attacco: capire cosa è successo, fermarlo ed eliminarlo. Il disaster recovery ripristina infrastrutture e servizi entro tempi definiti, qualunque sia la causa. In un attacco ransomware servono entrambi, nell’ordine: prima analisi e bonifica, poi ripristino.
Cosa NON bisogna fare nelle prime ore di un attacco?
Spegnere i sistemi in modo scoordinato, cancellando la memoria volatile e le evidenze; ripristinare i backup sull’infrastruttura ancora compromessa, con reinfezione quasi certa; comunicare sui canali che l’attaccante potrebbe già controllare; pagare o trattare senza una valutazione tecnica e legale.
Serve un Incident Response Plan anche a una PMI?
Sì, e in proporzione conta di più: una PMI ha meno persone da dedicare alla gestione della crisi, quindi ha più bisogno di decisioni già prese. Un piano utile per una realtà di questa dimensione è breve, operativo e mantenibile, non un manuale di cento pagine.
Entro quanto va notificato un incidente?
Per i soggetti NIS2, il D.Lgs. 138/2024 prevede una prima segnalazione al CSIRT Italia entro 24 ore, la notifica con valutazione iniziale entro 72 ore e la relazione finale entro un mese. Il GDPR richiede la notifica al Garante entro 72 ore quando la violazione presenta un rischio per gli interessati. Gli obblighi possono coesistere sullo stesso incidente.
Che differenza c’è fra un SOC e l’incident response?
Il SOC monitora, rileva e fa triage in modo continuativo. L’incident response entra in campo quando un evento diventa un incidente e richiede analisi approfondita, contenimento e coordinamento. Le due cose si integrano: un SOC riduce i tempi di rilevazione, un piano di IR riduce i tempi di reazione.
Preferisci compilare il modulo? Scrivi i tuoi dati qui sotto
Il servizio telefonico è attivo dal lunedì al venerdì dalle 8:00 alle 18:00 al numero 0452456669. Puoi anche compilare il modulo sottostante: