Ci hanno chiesto di adeguarci al framework NIST per l'incident response: lo adattiamo o facciamo un piano nostro?

Senza la gestione dei log, l'adeguamento al NIST non passa l'audit. Mettete in piedi una struttura semplice che trasferisca almeno i log dei server, gli accessi amministratore e il traffico firewall su uno storage separato e in sola lettura. Se si verifica un incidente e non potete dimostrare che l'attaccante non ha cancellato i log, la fase di analisi cade completamente nel vuoto.

Quando redigete il documento, chiarite bene questi tre punti: 1) In base a cosa si stabiliscono i livelli di gravità dell'incidente (basso, medio, critico)? 2) Entro quante ore vi impegnate a notificare l'accaduto al cliente e alle autorità competenti? 3) Se il responsabile decisionale non è reperibile, a chi viene delegata l'autorità? L'auditor andrà a guardare direttamente queste tre cose.

I team di audit dei grandi clienti corporate di solito si presentano con checklist già pronte. Voi magari vi fate in quattro per fare un piano ultra-perfetto solo perché hanno menzionato il NIST, ma l'auditor deve solo spuntare delle caselle sul modulo. Non vi esaurite: preparate una bozza essenziale che soddisfi i requisiti minimi e concordatela prima con il cliente.

L'anno scorso abbiamo affrontato un audit simile. Con un piano snello di 12 pagine e il verbale di una simulazione tabletop di due ore fatta sei mesi prima, abbiamo superato l'audit aziendale al primo colpo. Non abbiamo preso consulenti esterni, tutto il processo è stato preparato internamente in due settimane di lavoro.

Come prima cosa, definite i ruoli all'interno del team usando i titoli professionali e non i nomi propri. Se scrivete nel documento che Ahmet spegne il server, nel momento in cui il dipendente si licenzia il piano non è più valido. Se invece descrivete i compiti come "L'Amministratore di Sistema avvia il contenimento" e "L'Account Manager gestisce le comunicazioni", aggiornarlo in futuro sarà semplicissimo.

Ma questa simulazione tabletop come si fa esattamente? Ci si riunisce tutti in una stanza e si ragiona sullo scenario ipotetico o bisogna proprio spegnere i server e fare test tecnici reali?

Sulle tempistiche di notifica degli incidenti dovete fare molta attenzione al contratto principale e agli accordi di riservatezza (NDA) firmati con il cliente. I tempi di notifica indicati nel vostro piano NIST non devono mai essere più lunghi di quelli pattuiti a contratto; altrimenti rischiate di incorrere in responsabilità legali.

Da quel che ho capito dai commenti, il punto non è scrivere fiumi di carta, ma definire i ruoli, mettere al sicuro i log, delineare un flusso base di contenimento e documentare il tutto con un'esercitazione all'anno. Per una PMI non serve davvero nient'altro.

hai fatto bene ad aprire questo thread poi cioè prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

un backup non testato non è un backup. boh buon lavoro.

Questo thread è archiviato. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Direi di non avere fretta. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Io seguirei questa strada.

Tre cose da controllare mentre lo fai. Inizia con un piccolo test, non impegnarti subito su tutto.

Il fatto che tutti facciano una cosa non significa che sia quella giusta. Se avete domande scrivete rispondo per quanto possibile.

Non lo sapevo.

In generale è corretto, ma manca un pezzo. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Sono della stessa opinione. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

È tutto, scusate se mi sono dilungato.

Ha ragione.

Ho vissuto la stessa cosa.

Per un periodo ci siamo bloccati anche noi nello stesso punto. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Confermato dall'esperienza.