La sicurezza informatica non è un reparto: è una condizione di funzionamento. Nessun firewall, nessun EDR e nessuna campagna di phishing awareness riparano un processo che nessuno ha mai documentato, perché il rischio non si misura dove non si sa cosa succede. È il motivo per cui la frase più efficace che esista in sicurezza IT resta una frase scomoda: non possiamo proteggere ciò che non sappiamo di avere.
Il sintomo: il ticket che si chiude e il rischio che resta
Il caso tipico è riconoscibile. Un utente segnala un sospetto, il ticket viene preso in carico, l'utente viene istruito, il caso viene chiuso. Dal punto di vista del SOC è risolto. Ma nessuno ha chiesto quale dato era in gioco, e quindi nessuno ha potuto stabilire se il caso era un falso positivo o l'inizio di una perdita dati che nessuno ha ancora notato.
Il processo si è chiuso, il rischio no. Questa è la differenza operativa che separano un presidio vero da un risparmio apparente: il primo misura, il secondo archivia.
Le quattro domande che solo il business può rispondere
La collaborazione non serve a fare più riunioni. Serve a ottenere quattro informazioni che non esistono da nessuna parte se non dentro l'organizzazione:
Qual è il dato che, se perso, farebbe davvero danno? Non "dato sensibile" in astratto: il fatturato di un cliente specifico, la continuità di un servizio in una data finestra, la responsabilità legale su un documento.
Quanto tempo possiamo stare fermi? Un'azienda manifatturiera con fermo di linea da 40.000 euro l'ora e uno studio professionale hanno esigenze opposte sulla stessa identica vulnerabilità.
Chi ha accesso a cosa, davvero? Non cosa dice la matrice degli accessi: cosa fanno le persone. La matrice è un documento, il processo è un'abitudine.
- Quale processo regge, e quale regge solo perché nessuno l'ha ancora toccato?
Chiunque lavori in sicurezza informatica sa che la quarta è quella che fa danni. È la ragione per cui l'exploit più efficace non è quasi mai tecnico, ma sociale: passa da un processo che "così funziona da sempre" e da un utente che ha fatto bene a fidarsi.
Non è una novità: la separazione dei compiti è un principio del 1790
Vale la pena ricordare da dove viene l'idea. Il concetto di separation of duties nasce con la Rivoluzione Industriale e le prime contabilità a partita doppia, dove nessuno poteva essere contemporaneamente autore e verificatore delle proprie scritture. Il principio è che nessun singolo atto deve poter passare inosservato.
Nella sicurezza informatica la stessa logica ha una tradizione più recente ma ben consolidata: dai primi lavori sugli honeypot di fine anni '80 — che hanno raccontato in Dalle mappe false ai bucket — emergono due conclusioni operative. La prima è che il rilevamento non è un accessorio, è il prodotto. La seconda è che nessun controllo funziona se chi dovrebbe applicarlo non sa cosa sta facendo.
Tradotto: un reparto sicurezza che ha tutto il potere decisionale e nessuna responsabilità operativa produce procedure perfette e ignorate. Un reparto che non ha potere ma conosce i processi produce miglioramenti reali. Il primo scenario è più comodo da vendere.
Il costo nascosto dell'isolamento
L'IT che parla solo con l'IT produce un rischio molto specifico e sottovalutato: ottimizza il proprio lavoro invece di ridurre il rischio dell'organizzazione.
Un team che misura il proprio successo sul numero di ticket chiusi, su uptime, su patch applicate in tempo, è incentivato a chiudere il ticket. Un team che misura il suo successo sulla riduzione del rischio è incentivato a fare le domande scomode: perché quell'accesso serve, chi l'ha creato, e cosa succede se lo revochiamo. Sono due comportamenti incompatibili, ed entrambi sono razionali rispetto alla metrica che si sceglie.
Lo stesso vale per la formazione. Una campagna di phishing awareness "con percentuale di clicchi in calo" può essere vinta facendo la formazione più sgradevole del mondo. Una campagna utile si riconosce da un altro effetto: le segnalazioni di sospetto aumentano, perché le persone hanno imparato che segnalare è utile e non sanzionato. Un calo dei clicchi con un aumento delle segnalazioni è un successo. Un calo di entrambi, molto spesso, significa solo che nessuno guarda più.
Come si fa, senza che diventi un letterone annuale
La collaborazione che funziona ha tre caratteristiche: è piccola, è frequente e produce artefatti. Proposte concrete:
Un referente per area. Non un committee: una persona sola per reparto, che conosce i processi e risponde delle domande. Costa poche ore al mese.
Un registro dei processi critici. Solo quelli che reggono il business. Dieci righe per processo, scritte da chi lo fa, non da chi immagina di farlo.
Il riesame senza sorpresa. Trimestrale, in calendario, con la stessa regolarità con cui si fa il budget. Se salta due volte di fila, il registro delle decisioni lo dice e va rivisto.
Le decisioni si scrivono. Il verbale vale quanto la riunione: senza registro, la collaborazione è un'abitudine personale che sparisce con chi l'ha promossa.
Il test per capire se funziona
La domanda più utile che un responsabile della sicurezza può fare all'organizzazione non riguarda i controlli, ma le persone:
Se domani il vostro responsabile IT, il vostro reparto incassa in che modo la sicurezza informatica? E lui/lei lo sa?
Se la risposta è vaga, il problema non è tecnico. Se la risposta è «non lo so, ma immagino che dipenda da...», il perimetro di difesa è una lista di intenzioni, e le intenzioni non tengono.
In sintesi
I controlli tecnici sono necessari e non bastano mai: coprono i vettori noti, e gli attaccanti non leggono le tue liste. Il controllo che chiude il cerchio è organizzativo: sapere cosa si protegge, sapere quanto costa fermarsi, sapere chi fa cosa. Quel controllo non si compra e non si installa, si costruisce con le persone, una conversazione alla volta.
È anche l'unica attività di sicurezza che migliora quando il budget sale. Tutte le altre migliorano quando il budget raddoppia.