In un ufficio qualunque c’è una porta a vetri con un maniglione orizzontale e piatto su entrambi i lati: ogni persona che arriva per la prima volta o che cammina distrattamente lo spinge. E, ovviamente, è il verso sbagliato perché il maniglione andava tirato.
Don Norman ha reso celebre questo paradigma dell’ergonomia e dell’usabilità, chiamandolo “porta di Norman”: non perché le persone siano distratte, ma perché il design comunica l’azione sbagliata (Norman, The Design of Everyday Things, 1988).
Nessuno accusa di errore chi spinge invece di tirare. Eppure, in azienda, quando un dipendente clicca su un link o inserisce una password nel posto sbagliato, la prima riga del report recita qualcosa come: “La causa è stata l’errore umano”. O la negligenza, o la distrazione, a seconda della cultura aziendale. Ma comunque è colpa tua.
Indice degli argomenti
Perché l’indagine non può fermarsi all’utente
Formulo la questione in modo volutamente estremo: “l’errore umano” non esiste. Cioè, non è che l’errore umano non esista, ma non è quasi mai la causa radice di un incidente. È una differenza che cambia l’intero svolgimento dell’indagine volta a individuare la causa radice dei problemi.
La Root Cause Analysis, nell’ambito dell’incident response, nasce proprio per evitare questa scorciatoia. Il metodo dei “5 perché”, sviluppato in ambito industriale da Toyota, chiede di continuare a porsi la domanda “perché” fino a individuare una causa strutturale, non una persona:
- Perché numero 1: perché l’operatore ha cliccato sul link malevolo? Beh, perché è stato distratto o negligente, oppure perché qualcuno non lo ha formato adeguatamente. Errare humanum est e qualche essere umano ha sbagliato!
- Perché numero 2: perché quella email era nella sua casella? Ovvio, è colpa dell’antispam! Molti si fermano a questo punto, cioè al controllo di sicurezza primario. Ma l’analisi si è conclusa troppo presto.
- Perché numero 3: controlli tecnici compensativi sull’email “contenitore” (es. indirizzo IP del server di provenienza, DMARC, intera catena di trasmissione).
- Perché numero 4: filtri e altri controlli tecnici compensativi sul “contenuto” dell’email.
- Perché numero 5: permessi troppo ampi assegnati a quell’account.
Un caso per capire la dinamica
Un caso frequente mette in evidenza la differenza. Un addetto dell’ufficio acquisti riceve la fattura di un fornitore abituale, con l’indicazione che le coordinate bancarie sono cambiate, e aggiorna il pagamento. Il ticket viene chiuso con la dicitura “errore umano: mancata verifica”.
Fermarsi lì lascia intatte almeno quattro condizioni che hanno reso possibile l’incidente: il messaggio è arrivato senza che l’autenticazione del mittente venisse controllata a valle, la modifica di un IBAN non richiedeva una seconda approvazione, non esisteva un canale rapido per verificare il cambio con il fornitore, e la persona aveva l’autorizzazione a disporre il bonifico da sola.
La stessa email, il mese successivo, troverà un altro addetto nelle stesse condizioni. Tuttavia, consideriamo che nessuna di queste quattro condizioni riguarda la distrazione: tutte riguardano il modo in cui il processo è stato progettato.
Il rischio, quando un’organizzazione scrive “errore umano” nel campo “causa” di un ticket di incidente, è che quel campo chiuda l’indagine anziché aprirla. È un approccio comodo perché individua un responsabile visibile, non richiede di mettere in discussione l’architettura dei permessi, non genera un’azione per il team infrastrutture, non richiede un ulteriore budget per selezionare e poi acquistare controlli di sicurezza aggiuntivi.
Ma un’analisi che si ferma al “Perché” numero 2 non produce alcuna azione correttiva strutturale: il mese prossimo un altro dipendente, di fronte alla stessa email plausibile e allo stesso accesso privilegiato non necessario, farà lo stesso gesto.
Questo non significa che la formazione anti-phishing sia inutile: aiuta le persone a riconoscere i segnali, riduce il tasso di click sulle campagne simulate e costruisce cultura. Ma la formazione agisce sulla persona, non sul sistema che la espone al rischio.
Il Verizon Data Breach Investigations Report 2024 ha rilevato che l’elemento umano è stato una componente del 68% delle violazioni analizzate, un dato sostanzialmente stabile rispetto all’anno precedente (Verizon, 2024 DBIR).
Il punto interessante non è la percentuale in sé, ma ciò che succede dopo averla letta: se diventa l’alibi per fermarsi o il punto di partenza per chiedersi perché quella percentuale non scende, nonostante anni di corsi di sensibilizzazione.
Le implicazioni per il CISO
Un CISO che vuole ridurre davvero l’esposizione dovrebbe applicare alla propria organizzazione lo stesso test delle porte di Norman: quando un errore si ripete con una frequenza prevedibile, in ruoli diversi e con persone diverse, il problema non è nelle persone, ma nel design del processo che le mette in quella condizione.
Lo dice anche ITIL quando parla delle Pratiche di “Problem Management” e “Incident Management”.
La segmentazione dei privilegi, l’autenticazione a più fattori resistente al phishing e i controlli tecnici che rendono il clic errato non distruttivo sono le vere leve su cui intervenire dopo un incidente, non un memo che ricorda “attenzione alle email sospette”.
Per un CISO, questo si traduce in una scelta concreta sul modo di condurre l’indagine.
La prima è nel formato del campo “causa” del registro degli incidenti: se ammette la voce “errore umano”, quella voce continuerà a chiudere i casi. Sostituirla con una domanda obbligata (quale controllo assente o quale permesso in eccesso ha reso possibile l’azione) impedisce all’indagine di fermarsi sulla persona.
La seconda riguarda la lettura degli incidenti nel tempo: un errore che si ripete in ruoli diversi con la stessa frequenza non è un caso individuale, ma un segnale di progettazione, e va portato al team che possiede il processo, non al manager del singolo.
La terza è nel linguaggio verso il top management. Un incidente descritto come “disattenzione di un dipendente” non comporta budget aggiuntivo; lo stesso incidente, descritto come “un pagamento fraudolento non richiedeva una seconda approvazione”, comporta una correzione da assimilare e un costo finanziario da sostenere.
Quindi, dobbiamo considerare che il modo in cui definiamo la causa può determinare se l’organizzazione riceverà le risorse necessarie per correggerla.
Una proposta metodologica
Il cybercognitivismo spiega perché una decisione umana, sotto pressione o in un flusso di lavoro mal progettato, diventa il punto debole che un attaccante sfrutta. Ma spiegare il meccanismo non basta a governarlo: serve la parte tecnica e organizzativa che trasforma quella comprensione in controlli, policy e priorità di investimento verificabili.
Va detto con precisione: il cybercognitivismo è una proposta metodologica, basata su fonti consolidate sulla decisione sotto pressione. Serve a formulare la domanda corretta dopo un incidente, non a fornire una risposta certificata. Ma la domanda è molto semplice: se la stessa causa venisse scritta come proprietà del Sistema anziché come colpa di chi ha agito, quale correzione diventerebbe obbligatoria?
Un’indagine che si ferma all’errore umano non ha trovato la causa: ha solo smesso di cercarla.
È qui che si colloca il Manuale CISO Security Manager (per la preparazione all’esame CISSP e la pratica quotidiana)[1], pensato per chi deve tradurre l’analisi degli incidenti in un’architettura dei permessi, con competenze CISSP e di governance, capace di reggere la prossima Root Cause Analysis senza fermarsi al primo alibi. Spoiler: le placche invitano a spingere le porte e le maniglie a tirarle.
Partecipa alla community