redditodicittadinanza.gov.it ed i font (di Google)

Mi immetto nella polemica nata dalla analisi di Matteo Flora del sito www.redditodicittadinanza.gov.it per “gettare ulteriore benzina sul fuoco”.

Semplificando, Matteo dice che adottando, per la pagina web del sito in oggetto, un font di Google, si consegnano ad esso “i dati di navigazione degli utenti sul sito”.

Premessa per i non tecnici: cosa sono questi fonts di Google? Si tratta di una collezione di font (la rappresentazione dei caratteri sullo schermo) che Google rende disponibili “gratuitamente” a tutti coloro che li vogliono adottare per migliorare l’aspetto del proprio sito.
Moltissimi Framework e C.M.S. li hanno adottati di default (anche WordPress), con il risultato che molti siti li stanno usando. Questo comporta che, quando un utente si collega ad uno di questi siti, il suo browser procede a scaricare il font necessario dai server dedicati di Google (salvo che il font sia già presente nella cache del browser ed altro, ma non vorrei scendere troppo nei dettagli tecnici).
Come sappiamo, ogni qualvolta si realizza una connessione tcp-ip tra un browser ed un server, nel server si raccolgono vari dati tecnici, tra i quali l’indirizzo IP del client, che come ci dicono i vari Garanti, Corte di Giustizia UE, ecc. costituisce un dato personale; Google, per tali dati, si definisce data controller (impostazione che non condivido, ma qui si aprirebbe un lungo e complesso discorso).
L’adozione dei fonts Google su molteplici siti web determina una specie di “rete di sensori globale” dalla quale Google potrebbe acquisire informazioni; non che ne abbia particolarmente bisogno, dato che quasi tutti utilizzano il servizio “gratuito” Google Analytics, per non parlare di Ads, AdSense & C.

L’informativa privacy del sito redditodicittadinanza.gov.it riporta ad una pagina sul sito del Ministero del Lavoro e delle Politiche Sociali; non ha le caratteristiche richieste dal GDPR e non si riesce neanche a capire chi sia il DPO.

Aggiungo un elemento, a mio avviso trascurato ma determinante: perchè un sito del Governo Italiano deve stare in un server di una azienda americana, presso un datacenter americano, al di fuori dello spazio UE e delle tutele del GDPR?

P.S. io dico il font e non la font; il perchè lo trovate anche qui.

P.S.2 il codice WordPress di questo sito è stato da me modificato, da tempo, per caricare i webfont dal server locale (e non dai server di Google); questo rende il rendering delle pagine leggermente più lento, ma – per me – assolutamente necessario.

Aggiornamento: il Presidente del Garante per la protezione dei dati personali, in una memoria pubblicata nel pomeriggio, interviene con alcune osservazioni sul ddl di conversione in legge del decreto-legge 28 gennaio 2019, n. 4 (reddito di cittadinanza).
Al punto 5:
Un’ultima osservazione va riferita  all’architettura del sito web del Governo, dedicato al reddito di cittadinanza. 
Si segnala, al riguardo, che il sito rivela, già nel suo attuale stato di sviluppo, alcune carenze, in particolare, nell’informativa sul trattamento dei dati e nelle modalità tecniche della sua implementazione (che, ad oggi, comportano un’indebita e non trasparente trasmissione a terzi dei dati di navigazione, quali indirizzi IP e orario di connessione, da parte dei visitatori del medesimo sito). 


Maggiori Data Breach 2018

Fine anno è tempo di riepiloghi e bilanci; vorrei proporre una tabella riassuntiva con elenco sintetico dei più rilevanti Data Breaches occorsi nel 2018 (fonte WikiPedia).

Tutti conoscono il data breach Facebook – Cambridge Analytica, alcuni anche di quello occorso al gruppo Marriott, ma solo pochi sono al corrente del peggiore data breach avvenuto nel 2018: quello accaduto a MyHeritage , valutato l’impatto potenziale sugli interessati, in base alla tipologia di dati oggetto della violazione (dati genetici).

