Utilizzo dei dati sensibili in ambiti insicuri

GLI STANDARD NORMATIVI E L’INTRODUZIONE DEL REGOLAMENTO NOTO COME “NUOVA PRIVACY EUROPEA”, IN VIGORE A METÀ 2018, PONGONO LE AZIENDE DI FRONTE A NUOVE RESPONSABILITÀ NEL TRATTAMENTO DEI DATI

PREMESSA

La sicurezza dei sistemi informatici? oggi rappresenta una vera e propria emergenza che investe gli utenti finali di qualsiasi organizzazione pubblica o privata, richiedendo specifiche tutele. Ma la salvaguardia da potenziali rischi e la protezione dalla violazione dei dati non sono aspetti che possono essere esclusivamente delegati, devono piuttosto entrare a far parte del bagaglio culturale di ciascuno di noi. L’obiettivo è quello di trasformare sempre più la “tutela” in una forma di “autotutela”.

Purtroppo non ci si rende conto che il pensiero dominante, che sembra essere “perché proprio a me o alla mia azienda?”, può arrivare a compromettere la vita stessa dell’impresa o magari a mettere in seria difficoltà un governo… un atteggiamento consapevole e responsabile dovrebbe andare ben oltre la pubblicazione sull’intranet aziendale delle procedure di sicurezza o la loro diffusione tramite circolare interna.

Nelle aziende, così come negli enti pubblici, il management dovrebbe monitorare costantemente il livello di comprensione e accettazione delle policy di sicurezza da parte dei propri collaboratori, dotandoli magari di un codice di condotta che concorra a responsabilizzarli nella loro attività quotidiana. È tuttavia utile ricordare che politiche noiose, farraginose, di complessa attuazione o peggio ancora incomprensibili, saranno verosimilmente disattese.

A livello preliminare basterebbe adottare alcuni semplici accorgimenti… un esempio? Il mascheramento dei dati reali che ancora oggi, senza alcun tipo di restrizione, vengono impiegati dai gruppi dedicati al testing e al collaudo delle procedure.

INTRODUZIONE

L’evoluzione tecnologica dei rischi e delle normative richiede interventi manutentivi e adeguativi delle procedure per essere in regola ed evitare sanzioni. Ogni intervento però ha un costo sia economico sia di tempo e risorse, che poi sono la medesima cosa. Non sempre quindi si decide o si hanno i mezzi per intervenire.

In particolare quando si opera su procedure in esercizio, oppure quando gli interventi hanno impatto sui dati di produzione. Si rinviano cercando di smorzare i rischi con altre precauzioni. A volte, si provvede a coprire alcuni aspetti esteriori attraverso incarichi attribuiti con atti formali e/o richiedendo agli addetti di sottoscrivere clausole di riservatezza. Così che la sicurezza dei dati personali, sensibili e riservati, utilizzati per elaborazioni informatiche, è lasciata all’etica del dipendente e/o dei collaboratori addetti al trattamento dei dati. Oltre questi accorgimenti, comunque necessari, è utile prevedere l’utilizzo di strumenti che permettono l’operatività sui dati sensibili risolvendo in modo automatico alcune delle possibili criticità legate alla privacy e alla riservatezza.

Il nuovo Regolamento del Parlamento europeo e del Consiglio SeC (2012) sulla protezione dei dati, che entrerà in vigore a metà 2018, e gli standard normativi pongono le aziende di fronte alle loro responsabilità per non incorrere in pesanti sanzioni.

Gli standard che fanno riferimento ai rischi informatici inerenti la protezione delle informazioni nei contesti sopra indicati, sono l’ISo 27001/3013, la PCI-DSS per la gestione della sicurezza di sistemi finanziari, queste hanno ripercussioni a livello nazionale nella circolare della banca d’Italia n.263 del 27 dicembre 2006, “nuove disposizioni di vigilanza prudenziale per le banche” e successivi aggiornamenti, oltre alle raccomandazioni del Garante per la Privacy.

Questi standard richiedono che venga attuata una serie di controlli sulla base di “regole”, e che le eventuali “eccezioni” a tali “regole” siano appropriatamente giustificate e prevedano misure di controllo alternative. Ad esempio per la ISo 27001/2013 si ha:

