• Blogs, Cloud, Collaborazione, Microsoft 365, Normative, Sicurezza
• 9 Settembre 2020

I sistemi informatici che abilitano i processi di business delle aziende contengono al loro interno grossi quantitativi di informazioni. Ci preoccupiamo quindi di proteggerli con grande perizia, assicurandoci che siano adeguatamente robusti dal punto di vista infrastrutturale implementando le buone pratiche sistemistiche e controllando gli accessi in maniera scrupolosa tramite Conditional Access oppure utilizzando la Multi-Factor Authentication.

Come possiamo però assicurarci che questi sistemi vengano utilizzati in maniera conforme a come sono stati pensati ed implementati? Ad esempio, se un impiegato utilizza Microsoft Excel per raccogliere dei dati sensibili su dei pazienti e poi li invia tramite e-mail ad un partner esterno che non ha le necessarie autorizzazioni oppure alla propria e-mail personale, utilizza degli strumenti informatici che di per sé sono sicuri ma il suo comportamento sconsiderato ha creato un rischio elevato per l’organizzazione.
Inoltre l’organizzazione può avere degli obblighi normativi ai quali deve sottostare e rischia multe molto salate in caso di fuga (accidentale o deliberata) dei dati sensibili, come ad esempio accade con il GDPR.

Per proteggere adeguatamente le informazioni all’interno di Office 365 / Microsoft 365 esiste il Microsoft Information Protection Framework:

Figura 1 – Microsoft Information Protection Framework

Questo framework sfrutta un insieme di soluzioni tecniche molto differenti tra loro, per ogni singolo scopo:

• Know your data: conosci i tuoi dati, identifica cioè quali tipi di dati sensibili sono presenti all’interno dell’infrastruttura
  • Sensitive Information Types
    
• Protect you data: proteggi i tuoi dati. A tale proposito sono disponibili differenti tecnologie, alcune delle quali sono già state trattate in articoli precedenti:
  • Office Message Encryption -> Office 365 Message Encryption
  • Sensitivity Labels / Azure Information Protection -> Come classificare e proteggere le informazioni con le Sensitivity Labels di Office 365 Security & Compliance e il suo seguito Microsoft 365 Sensitivity Labels: integrazione con Office 365 Groups, PowerBI, Defender ATP, MCAS e reportistica
  • Cloud App Security -> Controllare l’adozione del Cloud tramite Microsoft Cloud App Security
    
• Prevent Data Loss: previeni la perdita dei dati
  • Data Loss Prevention
    
  • Endpoint Data Loss Prevention (per ora è una funzionalità in anteprima)
    
• Govern you data: governa i tuoi dati, archivia e conserva in maniera immutabile quelli che vanno archiviati ed elimina quelli che vanno eliminati
  • Retention Labels

In questo articolo ci soffermeremo sulle Sensitive Information Types e sulle funzionalità di Data Loss Prevention.

Tramite le funzionalità di Data Loss Prevention (DLP) all’interno di Office 365 / Microsoft 365 è possibile ridurre i rischi di fuga accidentale dei dati e avere una migliore visibilità sui dati sensibili che vengono trattati all’interno degli strumenti di collaborazione.

Le funzionalità di Data Loss Prevention sono coperte dalle licenze più avanzate:

Fondamentalmente è possibile utilizzare la funzionalità nei piani Enterprise, il piano E5 aggiunge la possibilità di applicare il DLP a Microsoft Teams ed ai singoli computer (Endpoint), funzionalità che per ora è in anteprima.

Sensitive Information Types

Una informazione sensibile, a livello tecnologico, è definita come un insieme di lettere e/o numeri che possono essere identificati da una regular expression oppure da una funzione. In aggiunta è possibile cercare delle prove circostanziali che corroborino il rilevamento delle informazioni sensibili.

All’interno del Microsoft Information Protection Framework esistono già diverse centinaia di Sensitive Information Types pronte all’uso, come ad esempio un numero di carta di credito: esso è un insieme di 14 o 16 cifre che per essere valido deve passare un determinato algoritmo, il test di Luhn.
Un numero di carta di credito valido però potrebbe non essere sufficiente ai nostri scopi in quanto per essere utilizzabile sono necessari anche il codice di verifica, il nome del proprietario e la data di scadenza.

NOTA: alla pagina Sensitive information type entity definitions è possibile trovare le definizioni di tutte le Sensitive Information Types predefinite

