, , , , , , , , ,

LA SANZIONE DELL’AGCM A TIKTOK PER IL CASO FRENCH SCAR. ACCOUNTABILITY E GESTIONE DEI CONTENUTI PERICOLOSI.

Di Giacomo Conti

Con provvedimento in data 05 marzo 2024, l’Autorità Garante della Concorrenza e del Mercato ha comminato a TikTok Information Technologies UK Limited una sanzione amministrativa pecuniaria di 10.000.000 € (diecimilioni di euro) per inadeguata vigilanza sui contenuti pubblicati dagli utenti.

La decisione dell’autorità si pone nel solco di un filone interpretativo che mira a responsabilizzare le piattaforme per la gestione dei contenuti e che individua una vera e propria responsabilità per mancata gestione del rischio laddove i contenuti condivisi all’interno del servizio possano porre dei rischi per i diritti degli utenti. Merita menzione sul punto il precedente caso AGCM contro TripAdvisor dove la piattaforma di recensioni era stata sanzionata per Mezzo Milione di Euro per non avere vigilato sulle false recensioni all’interno della piattaforma la cui presenza avrebbe provocato danni ad albergatori e ristoratori (https://www.agcm.it/media/comunicati-stampa/2014/12/alias-7365 ).

Nel caso in esame, l’autorità di vigilanza ha rilevato all’interno della piattaforma TikTok, da un lato, la presenza di contenuti suscettibili di minacciare la sicurezza psico-fisica degli utenti, quali quelli relativi alla challenge c.d. “cicatrice francese” (“french scar”); e, dall’altro, l’inadeguatezza delle azioni realizzate dal social per evitarne la diffusione. In particolare, è stato accertato che questi contenuti pericolosi venivano addirittura proposti reiteratamente agli utenti attraverso ‘sistemi di raccomandazione’ suscettibili di condizionare le scelte dei consumatori, nella specie di quelli vulnerabili.

In particolare, i contenuti vengono proposti sulla base di un sistema di profilazione algoritmica che individua e seleziona contenuti personalizzati in base a una combinazione di fattori volti a cogliere le preferenze e gli interessi del singolo attraverso le interazioni con gli altri utenti dove vengono inseriti like, quali video sono condivisi, commenti inseriti, tempo speso a vedere un vide,;  le caratteristiche del video come didascalie, hashtag, suoni, paese; nonché le informazioni sull’utente come le impostazioni del dispositivo, dell’account o la lingua selezionata. Inoltre, è integrato un sistema di consultazione basato sui feed “Seguiti”, dove sono rinvenibili i video pubblicati dagli utenti di cui l’utente è diventato “follower”.

L’AGCM ha, peraltro, messo bene in evidenza come il sistema di ricerca attiva dei contenuti operi solo in via residuale a maggiore evidenza di come gli utenti siano esposti ai contenuti proposti dalla piattaforma. In particolare, le risultanze istruttorie hanno dimostrato che adolescenti vulnerabili sono esposti con una frequenza maggiore a contenuti pregiudizievoli a causa del sistema di raccomandazione di TikTok in ragione della profilazione operata dalla piattaforma.

Inoltre, l’Authority ha messo in luce come l’aumento dell’attività degli utenti sulla piattaforma amplifica la redditività degli spazi pubblicitari perché il maggior utilizzo di TikTok fornisce al sistema di raccomandazione algoritmico più informazioni sulle preferenze degli utenti. Questo a maggiore dimostrazione dell’interesse della piattaforma a proporre contenuti potenzialmente perché di potenziale interesse dell’utente pure se dannosi per la salute fisica e mentale di questi.

Anche in questo caso, come accaduto in precedenza con la sanzione a TripAdvisor (v. https://www.agcm.it/media/comunicati-stampa/2014/12/alias-7365 ), l’AGCM ha ribadito l’esistenza di un vero e proprio obbligo per la piattaforma di gestire questi contenuti.

Dagli accertamenti, inoltre, è stata dimostrata l’inadeguatezza dei sistemi di moderazione dei contenuti, automatizzati e gestiti dalle risorse umane di TikTok posto che è emerso che la maggior parte dei video rimossi da TikTok riguarda le categorie che le Parti hanno definito “sicurezza dei minori”, “contenuti violenti espliciti”, “nudità e attività illegali”, mentre solo il 5% delle rimozioni ha riguardato “atti e sfide pericolose”. Nonostante l’attività umana di moderazione sia particolarmente rilevante per contenuti la cui inadeguatezza risulta meno immediata, dagli atti risulta che i componenti del “Team di moderatori” sono selezionati secondo requisiti generici come l’“attenzione alle problematiche sociale”, la familiarità con le leggi e normative relative a internet e la capacità di lavorare su turni diversi. Inoltre, è stato documentato che i moderatori vengono formati tramite corsi interni sull’applicazione delle Linee Guida che, per quanto in atti, appaiono incentrati più sui contenuti violenti, illegali, o a contenuto sessuale che non su challenge e atti pericolosi per i minori

Nella propria valutazione, pertanto, l’autorità ha ritenuto che la piattaforma avesse violato gli obblighi di diligente applicazione delle proprie Linee Guida comunicate agli utenti, condizionato indebitamente degli utenti attraverso la riproposizione di contenuti che sfruttano la vulnerabilità di alcuni gruppi di consumatori; predisposto inadeguate misure di controllo e vigilanza adottate da TikTok sui contenuti pubblicati dagli utenti, con particolare riferimento alla tutela dei soggetti minori e vulnerabili e, da ultimo, diffuso contenuti in grado di minacciare la sicurezza psico-fisica di bambini ed adolescenti.

Per queste ragioni è stata, pertanto, emessa una sanzione per pratica commerciale scorretta ai sensi degli articoli 20, comma 2 e 3, 21, comma 2 lettera b), 21, comma 4, 25, comma 1, lettera c) del Codice del consumo in quanto contraria alla diligenza professionale e idonea riconoscendo una vera e propria responsabilità per inadeguata vigilanza sui contenuti pubblicati dagli utenti.

 

 

