Dati aziendali condivisi con l’AI: rischi e cosa fare

Mani su una tastiera illuminate da luci colorate, con simboli di allarme sovrapposti che rappresentano il rischio di esposizione dei dati aziendali.

Dati aziendali condivisi con l’AI: rischi e cosa fare

Non tutti i dati vengono rubati.

A volte siamo noi a condividerli, per uno scopo legittimo, senza sapere che possono diventare un vettore di attacco.

È una situazione che incontriamo sempre più spesso nelle indagini svolte dal nostro SOC. In uno dei casi analizzati, una persona aveva autorizzato una piattaforma di intelligenza artificiale ad accedere ad alcune directory aziendali conservate su OneDrive.

Stava usando l’AI per lavorare: analizzare documenti, automatizzare un’attività, ottenere un risultato in meno tempo.

Tra i file accessibili, però, erano presenti anche dati sensibili e credenziali.

Nessun malware.
Nessuna intrusione.
Nessun attore malevolo.

Il rischio era nelle informazioni condivise e in ciò che avrebbero potuto rendere possibile.

Quando un’attività legittima crea un’esposizione

Utilizzare l’intelligenza artificiale per analizzare documenti o velocizzare un’attività non è, di per sé, un comportamento pericoloso.

Il rischio cambia in base alle informazioni affidate allo strumento, alle autorizzazioni concesse e alle condizioni applicate dalla piattaforma.

Nel caso esaminato dal SOC, non era stato selezionato soltanto un documento. La piattaforma aveva ricevuto l’accesso a directory aziendali nelle quali si trovavano file diversi da quelli necessari per l’attività.

È una distinzione importante.

Quando carichiamo un singolo file, scegliamo un contenuto preciso. Quando colleghiamo un archivio, l’applicazione può ricevere un accesso più ampio di quello che immaginiamo.

L’utente pensa al documento che vuole analizzare. L’autorizzazione, invece, riguarda ciò che la piattaforma può raggiungere.

Perché le credenziali cambiano il rischio

Un documento aziendale non è rilevante soltanto per ciò che racconta.

Un file di configurazione può contenere una chiave API. Un foglio di lavoro può includere password o riferimenti ad account interni. Una cartella di progetto può rivelare nomi di sistemi, indirizzi, fornitori e relazioni di fiducia.

Queste informazioni non hanno tutte lo stesso valore.

Un documento riservato può esporre contenuti che l’organizzazione vuole proteggere. Una credenziale può consentire di raggiungere altri sistemi. Un token può offrire un accesso diretto a un servizio. I dettagli sull’infrastruttura possono aiutare a ricostruire l’ambiente aziendale.

Il problema non è quindi soltanto che un file sia stato condiviso. È ciò che quel file permette di conoscere o di fare.

Nel caso individuato dal SOC, la presenza di credenziali ampliava l’indagine. Non bastava stabilire quali directory fossero accessibili. Occorreva capire a quali account e sistemi fossero collegate quelle credenziali e se fosse necessario sostituirle.

Condividere dati aziendali con l’AI: quali sono i rischi?

Condividere dati aziendali con l’AI non produce automaticamente un data breach. Ogni episodio deve essere valutato in base alla piattaforma utilizzata, al tipo di account, ai permessi concessi e alle informazioni coinvolte.

I rischi possono riguardare:

  • l’accesso a documenti non necessari per l’attività;
  • la conservazione dei contenuti su sistemi esterni;
  • la presenza di credenziali, chiavi o token nei file;
  • la condivisione di dati personali o informazioni sui clienti;
  • l’esposizione di codice, configurazioni e dettagli sull’infrastruttura;
  • autorizzazioni che rimangono attive dopo l’utilizzo;
  • l’impossibilità di ricostruire con precisione quali dati siano stati elaborati.

Non tutti questi elementi saranno presenti nello stesso caso. È compito dell’indagine stabilire che cosa sia accaduto, senza minimizzare il rischio e senza arrivare a conclusioni prima di avere ricostruito i fatti.

Cosa fare se dati aziendali sono stati condivisi con un’AI

Quando emerge un caso simile, la prima esigenza è limitare l’esposizione. Subito dopo occorre comprenderne la portata.

Identificare lo strumento utilizzato

Bisogna stabilire quale piattaforma abbia ricevuto i dati, attraverso quale account e con quale piano.

Servizi e versioni differenti possono applicare condizioni diverse alla conservazione, all’elaborazione e all’utilizzo delle informazioni.

Verificare le autorizzazioni

L’indagine deve ricostruire quali permessi siano stati concessi.

L’accesso poteva riguardare un singolo documento, una cartella o una parte più ampia dell’archivio. È necessario verificare i permessi effettivi, non soltanto ciò che l’utente ricorda di avere selezionato.