In questo caso si parla di fiducia (ConfidenceLevel) del match:

• Al solo numero di carta di credito viene assegnato una fiducia del 65%
• Al numero di carta di credito più una delle prove circostanziali (nome del proprietario, data di scadenza, codice di verifica…) viene assegnato una fiducia del 85%

Le Sensitive Information Types sono quindi delle definizioni in formato XML che ci permettono di identificare nella maniera più specifica possibile un determinato tipo di informazione

Figura 2 – Definizione XML di una Sensitive Infomation Type

Per creare una nuova Sensitive Information Type, portarsi nel Security & Compliance Center https://protection.office.com, andare su Classification -> Sensitive info types e selezionare una Sensitive Info Type

Figura 3 – Numero di carta di credito

Non è possibile modificare questa regola essendo di tipo predefinito, è però possibile valutare se è consona ai nostri scopi premendo il pulsante Test type

Figura 4 – Convalida Sensitive info type

Preparare un documento di testo con all’interno dei numeri di carta di credito validi, su internet esistono dei tool in grado di generare numeri che passano il test di Luhn senza utilizzare una carta vera, e caricarlo nel servizio.

Figura 5 – Documento con all’interno numeri di carte di credito

Verrà così generato un report con le Sensitive Info Types rilevate.

In Figura 6 l’esempio di un rilevamento con ConfidenceLevel del 85% e di fianco le prove circostanziali.

Figura 6 – Sensitive Info Type High Confidence

Mentre in Figura 7 è un rilevamento con fiducia più bassa, notare l’assenza degli elementi circostanziali.

Figura 7 – Sensitive Info Type Low Confidence

In caso di livelli di ConfidenceLevel mista, vince il più alto: nelle policy DLP (che vedremo più avanti nell’articolo) questo si tradurrà tendenzialmente nell’azione meno permissiva.
Il sistema ha quindi equiparato i match meno rilevanti a quelli più rilevanti.

Figura 8 – Sensitive Info Types Mixed Confidence

A fianco di quelle già disponibili è possibile creare delle Sensitive Information Types specifiche per la nostra organizzazione (ID paziente, matricole interne…) premendo il pulsante Create

Figura 9 – Creare nuova Sensitive Info Type

Assegnare un nome e una descrizione e proseguire

Figura 10 – Nome e descrizione nuova Sensitive Info Type

Aggiungere quindi le regole di match, eventuali regole di supporto al match ed assegnare un ConfidenceLevel

Figura 11 – Regole Sensitive Info Types

Rivedere i parametri per concludere il wizard

Figura 12 – Termine creazione Sensitive Info Types

Ora che il nuovo tipo di Sensitive Information Type è stata creato è possibile testarlo come visto in precedenza.

Per regole più avanzate, dove ad esempio si voglia creare delle funzioni di matching più complesse, è necessario utilizzare Windows PowerShell (ed il modulo Exchange Online per connettersi al Security & Compliance) per caricare le definizioni XML all’interno del servizio.

Data Loss Prevention – Creazione di una Policy

Una volta create le definizioni per le Sensitive Information Types che è necessario proteggere, si può passare alla creazione di una policy di Data Loss Prevention.

Una Policy DLP contiene i seguenti elementi:

• Locations: dove si trova il contenuto che vogliamo proteggere, come ad esempio Exchange Online, SharePoint Online oppure Teams
• Rules: quale contenuto ed in quale modo lo si vuole proteggere
  • Conditions: quali sono le regole per le quali il contenuto deve essere individuato, ad esempio: trovare i numeri di carte di credito, in numero superiore a cinque, che sono state condivise all’esterno dell’azienda
  • Actions: quali azioni vanno intraprese quando le conditions sono soddisfatte, ad esempio: interrompere la condivisione esterna, bloccare una e-mail dall’essere inviata oppure inviare una notifica al Compliance Officer

Figura 13 – Com’è fatta una DLP plicy

In una DLP policy se il contenuto viene individuato da più rules, queste ultime vengono valutate in ordine di priorità e viene eseguita l’azione più restrittiva.

Per creare una nuova policy portarsi sul Compliance Center https://compliance.microsoft.com e premere Data loss prevention -> + Create policy (preview)

Figura 14 – Microsoft 365 Compliance Center

Si potrà quindi scegliere se creare una policy da zero oppure se utilizzare un template, in questo caso sceglieremo di procedere con il template pensato per il GDPR

Figura 15 – Selezione template