Per maggiori informazioni si rinvia al testo integrale del provvedimento reperibile in https://www.agcm.it/media/comunicati-stampa/2024/3/PS12543-

/da
, , , , , , , ,

Ruoli GDPR, Whistleblowing e gestione del canale di segnalazione. Perché l’art. 13 del Decreto Whistleblowing non convince?

Di Giacomo Conti

 

Secondo l’art. 13 comma 4 del Decreto Whistleblowing, i trattamenti di dati personali relativi al ricevimento e alla gestione delle segnalazioni sono effettuati dai soggetti di gestori dei canali di segnalazione, che sono da considerarsi, a rigor di norma, titolari del trattamento.

Se così fosse, sarebbero questi soggetti sono tenuti ad adottare le misure di organizzazione e sicurezza appropriate a tutela dei diritti e delle libertà degli interessati, mentre per eventuali violazioni della normativa o per data breach. Il tutto mentre, l’organizzazione che non ha implementato il canale o non ha adottato adeguate misure di sicurezza non dovrebbe rispondere per violazioni o data breach non essendo titolare del trattamento.

A livello sistematico appare evidente come questa norma non sia compatibile con quanto stabilito dal GDPR secondo cui i ruoli nell’ambito delle attività di trattamento di dati personali sono dettati dal principio di finalità del trattamento in ragione del quale il titolare è colui che determina le finalità del trattamento e ne individua la base giuridica.

Pertanto, secondo l’art. 4 numero 7 del GDPR, deve intendersi come titolare del trattamento la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che, singolarmente o insieme ad altri, determina le finalità e i mezzi del trattamento di dati personali. Quindi, l’organizzazione che ha predisposto il canale di segnalazione.

Seppure il GDPR stabilisca che quando le finalità e i mezzi di tale trattamento sono determinati dal diritto dell’Unione o degli Stati membri, il titolare del trattamento o i criteri specifici applicabili alla sua designazione possono essere stabiliti dal diritto dell’Unione o degli Stati membri, la scrittura della norma appare non conforme con i principi generali in materia di protezione dei dati.

È, infatti, evidente come nel caso in cui la gestione dei canali di segnalazione si affidata a un ufficio interno all’ente le persone incaricate della gestione del canale di segnalazione saranno necessariamente autorizzate ai sensi dell’art. 29 GDPR. Peraltro, in ragione del principio di substance over form nella definizione dei ruoli GDPR non dovrebbe rilevare se questi soggetti sono professionisti autonomi o dipendenti dell’ente.

Il fatto che questi soggetti siano persone autorizzate e non titolari di trattamento è messo in evidenza dall’articolo 4 comma 2 del Decreto Whistleblowing secondo cui la gestione del canale di segnalazione è affidata a una persona o a un ufficio interno autonomo dedicato e con personale specificamente formato per la gestione del canale di segnalazione. Questo comma è in evidente contraddizione e distonia con l’art. 13 della norma.

Il Decreto Whistleblowing contempla anche il caso in cui la gestione del canale sia affidata a un soggetto esterno e, come nel caso precedente, il personale preposto alla gestione della segnalazione che in questo caso è del gestore del canale esterno deve essere specificamente formato. In questo caso, l’ente esterno incaricato della gestione del canale potrebbe essere un data processor ai sensi dell’art. 28 GDPR e le persone che trattano i dati personali nell’ambito delle segnalazioni, ugualmente, dovrebbero ritenersi soggetti autorizzati che operano sotto l’autorità non del controller, ma del processor.

Seppure la normativa sia ancora troppo recente per avere prodotto giurisprudenza sul punto, si può attingere, almeno per analogia, ad alcuni precedenti del Garante che si è espresso in tema di ruolo GDPR dell’Organismo di Vigilanza.

In alcune ipotesi, infatti, il gestore del canale di segnalazione potrebbe anche essere un membro dell’organismo di vigilanza e il Garante si è già espresso sul punto con il “Parere sulla qualificazione soggettiva ai fini privacy degli Organismi di Vigilanza previsti dall’art. 6, d.lgs. 8 giugno 2001, n. 231” in data 21 maggio 2020 reperibile in: https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9347842

Il Garante ha ritenuto che l’OdV, nel suo complesso e a prescindere dalla circostanza che i membri che lo compongano siano interni o esterni, debba essere considerato come parte integrante dell’ente. Per l’effetto, i singoli membri dell’OdV debbano considerarsi come soggetti autorizzati ai sensi dell’artt. 4, n. 10, 29, 32 par. 4 Regolamento e dell’art. 2-quaterdecies del Codice della Privacy.

La designazione dei membri dell’OdV, al pari dell’istituzione dell’ufficio preposto alla gestione del canale di segnalazione è, infatti, un atto di organizzazione e non negoziale e, pertanto, appare corretto qualificare questi soggetti come autorizzati (art. 29 GDPR) e non come responsabili di trattamento piuttosto che titolari (art. 28 GDPR).

Ne consegue che, anche nel caso di una violazione di dati derivante nell’ambito della gestione del canale di segnalazione affidata a un soggetto esterno, dovrà rispondere necessariamente l’ente. In quest’ultimo caso, per culpa in eligendo in ragione di una scelta di un soggetto non adeguato.

L’impostazione normativa, all’apparenza, sembra deresponsabilizzare le organizzazioni che, per legge sono tenute ad adottare il sistema di whistleblowing e, pertanto, è opportuno e necessario adottare un’interpretazione correttiva conforme al GDPR che vorrebbe che l’organizzazione fosse titolare di trattamento. Il tutto anche per assicurare un adeguato livello di protezione dei dati personali che il Decreto WhistleBlowing richiede essendo la protezione dei dati personali del segnalante uno dei principi cardini assieme alle misure di protezione della sua persona.

 

