Progettare prodotti di sicurezza che le persone riescono davvero a usare

Progetto prodotti digitali da circa venticinque anni, e parecchi nella cybersecurity: tre anni come Design Lead in Exein, sulla sicurezza embedded, e oggi come co-founder e CTO di Shorium.

La lezione che continuo a reimparare è semplice. Un prodotto di sicurezza vale quanto le decisioni che le persone riescono a prendere con esso.

Rilevamento, analisi e crittografia possono essere eccellenti. Se la persona davanti allo schermo non capisce cosa conta, perché, e cosa fare dopo, il prodotto fallisce proprio quando serve.

I due modi in cui falliscono le interfacce di sicurezza

Mostrano tutto. Ogni allarme, ogni risultato, ogni riga di log, tutti con lo stesso peso visivo. L’interfaccia è tecnicamente completa e praticamente inutilizzabile. Le persone imparano a ignorarla, il che è peggio di non avere niente.

Nascondono tutto. Un solo punteggio, un bollino verde, un semaforo. Sembra semplice e rassicurante. Ma quando qualcuno chiede «perché è rosso?» o «siamo sicuri che sia verde?», l’interfaccia non ha risposta.

Entrambi nascono dallo stesso errore: trattare la semplicità come eliminazione delle informazioni, invece che come loro organizzazione.

I principi che uso

1. Partire dalla decisione, non dai dati. Prima di progettare una schermata, scrivi le decisioni che l’utente deve prendere lì. Correggere ora o dopo? Escalare o chiudere? Quale prodotto è coinvolto? Ogni elemento della schermata deve aiutare una di quelle decisioni.

2. Dare un significato alla gravità. La gravità deve combinare quanto è grave un problema con quanto è esposto quel sistema specifico. Una vulnerabilità critica in un componente non raggiungibile non equivale a una media su un’interfaccia esposta. Mostra perché qualcosa è in quella posizione.

3. Mostrare sempre la provenienza. Da dove viene questo risultato? Quale scansione, quale regola, quali dati, quando? Nella sicurezza la fiducia nello strumento dipende dalla possibilità di verificarlo.

4. Mostrare le conseguenze prima delle azioni. Se un utente sta per revocare un certificato, ruotare una chiave o distribuire un aggiornamento, mostra prima cosa ne dipende. Gli errori più costosi nella sicurezza sono cambiamenti fatti in buona fede con effetti collaterali invisibili.

5. Progettare per l’incidente, non per la demo. Le demo si fanno nei giorni tranquilli con dati puliti. L’uso reale avviene alle 2 di notte, sotto pressione, con informazioni parziali. Prova l’interfaccia in quelle condizioni: utenti stanchi, dati incompleti, molti allarmi insieme.

6. Tenere traccia di cosa è stato deciso. Il lavoro di sicurezza viene sottoposto ad audit, e norme come il Cyber Resilience Act chiedono prove. L’interfaccia deve rendere facile registrare chi ha deciso cosa, in base a quali informazioni.

7. Renderla accessibile. I team di sicurezza includono persone con capacità diverse, che lavorano su dispositivi diversi, spesso sotto stress. Qui l’accessibilità non è una cortesia, è resilienza operativa.

La complessità non è il nemico

La sicurezza è complessa perché sono complessi i sistemi che protegge. Il compito del design non è far sparire quella complessità. È renderla percorribile: prima la visione d’insieme, i dettagli su richiesta, e un percorso chiaro da «qualcosa non va» a «ecco cosa facciamo».

Questo principio guida il modo in cui pensiamo il Trust Twin in Shorium. Un modello delle dipendenze crittografiche è utile solo se una persona riesce a ragionarci sopra. Ne ho scritto in Perché sto costruendo Shorium.

Un buon design della sicurezza non fa sentire le persone al sicuro. Le aiuta ad avere ragione.