Rischio interno: ridurre le opportunità e migliorare la risposta

Il rischio interno comprende l'uso improprio intenzionale, gli errori e le attività svolte tramite un account legittimo compromesso. Possono essere coinvolti dipendenti, collaboratori esterni, fornitori ed ex dipendenti con accessi residui. Il punto di partenza utile non è un elenco di persone ritenute a rischio, ma gli accessi e le azioni che potrebbero causare danni.

Per un CTO, il compito è ridurre le opportunità di uso improprio preservando il lavoro legittimo, e poi rendere indagabili le attività sospette. Ciò richiede controlli sulle identità, regole di gestione dei dati, telemetria utile e un processo di risposta che distingua un incidente accidentale da una compromissione dell'account o da un'azione intenzionale. Le possibili conseguenze comprendono frodi, perdita di proprietà intellettuale, esposizione di dati personali e interruzioni operative. Nessuna di esse richiede che un attaccante sfrutti una vulnerabilità software, se le autorizzazioni esistenti consentono già l'azione.

Individuare i percorsi ad alto impatto

Partite da un processo aziendale importante e mappate come qualcuno potrebbe causare un danno rilevante utilizzando un accesso legittimo. Includete applicazioni, interfacce amministrative, API, endpoint e fornitori esterni. Un esercizio di threat modeling incentrato sugli accessi può aiutare a individuare percorsi che attraversano più sistemi.

Chiedetevi che cosa una persona può leggere, modificare, esportare, eliminare o approvare, non semplicemente se dispone di un account.

Per ogni percorso, registrate il responsabile dell'asset, i ruoli autorizzati, lo scopo previsto, il controllo preventivo, la fonte di rilevamento e chi deve rispondere. Assegnate le priorità in base all'impatto potenziale, alla facilità di esecuzione e alla capacità di ripristino. Un'azione sensibile che una sola persona può compiere senza controlli indipendenti merita particolare attenzione.

Il risultato è un breve registro dei percorsi di accesso. Dovrebbe indicare con precisione quale azione richiede separazione dei compiti, un'approvazione aggiuntiva o un monitoraggio più attento.

Rimuovere i poteri non necessari prima di aggiungere sorveglianza

Privilegio minimo significa far corrispondere le autorizzazioni al lavoro attuale. Partite dai diritti effettivi, compresi gruppi annidati, ruoli specifici delle applicazioni, accessi delegati, account di servizio, token API e credenziali condivise. Un elenco ordinato dei ruoli nella directory può nascondere autorizzazioni eccessive all'interno delle singole applicazioni.

Fate convalidare ai responsabili di business il motivo per cui ogni diritto sensibile è necessario. Ove possibile, separate gli account di uso quotidiano dalle identità amministrative e sostituite gli accessi amministrativi permanenti con un'elevazione approvata e a tempo. Utilizzate l'autenticazione a più fattori, preferibilmente con metodi resistenti al phishing ove supportati, per ridurre l'esposizione alla compromissione delle credenziali. L'autenticazione non impedisce a una persona autorizzata di fare un uso improprio delle proprie autorizzazioni.

La separazione dei compiti deve esistere nel sistema, non soltanto nella politica. Chi modifica le coordinate di pagamento di un fornitore non dovrebbe anche approvare il pagamento che ne deriva. Le forzature di emergenza richiedono un motivo registrato, una scadenza definita e un riesame a posteriori da parte di una persona indipendente dall'azione.

Integrate le modifiche degli accessi nei flussi di lavoro relativi al personale e ai fornitori:

• Ingresso: assegnate un ruolo definito invece di copiare le autorizzazioni accumulate da un collega.
• Cambio di ruolo: rimuovete gli accessi obsoleti oltre ad aggiungere le nuove responsabilità.
• Uscita: coordinate disattivazione dell'account, chiusura delle sessioni, revoca dei token, gestione dei dispositivi e rimozione degli accessi dei fornitori.
• Lavoro temporaneo: assegnate un responsabile e una scadenza agli accessi elevati o specifici di un progetto.

Riesaminate separatamente gli account di servizio. Documentatene scopo, dipendenze, conservazione delle credenziali e responsabile. Evitate l'uso interattivo quando non è necessario. Se una credenziale condivisa non può ancora essere eliminata, registrate l'eccezione e i controlli compensativi; non date per scontato che i log identificheranno in modo affidabile il singolo utente.

Proteggere i dati e le vie di uscita

La protezione dei dati inizia dal sapere quali informazioni contano e dove si spostano. Classificate gli insiemi di dati sensibili, individuate le destinazioni approvate e definite quando esportazioni o condivisioni esterne sono legittime. Offrite agli utenti un percorso approvato praticabile, altrimenti i controlli possono spingere le attività verso canali non gestiti.

La prevenzione della perdita di dati può avvisare, bloccare o richiedere una giustificazione per determinati trasferimenti. Sperimentate le policy su flussi di lavoro rappresentativi prima di applicarle su larga scala. Verificate, ove pertinente rispetto al rischio, link di condivisione cloud, caricamenti dal browser, client di sincronizzazione, supporti rimovibili e stampa. La copertura varia a seconda della piattaforma e del canale; un test riuscito su un endpoint non dimostra la protezione dell'API di un'applicazione.

