4 maggio 2021

​Uber, Google e le "auto"- mobili

​Anthony Levandowski e i progetti copiati

​Anthony Levandowski era un importante ingegnere della divisione di Google che studiava le automobili a guida autonoma. Oggi quel progetto è vivo e vegeto (Waymo) ma Levandowski non ne è più parte, perché ha prima abbandonato Google per fondare la sua azienda (Otto) che ha poco dopo venduto a Uber. Poi è stato trascinato in una causa per furto di proprietà intellettuale tra Google e Uber, che è risultata per lui in una condanna a 18 mesi di reclusione (Donald Trump l'ha perdonato l'ultimo giorno della sua presidenza).

Antony non ha ammesso di aver copiato i documenti di progetto di Google, o più precisamente non ha ammesso di esserseli portati via e averli dati a Uber. Ma siccome ha acceduto a un singolo documento Google, non tecnico, quando non era più dipendente, (cosa che di per sé non poteva essere poi così grave) è stato condannato, un po' come Al Capone: la condanna è formalmente per un illecito minimo in confronto a quello che "tutti sanno che ha fatto" ma che nessuno è riuscito a dimostrare sia stato fatto da lui.

Ma cosa "ha fatto realmente" Antony? Ha scaricato quasi 10 Gb di documenti tecnici, a cui poteva accedere legittimamente, poco prima di dare le dimissioni per fondare Otto. Questo di per sé non è illegittimo, ma è ovvio che in quei pochi giorni sarebbe stato impossibile per Antony lavorare su un simile volume di dati. Quindi è ragionevole sospettare che il motivo per scaricarli fosse di copiarli.
Poi, dopo molti mesi, è spuntato (per un errore di un fornitore Uber) un documento interno Uber con parte del progetto del lidar (Lidar - Wikipedia, un radar basato su laser al posto della radio) ed era identico a quello di Google. Questa è stata la "pistola fumante" che ha spinto Google a fare causa.


Questa storia non ci interessa tanto per la vicenda di Antony, sul quale non vogliamo emettere giudizi non informati, ma per i risvolti tecnici che ne emergono. Come mai nemmeno Google ha saputo prevenire una cosa del genere?

Qualche tempo fa un cliente ci ha esposto essenzialmente lo stesso problema. Temeva, "era sicuro", che un ex dipendente se ne fosse andato con i disegni di un componente molto speciale e molto brevettato. Che è poi spuntato molto simile dalla concorrenza. E ci chiedeva cosa fare per evitare che la cosa si ripetesse.
La risposta non è semplice. Anzi, è semplice se si risponde "non si può", e probabilmente ci si azzecca. Perché il fatto è che se qualcuno ha legittimamente accesso a un documento, è praticamente impossibile evitare che ne faccia una copia, soprattutto se questo qualcuno è determinato e in malafede. Tant'è vero che nemmeno Google ha evitato che succedesse, con i documenti di un progetto molto importante, molto costoso, molto in vista e di conseguenza supponiamo molto protetto.
Ma Google aveva gli audit log, da cui ha potuto dimostrare che erano stati scaricati i documenti e quindi, a posteriori, ha potuto dimostrare (quasi) di aver subito un furto. Ma non ha potuto evitarlo.

Con Office 365, OneDrive e SharePoint si possono produrre gli audit log, con la lista degli accessi, e si possono generare allarmi quando troppi documenti vengono condivisi o scaricati in un breve intervallo di tempo. Ma nessuna di queste funzionalità può impedire che si compia il fatto, nel migliore dei casi si verrà avvisati mentre succede, o poco dopo. Ma se il malandrino è attento non farà nemmeno scattare l'allarme.