Organizz.Dati coinvoltiSettoreTipo Breach
AerServ (subsidiary of InMobi)75000advertisinghacked
Bethesda Game Studiosunknowngamingaccidentally published
BMO and Simplii90000bankingpoor security
British Airways380000transporthacked
Cathay Pacific Airways9400000transporthacked
Centers for Medicare & Medicaid Services75000healthcarehacked
Facebook50000000social networkpoor security
Google Plus500000social networkpoor security
Marriott International500000000hotelhacked
MyHeritage92283889genealogyunknown
Orbitz880000webhacked
Popsugar123857fashionhacked
Quora100000000Question & Answerhacked
Redditunknownwebhacked
SingHealth1500000government, databasehacked
Ticketfly (subsidiary of Eventbrite)26151608ticket distributionhacked
Typeformunknowntechpoor security
Under Armour150000000Consumer Goodshacked
WordpressunknownC.M.S.hacked

GDPR e fattura elettronica

Come saprete, l’Autorità di Controllo italiana si è espressa sulla imminente estensione dell’obbligo di fatturazione elettronica alle operazioni “business to business” e “business to consumer” , emanando un provvedimento nel quale ha evidenziato diverse importanti criticità.

Nel confermare tutte quante le preoccupazioni espresse dal Garante per la Protezione dei Dati Personali, vorrei evidenziare tre punti in particolare.

Il trattamento di tutti i dati relativi ad una fattura, comprese le descrizioni di ogni riga, oltre che violare i principi di privacy by default e di minimizzazione, determinano il rischio che soggetti terzi non autorizzati possano avere accesso a tali informazioni; tale condizione è particolarmente rilevante qualora la transazione economica riguardi interessi coperti da segreti aziendali, industriali o comunque si debba mantenere la riservatezza su tali importi o sconti applicati.

Come secondo punto, occorre considerare gli aspetti derivanti dalla funzione degli “intermediari e dagli altri soggetti operanti nell’ambito della fatturazione elettronica”;  si realizzeranno dei trattamenti “big-data”, soggetti non solo ai rischi indicati dal Garante ma anche a procedure di “data mining”, tramite le quali estrarre rilevanti e preziosissime informazioni sottese.

Come terzo aspetto, e consentitemi una notazione tecnologica; ai giorni nostri, l’adozione del protocollo ftp (nato nel 1971) per trasferire elevate quantità di dati, anche personali e potenzialmente di “levatura particolare”, equivale ad inviare dati personali usando piccioni viaggiatori. Ciò conferma che, spesso, chi determina non ha esatta contezza degli aspetti tecnici e delle conseguenze delle proprie decisioni.

Mi auguro che, in extremis, qualcuno si prenda la briga quantomeno di cercare soluzioni, procedurali e tecniche.

Aggiornamento del 21 dicembre: al tavolo tecnico svoltosi nei giorni scorsi tra Agenzia delle Entrate e Garante Privacy, ha fatto seguito un provvedimento del Garante.

Invito tutti i soggetti “coinvolti” nella fatturazione elettronica a leggere con attenzione il provvedimento, in particolare gli operatori sanitari, gli intermediari e gli altri soggetti delegati nell’ambito della fatturazione elettronica.

Sono state accettate le contestazioni della Autorità di Controllo italiana relative alla sproporzione della memorizzazione di tutti i dati delle fatture (le descrizioni di riga, ma anche i dati correlati, quali quelli dei vettori) e quelle relative alla assoluta insicurezza del protocollo ftp, che adesso verrà sostituito con sftp (logica conseguenza).

L’ Autorità ha autorizzato la fatturazione elettronica, alle condizioni indicate nel provvedimento, chiedendo alla Agenzia delle Entrate, entro il 15 aprile 2019, di rifare la DPIA (adesso carente in alcune parti) e di valutare l’adozione di algoritmi di cifratura dei files XML trasmessi al SDI.

Tipologie di trattamenti soggetti a DPIA