La cifratura a riposo e in transito protegge determinati percorsi di esposizione, ma un utente autorizzato può comunque accedere ai dati in chiaro. Combinate la cifratura con limiti di accesso, restrizioni sulle esportazioni e condivisione controllata. Proteggete anche i backup e l'amministrazione del ripristino: un uso improprio distruttivo diventa più difficile da recuperare quando la stessa identità può modificare la produzione e cancellarne i backup.

Rendere il rilevamento proporzionato e spiegabile

Raccogliete segnali legati ai percorsi ad alto impatto, invece di tutto ciò che una persona fa. Tra gli eventi utili possono figurare esportazioni insolitamente grandi, nuove condivisioni esterne, modifiche ai privilegi, logging disattivato, ripetuti accessi negati o accessi a repository sensibili al di fuori dei normali schemi di lavoro.

Utilizzate i log di audit delle applicazioni insieme agli eventi di identità, endpoint e cloud. Un sistema SIEM (security information and event management) può correlare queste fonti; l'analisi comportamentale di utenti ed entità (UEBA) può aiutare a individuare scostamenti da una baseline. Nessuno dei due stabilisce l'intenzione. Una migrazione, una risposta agli incidenti approvata o un cambio di ruolo possono spiegare un'attività insolita.

Per ogni regola di rilevamento, specificate:

• L'azione rischiosa e i sistemi coperti.
• I campi di log necessari, come attore, data e ora, oggetto, azione, esito e destinazione.
• Le eccezioni legittime previste e il modo in cui chi risponde le verifica.
• Il responsabile della risposta, il percorso di escalation e le condizioni per un contenimento urgente.
• Come il team verificherà la regola e ne misurerà l'utilità.

Proteggete i log da alterazioni non autorizzate, sincronizzate gli orari e verificate che i problemi di acquisizione siano visibili. Testate gli alert con attività approvate in un ambiente sicuro. Trattate la telemetria mancante e i falsi positivi come difetti tecnici, non soltanto come carico di lavoro per gli analisti.

Stabilire prima le garanzie per il monitoraggio

Prima di raccogliere dati sulle attività dei dipendenti, determinate la base giuridica, la finalità, le garanzie per la privacy, i controlli di accesso e la conservazione. Coinvolgete gli specialisti privacy, legali, di risorse umane e le rappresentanze dei lavoratori appropriati; gli obblighi di consultazione dipendono dalla giurisdizione e dal contesto.

Dove si applica il GDPR, i suoi articoli 5, 6, 13-14 e 32 riguardano principi, liceità del trattamento, trasparenza e sicurezza. L'articolo 35 richiede una valutazione d'impatto sulla protezione dei dati quando un trattamento può presentare un rischio elevato. Gli obiettivi di sicurezza non eliminano questi requisiti.

Come raccomandazione pratica, preferite metadati sugli eventi dall'ambito ristretto a una raccolta invasiva dei contenuti, quando ciò basta a rispondere alla domanda dell'indagine. Limitate l'accesso ai fascicoli, documentate le decisioni sulla conservazione e non considerate circostanze personali o disaccordi sul lavoro come prove di comportamenti scorretti. I punteggi automatici richiedono una validazione umana.

Aiutare le persone a segnalare tempestivamente gli errori

Offrite un canale di segnalazione evidente per condivisioni accidentali, dispositivi smarriti, richieste sospette e attività inattese sugli account. Spiegate che cosa segnalare: il sistema, l'orario approssimativo, le informazioni coinvolte, i destinatari e le azioni già intraprese. Il personale non dovrebbe dover classificare l'incidente prima di chiedere aiuto.

Rendete la formazione specifica per il lavoro svolto. I team finanziari hanno bisogno di scenari di verifica delle modifiche ai pagamenti; gli sviluppatori di esempi su repository e gestione dei segreti; il personale di assistenza di indicazioni su esportazioni di dati dei clienti e tentativi di impersonificazione. Includete collaboratori esterni e amministratori privilegiati.

Rispondete in modo costruttivo alle segnalazioni tempestive. Dite a chi segnala se smettere di usare un dispositivo, conservare un messaggio o evitare di contattare un destinatario finché il team di risposta non fornisce indicazioni. Istruzioni chiare evitano che interventi di pulizia in buona fede distruggano evidenze o amplino l'esposizione.

Rispondere ai fatti, non alle etichette

Un alert è uno spunto di indagine, non una prova di comportamento scorretto. Ricostruite il contesto e tutelate la riservatezza di tutte le persone coinvolte. Un'azione apparentemente valida da parte di un account potrebbe derivare da un errore, da un'automazione, da una sessione rubata o da un uso improprio intenzionale; le esigenze di contenimento possono sovrapporsi, mentre le implicazioni sul piano del rapporto di lavoro sono diverse.

Un playbook di risposta utilizzabile dovrebbe coprire cinque decisioni:

