Cosa si rompe nel tuo programma di Cybersecurity awareness quando se ne va chi lo gestiva

C’è una conversazione che si ripete nelle implementazioni e comincia sempre più o meno allo stesso modo. Dall’altra parte c’è qualcuno che ha appena ereditato un programma di Cybersecurity awareness, chiede l’accesso a una piattaforma che non ha configurato e scopre che l’account di amministratore è intestato a una persona che non lavora più nell’organizzazione.

Lo scenario di fondo è noto. Si è dimesso chi teneva in piedi il programma, la ricerca del sostituto richiederà qualche mese e nel frattempo qualcuno deve decidere cosa fare del piano. Nessuno decide di sospenderlo. Semplicemente smette di comparire nella lista di attività di qualcuno.

Il costo si vede più tardi. Quando arriva l’audit e viene richiesta l’attività del periodo, c’è un tratto senza nulla. Quel buco non si spiega con un organigramma, ed è esattamente quello che l’auditor segnalerà.

La continuità del programma di Cybersecurity awareness è la capacità di continuare ad assegnare attività e a produrre registrazioni anche quando nessuno lo sta spingendo. Una posizione scoperta per tre mesi è la prova più onesta che esista per capire se il tuo programma ce l’ha.

Cosa cade davvero quando se ne va la persona che gestiva il programma?

Conviene separare tre livelli, perché si rompono in momenti diversi e si sistemano in modi diversi.

Il primo è l’operatività. Qualcuno costruisce le campagne, controlla chi non ha completato, risponde alla mail della funzione che chiede una proroga. È il livello più visibile e quello che tutti danno per risolto distribuendo il lavoro tra chi resta.

Il secondo è l’intestazione tecnica. L’account di amministratore, il token che usa l’integrazione con la dashboard della direzione, l’applicazione registrata nel provider di identità, l’indirizzo da cui partono le email del programma, i destinatari dei report automatici. Tutto questo è stato legato a una persona in un certo momento dell’implementazione e da allora nessuno l’ha rivisto.

Il terzo è la serie di evidenze. Ogni mese in cui il programma ha assegnato qualcosa lascia una registrazione, e ogni mese in cui non ha assegnato niente ne lascia una anche lui, per assenza. Quella serie è l’unica cosa che un terzo può leggere senza ascoltare la spiegazione.

Distribuire l’operatività nel team, che è la prima cosa che si prova, copre il primo livello. Il secondo non si nota finché qualcosa non si guasta. E quando si guasta, il terzo ha già il suo buco.

Perché distribuire il compito nel team dura due settimane?

La distribuzione informale funziona finché il tema è ancora fresco. Poi inizia a competere con lavoro che invece ha un titolare, e perde sempre.

Un incidente di sicurezza ha qualcuno che lo reclama. Un requisito di audit ha una data. Una campagna di awareness non inviata questo mese non genera nessuna telefonata. Nessuno nel business nota la differenza, la funzione che l’avrebbe ricevuta ringrazia in silenzio e l’indicatore si muove solo due trimestri dopo. È l’unico compito dell’area il cui mancato svolgimento non fa rumore nel breve periodo.

Quello che si perde con la distribuzione non è solo attività. È il criterio. La persona che se n’è andata sapeva perché quel gruppo aveva una campagna diversa, cosa aveva concordato con le operations per non pestare i piedi alla chiusura di mese e perché era in vigore un’eccezione. Chi arriva a coprire la posizione trova un periodo senza attività e, soprattutto, senza le ragioni. Ricostruire quello richiede più tempo che eseguire il piano originale.

Il piano non cade per una decisione. Cade perché ha smesso di stare nella lista di qualcuno.

Quale parte del programma di Cybersecurity awareness può andare avanti senza nessuno dietro?

Quella che era già automatizzata prima della vacanza. Un programma di awareness alla cybersicurezza automatizzato è un insieme di campagne già sequenziate che si assegnano da sole a un pubblico per un periodo che va da uno a tre anni, con configurazioni generali e specifiche che si definiscono una volta sola. Finché c’è un pubblico, continua ad assegnare, con o senza qualcuno che guardi la console.

Qui sta la differenza pratica rispetto a un calendario costruito a mano. Il calendario manuale ha bisogno che ogni mese qualcuno lo esegua. Il programma automatizzato ha bisogno che qualcuno l’abbia deciso una volta. Quando quella decisione è già presa, la vacanza colpisce la supervisione, non la consegna. In SMARTFENSE questo è anche il meccanismo dietro il piano di conformità che si esegue da solo ogni giorno, che risponde alla stessa domanda dal lato della norma.

C’è una dipendenza che invece conviene guardare, e riguarda da dove arriva il pubblico. Un programma che si assegna da solo su una lista che qualcuno aggiornava a mano diventa, in poche settimane, un programma che gira in modo impeccabile sull’organizzazione del trimestre scorso. Chi è entrato durante la vacanza non compare in nessuna assegnazione, e l’indicatore resta verde perché anche il denominatore è rimasto vecchio.

Se l’importazione degli utenti è automatizzata contro la directory aziendale, quel rischio se ne va con la vacanza. Se dipendeva da un file che qualcuno caricava ogni mese, la continuità dura quanto dura quel file. È lo stesso meccanismo per cui i nuovi assunti muovono la conformità durante tutto l’anno, aggravato dal non avere nessuno che lo guardi.

Conviene dire cosa non risolve, perché presentarlo come una risposta completa sarebbe vendere fumo. L’automazione non negozia con una funzione che chiede di spostare un’attività, non interpreta un risultato strano, non decide di cambiare approccio quando il contesto è cambiato e non gestisce l’eccezione della persona che è stata in congedo per sei mesi. Tutto questo torna quando arriva il sostituto. Quello che l’automazione garantisce è che torni su una serie continua e non su un vuoto.

