Piano di incident response per un'azienda di 10 persone: cosa serve davvero senza produrre faldoni di documenti?

La primissima cosa da fare è non salvare quel piano sui server aziendali. Se entra un ransomware, non avrete più accesso ai vostri sistemi. Tenete una copia stampata per il manager e una per il lead tecnico, più una copia in una cartella cloud esterna indipendente. E per comunicare, stabilite fin da subito un canale alternativo all'e-mail aziendale.

Gestiamo un'agenzia di dimensioni simili a Monaco di Baviera. L'anno scorso è stato bucato l'account e-mail di un nostro cliente. Non avendo definito in anticipo chi dovesse chiamare chi, abbiamo perso le prime 4 ore nel panico interno a farci domande a vicenda. Dopo quell'episodio abbiamo creato un diagramma di flusso di una sola pagina. Ci sono volute solo 3 ore per prepararlo, ma poi durante un piccolo problema di DNS ci siamo coordinati in 20 minuti.

Sul piano tecnico l'errore più comune è staccare la spina o riavviare subito il server in preda al panico. Così si azzerano i log nella memoria volatile (RAM) e diventa impossibile capire da dove sia entrato l'attaccante. Nel piano deve essere specificata a chiare lettere la regola: "non spegnere la macchina, staccare solo il cavo di rete o disabilitare la scheda di rete della macchina virtuale".

Se operate in Germania non trascurate l'aspetto normativo. Nel vostro piano di incident response deve figurare come passaggio ben definito l'obbligo di notifica entro 72 ore all'autorità di controllo competente, ai sensi dell'art. 33 del GDPR, e l'eventuale comunicazione agli interessati. Nella confusione generale le aziende rischiano spesso di farsi sfuggire questa tempistica.

I questionari inviati dai clienti sono checklist standard da multinazionale. Il vostro piano di due pagine funzionerà benissimo all'interno, ma l'auditor aziendale potrebbe cercare voci tipo "SOC attivo 24/7". Scrivete il documento, ma quando lo presentate al cliente definite chiaramente i confini dicendo che si tratta di un "piano agile calibrato su una struttura di 10 persone", altrimenti vi metteranno inutilmente in difficoltà.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

anche noi siamo in 8 nel team quando ci è successa una cosa simile ci siamo resi conto che nessuno aveva il numero dell'avvocato. la lista dei numeri di emergenza e i recapiti secondari di tutti sono la parte fondamentale. basta che il file si chiami piano di incident response il contenuto tenetelo sintetico in 2 pagine.

Nel questionario il cliente chiede solo se il piano esiste o vuole anche l'ultimo verbale di test e una validazione di terze parti? Certi audit si accontentano del verbale della simulazione interna, altri pretendono un report di audit esterno. Avete verificato l'allegato sulla sicurezza nel vostro contratto?

Non fatevene una colpa e non perdetevi nei template corporate. Aggiungete al piano anche una semplice classificazione della gravità: Bassa (coinvolto un solo utente), Media (interruzione del servizio ma dati al sicuro), Alta (data breach o perdita di dati critici). Una suddivisione del genere rende chiarissimo a chi dare l'allarme e quando.

Sono nella stessa situazione, per questo chiedo. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi. Se scrivete qui il risultato, sarà utile anche ad altri.

Sono d'accordo, anzi vorrei sottolinearlo. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Se scrivete qui il risultato, sarà utile anche ad altri.

Avrei una domanda non vorrei deviare dall'argomento ma... Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio. boh correggetemi se sbaglio.

Grazie mille, proverò oggi.

ci proverò. quando prendi una decisione, guarda prima quali dati hai a disposizione.

sono curioso di saperre se qualcuno lo fa in modo diverso.

Questo thread è archiviato.

Nel nostro caso è andata così. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Argomento molto attuale.

riassumo l'argomento perché sono state date diverse risposte ma gran parte del tempo perso si accumula nele pratiche in attesa di approvazione.

spero che le sia utile.

Sì, per quanto riguarda piano di risposta agli incidenti la situazione è esattamente così. Prendere misure senza fare un inventario lascia aperta una porta che non vedi.