/da
, , , , , , , ,

Contratto tipo di contitolarità dell’Autorità di controllo per la protezione dei dati personali del Baden-Württemberg, Germania

In allegato il Contratto tipo contitolartà 26 GDPR Baden Wuttermberg  Modello contrattuale ai sensi dell’art. 26 GDPR fra contitolari del trattamento elaborato dall’Autorità di controllo per la protezione dei dati personali del Baden-Württemberg, Germania.

 

Traduzione a cura di Christopher SCHMIDT, CIPP/E CIPM CIPT CBSA con il contributo di Giacomo Conti

 

Il testo in lingua originale è reperibile al seguente link: https://www.baden-wuerttemberg.datenschutz.de/mehr-licht-gemeinsame-verantwortlichkeit-sinnvoll-gestalten/.Non 

 

/da
, , , , , , , , , ,

La protezione dei dati e del segreto aziendale. Riflessi applicativi processuali del principio di accountability

di Giacomo Conti

 

La protezione dei dati personali e delle informazioni riservate aziendali sono temi che, molto spesso, si sovrappongono e completano a vicenda: frequentemente, le misure per limitare l’accesso ai dati dei clienti non solo proteggono la privacy dei clienti da soggetti non autorizzati, ma tutelano anche informazioni che l’organizzazione ha interesse a mantenere segrete.

Pertanto; l’impostare sistemi di protezione delle informazioni aziendali e l’adozione di misure per revocare i privilegi di accesso alle informazioni a un ex dipendente una volta cessato dall’incarico non solo proteggono i dati dei propri clienti, ma anche il patrimonio informativo aziendale. Trattasi di misure di organizzative che, per quanto basilari qualunque impresa dovrebbe adottare anche a tutela dei propri interessi.

Infatti, un’organizzazione che non ha implementato policy di protezione delle informazioni e che non è in grado di dimostrarlo in corso di causa di averle applicate, verosimilmente, arriverà a soccombere in giudizio. Questa è la posizione che si sta affermando in giurisprudenza che sta tracciando dei principi processuali in tema di onere della prova di un principio sostanziale relativo all’organizzazione aziendale.

Un precedente importante è rappresentato dall’ordinanza in data 31 gennaio 2022 nell’ambito del procedimento cautelare 8293/2021 avente ad oggetto la legittimità di un accesso e conseguente scarico di una banca dati da parte di una ex dipendente nell’ambito di una compagnia di intermediazione assicurativa. Nella narrativa del ricorso, i suddetti dati sarebbero stati utilizzati al fine di sviare la clientela verso un concorrente del ricorrente.

La ex dipendente, come emergeva dai fatti di causa, aveva scaricato l’intero contenuto della sua casella e-mail, che conteneva tutte le comunicazioni inerenti ai clienti a lei affidati a seguito della cessazione del rapporto di lavoro. Nello specifico, l’accesso e download riguardavano la banca dati di clienti dell’intermediario assicurativo e il portafoglio di clienti gestito dalla ex dipendente.

Nonostante non fosse oggetto di discussione l’avvenuto download dei dati, come rilevava il Tribunale di Bologna, l’accesso al sistema le era ancora consentito in quanto la società ricorrente aveva chiesto all’ex dipendente di continuare a gestire il portafoglio clienti nelle more delle trattative dirette a cercare l’instaurazione di un nuovo rapporto di collaborazione.

Nel caso di specie, la ex dipendente accedeva liberamente al contenuto della casella di posta aziendale con le proprie credenziali di accesso. Questa circostanza fattuale arrivava a dimostrare, a livello processuale, la mancata adozione di misure ragionevolmente adeguate a mantenere le informazioni segrete.

Per l’effetto della mancata adozione delle misure di protezione del know how adeguate, la ricorrente non riusciva a dare prova della natura segreta delle informazioni sottratte con conseguente impossibilità di applicare gli articoli 98 e 99 del codice della proprietà intellettuale che tutelano il cosiddetto segreto industriale.

L’adozione di adeguate misure di protezione avrebbe dimostrato che i dati scaricati dalla ricorrente ricomprendevano informazioni commerciali segrete e dotate di valore economico in quanto segrete in quanto sottoposte a misure da ritenersi ragionevolmente adeguate a mantenerle segrete.

Pertanto, il Tribunale concludeva che non vi fossero elementi che consentissero di accertare una condotta di concorrenza sleale ai sensi dell’art. 2598 n. 3 c.c. e respingeva il ricorso.

La pronuncia in esame mette in evidenza importanti riflessi processuali in materia di accountabilty, sotto il profilo della capacità di dimostrare in sede giudiziale di avere adottato e documentato le procedure e l’attuazione delle stesse.

Per maggiori approfondimenti v. il testo del provvedimento: ordinanzaBLIND

/da
, , , , , , , ,

Disaster recovery & business continuity

di Jacopo Sabbadini

 

Solo negli ultimi due mesi vi sono stati diversi attacchi alle aziende italiane. SIAE, Regione Lazio, San Carlo, solo per citarne alcuni.

Recente è lo studio di Trend Micro che dimostra come l’Italia sia, ad oggi, il terzo paese più colpito da malware, al mondo, secondo solo a Stati Uniti e Giappone.

 

Per queste ragioni diventa imperativo adoperarsi, non importa quanto grande sia la propria azienda, per avere delle efficaci politiche di disaster recovery e business continuity.

Partiamo da una rapida definzione:

  • Per disaster recovery si intende la possibilità di riprendersi in maniera efficace da un evento atto a distruggere o compromettere gravemente la propria infrastruttura.
  • Per business continuity si intendono quella serie di procedure atte a mantenere attiva la propria infrastruttura durante un evento atto a compromettere l’infrastruttura.