L’Autorità di Controllo italiana (Garante per la Protezione dei Dati Personali) ha predisposto un elenco (ovviamente non esaustivo) delle tipologie di trattamenti soggetti al requisito di una valutazione d’impatto sulla protezione dei dati ai sensi dell’art. 35, comma 4, del Regolamento.

  1. Trattamenti valutativi o di scoring su larga scala, nonché trattamenti che comportano la profilazione degli interessati nonché lo svolgimento di attività predittive effettuate anche on-line o attraverso app, relativi ad “aspetti riguardanti il rendimento professionale, la situazione economica, la salute, le preferenze o gli interessi personali, l’affidabilità o il comportamento, l’ubicazione o gli spostamenti dell’interessato”
  2. Trattamenti automatizzati finalizzati ad assumere decisioni che producono “effetti giuridici” oppure che incidono “in modo analogo significativamente” sull’interessato, comprese le decisioni che impediscono di esercitare un diritto o di avvalersi di un bene o di un servizio o di continuare ad esser parte di un contratto in essere (ad es. screening dei clienti di una banca attraverso l’utilizzo di dati registrati in una centrale rischi).
  3. Trattamenti che prevedono un utilizzo sistematico di dati per l’osservazione, il monitoraggio o il controllo degli interessati, compresa la raccolta di dati attraverso reti, effettuati anche on-line o attraverso app, nonché il trattamento di identificativi univoci in grado di identificare gli utenti di servizi della società dell’informazione inclusi servizi web, tv interattiva, ecc. rispetto alle abitudini d’uso e ai dati di visione per periodi prolungati. Rientrano in tale previsione anche i trattamenti di metadati ad es. in ambito telecomunicazioni, banche, ecc. effettuati non soltanto per profilazione, ma più in generale per ragioni organizzative, di previsioni di budget, di upgrade tecnologico, miglioramento reti, offerta di servizi antifrode, antispam, sicurezza etc.
  4. Trattamenti su larga scala di dati aventi carattere estremamente personale (v. WP 248, rev. 01): si fa riferimento, fra gli altri, ai dati connessi alla vita familiare o privata (quali i dati relativi alle comunicazioni elettroniche dei quali occorre tutelare la riservatezza), o che incidono sull’esercizio di un diritto fondamentale (quali i dati sull’ubicazione, la cui raccolta mette in gioco la libertà di circolazione) oppure la cui violazione comporta un grave impatto sulla vita quotidiana dell’interessato (quali i dati finanziari che potrebbero essere utilizzati per commettere frodi in materia di pagamenti).
  5. Trattamenti effettuati nell’ambito del rapporto di lavoro mediante sistemi tecnologici (anche con riguardo ai sistemi di videosorveglianza e di geolocalizzazione) dai quali derivi la possibilità di effettuare un controllo a distanza dell’attività dei dipendenti (si veda quanto stabilito dal WP 248, rev. 01, in relazione ai criteri nn. 3, 7 e 8).
  6. Trattamenti non occasionali di dati relativi a soggetti vulnerabili (minori, disabili, anziani, infermi di mente, pazienti, richiedenti asilo).
  7. Trattamenti effettuati attraverso l’uso di tecnologie innovative, anche con particolari misure di carattere organizzativo (es. IoT; sistemi di intelligenza artificiale; utilizzo di assistenti vocali on-line attraverso lo scanning vocale e testuale; monitoraggi effettuati da dispositivi wearable; tracciamenti di prossimità come ad es. il wi-fi tracking) ogniqualvolta ricorra anche almeno un altro dei criteri individuati nel WP 248, rev. 01.
  8. Trattamenti che comportano lo scambio tra diversi titolari di dati su larga scala con modalità telematiche.
  9. Trattamenti di dati personali effettuati mediante interconnessione, combinazione o raffronto di informazioni, compresi i trattamenti che prevedono l’incrocio dei dati di consumo di beni digitali con dati di pagamento (es. mobile payment).
  10. Trattamenti di categorie particolari di dati ai sensi dell’art. 9 oppure di dati relativi a condanne penali e a reati di cui all’art. 10 interconnessi con altri dati personali raccolti per finalità diverse.
  11. Trattamenti sistematici di dati biometrici, tenendo conto, in particolare, del volume dei dati, della durata, ovvero della persistenza, dell’attività di trattamento
  12. Trattamenti sistematici di dati genetici, tenendo conto, in particolare, del volume dei dati, della durata, ovvero della persistenza, dell’attività di trattamento.