• A.14.3.1 Protezione dei dati di test
  1. esiste un processo di selezione dei dati di test?
  2. I dati di test sono adeguatamente protetti?” mentre la PCI-DSS indica ai punti:
• 3.3 Mascherare il PAn quando visualizzato (non devono essere visibili più di sei cifre all’inizio e quattro cifre alla fine);
• 6.4.3 I dati di produzione (PAn attivi) sono esclusi dalle attività di test o sviluppo;
• 7.1 Limitare l’accesso ai componenti di sistema e ai dati dei titolari di carta solo alle persone che svolgono mansioni per le quali tale accesso risulta realmente necessario.

La metodologia che definisce gli strumenti adeguati ai contesti sopra menzionati è il <mascheramento dei dati>, sia nella sua forma <statica> che <dinamica>, che permette di creare una versione strutturalmente simile, ma non autentica delle informazioni per utilizzarle in svariati contesti quali: test del software, formazione, protezione di campi sensibili in ambiti operativi, etc.

Lo scopo è quello di proteggere le informazioni salvaguardando la consistenza e la coerenza delle banche dati al fine di conservarne la funzionalità e l’accessibilità.

Nel seguito sono illustrate le tecnologie a sostegno delle due metodologie con riferimento allo stato dell’arte delle tecnologie leader di mercato.

MASCHERAMENTO STATICO DEI DATI

Antefatto: Nel laboratorio test e collaudo di una primaria azienda telefonica per le verifiche delle nuove procedure viene approntato l’ambiente e caricato un DB con dati di traffico estratti dai sistemi di produzione.

Si racconta di una programmatrice sposata con un utente della primaria azienda telefonica che aveva dei dubbi su certi comportamenti del consorte. Entrata così in possesso, per motivi di lavoro, dei dati reali di traffico, effettuò subito una ricerca sul traffico telefonico del marito, acquisendo certezza dei suoi sospetti. Oggigiorno la programmatrice è felicemente separata!

Le applicazioni di business richiedono progettazione continua e costanti cicli di aggiornamento, tutte queste fasi esigono il ricorso a copie dei dati di produzione, o sottoinsiemi coerenti di questi, per poter effettuare le verifiche funzionali nel rispetto delle leggi sulla privacy in materia di protezione dei dati personali e sulle varie normative inerenti la riservatezza. Riprendendo l’antefatto, la sicurezza dei dati clonati dalla produzione, per l’utilizzo in ambienti di test, è spesso lasciata all’etica del dipendente, con risultati potenzialmente disastrosi.

I dati personali e sensibili, che si ritengono al sicuro da qualsiasi attacco ed esportazione, vengono così minacciati in fase di test e collaudo. L’elevato rischio è dovuto all’utilizzo di queste informazioni anche da parte di soggetti non sempre con adeguate competenze in ambito riservatezza e privacy. Svariati studi confermano che durante i processi di collaudo degli applicativi le informazioni sono messe a rischio. La leggerezza tecnologica subordinata agli aspetti economici con cui molti sviluppatori o analisti operano, arriva a consegnare, con tutte le migliori intenzioni, a società terze intere banche dati, anche con informazioni sensibili o riservate, allo scopo di testare le procedure nel minor tempo possibile e non caricare sul progetto aspetti economici dovuti alla creazione e gestione di dati di test, ignorando o facendo finta, di non essere al corrente che questi dati potrebbero raggiungere soggetti non etici per la perversa catena dei subappalti.

La problematica investe tutte le aziende e si individuano casi in cui si è verificata almeno una violazione dei dati negli ultimi mesi; ciononostante, la medesima percentuale di aziende non dispone di tecniche per difendersi dall’esportazione dei dati di produzione negli ambienti di test.

L’esperienza porta a confermare i risultati di questi studi internazionali pure per le aziende Italiane.

Anche queste non dispongono di misure di sicurezza adeguate per i dati in ambito test e collaudo nonostante la netta maggioranza di esse abbia sperimentato una violazione dei dati.

Questa leggerezza, perché di questo e non altro si tratta, è rimediabile o con la creazione, fai da te, di apposite ed opportune banche dati per le verifiche degli applicativi, procedimento alquanto macchinoso e costoso, o con tecniche automatiche di mascheramento statico delle informazioni da copie di banche dati reali.

