Ci hanno chiesto di classificare gli incidenti con una "tassonomia": cos'è e perché complica la gestione?

Non fatevi spaventare dalla parola tassonomia. Aprite un foglio di calcolo e create le colonne "Data", "Categoria", "Livello di gravità", "Asset impattato" e "Azione intrapresa". Non dovrete mica riempire migliaia di righe al giorno: ci inserirete solo quei fatti concreti che richiedono un vero intervento, una volta alla settimana o al mese.

Due anni fa avevamo impostato una tassonomia con 15 categorie: il team passava il tempo a compilare form invece di lavorare e il tempo medio di risposta è schizzato da 30 minuti a 2 ore. L'anno scorso abbiamo ridotto tutto a sole 3 categorie di base e il tasso di tracciamento è arrivato al cento per cento.

se considerate incidente ogni singolo tentativo fallito su ssh state freschi a chiudere ticket fino a domattina. basta distinguere i log dagli eventi che finiscono nella tassonomia e il resto va a posto da solo.

Il motivo principale per cui auditor e assicuratori pretendono una tassonomia è capire se siete in grado di fare una corretta root cause analysis in caso di disastro. Se capita un data breach, vogliono che siate in grado di dire "accesso non autorizzato tramite social engineering" invece di un generico "è andato in tilt il sistema".

I 3 filtri d'oro da seguire quando registrate un evento sono: 1) L'integrità o la riservatezza dei dati è stata compromessa? 2) Il servizio offerto al cliente ha subìto interruzioni? 3) È scattato un obbligo di notifica legale o contrattuale? Se la risposta a tutte e tre è no, non si tratta di una crisi tassonomica, ma di un banale log di sistema.

Nel modulo di richiesta dell'assicurazione viene imposto uno standard preciso (tipo ISO 27035 o NIST SP 800-61) o chiedono solo una metodologia definita internamente? Di solito basta avere un documento proprio ben strutturato.

Le grandi società di consulenza la vendono come se un'azienda di 5 persone dovesse per forza mettere in piedi un SOC attivo h24. Nella maggior parte degli audit con i clienti basta mostrare una paginetta con una tabella chiara dicendo "noi etichettiamo gli incidenti così" e la questione si chiude lì.

al nostro primo audit siamo andati nel panico pure noi e abbiamo copiato un documento NATO di 40 pagine trovato online. l'auditor si è messo a ridere e ci ha chiesto "ma davvero applicate tutta 'sta roba?". comunque più è semplice, più è credibile.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Il vero problema non è il numero, ma su cosa si basa quel numero.

Io seguirei questa strada.

Ho vissuto la stessa cosa due anni fa. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Spero che le sia utile.

preso nota grazie.

Esatto, e non è nemmeno così noto. Prendere misure senza fare un inventario lascia aperta una porta che non vedi.

Ha ragione.

Scusate, ma questo non vale in ogni caso. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

L'errore commesso da tassonomia degli incidenti informatici è generalmente reversibile ma costoso. Questa è la mia opinione, non la scrivo come verità assoluta.

Argomento molto attuale.

C'è una trappola qui, non posso non segnalarla. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Mi sono rilassato leggendo questa risposta, quindi non succede solo a me. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.