Sono ovviamente sempre valide le precedenti indicazioni fornite dalla Autority su quando occorra effettuare una DPIA.

F.A.Q. Registro dei Trattamenti

Il Garante per la Protezione dei Dati Personali ha pubblicato, in una apposita pagina, le faq sul Registro dei Trattamenti; ne avevo parlato pochi giorni orsono.

Relativamente alle aziende private, i soggetti obbligati ad averlo ed aggiornarlo sono così individuabili:

  • imprese o organizzazioni con almeno 250 dipendenti;
  • qualunque titolare o responsabile (incluse imprese o organizzazioni con meno di 250 dipendenti) che effettui trattamenti che possano presentare un rischio – anche non elevato – per i diritti e le libertà dell’interessato;
  • qualunque titolare o responsabile (incluse  imprese o organizzazioni con meno di 250 dipendenti) che effettui trattamenti non occasionali;
  • qualunque titolare o responsabile (incluse  imprese o organizzazioni con meno di 250 dipendenti) che effettui trattamenti delle categorie particolari di dati di cui all’articolo 9, paragrafo 1 RGPD, o di dati personali relativi a condanne penali e a reati di cui all’articolo 10 RGPD.

Sono quindi individuati alcune tipologie di titolari del trattamento che debbono provvedere alla tenuta del Registro dei Trattamenti:

  • esercizi commerciali, esercizi pubblici o artigiani con almeno un dipendente (bar, ristoranti, officine, negozi, piccola distribuzione, ecc.) e/o  che  trattino dati sanitari dei clienti (es. parrucchieri, estetisti, ottici, odontotecnici, tatuatori ecc.);
  • liberi professionisti con almeno un dipendente e/o che trattino dati sanitari e/o dati relativi a condanne penali o reati (es. commercialisti, notai, avvocati, osteopati, fisioterapisti, farmacisti, medici in generale);
  • associazioni, fondazioni e comitati ove trattino “categorie particolari di dati” e/o dati relativi a condanne penali o reati (i.e. organizzazioni di tendenza; associazioni a tutela di soggetti c.d. “vulnerabili” quali ad esempio malati, persone con disabilità, ex detenuti ecc.; associazioni che perseguono finalità di prevenzione e contrasto delle discriminazioni di genere, razziali, basate sull’orientamento sessuale, politico o religioso ecc.; associazioni sportive con riferimento ai dati sanitari trattati; partiti e movimenti politici; sindacati; associazioni e movimenti a carattere religioso);
  • il condominio ove tratti “categorie particolari di dati” (es. delibere per interventi volti al superamento e all’abbattimento delle barriere architettoniche ai sensi della L. n. 13/1989; richieste di risarcimento danni comprensive di spese mediche relativi a sinistri avvenuti all’interno dei locali condominiali).

L’ineluttabilità della insicurezza

Ogni tanto accade un fatto talmente eclatante che dovrebbe fare scuola, nel campo della sicurezza informatica.

Il giorno 11 febbraio VFEmail, un provider e-mail americano è stato oggetto di un attacco catastrofico (definita da loro stessi “catastrophic destruction”), da parte di soggetti che hanno completamente azzerato le loro risorse I.T. , ivi compresi tutti i backups.

Allo stato attuale, sembra che non riusciranno a recuperare nulla; sono stati quindi cancellati tutti gli archivi di posta dei loro utenti.

Allo stato, non hanno ancora realizzato come questo attacco totale sia stato possibile:
“Strangely, not all VMs shared the same authentication, but all were destroyed. This was more than a multi-password via ssh exploit, and there was no ransom. Just attack and destroy.”

Sono molto spiacente dell’accaduto; talvolta capita che un cracker (in questo caso, probabilmente dei paesi dell’est) “bussi alla porta 22”; sta a noi averla precedentemente resa resiliente (oppure bloccata per gli IP “alieni”).

P.S. invito i giornalisti a comprendere la differenza tra hacker e cracker e ad usare la definizione appropriata.

Tentati databreach su siti web

In questi giorni si stanno evidenziando molteplici tentativi di databreach a danno di siti web.