Pietra angolare di ogni procedura di disaster recovery è una corretta politica di backup; questa deve essere pensata per essere automatica e sicura, in modo tale da evitare da un lato la perdita potenziale di dati, dall’altro il backup della minaccia stessa.
Per questa ragione si consiglia sempre di eseguire backup asincroni, in ridondanza su più unità, e solo dei file effettivamente importanti, mai dell’intero sistema; questo proprio per evitare di portarsi dietro, con il backup, anche un potenziale malware, rendendo quindi inutile la procedura stessa.

In aggiunta, i sistemi su cui vengono eseguiti i backup dovrebbero trovarsi su una rete particolare, non raggiungibile dalle altre, se non nel momento della copia dei dati o, in alternativa, completamente scollegati dalla rete.

Per quanto riguarda le procedure di business continuity  invece, il concetto principale è la ridondanza. Vanno previsti più sistemi, ridondanti tra di loro, in modo tale che se uno di questi sistemi dovesse trovarsi sotto attacco, esso possa essere velocemente scollegato e rimpiazzato da un altro; in questo modo si può garantire la continuità dei servizi, anche durante un incidente.

 

Essenziale è anche testare le sopracitate procedure. Un po’ come per le procedure antincendio, se le procedure di backup, disaster recovery e business continuity non vengono mai testate, non importa quanto queste possano essere sicure ed efficaci sulla carta, non può esserci garanzia di reale efficacia e funzionalità.
Una buona prassi è quella di simulare quindi, periodicamente, questi scenari, in modo tale che tutti i membri dell’azienda, grande o piccola che essa sia, siano a conoscenza dei propri ruoli, e possano agire in maniera efficace quando sarà necessario.

/da
, , , , , , , , ,

GDPR for dummies. Il modello organizzativo minimo per una PMI – Paperless compliance for free… almost.

Nonostante la protezione del dato e la cultura della sicurezza delle informazioni abbiano compiuto dei significativi passi in avanti negli ultimi anni, ancora oggi, molte piccole-medie imprese trovano difficoltà nell’implementare modelli di gestione della privacy anche basilari.

Molti continuano, ingiustamente, ad avere paura delle sanzioni previste dal Regolamento Europeo con l’effetto di produrre inutile carta senza aumentare il livello di consapevolezza, accountability e sicurezza. Da qui si producono inutili consensi controfirmati, lettere di incarico senza formare le risorse e burocratizzazione inutile di processi che potrebbero essere lineari, semplici e paperless.

Non penso sia un caso, dunque, che la protezione del dato continui erroneamente ad essere abbinata a burocrazia inutile quando essa potrebbe essere agevolmente gestita con pochi essenziali adempimenti.

Non me ne voglia chi ci ha prosperato con la paura delle salatissime multe e prodotto carta inutile; ma molte volte, per raggiungere un grado sufficiente di compliance, è sufficiente dotarsi di pochi piccoli accorgimenti ed effettuare pochi piccoli investimenti mirati, principalmente in misure di sicurezza e formazione delle risorse umane.

Sperando di ripetere l’ovvio, ribadisco che la “paperless compliance for free… almost” non può trovare applicazione, ad esempio, per realtà molto particolari che effettuano trattamenti ad alto rischio, anche se poco strutturate così come per realtà che trattano dati su larga scala o presentano rischi maggiori rispetto alla media.

Per affrontare il discorso relativo alla paperless compliance, è necessario tenere presente che il GDPR va letto partendo dall’articolo 1 per poi scorrere verso gli articoli finali abbinando, se possibile, la lettura dei considerando alla norma.

È oramai opinione consolidata fra gli esperti che il GDPR chiede di affrontare con un approccio organico tutti i processi aziendali dove vengono coinvolti dati personali.

Ogni processo deve, dunque, essere originariamente configurato per garantire il rispetto principi generali previsti dall’art. 5: liceità, correttezza e trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza e responsabilizzazione (o accountability per gli anglofili).  Non ci dilungheremo in questa sede su questi principi, limitandoci a citarli.

