Comma 22: punito per esserti protetto, di Paolo Zangheri

Approfondimenti

Comma 22

Punito per esserti protetto: quando l’allarme di sicurezza si amplifica fino a colpire chi ha fatto la cosa giusta.

di Paolo Zangheri · 27 agosto 2026 · 7 min di lettura

Ti sei protetto.
Dunque sei sospetto.
Resetta comunque.

Un ricercatore è in trasferta. Si collega da una rete wifi pubblica, e come gli hanno insegnato accende la sua VPN commerciale prima di aprire la posta. È esattamente il comportamento che ogni corso di sicurezza gli ha raccomandato: su una rete non fidata, cifra il traffico e nascondi la tua origine. Fa la cosa giusta.

Dall’altra parte, un SOC che presidia decine di enti osserva i log con regole di analisi preconfezionate. Vede un accesso con password corretta, da un indirizzo IP estero che le fonti pubbliche classificano come «VPN o proxy», con uno User-Agent leggermente diverso dal solito, di sera. La regola, uguale per tutti, si accende: rischio. Nasce una segnalazione. E qui sta il paradosso: il segnale che l’ha fatta scattare è la prudenza.

Non è una storia sulla minaccia, perché la minaccia non c’era. È una storia su cosa succede a un allarme dopo che è nato: su come si amplifica, di mano in mano, finché non si ritorce contro la persona che stava semplicemente proteggendo sé stessa.

L’allarme non è il colpevole

Sgombriamo il campo, per onestà. L’allarme, di per sé, poteva starci. Una password corretta da un luogo insolito è, dai soli log, indistinguibile da un account takeover: potrebbe essere il ricercatore in viaggio, oppure un attaccante con una credenziale rubata. I due scenari producono la stessa riga di log. Anzi: chiedere all’utente «sei stato tu?» è la mossa giusta, ed è persino ciò che, alla fine, viene fatto.

Il problema non è che l’allarme sia scattato. È tutto quello che succede tra lo scatto e quella domanda. Perché nel mezzo l’allarme non resta un’ipotesi da verificare: cresce.

L’amplificazione

Una segnalazione viaggia attraverso le persone, e a ogni passaggio cambia forma. Parte dal SOC come «possibile anomalia da verificare». L’operatore intermedio, che non ha il contesto per ridimensionarla e non vuole essere quello che ha sottovalutato un attacco, la inoltra come «accesso malevolo, correttamente bloccato». Arriva all’utente come un imperativo: «resetti immediatamente la password».

È il gioco del telefono al contrario. Di solito un messaggio, passando di bocca in bocca, si degrada e perde pezzi. Qui succede l’opposto: perde le sfumature ma guadagna certezza e urgenza. «Forse» diventa «sicuramente», «da verificare» diventa «da rimediare subito». Ogni anello della catena, non avendo il contesto per attenuare, sceglie la versione più prudente per sé, che è sempre la più allarmante per l’altro. E intanto partono le reazioni automatiche: blocco degli indirizzi dei servizi VPN commerciali, reset forzato delle credenziali, l’utente trattato come un incidente da contenere.

L’AMPLIFICAZIONE DELL’ALLARME SOC «possibile anomalia da verificare» operatore «accesso malevolo, bloccato» utente «resetti subito la password» A ogni passaggio: meno contesto, più imperativo.
L’amplificazione dell’allarme. La stessa segnalazione si indurisce di mano in mano: da ipotesi da verificare a ordine perentorio. Nessuno lungo la catena ha il contesto per attenuarla, e ognuno passa oltre la versione più prudente per sé.

Il Comma 22

Nel romanzo di Joseph Heller, il Comma 22 è la regola perfetta perché non ha via d’uscita: un pilota può essere esonerato dalle missioni solo se è pazzo, ma deve chiederlo lui, e chiunque chieda di sottrarsi al pericolo dimostra con ciò stesso di essere sano di mente, e quindi deve continuare a volare. La regola che dovrebbe proteggerti si annulla nel momento in cui provi a invocarla.

La nostra è la stessa trappola. Ti proteggi con una VPN, e la protezione diventa la prova a tuo carico. Fai ciò che la sicurezza ti ha insegnato, e proprio per questo finisci nell’elenco dei sospetti. Il sistema punisce il comportamento che esso stesso predica: usa una VPN sul wifi pubblico, ti dicono; poi ti segnalano perché hai usato una VPN sul wifi pubblico. E l’onere della prova si capovolge: non è il sistema a doverti spiegare perché ti accusa, sei tu a dover dimostrare la tua innocenza per aver fatto la cosa giusta.

Non è malizia, è il ruolo

Verrebbe da leggerci una specie di rivalsa contro gli utenti. Ma non serve immaginare cattiveria: basta la struttura.

C’è un’asimmetria di sforzo che toglie ogni freno. Per l’operatore la reazione è un clic: resetta, blocca, chiudi il ticket. Per l’utente sono ore perse, un account congelato, la propria identità messa in discussione. E chi decide non paga mai il costo del proprio falso positivo, quindi non ha alcun incentivo a essere prudente nel senso opposto, quello di non disturbare chi non ha fatto nulla. C’è poi la distanza: nella console l’utente non è una persona, è un oggetto-rischio, una riga con un punteggio. È più facile essere spietati con una riga che con una persona.