Il primo procedimento richiede una vera e propria progettazione per rendere la banca dati il più possibile vicino alla realtà con lo scopo di essere usufruibile in fase di test. La banca dati è popolata con decine e decine di informazioni create opportunamente da personale incaricato al momento. ovviamente i costi del progetto lievitano di conseguenza.

Come vediamo oggigiorno esistono metodologie e procedure automatiche che consentono l’abbattimento di costi. Queste consentono di trasformare i dati nel momento in cui vengono migrati da un ambiente protetto (come quello di Produzione) ad ambienti per loro natura meno protetti (come quelli di Collaudo, Sviluppo, open Data o Formazione) o addirittura non protetti in quanto esterni all’azienda (Sviluppo “offshore”).

Un elemento importante del mascheramento statico è l’irreversibilità dell’operazione di elaborazione. una volta operato sui dati originali, questi non possono essere ripristinati, per questo non si applica mai sul database originale ma su un estratto. Il processo è strutturato in modo da non alterare in nessuna maniera le banche dati di esercizio, coinvolte in sola in lettura. I dati sono estratti dalle basi dati di esercizio, e depositati in un ambiente sicuro.

Nel seguito vengono illustrate alcune tecniche per un’ottimale mitigazione delle informazioni personali, sensibili o riservate.

Tecniche di mascheramento dati

Fase iniziale del processo è la raccolta dei requisiti, collegati con le applicazioni/procedure e con i dati da utilizzare, per arrivare a stabilire le azioni successive per la creazione delle banche dati necessarie negli ambienti di sviluppo, test o collaudo. Si distinguono due macrofasi operative:

i. Selezione dei dati da estrarre Vista la cardinalità che possono raggiungere i dati di esercizio è doveroso selezionare solo quelli necessari e sufficienti al trattamento, generalmente un sottoinsieme dei dati di produzione.

Il criterio per la selezione dei dati ovviamente è determinato dall’utilizzo di questi ultimi: test interno, sviluppo offshore, open data, ecc.

In questa fase si considera la completezza dell’informazione e le relazioni con altri dati nelle altre tabelle dei database, partendo ovviamente dalla tabella selezionata come punto di partenza per l’estrazione.

In genere i dati da selezionare sono solo quelli necessari per numerosità (alcuni test richiedono un numero minimo di dati per poter essere eseguiti) e per tipologia. Questa analisi consente di individuare anche il criterio che è utilizzato come guida per un’estrazione di dati coerente con l’obiettivo fissato.

ii. Selezione della tipologia di Mascheramento

Questa fase consente di stabilire quali dati devono essere mascherati mediante l’identificazione e la catalogazione di dati sensibili o regolamentati. Si analizza come viene effettuato l’acceso a tali dati (dove risiederanno, ecc.) e l’utilizzo che ne è fatto (trattamento, processo, ecc.).

Si verifica l’eventuale esistenza di informazioni che non debbano essere in nessun caso trasferite allo sviluppo e che quindi non possano essere esportate e neppure mascherate.

Il mascheramento deve avvenire con modalità e tecniche tali da garantire che tutti i soggetti abilitati all’accesso verso il DB non possano venire a conoscenza delle informazioni sensibili e riservate.

E’ fondamentale aver chiare le correlazioni che l’applicativo implementa e che sussistono in origine sui dati e tabelle (ad esempio vincoli di chiave), al fine di non perdere l’operatività e compromettere i controlli effettuati dall’applicativo.

MASCHERAMENTO DINAMICO DEI DATI

Antefatto: In un primario Istituto di Credito l’applicazione di una nuova normativa richiede la revisione dei profili di accesso alle informazioni gestite da un processo informatico che dovrà distinguere sulla presentazione o meno delle informazioni, inibendo alcuni campi, qualora l’accesso provenga da soggetto non autorizzato a vederle.

Fino a ieri tutti gli operatori potevano accedere alle informazioni gestite e visualizzate dal processo informatico. L’attuazione di questa normativa necessita un aggiornamento dell’applicativo. Cioè costi di studio, analisi e modifica, oltre che test e collaudo delle così dette patch evolutive. Per non accennare alla riscontrata carenza documentativa dell’applicazione.