Il sistema è molto semplice ed è stato già usato in passato con successo; spesso, i webmasters hanno la brutta abitudine di realizzare copie del database per attività di manutenzione e di piazzarle nella root del sito, talvolta dimenticando di cancellarli.

I soliti ignoti, tramite dei bot appositamente predisposti, si sono messi a scansionare innumerevoli siti alla ricerca di tali copie (dump), tentando i nomi più usati, quali:

//db.zip
//db.tar.gz
//db.rar
//2018.zip
//2018.tar.gz
//2018.rar
//2017.zip
//2017.tar.gz
//2017.rar
//2016.zip
//2016.tar.gz
//2016.rar
//123.rar
//123.7z
//111.zip
//111.tar.gz
//111.rar
//1.zip
//1.tar.gz
//1.rar
//1.7z

Si consiglia di non effettuare mai backup temporanei di basi dati in spazi pubblici del sito, in quanto potrebbero essere scaricati da soggetti malintenzionati e realizzandosi, in tal modo, un probabile databreach (di norma i dump non sono cifrati).


Data Breach Unicredit

Unicredit è stata ancora oggetto di un data breach, il 21 ottobre 2018.

Il fatto è divenuto di pubblico dominio a seguito del provvedimento del 13 dicembre della Autorità di Controllo italiana, nella quale si prescrive di comunicare, a tutti i 731.519 interessati dalla violazione, quanto accaduto.

Tra le varie considerazioni che mi saltano in mente, non riesco a capire come sia possibile che una Banca come Unicredit non avesse disposto un blocco del traffico proveniente dalla rete TOR e indirizzato verso il portale di accesso all’area clienti.

Collections #2-5

Ovviamente, dopo Collection #1 attendevamo ulteriori leaks; la prima segnalazione proviene dal quotidiano tedesco Heise Online; successivamente è stata confermata da un gruppo di ricercatori universitari tedeschi dello Hasso Plattner Institute.

Si tratta di oltre 2,2 miliardi di registrazioni contenenti dati personali, talvolta solo credenziali, altre profili completi provenienti da database (violati) relativi a registrazioni su siti e servizi in tutto il mondo.

Anche l’università tedesca ha reso disponibile uno strumento di controllo per verificare se i propri dati sono presenti all’interno dei miliardi di dati personali collezionati.

Stavolta è liberamente disponibile su InterNet, anche se si tratta di archivi da quasi 1 TeraByte; ovviamente lo scaricamento e la detenzione sono illegali.

Valgono le considerazioni espresse per Collection #1.

Your account has been hacked! You need to unlock.

Dopo Alto Pericolo! , continua la saga dei messaggi di truffa ai danni degli account e-mail italiani; questa volta il messaggio, in inglese, asserisce di avere compromesso il nostro router (sfruttando una vulnerabilità); da tale trojan si sarebbe intrufolato nel PC, prendendone il controllo, ed accorgendosi delle “frequentazioni” di siti per adulti.

Poi avrebbe fatto screenshots, e bla bla bla… ; per avere il suo silenzio, occorre versare 670$ “I think is a very, very small amount for my silence”, ovviamente in BitCoin.

Conclude con “Do not hold evil! I just do my job. Have a nice day!”

Attenzione: nei casi che ho analizzato, gli account non sono stati compromessi; si tratta di una tecnica che consente di inviare un messaggio e-mail forgiando il mittente in modo da far sembrare che il messaggio sia stato inviato dal vostro server di posta.
Tutti i messaggi provenivano da un indirizzo IP sudafricano.

Ovviamente la certezza si ottiene analizzando gli headers del messaggio oppure i log del mail-server che ha ricevuto il messaggio.
Se volete avere la sicurezza che il vostro account non sia stato compromesso, contattatemi per le attività di security assessment del vostro device; di norma esse possono essere condotte anche tramite supporto remoto.

Non pagate assolutamente in quanto dareste spago ad altri criminali per tuffarsi nel “business”; il portafoglio del precedente messaggio “Alto Pericolo” ha incassato quasi 5 bitcoin (circa 16.600 euro), mentre quello del messaggio recente totalizza adesso 5 versamenti di soggetti che hanno abboccato.