Revocare gli accessi non necessari

Se la piattaforma non è approvata o non deve più accedere ai dati, l’autorizzazione va revocata.

La revoca impedisce nuovi accessi, ma non chiarisce quali informazioni siano già state elaborate o conservate. Per questo non sostituisce l’indagine.

Ricostruire le informazioni esposte

Occorre identificare i file raggiungibili durante il periodo in cui l’autorizzazione è rimasta attiva e determinarne il contenuto.

L’attenzione deve concentrarsi su dati personali, informazioni riservate, codice, documentazione tecnica e credenziali.

Sostituire le credenziali coinvolte

Password, token e chiavi presenti nei file devono essere valutati come possibili elementi esposti.

Quando necessario, vanno sostituiti. È inoltre opportuno controllare gli account e i sistemi collegati per individuare accessi o attività che richiedano approfondimenti.

Coinvolgere le funzioni competenti

Se sono presenti dati personali, informazioni soggette a obblighi contrattuali o altri contenuti regolamentati, può essere necessario coinvolgere privacy, compliance e funzione legale.

La valutazione deve basarsi sui dati realmente coinvolti e sulle conseguenze possibili.

Il ruolo del SOC cambia insieme agli strumenti di lavoro

Molte attività di sicurezza cercano comportamenti riconoscibili: malware, accessi anomali, esecuzioni sospette e comunicazioni verso infrastrutture ostili.

La condivisione di dati con una piattaforma AI può non produrre nessuno di questi segnali.

L’utente è autorizzato. Il dispositivo è conosciuto. L’applicazione è legittima. L’attività nasce da un’esigenza di lavoro.

Ogni elemento, osservato da solo, può sembrare normale.

Il rischio emerge quando il SOC li mette in relazione: quali informazioni sono state condivise, quale strumento le ha ricevute, quali permessi possiede e che cosa può diventare accessibile attraverso quei dati.

L’indagine non riguarda più soltanto chi tenta di entrare nell’organizzazione. Riguarda anche le informazioni che escono attraverso attività autorizzate.

Non significa trattare ogni utilizzo dell’AI come una minaccia. Significa riconoscere quando un’attività legittima crea un’esposizione.

Cercare il problema oltre il singolo episodio

Scoprire un caso non basta.

Se una persona ha collegato una piattaforma AI a un archivio aziendale, è possibile che altri utenti abbiano adottato strumenti simili. L’organizzazione deve quindi verificare se esistano altre applicazioni autorizzate, quali permessi abbiano ricevuto e se siano ancora necessarie.

Il caso può inoltre rivelare problemi che precedono l’utilizzo dell’AI.

Perché le credenziali si trovavano in una directory condivisa? Erano ancora valide? Esistevano regole sulla loro conservazione? Erano disponibili strumenti aziendali capaci di rispondere alla stessa esigenza dell’utente?

Concentrarsi soltanto sull’applicazione AI rischia di lasciare aperte le condizioni che hanno reso possibile l’esposizione.

Proteggere i dati senza bloccare l’AI

Vietare ogni strumento di intelligenza artificiale può sembrare la risposta più semplice. Nella pratica, può spingere le persone a utilizzare servizi non autorizzati e più difficili da osservare.

Lasciare che ciascuno decida in autonomia quali strumenti usare e quali dati condividere produce il problema opposto.

L’organizzazione deve offrire indicazioni applicabili:

  • quali piattaforme possono essere utilizzate;
  • quali informazioni possono essere condivise;
  • quali autorizzazioni non devono essere concesse;
  • quali strumenti aziendali sono disponibili;
  • a chi segnalare un caricamento o un accesso concesso per errore.

Servono inoltre controlli sulle applicazioni collegate agli account aziendali, revisioni periodiche dei permessi e regole per evitare che credenziali e altri segreti vengano conservati nei documenti.

L’obiettivo non è scegliere tra produttività e sicurezza. È permettere alle persone di usare l’AI senza dover valutare da sole rischi che non possono vedere.

Una visione più ampia del rischio

Il caso analizzato dal SOC non è iniziato con un attacco.

È iniziato con uno strumento utile, un’attività legittima e un’autorizzazione concessa per lavorare.

Il rischio è emerso dall’incontro tra persone, applicazioni, identità e dati. Osservare questi elementi separatamente non sarebbe bastato a riconoscerlo.

Per questo la sicurezza non può concentrarsi soltanto sugli attori malevoli. Deve comprendere anche come gli strumenti che utilizziamo modificano il percorso delle informazioni e possono creare nuove esposizioni.

Non tutti i data leak iniziano con un attacco.

Alcuni iniziano cliccando su “Consenti”.

Hai bisogno di una consulenza? Contattaci!