Dobbiamo preparare un piano di risposta agli incidenti: i template online funzionano?

La pecca più grande dei template sono le istruzioni sull'isolamento tecnico. Quando una macchina viene colpita da un ransomware, invece di staccare la spina bisogna staccare il cavo di rete ed estrarre un dump della RAM. Il piano dovrebbe includere questi dettagli tecnici in punti sintetici.

Prendete il template e tenete solo i titoli. Quando abbiamo redatto il nostro primo piano abbiamo indicato i cellulari di tutti e il sostituto di chi deve spegnere il server in emergenza. Stampato su carta e appeso alla bacheca in ufficio è la soluzione più pulita.

Nel contratto, entro quante ore il cliente vi impone di avvisarlo in caso di violazione dei dati? Se non mettete quella tempistica al centro del piano, risulterete inadempienti.

Il mese scorso abbiamo superato un audit aziendale simile. Abbiamo presentato un piano semplice di 6 pagine. L'auditor ha approvato direttamente questo documento sintetico con i ruoli ben definiti, preferendolo ai soliti template copia-incolla da 50 pagine.

Nessuno si mette a leggere 40 pagine di PDF in piena emergenza. Se non avete mai simulato lo scenario a tavolino con tutta la squadra almeno una volta, il vostro piano è solo un pezzo di carta buono per ingannare l'auditor.

Nel vostro piano tenete sempre pronti questi tre contatti: 1) Assistenza emergenze h24 dell'hosting provider, 2) Numero diretto dell'avvocato aziendale, 3) Contatto del consulente di cybersecurity esterno da chiamare.

quando siamo stati hackerati noi avevamo il template ma le password sono rimaste bloccate dentro al server dov'era salvato. stampatelo su carta e tenetelo in un cassetto fidatevi

ma questa simulazione a tavolino come si fa esattamente? ci si riunisce col team e si discute solo dello scenario o bisogna proprio spegnere i sistemi e fare prove tecniche?

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

Riassumo l'argomento, perché sono state date diverse risposte. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Avete ragione, sono passato anch'io per la stessa strada. Chiunque abbia fretta su piano di risposta agli incidenti si blocca nello stesso punto.

Naturalmente cambia se la vostra situazione è diversa.

Sì, per quanto riguarda piano di risposta agli incidenti la situazione è esattamente così. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

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

Breve riassunto per i nuovi arrivati: Il vero problema non è il numero, ma su cosa si basa quel numero.

Lascio un avvertimento. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Se avete domande, scrivete, rispondo per quanto possibile.

Scusate, ma questo non vale in ogni caso. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Io seguirei questa strada.

Mi farebbe piacere se scrivesse il risultato.

La discussione si è dispersa, la riassumo. Le persone difendono le abitudini non i processi. La resistenza nasce da lì.

Spero che le sia utile.

Dopo aver vissuto questa cosa, il mio punto di vista è cambiato. Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

È tutto, scusate se mi sono dilungato.

Il mio dubbio è stato chiarito, grazie. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo. Confermato dall'esperienza.