Una volta selezionato il template è necessario dare un nome ed una descrizione alla policy che si sta creando

Figura 16 – Nome DLP policy

È la volta di decidere quali workload dovranno ricevere la policy, in questo caso ho scelto di assegnarla a Exchange Online, SharePoint Online e Microsoft Teams. Non stiamo sfruttando la funzionalità Endpoint Data Loss Prevention (DLP), che tratteremo in seguito.

Figura 17 – Workloads

Il wizard offre la possibilità di accettare le regole predefinite oppure di personalizzarle

Figura 18 – Rivedi opzioni

Abbiamo quindi deciso di rilevare queste informazioni solo quando esse vengono condivise all’esterno dell’organizzazione perché non reputiamo la condivisone interna all’azienda un rischio.

Figura 19 – Conditions

Premendo su Edit è possibile affinare le regole. Ad esempio, la nostra organizzazione può decidere che è un rischio solo quando vengono condivisi più di cinque numeri di carta di credito. Modificando il parametro Instance count variamo la quantità di informazioni sensibili necessarie a far intervenire la regola.

Figura 20 – Rules semplificate

A questo punto è il momento di definire le azioni che vengono intraprese. In base ai nostri requisiti abbiamo deciso che:

• Ci devono essere almeno cinque o più istanze di una stessa informazione sensibile per far scattare le azioni
  • Invia un incident report tramite e-mail
  • Restringere l’accesso all’informazione che si sta condividendo

Figura 21 – Actions semplificate

Siccome abbiamo abilitato l’opzione di restringere l’accesso al contenuto, ora è necessario configurare i criteri secondo i quali esso verrà limitato. È possibile bloccare l’accesso a chiunque tranne gli amministratori e l’ultimo utente che l’ha modificato (per consentirgli di rimuovere le informazioni sensibili), oppure solamente agli utenti esterni.

È anche possibile fare in modo che gli utenti visualizzino dei policy tips e permettergli di fare l’override della policy riportando, ad esempio, un falso positivo oppure una eccezione autorizzata dal business.

Figura 22 – Restrizioni accesso

Inoltre, viene data la possibilità di testare la policy appena creata. Il consiglio è di non bruciare le tappe e seguire un processo a fasi, testando approfonditamente ogni passo del percorso. Non bisogna mai applicare una policy non testata, i risultati possono essere catastrofici.

Figura 23 – Ablitazione policy

Viene quindi data la possibilità di rivedere la policy appena creata

Figura 24 – Rivedi policy

Premendo Submit essa verrà creata ed inviata ai workload selezionati

Figura 25 – Policy creata

Una nuova policy può impiegare fino a 24 ore per essere correttamente applicata a tutti i workload. È possibile verificarne lo stato tramite una sessione Windows PowerShell connessa al Security & Compliance Center.

Per verificare lo stato di replica della policy potete utilizzare il comando PowerShell

Figura 26 – Policy DistributionStatus

È possibile modificare le proprietà di una policy già creata premendo sul tasto Edit policy (preview)

Figura 27 – Edit policy

Durante la creazione tramite template sono state create due rules separate: una denominata “low volume” ed un’altra “high volume“. Queste due regole separate servono a discriminare le violazioni minori dalle condivisioni massive e ad applicare restrizioni differenti.

Figura 28 – Advanced DLP rules

In Figura 29 è possibile osservare, tramite l’editor avanzato, l’anatomia di una condition:

SE il contenuto contiene questi tipi di Sensitive info types con questo determinato ConfidenceLevel….   E   il contenuto è condiviso con persone esterne all’organizzazione…

Figura 29 – Advanced Conditions

ALLORA restringi l’accesso al contenuto alle persone esterne all’organizzazione  E  invia un policy tip agli utenti, oltre ad una mail di notifica.

Figura 30 – Advanced Actions

Data Loss Prevention – Reporting

All’interno del Compliance Center sono disponibili due report per monitorare la funzionalità di Data Loss Prevention (DLP): la policy appena creata non ha notifiche o azioni abilitate, ma sta in ogni caso riportando i rilevamenti effettuati.
Portandosi su Reports -> DLP Incidents è possibile controllare quali rules sono state innescate dagli utenti per il periodo selezionato. Nell’esempio in Figura 31 è possibile osservare che è stato trovato un file Excel su OneDrive for Business che ha impattato la regola High e due e-mail che hanno fatto scattare la regola Low.

Figura 31 – DLP Incidents

