Ho sempre apprezzato la musica jazz. Nasce da un'interazione coordinata di musicisti che intrecciano ritmi e armonie per dare vita a una melodia coesa e coinvolgente. Come spesso accade, questo riflette anche le modalità con cui i team di sicurezza incentrata sulle persone devono operare.
Il mese della sensibilizzazione alle minacce interne è un buon momento per riflettere: i tuoi team della sicurezza operano in modo isolato o si rafforzano a vicenda?
In un ensemble jazz, ogni musicista ha il proprio riff, il proprio momento per emergere. Ma la vera magia nasce quando tutte le parti si fondono in armonia. La sicurezza non è diversa. La sua forza non risiede in un singolo team che cerca di interpretare ogni parte, ma dall’integrazione di prospettive complementari, ognuna delle quali contribuisce con la propria voce. Questo rafforza l’insieme e fornisce l'immagine completa e unica di ciò che si è verificato. Proprio come nessun brano jazz è uguale all'altro, nessun incidente si svolge allo stesso modo. Ecco perché la combinazione di prospettive diverse è così importante.
In una sicurezza unificata e incentrata sulle persone ogni team fa la sua parte. Con passaggi ben comunicati, confini chiari ed esecuzioni parallele, i team si rafforzano a vicenda invece di duplicare gli sforzi o ostacolarsi l'uno con l'altro. La sicurezza si evolve per affrontare dinamicamente i rischi legati alle interazioni umane con i dati e i sistemi, e contribuisce anche ad avvicinare i team.
Ogni team ha un ruolo unico
A causa di questa sovrapposizione, i team di gestione dei rischi interni e della sicurezza dei dati, in particolare quelli che hanno intrapreso da poco il loro percorso di sicurezza o stanno rivedendo il loro programma, mi fanno spesso questa domanda: “Cosa dobbiamo considerare come punti di contatto tra i team e chi è responsabile di quale parte di un incidente quando si verifica una sovrapposizione?”
Quando parliamo di punti di contatto, ci sono molti team che possono, e dovrebbero, essere coinvolti: Risorse umane, Relazioni con il personale, Ufficio legale, Sicurezza aziendale, solo per citarne alcuni. Per rimanere sulla questione, mi concentro sui tre gruppi principali che emergono più spesso nelle conversazioni reali:
- Team della protezione dei dati: Si tratta dei team che rilevano gli incidenti. Il loro ruolo è individuare e contenere gli spostamenti di dati rischiosi, assicurando che tutto sia sotto controllo.
- Team di gestione dei rischi interni: Esaminano i motivi per cui si è verificato un incidente. Oltre agli spostamenti dei dati, esaminano il contesto, il movente e il comportamento. Possono anche coprire aree come la frode, la violenza sul posto di lavoro o addirittura il sabotaggio, che non sono sempre evidenti dai soli allarmi tecnici.
- Operazioni della sicurezza: Sono i team preposti alla valutazione e validazione della gravità dell’incidente, al contenimento delle minacce e al blocco dell'attività dei criminali informatici prima che si diffonda.
Ora che abbiamo definito quali sono i team e i loro ruoli, prendiamo in esame due esempi.
Caso 1: Account di un ingegnere compromesso: il team della protezione dei dati lo rileva per primo
Daniel, un ingegnere di dati cloud, ha attivato un allarme caricando set di dati di produzione su un cloud personale alle 2:00 del mattino.
- Protezione dei dati - Il team ha rilevato immediatamente il rischio. I controlli dinamici hanno bloccato automaticamente il trasferimento, impedendo la fuoriuscita di dati.
- Gestione dei rischi interni - Il team ha esaminato lo storico dei comportamenti e il contesto fornito dalle risorse umane. Non ha trovato alcun segno di movente. Le valutazioni delle prestazioni di Daniel erano eccellenti: il dipartimento delle risorse umane non ha segnalato problemi e i suoi registri di attività non hanno mostrato schemi di comportamento a rischio oltre ai caricamenti anomali.
- SecOps - Il team ha confermato che le sue credenziali erano state violate e venivano sfruttate attivamente.
Risultato unificato - L'account è stato isolato, le credenziali sono state modificate e a Daniel è stato fornito supporto come vittima, invece di essere classificato erroneamente come utente interno malintenzionato.
Caso 2: Analista scontento con accesso a rischio: il punteggio di rischio interno attiva la prevenzione
Sofia, un'analista finanziaria con accesso ai file relativi a fusioni e acquisizioni, era in un gruppo di utenti ad alto rischio a causa del suo ruolo.
- Gestione dei rischi interni - In base alle ricerche di lavoro presso aziende concorrenti, recensioni di prestazioni negative e comunicazioni interne cariche di risentimento, il punteggio di rischio di Sofia ha superato la soglia prestabilita.
- Protezione dei dati - Una volta raggiunta la soglia di rischio, la prevenzione dinamica ha bloccato ripetuti tentativi di stampa e quindi ha eseguito una verifica per confermare che non fossero stati persi altri dati.
- SecOps - Il team ha verificato che le sessioni fossero legittime, escludendo qualsiasi violazione.
Risultato unificato - Grazie all’allineamento di movente, mezzi e preparazione, i team delle Risorse umane e dell’Ufficio legale sono intervenuti utilizzando una narrazione validata. L'accesso di Sofia è stato limitato e l'intervento è avvenuto prima che si verificasse una perdita di dati.
Principali best practice per l'escalation
Di seguito sono riportate le best practice per i percorsi di escalation tra i team di gestione dei rischi interni, protezione dei dati e SecOps.
- Indagini parallele e risultati unificati
Perché è importante - Quando i team di gestione dei rischi interni e SecOps operano in modo isolato, spesso giungono a conclusioni diverse. Il team delle risorse umane o dell’Ufficio legale possono quindi ricevere narrazioni frammentate, persino contraddittorie.
In pratica - Svolgere indagini in parallelo ma attendere fino a quando i singoli risultati non vengono combinati prima di presentarli alle parti interessate dell’azienda. Una narrazione convergente riduce le informazioni irrilevanti, evita rielaborazioni e rafforza la fiducia nel fatto che il comparto della sicurezza sappia gestire la propria narrazione in modo coerente. - Nessun coinvolgimento prematuro
Perché è importante - Contattare un collaboratore troppo presto può essere dannoso, soprattutto se è vittima di una violazione. Un coinvolgimento prematuro non solo mina la fiducia, ma può anche mettere in allerta un utente interno malintenzionato.
In pratica - Il team di gestione dei rischi interni conferma il contesto, il team SecOps convalida l'impatto tecnico e solo allora si richiede alle Risorse umane di interagire con l'utente. Il coinvolgimento deve essere sempre pianificato e coordinato con il team delle Risorse umane e dell’Ufficio legale. - Contesto piuttosto che ripetizione
Perché è importante - Una serie di avvisi DLP ripetuti spesso indica problemi sistemici (formazione, carico di lavoro e progettazione dell'accesso) piuttosto che azioni intenzionali illecite. Trattarli come "violazioni" isolate rischia di sanzionare i sintomi senza individuare la causa principale.
In pratica - Aggrega gli avvisi nel tempo. I modelli potrebbero riflettere fattori sistemici o umani come un esaurimento da sovraccarico di lavoro e scadenze irrealistiche. In questo contesto, gli interventi diventano costruttivi (coaching, formazione o adattamento dei carichi di lavoro) piuttosto che un'escalation punitiva. - Applicazione di limiti RBAC
Perché è importante - Anche i team convergenti possono tendere verso modelli “omnicomprensivi”. Ma i casi ad alta sensibilità (ad esempio, dirigenti, fusioni e acquisizioni e set di dati regolamentati) richiedono controlli rigorosi su quali utenti possono visualizzare quali dati. Questo riduce i pregiudizi, protegge la riservatezza e garantisce la difendibilità in caso di contenziosi.
In pratica - Alcuni analisti potrebbero gestire solo casi di gravità da bassa a media. I casi di gravità elevata dovrebbero essere riservati al personale più esperto del team di gestione dei rischi interni o a gruppi interfunzionali con la supervisione del team delle Risorse umane e dell’Ufficio legale. - Convalida delle prove attraverso la visibilità
Perché è importante - La mancanza di prove non dovrebbe mai essere interpretata come la certezza che nulla sia accaduto o che si sia trattato di un caso, a meno che tutti i team non confermino che sono stati implementati il monitoraggio e i controlli adeguati. Se il monitoraggio non rivela l'azione, allora l'assenza di dati ha poco senso.
In pratica - Sii cauto nel considerare le lacune nei report come conclusioni. Verifica sempre se una lacuna significa assenza di attività o semplicemente assenza di copertura. Ad esempio, se gli upload cifrati non sono visibili agli strumenti di prevenzione della perdita di dati (DLP), allora l'assenza di allarmi non dimostra la sicurezza, ma evidenzia una lacuna di visibilità che deve essere gestita. - Misurazione e adattamento costanti
Perché è importante - I processi di escalation sono efficaci solo se si evolvono con l'azienda. I programmi statici portano a una copertura datata, a un calo di concentrazione causato da un elevato numero di allarmi e a una credibilità ridotta.
In pratica - Monitora quanti allarmi si trasformano in casi reali, quanto velocemente avvengono i passaggi e quali interventi (ad esempio, formazione, azioni disciplinari e licenziamento) ne risultano. Usa questi dati per perfezionare policy, flussi di lavoro e personale.
Conclusione
Come in un’eccezionale esibizione jazz, la resilienza deriva dalla struttura, dall'abilità e dalla libertà di adattarsi al momento. La domanda su cui riflettere è la seguente: i tuoi team operano in armonia, sbloccando il pieno potenziale della sicurezza, o si esercitano ancora da soli?
Per conoscere le best practice per rilevare e prevenire le minacce interne, guarda il nostro webinar sulle minacce interne più devastanti.