È l’immagine resa celebre dall’esperimento carcerario di Stanford: metti persone normali in un ruolo di potere su altre, dietro un’uniforme e una procedura, e la deriva verso l’abuso arriva da sola. Non serve cattiveria individuale: bastano il ruolo, la distanza e il potere di decidere sull’altro senza pagarne il prezzo.

La formulazione più sobria e più utile è quella di Angela Sasse, in un articolo del 1999 dal titolo che è già una tesi: «Users Are Not the Enemy». Quando la sicurezza tratta gli utenti come il nemico da controllare, non li rende più sicuri: li trasforma in avversari, e li spinge esattamente verso i comportamenti che voleva evitare. L’utente trattato come sospetto smette di collaborare, aggira, non segnala. La sfiducia è reciproca, e si autoalimenta.

Detection senza contesto

Sotto tutto questo c’è una radice tecnica precisa: rilevare senza contesto. Le regole preconfezionate di un SIEM o di un motore di identity protection codificano un «normale» generico, buono per un ufficio qualunque: si lavora dalla sede, in orario, con lo stesso dispositivo, dallo stesso Paese. Applicato alla cieca a un ente di ricerca, dove mobilità, VPN, collaborazioni internazionali e orari improbabili sono la normalità, quel «normale» descrive un mondo che non esiste, e ogni deviazione da un modello sbagliato diventa un allarme.

Così un IP classificato come «VPN commerciale» viene letto come «malevolo», quando è solo contesto: la reputazione dice cosa transita da quell’indirizzo, non chi sei tu. È la stessa confusione, vista da un’altra angolazione, tra «abbiamo trovato qualcosa» e «dovete agire». E non è un caso isolato: nei centri operativi i falsi positivi superano regolarmente la metà degli allarmi, in certi casi l’ottanta per cento, gli analisti passano più di un quarto del tempo a smaltirli e una quota enorme di segnalazioni finisce semplicemente ignorata. È il mare in cui galleggia il nostro episodio: un rumore così alto che il segnale, quando è vero, non si sente più.

STESSI SEGNALI, DUE LETTURE password corretta · IP di VPN User-Agent diverso · sera ricercatore in trasferta comportamento virtuoso account takeover credenziale rubata Dai soli log sono identici. A distinguerli è il contesto, non la regola.
Stessi segnali, due letture. La medesima riga di log descrive sia il ricercatore che si protegge sia l’attaccante con una credenziale rubata. A separarli non è la regola, ma il contesto che le si dà intorno.

Come si fa, invece

La cura non è spegnere il monitoraggio, ed è persino ovvia una volta detta. È restituire contesto al controllo.

Significa fare una baseline sul comportamento reale di quell’ambiente, non su un modello generico: se quell’utente viaggia e usa una VPN da mesi, quello è il suo normale. Significa arricchire il segnale prima di giudicarlo, trattando la reputazione di un IP come un indizio e non come una sentenza. Significa mettere un umano nel loop prima della remediation, non dopo: la domanda «sei stato tu?» va fatta all’inizio, non dopo aver bloccato mezza infrastruttura VPN e resettato le credenziali. Significa una risposta proporzionata, lo stesso principio del privilegio minimo applicato non ai permessi ma alle reazioni: la misura più piccola che risolve, non la più grande che rassicura chi la ordina. E significa, in fondo, la scelta di campo di Sasse: progettare la sicurezza con gli utenti e non contro di loro, perché un utente trattato da alleato è la migliore rete di rilevamento che hai, e un utente trattato da sospetto è un sensore che hai appena spento.

Perché capirlo fa la differenza

Un controllo che non capisce l’ambiente che sorveglia non è più sicuro degli altri: è solo più rumoroso e più ostile. E il primo prezzo non lo paga l’attaccante, che quella sera non c’era: lo paga la fiducia. Ogni ricercatore punito per essersi protetto impara due lezioni sbagliate, che la sicurezza è un fastidio da aggirare e che segnalare non conviene, e sono esattamente le due lezioni che, il giorno in cui la minaccia sarà vera, ci faranno arrivare l’allarme troppo tardi.

Il Comma 22 ha una caratteristica crudele: chi ci è dentro non può romperlo. Solo chi tiene la penna, chi scrive le regole e ordina le reazioni, può decidere di spezzarlo. La sicurezza matura non si misura da quanti allarmi genera, ma da quante volte, prima di trattare una persona come una minaccia, si è presa la briga di chiedersi se non stesse semplicemente facendo la cosa giusta.

Fa parte della serie sulle fondamenta invisibili dell’infrastruttura. Leggi anche Il deserto dei falsi positivi e Vieni al lato oscuro.

La tua detection conosce l’ambiente che sorveglia?

Ridurre i falsi positivi, dare contesto agli allarmi e progettare risposte proporzionate che non trattino gli utenti come nemici: è la differenza tra un controllo che protegge e uno che disturba, e si può costruire.