Come dimostrare al comitato che il programma di Cybersecurity awareness protegge

Il comitato chiede sempre la stessa cosa e la chiede allo stesso modo. Questo ci protegge o è un requisito di conformità normativa che firmiamo una volta all’anno? Le quattro puntate precedenti di questa serie hanno seguito una email sospetta dal pulsante fino alla decisione del team di sicurezza. Questa ultima guarda lo stesso mese dalla sala riunioni, perché la segnalazione di una email non finisce quando il caso si chiude. Torna al programma di Cybersecurity awareness e cambia ciò che ogni persona riceve dopo. I numeri vengono da un’organizzazione concreta, la stessa delle puntate precedenti, e non sono medie di settore.

Che cosa dice una email segnalata sulla persona che l’ha segnalata?

C’è un modo di guardare le segnalazioni di email che le lascia sempre dal lato della sicurezza operativa. Qualcuno avvisa, qualcuno controlla, il caso si chiude. Funziona, e spreca metà delle informazioni.

Quando Lucía, dell’area operativa, segnala una email reale che non le è sembrata giusta, sta dimostrando esattamente il comportamento che il programma voleva costruire. Una segnalazione è un segnale di condotta, perché identifica chi riconosce un attacco, con quale criterio e quanto tempo impiega a segnalarlo. Questo dice più sullo stato della cultura di qualsiasi percentuale di partecipazione a un corso, e non dovrebbe morire dentro il caso.

Dentro la piattaforma questo ha due esiti distinti, e conviene non confonderli.

Una email reale segnalata può innescare un Nudge, che è un messaggio che la piattaforma invia a una persona quando accade un determinato evento. Nella segnalazione delle email ci sono cinque eventi che lo innescano.

• Un utente segnala una email che non è una simulazione di phishing.
• Un utente segnala una email di simulazione di phishing.
• Una email reale segnalata viene classificata come phishing.
• Una email reale segnalata viene classificata come falso allarme.
• Una email reale segnalata viene riclassificata a mano.

I primi due accadono nel momento della segnalazione, quindi la risposta esce senza aspettare nessun verdetto. I tre successivi accadono quando il caso si risolve, e sono quelli che permettono di raccontare alla persona qualcosa che quando ha premuto il pulsante non si sapeva ancora.

Da lì arriva la risposta che Lucía percepisce davvero. Il messaggio le arriva per email, su Slack o su Microsoft Teams, e ogni canale ha il proprio oggetto e il proprio testo. È lo stesso meccanismo dei nudge nel momento giusto di cui questo blog ha già parlato, innescato questa volta da una condotta corretta e non da un errore.

Le simulazioni, invece, alimentano il profilo della persona. Segnalare una simulazione entra nel suo indice di resilienza, che conta quante simulazioni segnala per ognuna in cui cade, e rende quella persona eleggibile per il report dei referenti di awareness, l’elenco nominale di chi sostiene il buon comportamento. Lì la segnalazione pesa a favore, accanto ai segnali che pesano contro.

Come si chiude il circolo tra la simulazione e la segnalazione?

Visto da lontano, il percorso completo ha cinque tratti.

1. Simuli un attacco in un ambiente controllato.
2. La persona impara a riconoscerlo e a segnalarlo, e questo resta nel suo profilo.
3. Con il tempo segnala anche le email reali, che è il salto che conta davvero.
4. Quelle segnalazioni vengono classificate senza intervento e restituiscono un verdetto invece di un compito.
5. La risposta torna alla persona sul momento, e l’attività del mese resta visibile nella console delle segnalazioni.

Il tratto che mancava per anni era il quarto, e senza di esso il terzo si spegne da solo. La seconda puntata di questa serie ha spiegato perché. Un canale che non risponde insegna all’organizzazione che segnalare è una formalità.

Quali tre metriche delle segnalazioni di phishing guardano i responsabili del programma?

Nessuna delle tre è il totale delle email elaborate.

Quante simulazioni vengono segnalate. Il tasso di segnalazione misura quale percentuale delle simulazioni ricevute è stata segnalata, e la piattaforma lo colloca inoltre rispetto a un benchmark di settore perché il numero non resti sospeso. Nell’organizzazione di questa serie è stato del 62%. Risponde alla domanda che viene prima di tutte le altre. Le tue persone riconoscono un attacco e lo segnalano?

Accanto a quel tasso c’è un dato che quasi nessuno guarda e che vale altrettanto. La finestra di esposizione di ogni campagna sovrappone il tempo tipico che una persona impiega a cadere con il tempo tipico che impiega a segnalare. Quando la curva della segnalazione va avanti a quella della caduta, la tua organizzazione avvisa prima di sbagliare.