Cosa è rimasto intestato a una persona e non all’organizzazione?

Questo è il livello che quasi nessuno verifica prima di averne bisogno, e quello che come CTO vedo cedere più spesso. Durante un’implementazione le cose si creano in fretta, con l’account che si aveva a portata di mano, e quell’account è di solito quello di chi porta avanti il progetto.

Cosa conviene rivedere, idealmente prima che ci sia una lettera di dimissioni sul tavolo:

• L’account amministrativo e la sua casella. Se l’accesso è associato a un indirizzo nominale che l’ufficio HR disabilita il giorno dell’uscita, il programma perde il suo amministratore lo stesso giorno in cui perde la persona.
• I token delle integrazioni. Un token creato da qualcuno non smette di funzionare quando quella persona se ne va, e questo è il problema. Continua a girare quando non dovrebbe più, finché qualcuno non lo ruota. Vale la pena rivedere con quale credenziale si autorizza ogni integrazione e quale ambito ha, che è la parte che ho sviluppato in cosa smette di essere fatto a mano quando il programma ha un’API.
• L’applicazione registrata nel provider di identità. Il certificato di firma ha una data di scadenza e qualcuno deve tenerla d’occhio. Se quella data vive nel calendario personale di chi ha montato l’integrazione SSO, il giorno in cui scade nessuno potrà entrare e nessuno saprà perché.
• La consegna delle email del programma. L’indirizzo mittente e le regole che il team di posta ha configurato perché i messaggi arrivino sono di solito documentate nel ticket di una persona. Quando quelle regole vengono toccate per un altro motivo, non resta nessuno che spieghi a cosa servivano.
• I destinatari dei report e delle notifiche. Se il report mensile arrivava a una casella personale, smette di arrivare e nessuno reclama, perché chi l’avrebbe reclamato era il suo unico lettore.
• Il contatto tecnico presso il fornitore. Chi riceve gli avvisi di manutenzione e chi può chiedere una modifica deve essere un ruolo dichiarato, non un nome ereditato.

La regola pratica è semplice. Niente del programma dovrebbe dipendere da una casella personale, e ogni integrazione dovrebbe avere un titolare dichiarato che sia una posizione e non una persona. Sui dati, quella intestazione è già risolta per contratto, perché l’organizzazione è il titolare del trattamento e conserva i suoi diritti sulle informazioni anche quando cambia chi le amministra, come abbiamo messo per scritto parlando di conservazione e residenza dei dati. Quello che non è risolto per contratto sono gli accessi, e quelli si rivedono a mano.

Cosa si misura?

Mesi consecutivi con attività assegnata. È l’indicatore che risponde alla domanda vera del trimestre, che non è quanto è migliorato il programma ma se il programma ha continuato a esistere.

Si legge di seguito sul calendario dell’anno. Una serie senza interruzioni dice che l’assegnazione non dipendeva da nessuno in particolare. Un’interruzione di tre mesi che coincide con una posizione scoperta dice il contrario, e lo dice con una precisione scomoda.

Questo indicatore ha bisogno di un accompagnatore per non diventare banale. Insieme ai mesi consecutivi bisogna guardare la percentuale di organico raggiunta in ciascuno di quei mesi. Senza quel secondo numero, la continuità si può sostenere assegnando qualcosa di simbolico a un gruppo ristretto, che tecnicamente riempie la casella e non copre nessuno. È lo stesso vizio per cui una percentuale di conformità segna il 100% mentre metà dell’organizzazione resta senza formazione.

Un’interruzione non è sempre un fallimento, e l’indicatore da solo non fa la differenza. Se a marzo non è stato assegnato nulla perché si era concordato con l’area finance di spostare l’attività fuori dalla chiusura, quella è una decisione e si spiega in una riga. Il problema arriva quando l’interruzione non ha nessuna decisione dietro e chi potrebbe spiegarla non lavora più nell’organizzazione.

Davanti al comitato, la dichiarazione che ci sta è che il piano non è caduto durante la transizione. È una frase modesta ed è esattamente quello che il trimestre aveva da dare.

Cosa trova chi arriva nella posizione?

Il passaggio di consegne vero non è un documento che qualcuno riesce a scrivere nella sua ultima settimana. È lo stato in cui è rimasto il sistema.

La piattaforma registra tre cose distinte e tutte tre contano qui. Le azioni degli utenti finali, con data e argomento di quello che hanno completato. Le azioni degli utenti amministrativi, come la creazione o l’eliminazione di una campagna. E le azioni della piattaforma stessa, come l’invio di email, l’importazione di utenti o l’esportazione di dati. Quelle registrazioni sono dettagliate e inalterabili, con protezione anti-tampering, e alimentano report di audit pronti per essere utilizzati da auditor interni ed esterni.

Per chi arriva, questo cambia il primo mese di lavoro. Invece di ricostruire dalla memoria altrui cosa è stato fatto, può leggere cosa è stato assegnato, quando e a chi, e cosa qualcuno ha cambiato nella configurazione prima di andarsene. E quando arriverà l’audit, ha la risposta alle domande a cui un foglio di calcolo non risponde senza essere stato presente quando i fatti sono accaduti.

La continuità non si risolve il giorno delle dimissioni. Si risolve prima, quando si decide quale parte del programma dipende da una persona e quale parte dipende dall’organizzazione. Se vuoi vedere come si sostiene quella serie nella pratica, la sezione report e audit della piattaforma mostra cosa resta registrato e con quale livello di dettaglio.