Si ritenne di essere conformi alle ferree disposizioni poste dalla nuova normativa solamente incaricando tutti, interni ed esterni, al trattamento dei dati personali, sensibili e riservati, oltre che impostare una possibile analisi dei log al fine di monitorare comportamenti non corretti.

Le informazioni però restarono visibili e quindi esportabili.Si era spostato il problema verso il personale, senza opportunamente prevenirlo e pertanto risolverlo.

La soluzione che consente la conformità normativa, senza porre mano all’applicativo, esiste ed è offerta dal mascheramento dinamico dei dati, più noto con il suo acronimo DDM (Dynamic Data Masking).

Il DDM è una tecnologia che opera on-fly cioè mascherando i dati in visualizzazione senza modificarli sulla banca dati dove restano inalterati. Se erano in chiaro restano in chiaro, se erano crittografati restano crittografati.

Il DDM si pone con funzionalità di proxy, tra l’applicativo e la banca dati. L’applicativo punta al DDM che punta alla Banca dati. Il DDM si interfaccia con l’active directory o LDAP da dove prende le informazioni per stabilire chi deve vedere che cosa.

I dati richiesti alla banca dati dall’applicativo transitano per il DDM che in base al profilo utente definisce se deve o meno mascherare qualche informazione. Se l’utente può vedere tutti i dati, questi transitano intonsi, altrimenti alcuni vengono mascherati e inoltrati all’applicativo.

L’utente che non ha i permessi non vede le informazioni che non deve vedere.

Tutto questo avviene in totale trasparenza per l’applicativo che non subisce alcuna variazione.

Il dato è mascherato in maniera consistente e coerente con l’applicativo al fine di non alterare l’algoritmo che lo sottende. Può avvenire semplicemente oscurandolo con simboli come # * oppure con le tecniche di mascheramento nel seguito illustrate, in quanto il DDM può operare mediante il richiamo di semplici programmi.

Essendo posto davanti alla banca dati il DDM gestisce e protegge gli accessi a questo impedendo abusi e tenendo traccia di tutto ciò che avviene in apposito log. La funzionalità espletata dal DDM è anche quella di Data Base firewall in quanto qualora l’utente non fosse abilitato all’accesso viene bloccato in tempo reale. Il DDM invia anche un avviso al team di sicurezza del tentativo di accesso.

METODOLOGIE DI MASCHERAMENTO DATI

Il processo di mascheramento dei dati, sia statico che dinamico, agisce su informazioni reali sostituendole in maniera realistica, utilizzando metodi che consentono di lasciare inalterati i legami tra i dati e le loro logiche di connessione. I dati mascherati hanno la stessa struttura delle informazioni originali in modo da non compromettere il funzionamento dell’applicativo. Le metodologie illustrate si applicano, coerentemente alla loro natura, sia al mascheramento statico che al dinamico.

I metodi principalmente utilizzati sono:

• Sostituzione – si sostituisce il contenuto di una colonna di dati o di un singolo campo, con informazioni simili ma completamente diverse dai valori reali, mantenendo la stessa struttura e tipologia di significato (ad esempio nome proprio con altro nome proprio);
• Rimescolamento – si scambiano i valori tra i record di una stessa colonna;
• Varianza numerica – (per i campi numerici) si utilizza un algoritmo che modifica il valore reale del dato di una percentuale casuale, in aumento o diminuzione, coerentemente con il significato.

Qualunque sia la metodologia scelta, l’intervento sui dati deve garantire:

• uno sviluppo coerente;
• la pertinenza dell’informazione mascherata;
• mascheramento di tutti i campi necessari e sufficienti, ossia il numero minimo di campi necessario a far sì che i dati personali e sensibili non siano riconducibili al soggetto;
• che tutti i campi siano stati riempiti in modo logico e rigoroso;
• il mantenimento della distribuzione originaria dei valori;
• sincronizzazione dei dati sia in senso orizzontale (correlazione per riga) che verticale (correlazione per colonna);
• la ripetibilità dell’operazione di mascheramento a fronte di aggiornamenti della banca dati originale.

A cura di Pistilli Marcello – Security Consulting presso Medialogic S.p.A, socio AIIC

Articolo pubblicato sulla rivista Safety & Security – Maggio/Giugno 2016