Ciclo di vita della risposta agli incidenti: come strutturarlo per una piccola azienda?

Non fatevi spaventare dagli standard BSI, alla base c'è solo buon senso. Nelle piccole imprese l'errore più comune è non sapere a chi spetti la decisione. In caso di emergenza decide l'office manager, l'IT esterno o il titolare? Se non mettete questa catena di comando nero su bianco adesso, durante un attacco perderete ore preziose al telefono.

Nella fase di contenimento, l'unica cosa che il personale deve fare è staccare la connessione fisica di rete. Riavviare o togliere la corrente fa perdere le tracce del malware rimaste nella RAM. Staccando solo il cavo di rete, l'esperto esterno ha molte più possibilità di analizzare la memoria volatile e individuare l'origine della minaccia.

Domattina fate subito queste 3 cose: 1) Stampate il numero di emergenza del vostro supporto IT e appendetelo in bacheca. 2) Fate un backup su disco esterno settimanale e chiudetelo in cassaforte. 3) Dite al team che se succede qualcosa di strano devono solo staccare internet senza spegnere il PC. Così avete già fatto metà della preparazione.

Due anni fa ci siamo trovati impreparati davanti a un ransomware. Abbiamo dovuto pagare 6.500 EUR a una ditta esterna per recuperare il server e fare l'analisi forense. Se solo avessimo preparato un protocollo di emergenza tre mesi prima, ci saremmo risparmiati più di metà di quella spesa.

c'è una cosa che non mi è chiara: perché spegnere il PC sarebbe dannoso? togliendo la corrente il virus non smette di funzionare? non ha più senso staccare subito la spina?

Evitate assolutamente di comprare quei pesanti faldoni di framework proposti dai consulenti. Provano a far compilare questionari da cento punti a piccole aziende, e poi nel momento del bisogno nessuno apre nemmeno quel raccoglitore. Qualsiasi cosa oltre a una semplice checklist è solo tempo perso.

In sintesi il ciclo si riduce a quattro passaggi: prepara il piano di contatto e i backup prima che succeda qualcosa, isola la macchina dalla rete al minimo sospetto, fai pulire tutto all'esperto IT e, finita l'emergenza, metti a verbale la falla per blindare il sistema.

Sono passato da qui, vi racconto. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi. Naturalmente cambia se la vostra situazione è diversa.

Su questo punto non sono d'accordo. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

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

Ho lavorato a lungo su questo. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo. Spero che le sia utile.

Racconto la mia esperienza. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Questa è la mia opinione, non la scrivo come verità assoluta.

Riassumo l'argomento, perché sono state date diverse risposte. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

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

La discussione si è dispersa, la riassumo. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

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

Secondo me è difficile essere così netti sul lato ciclo di vita incident response. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Io seguirei questa strada.

Salvato.

Parlo dal lato opposto, io sono dalla parte dei fornitori. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Io seguirei questa strada.

Ho vissuto la stessa cosa due anni fa. Un backup non testato non è un backup.

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

Vi spiego come si fa in pratica. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Confermato dall'esperienza.