In secondo luogo, bisogna vedere se ricorre una o più delle basi di legittimità previste dal susseguente art. 6, fra cui è presente anche il consenso dell’interessato che però, è bene richiedere solo ove strettamente necessario (v. https://avvgiacomoconti.com/un-consenso-per-uno-e-uno-per-tutti-una-corretta-applicazione-del-principio-di-irresponsabilizzazione/ ).

Se l’organizzazione sa perché tratta il dato e partendo da quali basi, ad esempio un contratto o una norma di legge o un legittimo interesse, potrà approfondire la conformità del processo al GDPR, ma potrà con una certa ragionevolezza essere sicura che il processo è, in linea di massima, lecito.

Sorvolando sugli articoli seguenti ci troviamo all’art. 24 che menziona espressamente i rischi per i diritti e per le libertà degli interessati che sono indicati per sommi capi nel testo dell’articolo. La norma, senza richiedere nulla di trascendentale chiede semplicemente di tenere conto dei trattamenti che vengono operati all’interno dell’organizzazione e di adottare misure organizzative e di sicurezza adeguate e parametrate al rischio.

Senza pretesa di esaustività, basti pensare al fatto che il trattamento di dati personali apre una finestra sulla vita dell’interessato e a seconda del “peso specifico” del dato personale sarò in grado di conoscere certi aspetti della vita di una persona che sarà, conseguentemente, vulnerabile. Per questa ragione il GDPR distingue i dati in comuni (che permettono di identificare o prendere contatto con l’interessato) e particolari (che invece rilevano aspetti particolarmente delicati della vita privata altrui).  È bene abbinare la lettura dell’art. 24 agli artt. 9 e 10 del GDPR per meglio comprendere il concetto di “rischi per i diritti e per le libertà”.

Semplificando al massimo questo processo che è piuttosto complesso, è essenziale che ogni organizzazione sappia almeno in linea di massima quali dati tratta, per quale motivo e che effetto una violazione alla loro riservatezza, integrità e disponibilità può avere sulla vita personale del lavoratore, del cliente del fornitore e degli altri soggetti coinvolti nel trattamento.

Veniamo ora all’art. 29 che richiede di adottare misure organizzative adeguate. In questa sede ci limiteremo ad indicare le misure che ogni impresa dovrebbe adottare fra le quali, l’individuazione del designato/privacy officer che è un soggetto interno incaricato della gestione delle procedure di trattamento dei dati e per rispettare il GDPR, come garantire le richieste degli interessati o comunicare con l’autorità garante.

Questa figura dovrebbe essere interessata alla materia, adeguatamente formata e responsabilizzata per assicurare un adeguato livello di compliance interno all’organizzazione. L’attività di designazione del referente privacy è un processo a costo zero. Altrettanto gratuita potrebbe essere la creazione dell’organigramma aziendale dove vengono mappati funzioni e compiti dei soggetti designati dall’organizzazione.

Se si vuole che la designazione sia efficiente, tuttavia, sarebbe bene stanziare una somma – anche modesta – per la formazione dei referenti affinché questi siano in grado di mappare e gestire le procedure di cui sono incaricati e responsabilizzare anche gli altri soggetti autorizzati al trattamento.

Veniamo a questo punto ai registri disciplinati dall’art.30: questi altro non sono che un processo di mappatura dei trattamenti che l’azienda opera. Pertanto, i registri dovrebbero configurarsi più che come un documento, come una procedura da monitorare e tenere aggiornata con l’evolversi dei processi aziendali. Pertanto, essi possono essere tenuti senza particolari formalità e aggiornati, anche mediante stampa del file anche in PDF, all’occorrenza.

Più che la forma, è importante che questi strumenti siano tenuti da un soggetto competente che, verosimilmente, sarà il designato aziendale che conoscerà i processi aziendali ed avrà anche una discreta conoscenza normativa ove adeguatamente formato.

Oltre al registro delle attività di trattamento (art. 30), è opportuno che l’organizzazione si munisca anche di un registro della formazione per documentare l’attività svolta e un registro delle violazioni (art. 33) per documentare eventuali data breach e che è uno strumento di ausilio e responsabilizzazione fondamentale per valutare se e quali conseguenze la violazione potrà avere per gli interessati coinvolti.

Seppure i registri non siano richiesti a tutte le organizzazioni, l’adozione di questi è stata fortemente incoraggiata sia dalla nostra Autorità Garante che dal Comitato Europeo per la protezione dei dati personali, ma anche da autorità straniere.

Veniamo ora ai processi relativi alla sicurezza dei dati che possono avere natura fisica o logica.

La sicurezza fisica si articola in misure piuttosto banali come, ad esempio, l’apposizione di porte blindate agli ingressi, inferriate alle finestre, la presenza di estintori.

Apparentemente più complesso è il profilo della sicurezza informatica, ma anche qui, vedremo soluzioni a basso costo o gratuite che possono aiutare enormemente l’organizzazione ad aumentare il proprio livello di sicurezza.

Il primo problema comune a tutte le organizzazioni è la gestione delle Password. Avere password in giro non protette è come lasciare le chiavi della porta vicino allo zerbino di casa.

Rinviando all’apprezzabile vademecum elaborato dal Garante (v. https://www.garanteprivacy.it/temi/cybersecurity/password) è consigliabile adottare gestionali gratuiti come KeePass ( v. https://keepass.info/ ) che salvano i dati in locale criptati eliminando il rischio del cloud e attraverso la master password e i plugin consentono un’agile gestione delle password eliminando fogliettini, il rischio di perderle e altri rischi. Il dipendente dovrà ricordarsi solo la Master Password di accesso al servizio KeePass per accedere in sicurezza a tutte le proprie credenziali.

Altro problema che ogni organizzazione affronta è il backup e, per le organizzazioni più semplici, può bastare anche un piccolo investimento in un NAS o in un economico servizio di backup online scegliendo quello più adatto alle proprie esigenze. Senza dilungarci sulla gestione della backup policy in questa sede, si segnala Duplicati (v. https://www.duplicati.com/ ): una soluzione che rende più efficiente il processo di backup e aiuta a gestire il rischio di perdita dei dati trattati. Questo sistema, di default cripta i dati in formato criptato e permette di gestire la recovery dei dati in maniera intuitiva e semplice. Il gestionale è anche flessibile e permette all’utente di configurare i tempi, modi e livelli di sicurezza del backup.

Potrebbe essere auspicabile anche prevedere un programma formativo con oggetto la cybersecuirty awareness per sensibilizzare i dipendenti alle minacce informatiche. Per iniziare il percorso di sensibilizzazione si può iniziare con il fruire di risorse gratuite e accessibili online.

I problemi della sicurezza informatica, ça va sans dire, non si esauriscono a quelli indicati ed è auspicabile che buona parte delle organizzazioni si accerti, fra le altre cose, di:

  1. Installare solamente programmi originali da autori verificati e sempre aggiornati all’ultima versione
  2. Investire in un solido antivirus che implementi almeno un firewall logico e sistemi di rimozione di malware
  3. Differenziare la rete ad uso interna da quella data ad uso degli ospiti adottando processi di segmentazione

I più scrupolosi vorranno, altresì, adottare un firewall perimetrale integrato con un servizio di analisi dei file di log.

Pare, dunque, opportuno stanziare somme, anche modeste, per aumentare il proprio livello di sicurezza informatica in azienda investendo sulle risorse umane e sulle misure di protezione tecniche.

Un’azienda con un elevato grado di compliance al GDPR, dunque, saprà valutare in autonomia gli investimenti, a livello tecnico e sulle risorse umane, che dovrà operare e saprà gestirsi autonomamente evitando di spendere soldi in consulenze inutili e carte e agire in autonomia per rispettare la norma, nelle migliori ipotesi, con un costo tendente allo zero o con un investimento più che contenuto.

Il GDPR non richiede, dunque, di produrre carte, ma di implementare dei processi efficienti per una corretta gestione del dato e, per essere applicato efficacemente, richiede cultura, formazione e sensibilizzazione.

/da
, , , , , ,

Attacchi informatici ai fornitori e crisi della supply chain. Da una difesa attiva a una logica di difesa zero-trust.

Di Jacopo Sabbadini

Negli ultimi anni abbiamo visto una crescita esponenziale delle minacce alla sicurezza informatica. Questo fenomeno si è acuito nell’ultimo periodo a causa della situazione dovuta alla pandemia mondiale, che ha portata ad un incremento del lavoro da remoto, accelerando di molto un fenomeno già in essere.

A seguito di questo trend molte realtà aziendali hanno cominciato ad implementare svariate soluzioni di sicurezza basate sull’analisi del traffico e dei pacchetti , sulle firme dei programmi , sul comportamento delle utenze.

 

 

Questa “presa di consapevolezza” da parte delle aziende non sembra però aver sortito effetto, praticamente ogni giorno si legge di un nuovo attacco a grandi infrastrutture, spesso strategiche (Colonial Pipeline, AXA, Glovo, solo per citarne alcune) dunque sorge spontanea una domanda: come è possibile che con l’aumento delle misure di protezione, vi sia un conseguente aumento degli attacchi riusciti contro le stesse infrastrutture che implementano questi sistemi?

Per rispondere a questa domanda, bisogna partire da un concetto che pare banale, ma è cardinale in questa analisi: nessun’azienda, nessuna realtà è un’isola. Maggiore è l’azienda, maggiore è il suo giro di affari, maggiore è la galassia di fornitori di beni e servizi che orbitano intorno all’azienda stessa.

Se l’azienda di riferimento è in grado di utilizzare un determinato budget per l’implementazione e il controllo delle misure di sicurezza informatica, è quasi matematico che almeno una parte dei suoi fornitori non abbiano accesso a simili risorse; e quindi, i fornitori stessi diventano il principale obiettivo di un attacco, non tanto per i dati che possono possedere, ma per gli accessi che si possono recuperare.

Un esempio emblematico su tutti è quanto successo con VMWare; la società si occupa di virtualizzazione, ed è leader di mercato per quanto riguarda il deploy di macchine virtuali su server di produzione, ricerca e sviluppo. Quanto accaduto è stato che, ad un certo punto, durante un controllo, il team di sicurezza di VMWare si è reso conto che vi era una API con all’interno del codice mai scritto da loro, che permetteva un accesso non autenticato ma con alti privilegi dall’esterno, e l’esecuzione di codice da remoto; in buona sostanza, era un rootkit inserito non si sa da chi o quando, con molta probabilità aggiunto a seguito di una violazione dei sistemi di un proprio fornitore, che non ne era neanche a conoscenza. Quello che però si sa di per certo sono state le conseguenze: l’attacco a SolarWinds che ha messo in ginocchio moltissime aziende che utilizzano i loro software; tutto è partito da un attacco ai fornitori di VMWare, ed si è arrivati alla crisi della gestione di Orion ed Exchange.

Come fare quindi in una realtà in cui chiunque può essere un bersaglio, e magari anche un veicolo inconsapevole di attacchi mirati?
È da ripensare completamente l’idea di cybersecurity e sicurezza in generale.

Ad oggi si utilizzano dei sistemi con una vulnerabilità lampante: un antivirus, per quanto complesso e “intelligente” si basa su delle firme, su qualcosa di già noto, oltre che su un costante aggiornamento delle proprie componenti di rilevazione.

Una simile soluzione è inadeguata a proteggere contro le odierne minacce, che spesso si declinano in zero days e potenziali attacchi che arrivano da utenti “fidati” all’interno del sistema.

Bisogna passare da una logica di controllo attivo, come quella degli antivirus, firewall e via discorrendo, ad una logica di zero-trust per la quale indifferentemente dal fatto che l’utente sia autenticato, che il processo sia considerato sicuro o in ogni caso non facente riferimento ad alcun database di malware, qualsiasi azione considerata potenzialmente pericoloso viene immediatamente interrotta e segnalata.

Vista l’evoluzione delle tecniche di attacco, la ampia superficie d’attacco disponibile, le classiche soluzioni hanno fatto il loro tempo.

 

 

[1] Application Program Interface, è un sistema di interrogazione di un’applicazione utilizzato per automatizzare dei processi in programmazione.

[1] Malware che permette l’accesso a un sistema, l’esecuzione di comandi e/o programmi, spesso con alti livelli di privilegio.

[1] Malware sconosciuti, di cui non esistono firme digitali in nessun database

/da
, , , , ,

MySQLInjection: gestione dei rischi e corretta configurazione dei form nelle pagine html

di Jacopo Sabbadini

Uno degli attacchi più semplici che si possono portare contro un database è sicuramente il cosiddetto SQLInjection, che consiste nel utilizzare il linguaggio SQL per accedere ai dati di un database.
Facciamo un attimo di chiarezza su cosa sia un form e come funzioni a livello di backend del database; in poche parole, il form è l’interfaccia che vede l’utente, in cui inserisce i propri dati (ad esempio nome, cognome, data di nascita, password e via discorrendo) al momento della registrazione su un sito, o al momento del login sul sito stesso. Questi dati inseriti dall’utente vengono trattati dal database ed inseriti all’interno dello stesso, utilizzando la sintassi propria del database in esame (nel nostro caso SQL per un database scritto in MySQL).
Appare immediatamente evidente un problema: come fa la macchina a distinguere nel momento in cui viene digitata una stringa nel campo del form, tra una stringa che deve inserire all’interno del database (ad esempio il nome) e un comando nel proprio linguaggio?
Qui è necessaria la corretta configurazione del form, vi sono vari tools che permettono di filtrare quanto viene scritto dall’utente, in modo tale che qualsiasi cosa scriva non verrà mai interpretata come un comando.
Se questa precauzione però non viene presa, si rende l’intero database vulnerabile ad un injection, cioè l’inserimento dall’esterno di un comando.
A titolo dimostrativo useremo una macchina virtuale appositamente costruita con questa vulnerabilità.
Iniziamo con registrare un nuovo utente, lo chiameremo Pippo, password Topolino, signature Paperino

 

Una volta creato il nostro nuovo utente, vediamo come normalmente risponde il database ad una query normale, cioè inserendo i corretti parametri per username e password

 

Come si può vedere, nulla di strano, mi viene restituito a video un riepilogo delle informazioni inserite.
Vediamo però cosa succede se cambiamo leggermente il nostro username, e aggiungiamo un ‘, cioè un apice, alla fine del nome. Se il form fosse correttamente settato, dovrebbe semplicemente restituirci un errore in quanto non esiste nessun utente con lo username Pippo’.

 

 

In realtà ci viene restituita una videata in cui ci dice che il codice che abbiamo inserito contiene un errore, nello specifico: Query: SELECT * FROM accounts WHERE username=’Pippo ” AND password=” (0) [Exception]
Questo ci fa capire che in realtà il form non era correttamente configurato, e il database va in errore in quanto il comando che gli è stato dato non era sintatticamente corretto.
A questo punto, possiamo provare a passare un comando che riconosca come sintatticamente corretto, ad esempio dicendogli di cercare tutti i campi in cui il nome utente sia Pippo, oppure di mostrare a video tutti i campi in cui una condizione che sappiamo essere sempre vera (nell’es 1=1) appaia; questa condizione sarà ovviamente vera per ogni riga del database, e questo è il risultato:

 

Andando in errore il database, stampa a video TUTTE le linee al suo interno, comprensive di username e password. Questa tecnica può essere utilizzata per carpire non solo informazioni dalle tabelle di un database, ma anche per portare ulteriori attacchi al server stesso; la prima linea che ci viene stampata è infatti un utente con username admin e password admin; si potrebbe provare a connettersi direttamente al server usando queste credenziali, per prenderne il controllo, e per iniziare un’escalation di permessi.

Per concludere quindi, sempre controllare che le interfacce utente siano correttamente settate, altrimenti il backend più sicuro al mondo può essere bypassato con estrema semplicità.

/da
, , , , ,

L’INDIRIZZO IP E’ UN DATO PERSONALE?

di Alessandro Bottonelli

 

Secondo la Commissione Europea, parrebbe di si (V. risposta ufficiale). Eppure chi avesse interpretato che da solo un Indirizzo IP è “dato personale” ha forse preso una abbaglio? Notare che si considerano dati personali tutte le informazioni relative a una persona vivente identificata o identificabile. Anche le varie informazioni che, raccolte insieme, possono portare all’identificazione di una determinata persona costituiscono i dati personali”. Notare il raccolte insieme. Dopo la premessa, segue una lista esemplificativa di possibili dati personali, fra cui spicca: “un indirizzo IP”. Le informazioni della lista d’esempio sono individualmente “dati personali”? O sono tali quando sono informazioni che assemblate fra loro identificano una persona fisica? (v. ancora il raccolte insieme).

La tesi dell’autore è che da solo un indirizzo IP non identifica una persona fisica. Nella migliore delle ipotesi, e non sempre, identifica una macchina o meglio un sistema (PC, Server, Stampante, Disco di Rete, Router, qualunque cosa). Di per sè l’indirizzo IP non ci dice nulla della “persona” (fisica!) dietro al o ai sistemi¦ quando una persona c’è! (v. IoT, domotica ed altro).

Legare un IP pubblico ad un interessato (persona fisica: individuo appartenente alla specie homo-sapiens) richiede molti altri dati da correlare fra loro temporalmente e logicamente. E quasi mai oltre ogni ragionevole dubbio. Molti di questi altri dati sono accessibili solo alle c.d. “LEA” (Law Enforcemente Agencies) a fronte di specifiche circostanze e mandati. Da notare che le “LEA” sono escluse dal campo di applicazione (o “scope“) del GDPR. Anche per un’azienda di qualunque dimensione è difficile legare con assoluta certezza un IP privato delle proprie reti interne ad una persona fisica. Anche quando (quando?) si raccolgano a norma i log.

In sintesi: un indirizzo IP da solo non è, di per sé, dato personale: difficile da esso identificare univocamente una persona fisica. Servono altri dati.

A supporto di questa tesi occorre una spiegazione tecnica: che si spera d’aver reso il più possibile accessibile a tutti. Un indirizzo IP è ¨ la proprietà   di uno o più sistemi. Non è una proprietà dell’interessato che forse sta usando il sistema: se c’è¨ almeno un umano dietro al sistema. Non è neanche una proprietà della o delle macchine che compongono il sistema. E spesso è una proprietà volatile, non fissa nel tempo (i c.d. “ip dinamici”). Per parafrasare: sarebbe come sostenere che la “targa”, e non necessariamente permanente, di una automobile identifichi il suo guidatore. O, peggio, sostenere che la targa, mutevole, di un autobus identifichi tutti i suoi passeggeri (quando più¹ sistemi condivisi da più¹ persone condividono lo stesso IP).Per esemplificare e semplificare, prendete il vostro PC (ma vale per qualunque sistema/macchina: un server, una WebCam, un Televisore, ecc.).

Fig. 1 – la “pila” o “catena” apri in nuova scheda

Fate riferimento alla figura 1. Pensate al PC o qualunque altro oggetto di rete. Da spenta la macchina è un semplice “pezzo di ferro”, senza alcuna proprietà e men che meno un indirizzo IP. Da acceso il pezzo di ferro diventa sistema grazie al Sistema Operativo “OS” installato sulla macchina, non importa quale OS, anzi, una singola macchina potrebbe diventare più sistemi (questione qui non approfondita) che condividono lo stesso indirizzo IP. Fra le tante cose che fa, l’OS inizializza la c.d. Scheda di Rete (NIC o “Network Interface Card“), di qualunque natura essa sia: wifi, cablata o altro. Per i puristi: la NIC ha, anzi avrebbe, una proprietà unica di fabbrica chiamata MAC-Address, peccato che esso sia riprogrammabile dall’OS e serva solo alla rete locale, quindi è un’informazione che va perduta oltre il primo router: quindi la NIC non identifica neanche il pezzo di ferro. Finita di inizializzare la NIC, il Sistema Operativo (forse!) associa alla NIC un “indirizzo IP” della rete locale, ma anche due, tre o dieci indirizzi IP: nulla lo impedisce. Concluso tutto questo processo, il sistema (non la macchina, non i suoi utenti!) ha uno o più indirizzi IP. Che sia stato o meno riprogrammato, il MAC-Address è “informazione perduta”: non arriva ad InterNet. È probabile che il sistema o sistemi della rete locale subiscano il c.d. “NATting”: tutto e tutti si presentano ad internet con un solo indirizzo IP pubblico. Le informazioni MAC-Address e IP address della rete locale sono andate perdute.

In conclusione. Organizzazioni con uno o migliaia di sistemi “dentro” la propria rete locale si presentano ad Internet con un unico indirizzo IP: come si lega quell’indirizzo al o agli umani, se ce ne sono, che stanno usando quell’indirizzo? Come anticipato, si può fare: ma è¨ un esercizio difficile proprio come provare a legare la targa (mutevole!) di un autobus a tutti i suoi passeggeri! O, peggio, tentare di legare il codice radio di una nave traghetto che trasporta più autobus prima agli autobus e poi ai passeggeri di ogni autobus.

In realtà , la parafrasi è imperfetta. È più facile per una “LEA” (Law Enforcement Agency”) legare il codice radio della nave traghetto agli autobus attraverso il manifesto di carico della nave e con qualche altro passaggio arrivare ai passeggeri degli autobus. Il codice radio del traghetto e le targhe degli autobus sono statici. Invece gli indirizzi IP (le targhe e codici radio della parafrasi) sono spesso volatili: rendendo l’esercizio ben più complicato.

/da
, , , ,

Aggiornamenti e vulnerabilità del sistema Linux. Bug, Access Point e Wi-Fi.

di Paolo Montali

 

L’overflow del buffer può essere attivato nei chip Wi-Fi Realtek

Qualsiasi Software, allo stato attuale delle cose, presenta delle vulnerabilità. Per vulnerabilità, si intendono delle debolezze che vengono (spesso) inconsapevolmente create dagli sviluppatori e che possono essere utilizzate da parte di malintenzionati per entrare all’interno di un sistema.

Questo è noto agli sviluppatori, per cui le case di software si preoccupano, nei loro reparti di ricerca e sviluppo, di miigliorare gli aspetti di sicurezza e in generale di andare ad eliminare mano a mano le vulnerabilità e in generale qualsiasi tipo di “bug” che si sia manifestato o sia stato rilevato, in fase di testing, così come a seguito delle segnalazioni da parte dei Clienti/utilizzatori.

I “bug” sono ancora più pericolosi nei sistemi di connettività o di networking, in quanto, vista la loro funzione di apparati per l’interconnessione di computer, possono consentire di aprire delle porte che dovrebbero restare chiuse.

Questo è il motivo per cui è fondamentale tenere aggiornati tutti i sistemi ad ogni livello, dai BIOS o firmware dei Computer e dei vari dispositivi di networking, ai Sistemi Operativi, a tutti gli applicativi utilizzati sui computer, fino agli ERP o sistemi gestionali.

Oggi ci occupiamo del problema del mancato aggiornamento degli apparati Wi-FI con CHIP Realtek.

Le reti Wi-Fi sono una grande comodità, ma spesso ci dimentichiamo che anche questi apparati sono dotati di software per funzionare. A bordo hanno un sistema operativo (Linux) sul quale vengono implementati dei software per l’implementazione degli standard di comunicazione e per la gestione delle regole di connettività.

E’ stato verificato che gli Access Point con CHIP Realtek non patchati possono essere attaccati sfruttando le onde Wi-Fi, causando l’overflow nel buffer del nucleo (kernel) del Sistema Operativo Linux e creando il blocco o il controllo totale da parte dell’attaccante, dei computer connessi.

Il bug rilevato, si trova nel driver RTLWIFI, che viene utilizzato per gestire i chip Wi-Fi Realtek. La vulnerabilità causa un overflow del buffer nel kernel Linux quando una macchina con un chip Wi-Fi Realtek si trova nel raggio di azione di un dispositivo “malevolo”.

E’ stato verificato che come minimo, gli exploit possono causare un arresto anomalo del sistema operativo e possono consentire a un hacker di ottenere il controllo completo del computer connessi. Il difetto risale alla versione 3.10.1 del kernel Linux rilasciato nel 2013.

Purtroppo sappiamo bene che ci sono molti dispositivi che non vengono aggiornati, per cui potremmo avere nei nostri uffici o nelle nostre case dispositivi con questo bug.

‘Il problema è serio’, ha detto ad Ars Nico Waisman, un ingegnere capo della sicurezza presso Github. ‘È una vulnerabilità che, nei sistemi che utilizzano il driver Realtek (RTLWIFI), attiva un overflow in remoto tramite Wi-Fi sul kernel Linux.

La vulnerabilità è stata denominata CVE-2019-17666. Gli sviluppatori hanno proposto una correzione intorno alla metà del mese di Ottobre 2019, che probabilmente verrà incorporata nel kernel del sistema operativo nei prossimi giorni o settimane. Solo dopo ciò la correzione si farà strada in varie distribuzioni Linux.

/da