E quindi?
Non possiamo impedire la copia, ma possiamo rendere il furto un po' più difficile, e evitare che la diffusione di informazioni riservate avvenga incidentalmente. Purtroppo la cosa fondamentale è avere collaboratori di cui ci si può fidare: se poi si scopre che ci hanno tradito allora i primi a sbagliare siamo stati noi, i sistemi possono fare qualcosa per proteggerci, ma il rischio rimane comunque.
Alcune delle cose che possiamo fare sono:

  • Avere i log degli accessi, ai documenti e alla rete, per poter eventualmente usarli per capire cosa è successo.
  • Limitare i diritti di accesso ai soli documenti necessari a eseguire i propri compiti
  • In casi estremi limitare il diritto di accedere ad archivi storici senza una giustificazione. Consentire l'accesso solamente dopo un processo approvativo.
  • Usare gli strumenti di DLP1 (data loss prevention), in particolare identificare come riservati i documenti da proteggere e imporre politiche di accesso più restrittive su questi documenti.
  • Attivare Azure Information Protection2 e applicare politiche che impediscano l'uso di strumenti che consentirebbero di aggirarlo.
  • Utilizzare conditional access per consentire l'accesso ai dati aziendali solamente da dispositivi aziendali
  • Controllare i dispositivi tramite Intune in modo da garantire che la configurazione corrisponda ai nostri requisiti
  • Utilizzare Bitlocker in modo che, in caso di perdita o furto di un portatile, i dati non siano accessibili. 

Dobbiamo tenere presente che anche il più sofisticato e rigoroso apparato di sicurezza non può impedire che un tecnico acceda a documenti con cui lavora normalmente. Perché appunto è previsto che lo faccia. Quello che vorremmo è che gli si impedisca di farne un uso improprio, ma di fatto questo è praticamente impossibile: come si può ad esempio assicurarsi che non fotografi lo schermo, o che banalmente prenda appunti a mano, o che utilizzi una microcamera per scorrere tutto un documento o un progetto, ecc.? 

Un altro aiuto è meno tecnologico, ma altrettanto o più importante. I processi aziendali devono prevedere rigorose procedure di dismissione del personale che potrebbero (se opportuno e legale) limitare il perimetro delle informazioni accessibili a un dipendente dimissionario e alzare il livello di allerta su eventi che lo coinvolgano. In extremis si potrebbe persino ipotizzare un istantaneo blocco del diritto di accedere ai dati dal momento delle dimissioni. Ovviamente questo avrà un impatto economico, e diventa quindi una questione di ROI. Sempre in seguito alle dimissioni si può prevedere un' analisi degli accessi sia nel periodo immediatamente precedente, che durante il preavviso, che possa evidenziare eventuali anomalie e costituire anche un' azione deterrente. Tutte queste cose non sono certo risolutive, ma possono fare differenza. 

Un'ultima osservazione: possiamo legittimamente ritenere che un collaboratore che se ne va non debba portarsi via documenti riservati. Ma non possiamo pretendere che non si porti via la testa. Quella è sua e quello che ha imparato lavorando con noi diventa anche suo patrimonio, la distinzione tra copiare e appoggiarsi sulla propria esperienza non è poi così netta. Certo, se mi faccio una copia di qualcosa risparmio un po' di fatica, e non è giusto. Ma alla fine probabilmente il risultato cambia poco, e l'unica protezione efficace è il brevetto.


---------------------------------------------------------------------------------------- 


(1) Purtroppo molte delle protezioni di Microsoft 365 sono più efficaci su documenti Office. Questo perché in realtà la protezione è frutto di una collaborazione tra il client (il prodotto Office, ad esempio Word) ed il server (ad esempio SharePoint). Ad esempio se un documento non può essere stampato, è il client che deve rifiutarsi di stamparlo, il server non può impedirlo. Quindi la protezione di documenti non Office dipenderà anche dal prodotto con cui quel documento è creato. 

(2) Un insieme di strumenti di Office 365 che consentono di associare limiti di utilizzo ai documenti, per cui il documento è leggibile solo da persone autorizzate ed è protetto da specifiche azioni (esempio: non inoltrare, non stampare, …), indipendentemente da dove si trova. Quindi per esempio anche una copia spedita per mail rimane protetta.


Segui la nostra
pagina su LinkedIn