Premendo su una voce è possibile visualizzarne i dettagli: nel caso del file Excel sono stati trovati differenti tipi di Sensitive Information Types.

Figura 32 – DLP Incidents details

Il secondo report disponibile è DLP Policy Matches il quale offre una vista più dettagliata sulla singola Sensitive Information Type.

Figura 33 – DLP Policy Matches

Premendo su una riga avremo infatti i dettagli del rilevamento: questo report è molto utile per affinare i metodi tramite i quali rileviamo le Sensitive Information Types.

Figura 34 – DLP Policy Matches details

Data Loss Prevention – Esperienza utente

Dopo che si è soddisfatti dei risultati dei report e si ha affinato a sufficienza le query con cui rileviamo le Sensitive Information Types e le Rules, si può procedere ad abilitare la policy. Dopo
24 ore, necessarie alla policy per propagarsi sui workload ed ai client Office per far scadere le loro cache interne, ecco cosa accadrà se un utente tenta di inviare una e-mail contenente abbastanza numeri di carte di credito da far scattare la rule High (più di 10 nel nostro caso).

Verrà visualizzato un Policy Tip che avviserà l’utente che questa azione non è permessa, ma offrirà l’opzione (premendo override) di proseguire lo stesso. Opzionalmente si può richiedere all’utente una giustificazione, che sarà registrata.

Figura 35 – Policy Tip in Outlook

Lo stesso comportamento si applica al testo presente in un file allegato ad un messaggio di posta elettronica.

Figura 36 – DLP Match su allegato

L’utente viene avvisato che la sua azione verrà monitorata se decide di proseguire con l’invio della e-mail.

Figura 37 – DLP is watching you

L’esperienza è consistente anche quando viene effettuato l’accesso tramite Outlook On the Web.

Figura 38 – DLP Policy Tip in OOW

Su Outlook for iOS and Android, invece, i Policy Tips (al momento) non vengono visualizzati. Il messaggio in ogni caso non verrà recapitato e dopo pochi secondi si riceverà un NDR (Non-Delivery Report) da Exchange Online che spiega il perché della mancata consegna.

Le stesse restrizioni si applicano ai documenti presenti su OneDrive for Business e nelle Document Library su SharePoint Online

Figura 39 – DLP su ODB

Anche in questo caso viene offerta una spiegazione dettagliata e, siccome la policy lo consente, viene permesso all’utente di condividere lo stesso l’informazione.

Figura 40 – DLP override su ODB

Quando un utente tenta di violare una policy DLP riceverà una e-mail in cui sono elencate, in un linguaggio comprensibile, le sue violazioni. Volendo l’utente può modificare il documento incriminato rimuovendo le informazioni sensibili e ritentare la condivisione.

Figura 41 – DLP Alert tramite e-mail

Il destinatario con il quale il documento è stato condiviso non sarà in grado di aprirlo e riceverà un messaggio di accesso negato.

Figura 42 – Accesso negato DLP

All’interno del Security & Compliance Center è disponibile il report tramite il quale è possibile visualizzare gli overrides effettuati e le giustificazioni prodotte dagli utenti.

Figura 43 – Override details

Conclusioni

Le fughe di dati sono uno degli eventi più temuti dalle organizzazioni: sia per il danno economico che spesso comportano sia per il danno alla reputazione che può venire gravemente compromessa. Le tecnologie di Data Loss Prevention all’interno di Microsoft 365 sono un valido alleato per prevenire le fughe di dati accidentali, spesso legate a processi aziendali pensati in buona fede ma per i quali non è stata effettuata una corretta riflessione sugli effetti a lungo termine oppure frutto di semplici dimenticanze o leggerezze.

È necessario sottolineare che non sono pensate per contrastare l’estrazione deliberata di informazioni (es. tramite malware oppure tramite foto allo schermo). Per questi particolari scenari – “Rogue / disgruntled employee” esistono altri strumenti all’interno della suite Microsoft 365 di cui parleremo in un prossimo articolo.

Alla pagina Overview of data loss prevention trovate la documentazione ufficiale sul prodotto mentre alla pagina Sensitive information type entity definitions è possibile trovare le definizioni di tutte le Sensitive Information Types predefinite. Al collegamento Customize and tune Microsoft Office 365 Data Loss Prevention trovate una sessione di Microsoft Ignite 2016 in cui viene mostrato come creare Sensitive Information Types personalizzate ed offre qualche utile consiglio.