Che cosa ha risolto l’analisi automatica questo mese. La dashboard separa le email che la classificazione automatica ha marcato come phishing da quelle che ha scartato come falsi allarmi. Nel mese di questa storia sono stati 23 attacchi reali e 160 falsi allarmi su 183 segnalazioni. C’è una precisazione per leggere bene quel numero, ed è che conta solo ciò che l’analisi ha risolto da sé all’interno del mese in corso, quindi una email che poi qualcuno ha riclassificato a mano esce da quel conteggio.

L’elenco delle email segnalate mostra chi ha segnalato ciascuna, quindi separare chi avvisa con criterio da chi segnala tutto ciò che gli sembra strano è una lettura che si fa lì e non un indicatore che la dashboard calcola. Sono due conversazioni distinte e sono utili entrambe, anche se nessuna si risolve guardando una media.

Quel 23 su 183 si legge facilmente come un problema di precisione degli utenti, e non lo è. Che la maggior parte delle segnalazioni risulti innocua è la conseguenza attesa di avere persone attente, e la prima puntata della serie ha sostenuto che questo è lo scenario sano. Ciò che conta è che quei 23 siano emersi, e che li abbiano trovati le persone.

Quante segnalazioni sono ancora senza decisione. È un cumulato senza taglio per data, quindi una rimasta aperta tre mesi fa conta ancora oggi. Prima del triage automatico quel numero era 47, e alcune aspettavano da tre giorni. È il debito reale del programma e l’unico dei tre che dovrebbe tendere a zero.

Che cosa si risponde al comitato quando chiede se il programma protegge?

Due numeri, e nessuno dei due è di attività.

Il primo, 23 email di phishing reale rilevate dai dipendenti in un mese, e non dall’email security né dal firewall. Le hanno trovate persone che hanno visto qualcosa di strano e hanno premuto un pulsante.

Il secondo, quattro minuti tra la segnalazione e la classificazione dell’incidente, invece dei tre giorni che impiegava la coda. Quello è il tempo durante il quale un attacco resta vivo nelle caselle di posta di tutti gli altri.

Entrambi rispondono alla domanda che il comitato fa davvero, che non è quante persone hanno completato il corso. E arrivano con un vantaggio sul report trimestrale, perché sono disponibili il giorno in cui qualcuno li chiede. Se il problema di fondo è che il report arriva tardi alla riunione, quello si risolve a parte.

Che cosa conviene guardare tra sei mesi?

Due cose, e sono entrambe tendenze.

La prima è se l’abitudine cresce. Mese dopo mese, più persone segnalano, e segnalano anche fuori dalle simulazioni. L’attività mensile degli ultimi sei mesi è nella dashboard proprio per questo, perché un mese isolato non dice nulla e sei di fila sì.

La seconda è il debito, che si misura in quante segnalazioni sono ancora in attesa di una decisione. Se quel numero scende mentre il primo sale, il programma è migliorato nei due modi che contano allo stesso tempo, e nessuno dei due è costato ore in più.

Quell’incrocio è anche la risposta a un’obiezione ragionevole che compare in qualsiasi comitato. Un programma di Cybersecurity awareness che mostra solo più attività può generare più lavoro interno senza ridurre alcun rischio. Quando l’attività sale e la coda no, l’organizzazione è passata a elaborare più minacce con lo stesso team, che è un’affermazione diversa e parecchio più difficile da contestare.

Una casella vuota è un buon segnale?

Dipende da perché è vuota, e le due spiegazioni possibili sono opposte. Può essere che la tua organizzazione sia tranquilla. Può essere che abbia smesso di avvisare.

Quello che bisogna cercare è il contrario di una casella vuota. Persone che segnalano senza esitare, segnalazioni che si risolvono senza fare la coda e un team di sicurezza che dedica il suo tempo alle email che lo meritano.

Il pulsante di segnalazione è uno strato di difesa umano con l’analisi automatica dietro.

E quando quello strato deve parlare con il resto dell’organizzazione, lo stesso evento può uscire dalla piattaforma. Un Playbook chiama un sistema proprio tramite webhook, oppure avvisa per email, Slack o Microsoft Teams chi deve saperlo, dal responsabile dell’area al turno del SOC.

Così funziona Smart Triage all’interno della console delle segnalazioni di SMARTFENSE, sulle email che le tue persone segnalano con il pulsante. Se vuoi vedere questi tre numeri con i dati della tua organizzazione, la strada più breve è una demo della piattaforma.