1. Triage: confermate l'evento, gli asset interessati, la sensibilità, l'autorizzazione e se il danno è ancora in corso. Verificate le modifiche approvate e contattate il responsabile del processo tramite un canale affidabile.
2. Conservazione: conservate, ove opportuno, log pertinenti, eventi di identità, registrazioni di condivisione e file originali. Registrate ora di raccolta, fonte, investigatore e modalità di gestione. Limitate l'accesso al materiale del fascicolo.
3. Contenimento: scegliete misure proporzionate, come revocare sessioni, limitare le esportazioni, disattivare le condivisioni o rimuovere privilegi elevati. Considerate le dipendenze dei servizi prima di disattivare un account, senza ritardare una protezione urgente.
4. Coordinamento: coinvolgete, in base ai fatti, sicurezza, responsabile del sistema, privacy, ufficio legale e risorse umane. I provvedimenti disciplinari e le segnalazioni alle forze dell'ordine richiedono un'autorità adeguata, non una soglia di alert automatica.
5. Ripristino: ripristinate accessi e configurazioni approvati, cambiate le credenziali interessate, verificate l'integrità dei dati e monitorate eventuali recidive.

Definite chi può autorizzare un contenimento urgente e un contatto alternativo nel caso in cui sia coinvolto un amministratore privilegiato o la persona che decide abitualmente.

Valutate separatamente gli obblighi di notifica. Ai sensi degli articoli 33 e 34 del GDPR, i titolari valutano la notifica all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne sono venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. I responsabili del trattamento informano i titolari senza ingiustificato ritardo. Un rischio elevato può richiedere la comunicazione agli interessati, fatte salve le eccezioni dell'articolo 34. Registrate le motivazioni di un'eventuale mancata notifica e verificate gli altri obblighi contrattuali o di legge applicabili.

Esempio pratico: un'esportazione insolita di dati dei clienti

Ipotesi illustrative: un'applicazione di assistenza contiene i recapiti dei clienti; i supervisori possono esportare un numero limitato di record per casi approvati; un'identità di integrazione separata esegue la reportistica programmata.

Un alert segnala che un supervisore ha esportato molti più record rispetto al suo normale carico di lavoro. L'analista verifica ambito e destinazione dell'esportazione, eventi di identità e riferimento al caso approvato. Un nuovo contesto di accesso aumenta la preoccupazione, ma non stabilisce chi abbia agito.

Il team di risposta conserva i log dell'applicazione e delle identità, revoca la sessione sospetta e rimuove temporaneamente l'autorizzazione all'esportazione dell'utente. Verifica che l'integrazione programmata non sia interessata prima di modificare accessi più ampi. Tramite un contatto affidabile, il supervisore conferma di non aver richiesto l'esportazione.

L'ipotesi di lavoro diventa la compromissione dell'account. Gli investigatori esaminano l'esposizione di credenziali e sessioni, individuano ove possibile destinatari o destinazioni e valutano gli obblighi di notifica della violazione. Il ripristino comprende la messa in sicurezza dell'account e la verifica delle autorizzazioni.

Il riesame dei controlli rileva che il normale lavoro di assistenza non richiedeva ampi diritti di esportazione. L'azione correttiva consiste in un ruolo più ristretto, un'approvazione per le esportazioni più grandi e un alert testato. Le evidenze comprendono registrazioni della configurazione, un test controllato e l'approvazione del revisore, non l'affermazione che ogni futura esportazione sarà impedita.

Conservare evidenze che dimostrino il funzionamento dei controlli

Dopo un caso o un'esercitazione, registrate fatti, risposta, impatto e miglioramenti. Esaminate se vi abbiano contribuito autorizzazioni eccessive, approvazioni mancanti, istruzioni poco chiare o telemetria incompleta. Assegnate a ogni azione correttiva un responsabile, una scadenza e un metodo di verifica.

Tra le evidenze di assurance utili figurano revisioni dei diritti con registrazioni delle rimozioni, cronologie delle elevazioni dei privilegi, test di offboarding, test delle regole di rilevamento, verifiche della copertura dei log ed esercitazioni che dimostrano il percorso di escalation. Misurate i risultati dei controlli, come accessi scaduti effettivamente rimossi e alert con contesto sufficiente, invece di contare soltanto i corsi di formazione completati.

Secani collega rischi, attuazione dei controlli ed evidenze in un contesto governato. Per un percorso di accesso, i team possono modellare i sistemi pertinenti, allegare esportazioni delle revisioni e registrazioni dei test, assegnare attività di risoluzione delle lacune e conservare le decisioni di revisione umana. La documentazione su autorizzazioni e accesso alle API descrive il ruolo dell'API OSCAL limitato alla sola validazione, un esempio concreto di come assegnare alle credenziali una capacità circoscritta al compito previsto. Riportate in questa registrazione collegata dei controlli le esportazioni delle revisioni degli accessi, i rilievi del monitoraggio e le decisioni di risposta approvate.

Iniziate verificando un percorso di accesso ad alto impatto e il percorso di escalation in caso di uso improprio. Confermate che i poteri non necessari siano stati rimossi, che un evento significativo sia visibile e che una persona autorizzata possa intervenire con evidenze e contesto sufficienti.