Sull’interfaccia della piattaforma di orchestrazione campeggia un contrassegno verde brillante: Incident #8492 – Auto-Remediated. Il playbook automatizzato ha isolato l’endpoint compromesso, revocato i token di sessione e archiviato la segnalazione in poco più di quattro secondi.
Eppure, l’analista senior apre la console a riga di comando, lancia una query manuale sui log e poi accede al pannello dell’EDR per verificare personalmente che il processo sospetto sia stato terminato per davvero, che non si sa mai. E impiega venti minuti per ripercorrere a mano la sequenza che il software ha già completato a velocità di calcolo.
Non si tratta certamente di una forma di ostilità luddista verso il progresso tecnologico né di un rifiuto ideologico delle nuove architetture, bensì è la conseguenza prevedibile dell’aversione all’algoritmo, che spinge l’essere umano a rigettare la decisione automatica non appena percepisce un margine di incertezza, anche minimo.
Indice degli argomenti
La frattura della fiducia verso la macchina
Il fenomeno dell’aversione all’algoritmo (algorithm aversion), formalizzato dagli studi di Berkeley Dietvorst, Joseph Simmons e Cade Massey (2015), dimostra come gli individui tendano a perdere fiducia nei sistemi automatizzati in modo del tutto sproporzionato rispetto a quanto facciano nei confronti dei colleghi umani.
Di fronte a un errore commesso da una persona, il modello cognitivo mostra una naturale tolleranza, catalogando lo sbaglio come una deviazione occasionale o una svista comprensibile; al contrario, quando l’errore proviene da una procedura automatizzata, il giudizio si fa rigido e binario.
Basta un singolo falso positivo o una rimozione errata osservata nel passato per far crollare l’affidabilità percepita della macchina e spingere gli utenti a preferire la valutazione manuale anche quando le metriche dimostrano che l’algoritmo garantisce prestazioni statisticamente superiori.
Parallelamente, le ricerche di Raja Parasuraman e Victor Riley (1997) sulle interazioni tra uomo e automazione hanno classificato questa condotta sotto la categoria del disuse (il mancato utilizzo o l’aggiramento sistematico delle funzioni automatiche).
Questo comportamento emerge quando l’operatore umano soffre di un deficit di trasparenza sulle logiche interne del software e percepisce una privazione del proprio controllo decisionale.
Nell’ambiente di un SOC, dove la responsabilità finale di un’infezione non rilevata ricade sempre sulla persona fisica e mai sulle righe di codice del playbook, l’analista sviluppa una naturale resistenza.
Il cervello rifiuta la delega cieca a una scatola nera e richiede una conferma visiva diretta per calmare l’ansia e riaffermare la propria padronanza sul sistema.
Un caso per capire la dinamica
Immaginiamo, a titolo esemplificativo, la control room di un primario istituto bancario. Per ridurre il tempo medio di risposta (MTTR) di fronte ad attacchi informatici a propagazione rapida, il CISO ha implementato un SOAR (Security Orchestration, Automation, and Response) in grado di isolare automaticamente le macchine non appena l’agent EDR rileva la presenza di strumenti di estrazione delle credenziali in memoria.
Durante la prima settimana di affiancamento, il sistema automatizzato commette un errore, isolando il computer di un responsabile della tesoreria, a causa di un falso positivo generato da uno script legittimo di manutenzione.
L’incidente causa un blocco temporaneo delle operazioni di rendicontazione per 15 minuti. Il fornitore del software corregge la regola nel giro di poche ore e la piattaforma torna a garantire un tasso di precisione superiore al 99% su decine di migliaia di eventi al giorno. Tuttavia, la memoria di quell’unico errore rimane impressa nell’ambiente di lavoro.
Gli analisti smettono di fidarsi dell’automazione. Per evitare che la macchina fermi nuovamente un dirigente per errore, il team modifica la configurazione, imponendo una conferma manuale intermedia prima di ogni isolamento di rete.
Un gruppo criminale specializzato in intrusioni mirate tramite ransomware lancia una campagna d’attacco guidata. Gli attaccanti inviano deliberatamente un volume di segnali rumorosi ma secondari su vari segmenti della rete, sapendo che gli analisti impiegheranno diversi minuti per verificare manualmente ciascun evento sulla console.
Durante il tempo trascorso dagli operatori a convalidare manualmente i log che il SOAR avrebbe potuto elaborare e chiudere in pochi istanti, l’attaccante esegue il movimento laterale sulla rete principale e completa la cifratura del dominio prima che la prima richiesta di isolamento venga confermata a schermo.
Le implicazioni per il CISO
Per il CISO, questo si traduce nella necessità di riprogettare le architetture di risposta automatica tenendo conto della calibrazione psicologica della fiducia, evitando l’illusione che basti acquistare una licenza software per velocizzare i processi di difesa.
Se la squadra di analisi percepisce l’automazione come una minaccia alla propria autonomia o come un rischio per la propria reputazione aziendale, l’investimento tecnologico produrrà soltanto un duplicato dei tempi di gestione. L’intervento sui processi richiede misure mirate:
- Progressive Automation Tiers: configurare i playbook automatizzati secondo una graduatoria di vincoli crescenti, passando da modelli human-in-the-loop (dove il sistema prepara l’azione e richiede un unico click di conferma) a modelli human-on-the-loop (dove il sistema agisce subito, ma concede una finestra temporale circoscritta per l’annullamento).
- Algorithmic Explainability UI: arricchire le dashboard di gestione con spiegazioni chiare dei motivi che hanno spinto la macchina a prendere una determinata decisione, mostrando la catena logica e le evidenze rilevate anziché un semplice verdetto sintetico.
- Granular Override Controls: permettere agli analisti di regolare la sensibilità delle soglie di intervento automatico in base al contesto aziendale, restituendo loro il senso di padronanza sull’architettura.
In sostituzione del conteggio del numero di regole di automazione attivate sulla piattaforma, il controllo comportamentale deve basarsi sul tasso di duplicazione manuale dei triage. Questo KPI misura la percentuale di segnalazioni gestite e bonificate dall’automazione che vengono riaperte o sottoposte a query manuali di riscontro da parte del personale entro 60 minuti dalla chiusura.
Un valore elevato di questo indicatore indica la presenza di una sfiducia strutturale nei confronti degli strumenti in dotazione.
Una proposta metodologica
Guardando la situazione attraverso la lente del cybercognitivismo, il blocco dell’efficienza non nasce dalla resistenza al cambiamento dei dipendenti, bensì da una progettazione delle interfacce che ignora la necessità umana di controllo e di trasparenza.
L’errore umano non è quasi mai la causa radice dei ritardi nella risposta alle minacce, ma il sintomo di una tecnologia calata dall’alto che costringe l’operatore a scegliere tra la velocità della macchina e la tutela della propria responsabilità.
Il Manuale CISO Security Manager (per la preparazione all’esame CISSP e la pratica quotidiana) affronta la strutturazione dei Security Operations Center integrando i modelli di automazione con le dinamiche di affidamento del personale.
La corretta definizione delle procedure di Incident Response impone che la delega agli algoritmi sia accompagnata da rigorosi protocolli di validazione a campione e da una chiara attribuzione delle responsabilità, liberando l’analista dalla paura dei falsi positivi.
Soltanto quando la tecnologia viene percepita come uno scudo informativo e non come un elemento imprevedibile, il team smette di contrastare la velocità dei playbook.
Dopo aver speso centinaia di migliaia di euro in piattaforme di intelligenza artificiale, se ti accorgi che il tuo analista migliore sta ancora controllando a mano gli indirizzi IP su un blocco note, non sgridarlo. Sta soltanto cercando di capire se la macchina ha lavorato per lui, o se gli sta preparando la lettera di licenziamento.
Partecipa alla community