Esiste un momento in cui una procedura di incident management smette di essere un documento e diventa un vero strumento di sopravvivenza organizzativa.
Immaginiamo che siano le 23:00 di un venerdì sera.
Un sistema di monitoraggio rileva un’anomalia importante. Potrebbe esserci un attacco in corso. Il responsabile della cybersecurity non è raggiungibile, l’amministratore delegato è in ferie e il fornitore cloud non sta rispondendo.
Nel frattempo, però, il tempo continua a scorrere.
Ed è proprio qui che emerge una delle debolezze più frequenti dei sistemi di gestione: sono progettati per funzionare quando tutto funziona normalmente.
Ma un incidente, per definizione, avviene quando qualcosa è già uscito dalla normalità.
Il problema non è soltanto tecnico: è organizzativo
Per molti anni la gestione degli incidenti informatici è stata considerata principalmente un problema tecnico.
Si rileva l’attacco, si identifica la causa, si isolano i sistemi compromessi, si ripristinano i servizi e solo successivamente si affrontano gli aspetti amministrativi e normativi.
Oggi questo approccio non è più sufficiente.
Con l’introduzione di normative come NIS2 e Cyber Resilience Act, il tempo è diventato parte integrante della gestione della conformità.
Non basta risolvere l’incidente.
Occorre essere in grado di:
- riconoscerlo;
- valutarne la rilevanza;
- coinvolgere rapidamente le persone corrette;
- raccogliere le informazioni disponibili;
- decidere se esistono obblighi di notifica;
- conservare evidenza di ciò che è stato fatto e quando.
Il problema è quindi molto più ampio della cybersecurity.
È un problema di governance.
Le 24 ore che cambiano il modo di gestire gli incidenti
La NIS2 introduce, per gli incidenti significativi soggetti agli obblighi previsti dalla normativa, una prima comunicazione entro 24 ore dalla conoscenza dell’incidente, seguita da ulteriori comunicazioni previste dal processo di reporting.
Il Cyber Resilience Act introduce a sua volta obblighi temporali per i fabbricanti di prodotti con elementi digitali in relazione, tra l’altro, alle vulnerabilità attivamente sfruttate.
Il punto interessante non è soltanto il numero delle ore.
La domanda davvero importante è:
quando comincia a decorrere quel tempo?
Un alert generato da un sistema di monitoraggio non significa automaticamente che l’organizzazione abbia già compreso natura e gravità dell’evento.
Allo stesso tempo, però, non è possibile attendere giorni alla ricerca della certezza tecnica assoluta prima di attivare il processo di valutazione.
Occorre quindi costruire un meccanismo capace di trasformare rapidamente:
segnale tecnico → valutazione → escalation → decisione.
Ed è proprio qui che molte procedure iniziano a mostrare i propri limiti.
La procedura perfetta del martedì mattina
Immaginiamo una procedura aziendale apparentemente impeccabile.
In caso di incidente grave:
- l’analista informa il responsabile cybersecurity;
- il responsabile valuta l’evento;
- il CISO informa il management;
- il management autorizza la comunicazione;
- compliance o ufficio legale procede con gli adempimenti necessari.
Sulla carta funziona perfettamente.
Soprattutto il martedì mattina alle 10:30, quando tutti sono in ufficio.
Ma cosa succede se il responsabile cybersecurity è su un volo intercontinentale?
E se l’amministratore delegato è in ferie?
E se contemporaneamente il sistema di posta aziendale è indisponibile proprio a causa dell’incidente?
Una procedura che dipende dalla presenza di una singola persona contiene già una vulnerabilità.
Non informatica.
Organizzativa.
Il single point of failure umano
In informatica conosciamo molto bene il concetto di single point of failure.
Un componente la cui indisponibilità può bloccare l’intero sistema.
Eppure spesso costruiamo processi aziendali in cui il single point of failure è una persona.
Solo il CISO può autorizzare una determinata azione.
Solo il responsabile compliance possiede le credenziali necessarie.
Solo una persona conosce il contatto dell’autorità.
Solo un manager può approvare l’isolamento di un sistema critico.
Quando quella persona non è disponibile, il processo si ferma.
La vera domanda da porsi non è quindi:
“Chi è il responsabile?”
Ma:
“Cosa succede se il responsabile non è disponibile?”
È una differenza apparentemente piccola, ma fondamentale per la resilienza.
Il problema dei fornitori
La situazione diventa ancora più complessa quando una parte significativa dell’infrastruttura è affidata a soggetti esterni.
Cloud provider, SOC esterni, Managed Security Service Provider e fornitori software possono essere essenziali per ricostruire ciò che è accaduto.
Ma gli obblighi dell’organizzazione non scompaiono semplicemente perché una parte del servizio è stata esternalizzata.
Da qui nasce un problema molto concreto.
Se l’organizzazione dispone di un periodo limitato per valutare e comunicare un incidente, non può permettersi che il proprio fornitore utilizzi tutto quel tempo prima di fornire le informazioni necessarie.
I contratti, gli SLA e i meccanismi di escalation devono quindi essere coerenti con gli obblighi dell’organizzazione.
Non significa necessariamente imporre una specifica quantità di ore a tutti i fornitori.
Significa chiedersi:
il tempo previsto dal contratto mi lascia realmente il tempo necessario per rispettare i miei obblighi?
Se la risposta è no, esiste un rischio.
Esternalizzare un servizio non significa esternalizzare la responsabilità
È una convinzione ancora molto diffusa.
“Abbiamo tutto nel cloud.”
“Il SOC è esterno.”
“Abbiamo pagato un MSSP per gestire la sicurezza.”
Tutto vero.
Ma l’outsourcing delle attività tecniche non trasferisce automaticamente gli obblighi attribuiti dalla normativa all’organizzazione.
È possibile affidare a terzi:
- monitoraggio;
- analisi;
- infrastruttura;
- incident response tecnica;
- gestione dei log.
La governance, però, deve comunque essere in grado di prendere decisioni.
Questo significa conoscere:
- chi deve essere coinvolto;
- chi possiede l’autorità necessaria;
- chi sostituisce una persona assente;
- quali informazioni servono;
- dove sono conservate;
- quali canali utilizzare se quelli ordinari non funzionano.
Quando CRA, NIS2 e GDPR si incontrano nello stesso incidente
Un singolo evento può coinvolgere contemporaneamente diversi processi normativi.
Pensiamo, per esempio, a una vulnerabilità sfruttata in un prodotto digitale che genera anche un incidente su un servizio critico e comporta una violazione di dati personali.
Potrebbero entrare contemporaneamente in gioco:
- Cyber Resilience Act;
- NIS2;
- GDPR;
- processi interni di incident management;
- business continuity;
- gestione della sicurezza del prodotto.
L’incidente è uno.
Le funzioni aziendali coinvolte, invece, possono essere molte.
Product Security.
IT.
Cybersecurity.
Legal.
DPO.
Compliance.
Management.
Il vero rischio è quindi continuare a gestire questi mondi come silos indipendenti.
Durante una crisi non esistono tre incidenti diversi.
Esiste un evento reale che genera conseguenze diverse.
Il sistema di gestione deve essere capace di riconoscerle e coordinarle.
ISO 27001 e incident management: il documento non basta
ISO/IEC 27001 affronta l’incident management attraverso diversi controlli dell’Annex A, dalla preparazione alla valutazione degli eventi, dalla risposta all’apprendimento successivo all’incidente.
Ma una procedura perfettamente scritta non dimostra automaticamente che il processo sia efficace.
Per capire se funziona bisogna provarlo.
Ed è qui che entra in gioco uno degli strumenti più utili: il tabletop exercise.
Una buona simulazione dovrebbe cercare di far fallire il sistema
Molte esercitazioni aziendali vengono costruite in condizioni ideali.
Tutti i responsabili sono presenti.
Tutti conoscono lo scenario.
Le comunicazioni funzionano.
La documentazione è disponibile.
A quel punto il test viene superato e l’organizzazione conclude che il piano funziona.
Ma abbiamo realmente verificato qualcosa?
Una simulazione utile dovrebbe inserire deliberatamente condizioni sfavorevoli:
- il CISO è irraggiungibile;
- il provider cloud non risponde;
- le informazioni sono incomplete;
- il sistema email non funziona;
- alcuni dati risultano contraddittori;
- il principale decisore è assente;
- il fornitore comunica con molte ore di ritardo.
L’obiettivo non dovrebbe essere dimostrare che il piano funziona.
Dovrebbe essere scoprire dove può fallire.
Solo così è possibile correggerlo prima che sia un incidente reale a far emergere le debolezze.
La compliance del venerdì sera
Arriviamo quindi alla domanda centrale.
Quanto vale realmente un piano di incident response?
Non quanto è dettagliato.
Non quante firme contiene.
Non quanto è elegante il diagramma di flusso.
Vale quanto la capacità dell’organizzazione di utilizzarlo quando:
- manca una persona fondamentale;
- il fornitore non risponde;
- le informazioni sono incomplete;
- il tempo è limitato;
- i sistemi ordinari non funzionano.
La conformità reale non viene misurata quando tutto procede normalmente.
Viene misurata quando l’organizzazione deve prendere una decisione sotto pressione.
Ed è per questo che una delle domande più utili che un auditor, un consulente o un componente del management possa fare è estremamente semplice:
“Se questa persona non rispondesse al telefono, cosa succederebbe?”
Se la risposta è:
“Dovremmo capire cosa fare”,
allora probabilmente abbiamo appena trovato una vulnerabilità molto più importante di quelle presenti nei nostri server.
🎙️ Normalizziamoci – La compliance del venerdì sera
Nella nuova puntata approfondiamo il rapporto tra incident management, NIS2, Cyber Resilience Act, ISO/IEC 27001, continuità operativa e responsabilità organizzativa.
Perché una procedura non è realmente efficace finché non funziona anche nel momento peggiore.
Ascolta su Spotify