3 violazioni di dati personali in strutture sanitarie e problemi vari

La newsletter del Garante privacy del 19 febbraio 2021 riporta la notizia
"Data breach sanitari, il Garante privacy sanziona tre strutture":
- https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9544567.

In due casi, un invio cartaceo è stato indirizzato alla persona sbagliata,
mentre nel terzo caso un'infermiera aveva contattato i familiari di una
paziente, nonostante questa avesse richiesto di non farlo.

Il terzo caso è abbastanza semplice da capire: la richiesta della paziente
non era stata archiviata in modo opportuno e la struttura sanitaria non
aveva ben stabilito come gestire questo tipo di richieste in modo che il
personale non faccia errori (p.e. con maschere che ricordano le opzioni
indicate dai pazienti oppure cancellando i numeri di telefono non più
dichiarati accettabili dai pazienti).

Gli altri due casi sono invece di difficile comprensione. I provvedimenti
indicano che "sono ricostruite le dinamiche dell'accaduto, analizzate le
cause e definite le azioni correttive", ma io non e trovo traccia.
Certamente i provvedimenti non sono sempre il posto dove trovare queste
informazioni, ma così ho avuto l'idea di una giustizia un po' cieca, che non
ammette l'errore.

Infatti il GDPR non richiede che non vengano fatti errori, ma che vengano
valutati i rischi privacy. I provvedimenti non specificano niente in merito
alla valutazione del rischio delle aziende ospedialiere. E qui si palesa lo
scenario peggiore quando si parla di valutazione del rischio, ossia
l'affermazione (scorretta) secondo cui "se c'è stato un incidente, vuol dire
che la valutazione del rischio non era adeguata".

Dispiace che si sia arrivati a questo. Così la valutazione del rischio
rimarrà sempre più un esercizio formale (utile solo a qualche auditor o
consulenti per lanciarsi in noiosissime disqusizioni; l'ultima lezione che
ho ricevuto, in un'azienda di 5 persone, riguardava i rischi inerenti,
correnti, attesi e residui).

Spero che la rotta cambi, ma non credo che succederà in tempi brevi:
l'approccio basato sul rischio è bello da raccomandare e da sbandierare, ma
è difficile da capire e accettare fino in fondo.

Pubblicazioni ENISA per TSP

Franco Ferrari di DNV mi ha segnalato la recente pubblicazione (16 febbraio)
di nuovi documenti da parte di ENISA, significativi per i TSP (e forse non
solo per loro).

Security Framework for Trust Providers
-
https://www.enisa.europa.eu/publications/security-framework-for-trust-provid
ers/.

Security Framework for Qualified Trust Providers
-
https://www.enisa.europa.eu/publications/security-framework-for-qualified-tr
ust-providers.

Remote ID Proofing
- https://www.enisa.europa.eu/publications/enisa-report-remote-id-proofing.

Assessment of Qualified Trust Service Providers
-
https://www.enisa.europa.eu/publications/assessment-of-qualified-trust-servi
ce-providers/.

Recommendations for QTSPs based on Standards
-
https://www.enisa.europa.eu/publications/reccomendations-for-qtsps-based-on-
standards/.

Me li dovrò studiare per bene, ma sono sicuro che siano estremamente validi.

Purtroppo ENISA ha un sito web che non aiuta a trovare i documenti: la
pagina "Publications" non evidenzia questi nuovi documenti e, in realtà, si
concentra sui rapporti, sui documenti interni e altra roba non molto
importante per gli altri. Poi ha etichette e argomenti (topic) non
aggiornati alle attuali esigenze. Insomma, la situazione è molto difficile e
ritengo che sia un peccato vista la qualità della documentazione di ENISA.

Disponibili gli interventi di DIG.eat 2021

Segnalo che si è chiusa la manifestazione DIG.eat 2021.

Io ho tenuto un intervento, ma gli argomenti trattati sono molto vari e interessanti. Tutti gli interventi sono disponibili al pubblico e raccomando a tutti di guardare se ci sono cose di interesse:
- https://anorc.eu/attivita/il-netflix-della-cultura-digitale-chiuso-il-dig-eat-2021-la-piattaforma-offrira-contenuti-gratis-e-on-demand.

Il difetto è che è necessario registrarsi per poter accedere ai contenuti. Però ne vale la pena.

Linee guida EDPB sulla gestione degli incidenti

L'EDPB (la commissione dei garanti privacy europei) ha pubblicato le "Guidelines 01/2021 on Examples regarding Data Breach Notification" (grazie a Giancarlo Caroti di Neumus che me le aveva inoltrate qualche giorno fa):
- https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2021/guidelines-012021-examples-regarding-data-breach_en.

Per ora sono solo in inglese.

Non dicono nulla di nuovo a chi si occupa di privacy e sicurezza delle informazioni. Ma... lo dicono bene.

Innanzi tutto sono presentati 18 casi di incidente. Essi possono essere causati da alcuni attacchi (ransomware, intrusione in un sito web, copia di dati da parte di un interno, accesso non autorizzato da parte di un interno a causa di un errore di configurazione, perdita o furto di dispositivi IT, perdita o furto di documenti cartacei, invio di email o posta cartacea a destinatari sbagliati, furto di identità con attacco di social engineering, riconfigurazione malevola di un server di posta). Già qui abbiamo una sorta di lista di minacce da considerare perché significative.

Poi sono anche elencate le misure di sicurezza preventive raccomandate. Ripeto: nulla di nuovo, ma messo per bene.

Inoltre l'EDPB raccomanda la redazione di un "Manuale per gestire gli incidenti". E proprio il documento stesso, se utilizzato opportunamente, fornisce la base per una prima versione di questo manuale (proprio prendendo i casi riportati e personalizzando i relativi processi di "mitigazione e obblighi").

I casi sono accompagnati anche da considerazioni in merito alla necessità di notificare all'autorità garante e agli interessati l'evento.

Finalmente, dopo tantissimi documenti fumosi, che raccomandano le "solite" misure di sicurezza, un documento facilmente leggibile e pratico.

Mio intervento il 18 febbraio 2021

Interverrò, per un tempo brevissimo con qualche riflessione sulla valutazione del rischio, il 18 febbraio alle 14.30:
- https://www.linkedin.com/posts/coretech-s-r-l_cybersecurity-coretech-coretalks-activity-6767035215618555906-li0e.

Si parlerà di privacy e violazioni di dati personali.

Furto di dati con il lavoro da remoto

Questa notizia l'ho letta su Crypto-gram di febbraio 2021:
- https://www.schneier.com/blog/archives/2021/01/dutch-insider-attack-on-covid-19-data.html.

In breve: due persone sono state arrestate nei Paesi Bassi perché hanno venduto dati dai sistemi del Ministero della salute. Li raccoglievano scattando foto al proprio schermo.

Ovviamente questo sarebbe stato immediatamente rilevato in caso di lavoro in un ufficio con altri colleghi a guardare. Quindi questo caso può permetterci di considerare questa minaccia.

Attacco a un impianto idrico in Florida

Il SANS NewsBites segnala la notizia di un attacco a un impianto di trattamento dell'acqua in Florida. Uno degli articoli suggeriti è questo:
- https://www.zdnet.com/article/following-oldsmar-attack-fbi-warns-about-using-teamviewer-and-windows-7/.

Sembra che gli attaccanti abbiano sfruttato una cattiva configurazione di TeamViewer, usato dal personale dell'impianto per accedere ai sistemi con un'unica password condivisa. Nell'impianto erano usati anche dei pc Windows 7, ma forse non c'entrano con l'attacco.

Riassumo i commenti degli editor del SANS NewsBites perché mi sembrano decisamente interessanti. Li trovate al completo qui:
- https://www.sans.org/newsletters/newsbites/xxiii/12.

Ecco i commenti da me selezionati.
- Le applicazioni per il controllo remoto, come TeamViewer, dovrebbero essere configurati con credenziali personali per ciascun utente.
- Gli accessi da Internet dovrebbero basarsi sull'autenticazione a più fattori (TeamViewer lo permette e permette anche l'integrazione con altri sistemi di SSO).
- Se, nell'ambito degli impianti industriali, non è possibile aggiornare vecchi sistemi operativi (come Windows 7) allora questi vanno protetti con firewall.

Nulla di innovativo. Le misure da applicare sono sempre le stesse: qualcuno non le applica e comunque ripetercele non fa male.

PS: mi viene da pensare che è ormai quasi un anno che ci ripetiamo di mettere la mascherina. E' vero che inizialmente non c'erano le mascherine, ma adesso ancora troppi pensano di poterne fare a meno. Chi si occupa di sicurezza (delle informazioni, informatica, delle persone, eccetera) non può che ritrovare la ripetizione degli errori e delle superficialità.

Patent box

Fabrizio Monteleone del DNV Italia mi ha segnalato le agevolazioni fiscali dette "Patent box":
- https://www.mise.gov.it/index.php/it/incentivi/impresa/patent-box.

Le imprese possono avere agevolazioni fiscali per l'utilizzo di determinati beni immateriali (software protetto da copyright, brevetti industriali, disegni e modelli, processi, formule e informazioni relativi a esperienze acquisite nel campo industriale, commerciale o scientifico giuridicamente tutelabili). Questi beni devono essere dichiarati all'Agenzia delle entrate.

Io non capisco quasi niente di fiscalità, però mi pare di capire che, nel caso una valutazione del rischio dovesse considerare questi beni immateriali, essa dovrà essere in qualche modo allineata a quanto dichiarato all'Agenzia delle entrate.

Perimetro di sicurezza: decreto sugli incidenti

Del provvedimento in merito al perimetro di sicurezza nazionale avevo scritto a suo tempo:
- http://blog.cesaregallotti.it/2019/09/perimetro-di-sicurezza-nazionale.html.

Ora è in discussione il DPCM per la comunicazione degli incidenti da parte delle organizzazioni che rientrano nel perimetro. La bozza ("schema") è reperibile sul sito della Camera:
- https://www.camera.it/leg18/682?atto=240&tipoAtto=Atto&idLegislatura=18&tab=1#inizio.

Ringrazio Giancarlo Caroti per la segnalazione.

Non mi piace annunciare provvedimenti in bozza (e infatti non lo faccio quasi mai, nonostante ne riceva alcune volte notizia), ma questo merita alcune brevi considerazioni:
- acquista importanza lo CSIRT nazionale, a cui vanno comunicati gli incidenti;
- i tempi di comunicazione sono strettissimi e sono di un'ora per gli incidenti più gravi e 6 ore per quelli meno gravi; forse eccessivamente brevi per un'organizzazione che sarà impegnata nella loro chiusura;
- non viene detto da dove è stata ricavata la tassonomia degli incidente in allegato A ed è un peccato, visto che un riferimento autorevole ed esplicito era auspicabile;
- mi chiedo come questa tassonomia si integri con quella di ENISA per i fornitori di servizi eIDAS (https://www.enisa.europa.eu/publications/article19-incident-reporting-framework); non vorrei che troppe tassonomie tra loro scollegate facciano più
male che bene;
- è richiesto che le informazioni sugli incidenti vengano comunicate a molti
soggetti e penso che questa diffusione di informazioni sia rischiosa (anche
se l'allegato C specifica le misure di sicurezza da prevedere per queste
informazioni, bisogna dire che sono talmente generica da non essere
significative);
- Il DPCM richiede anche esplicitamente ai soggetti inclusi nel perimetro di
adottare le misure minime di sicurezza già previste da AgID.

PS: non annuncio più provvedimenti in bozza da quando, in epoche
preistoriche, avevo annunciato la morte del DPS, poi annullata, e
l'inserimento della privacy nel D. Lgs. 231, poi non avvenuto. Inoltre le
bozze sono spesso modificate (come ha dimostrato il GDPR). Infine, i
commenti possono aspettare l'approvazione definitiva dei provvedimenti,
visto che sono sempre previsti dei tempi di adozione che lasciano il tempo
anche per queste cose.

"Un piccolo libro sulla privacy, il GDPR e come attuarlo" e beneficenza

Pubblicizzando il libro degli Idraulici della privacy "Un piccolo libro sulla privacy, il GDPR e come attuarlo", avevo detto che i ricavati sarebbero andati in beneficenza.

Mi sembra giusto dire come sono andate le cose.

Innanzi tutto abbiamo pubblicato la versione digitale su Streetlib e quella cartacea prima su Lulu e poi su Youcanprint (distribuisce in più posti rispetto a Lulu). Ovviamente non abbiamo potere contrattuale con queste piattaforme che quindi si sono tenute il loro margine.

In tutto al 31 gennaio abbiamo ricavato 1133 Euro. Metà è andata alla Fondazione Meyer (https://donazioni.fondazionemeyer.it/) e metà alla Parrocchia di San Stanislao a Roma che si occupa del supporto alimentare alle famiglie in difficoltà (soprattutto adesso con le difficoltà legate all'emergenza COVID).

Grazie a quanti hanno sostenuto, anche promuovendola, l'iniziativa.

CSA Cloud Controls Matrix v4

La Cloud security alliance ha pubblicato il 20 gennaio 2021 la versione 4 della sua Cloud Controls Matrix v4:
- https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4/.

Ho lavorato sulla versione 3 e l'ho trovata in alcuni punti non chiara, in altri inutilmente ripetitiva e in altri ancora (la maggior parte) utilissima e molto significativa. Non ho ancora letto la versione 4 e quindi non mi pronuncio.

Penso che, al di là dei suoi difetti, sia un documento fondamentale per chi si occupa di sicurezza informatica. Infatti è di alta qualità, autorevole e ampiamente riconosciuto. Oltre a ciò, su di esso si basa il porgramma STAR, una sorta di certificazione dei servizi cloud.

Ringrazio Antonio Salis di Engineering per avermi segnalato la novità.

Antonio mi segnala che hanno anche pubblicato due ulteriori documenti:
- Enterprise Architecture CCM Mapping (sulla versione 3.0.1): https://cloudsecurityalliance.org/artifacts/enterprise-architecture-ccm-v301-mapping;
- Enterprise Architecture CCM Shared Responsibility Model:
https://cloudsecurityalliance.org/artifacts/enterprise-architecture-ccm-shared-responsibility-model/.

Cito la email di Antonio Salis: "Questi propongono una mappatura dei controlli CCM secondo un modello di responsabilità condivisa per IaaS, PaaS e SaaS. Vorrebbero dare una vista delle responsabilità lato cloud con il dominio di controllo specifico (per il cloud provider o per il cloud user). Forse per evitare di aggiungere altre colonne al CCM e renderlo ancor più difficile da consultare, hanno gemmato due documenti, ma il risultato non è un esempio di chiarezza". Condivido.

Sugli schemi di certificazione per GDPR

Fabio Guasconi ha tenuto un interessante webinar il 12 gennaio per il Clusit e Osservatori (ringrazio poi Franco Vincenzo Ferrari di DNV GL per avermelo ricordato):
- https://www.osservatori.net/it/eventi/on-demand/webinar/isoiec-27701-certificazione-gdpr-approccio-oggi-domani-webinar.

L'evento è a pagamento. Io mi permetto solo di segnalare due cose che mi erano sfuggite sui lavori di standardizzazione per gli schemi di certificazioni previsti dal GDPR.

In poche parole, a livello CEN, ossia europeo, sono in discussione due standard per la certificazione prevista dal GDPR:
- uno basato sulla ISO/IEC 27701, che prevede un suo "raffinamento" per poterla usare con la ISO/IEC 17065 (come previsto dal GDPR) in ambito europeo;
- uno che prevede un nuovo standard basato sull'italiana PdR 43-2, non più limitata all'ambito ICT e più orientata alle PMI.

La previsione è di finire i lavori entro fine 2021. Poi, ovviamente, bisognerà vedere come saranno recepiti dall'EDPB, visto che questi sarebbero gli standard per le organizzazioni da certificare, ma vanno ancora creati gli schemi di certificazione con le caratteristiche degli organismi di certificazione e le modalità per verificare se gli organismi hanno le caratteristiche previste, le competenze richieste agli auditor, il calcolo dei tempi di audit, eccetera.

Microsoft Teams (e non solo) e la privacy

Glauco Rampogna degli Idraulici della privacy mi ha segnalato questo articolo dal titolo, un po' lungo, "I looked at all the ways Microsoft Teams tracks users and my head is spinning":
- https://www.zdnet.com/article/i-looked-at-all-the-ways-microsoft-teams-tracks-users-and-my-head-is-spinning/.

L'articolo è forse troppo emotivo, ma pone due problemi importanti. Il primo è quello della privacy e del controllo a distanza dei lavoratori. Dovrei capire meglio se e come le funzionalità di monitoraggio possano essere messe a disposizione dei manager, però dovrò approfondire la questione, visti gli impatti sulla privacy.

Il secondo tema è quello delle tecniche gestionali, che vorrebbero, erroneamente, essere quantitative. Come si chiede l'autore, il numero di messaggi inviati è veramente sintomo di una buona produttività (e, aggiungerei, non di inutile spreco di risorse)? Purtroppo il mito del management by objective continua a sopravvivere, nonostante fosse già stato criticato negli anni Quaranta da Deming (non un tizio qualsiasi).

Ovviamente le stesse considerazioni valgono per tutti questi strumenti che da una parte aiutano i lavoratori e le organizzazioni, ma dall'altra mettono a disposizione strumenti per controllare i lavoratori stessi.

Libro su sicurezza delle informazioni e GDPR

Chiara Ponti e Renato Castroreale pubblicheranno (a febbraio) un libro dal titolo "Il sistema integrato per la sicurezza delle informazioni ed il GDPR":
- https://www.epc.it/Prodotto/Editoria/Libri/Il-sistema-integrato-per-la-SICUREZZA-delle-INFORMAZIONI-ed-il-GDPR/4909.

Mi hanno chiesto di scrivere la presentazione e io l'ho fatto molto volentieri. Il testo, infatti, tratta di un argomento fondamentale, ossia, come dice il titolo, dell'integrazione delle attività relative alla sicurezza delle informazioni e al GDPR. Oggi sempre più organizzazioni stanno seguendo questo approccio, ma ancora troppe separano quasi completamente le due materie, spesso affidando la prima ai tecnici e la seconda ai legali, senza capire le tantissime relazioni reciproche e la necessità di avere un approccio interdisciplinare in ambedue.

A questo proposito ho ricordato come queste materie permettono di avere grandi soddisfazioni, soprattutto perché: 1) si ha l'opportunità di conoscere persone validissime e molto professionali con esperienze e competenze diverse; 2) questa diversità ci richiede di approfondire il rapporto; 3) alcune volte questo approfondimento sfocia nell'amicizia.

Concludo quindi ringraziando Chiara e Renato per avermi dato l'opportunità di riflettere su queste cose.

Password manager

Segnalo questo articolo dal titolo "Gestione delle credenziali: un'analisi comparativa dei principali strumenti di Password Management":
- https://www.ictsecuritymagazine.com/articoli/gestione-delle-credenziali-una-comparazione-tra-i-principali-strumenti-di-password-management/.

Mi accorgo di non aver mai scritto alcunché sui password manager, ma sono strumenti oggi essenziali per gestire qualunque ambiente e pertanto vanno conosciuti.

Analisi dei vulnerability scanner

Segnalo questo articolo dal titolo "I migliori scanner di vulnerabilità per valutare la sicurezza di un'applicazione Web?":
https://www.ictsecuritymagazine.com/articoli/i-migliori-scanner-di-vulnerabilita-per-valutare-la-sicurezza-di-unapplicazione-web/.

Il titolo è forse più pretenzioso di quanto è il contenuto reale dell'articolo. Però è molto interessante vedere come nessuno dei 7 strumenti di scansione delle vulnerabilità analizzati abbia identificato tutte le vulnerabilità.

Mi sembra che forse altri strumenti avrebbero potuto essere analizzati (i più noti sono Nessus e OpenVAS), ma mi sembra che l'analisi non avesse ambizioni di completezza, essendo stata condotta nell'ambito di una tesi universitaria.

Attacco a Leonardo S.p.A.

A dicembre è stato identificato un attacco a Leonardo S.p.A., azienda italiana parzialmente pubblica e presente su molti progetti, inclusi quelli di difesa.

Glauco Ramponga degli Idraulici della privacy mi ha fatto inviato un buon link:
- https://reaqta.com/2021/01/fujinama-analysis-leonardo-spa/.

Ecco il super-riassunto di Glauco, che ringrazio.
ReaQta Threat Intelligence Team ha identificato il malware utilizzato in un'operazione di esfiltrazione contro Leonardo Spa. L'analisi del malware, che hanno soprannominato Fujinama, ne evidenzia le capacità di furto ed esfiltrazione dei dati mantenendo un profilo ragionevolmente basso, nonostante la mancanza di sofisticazione, principalmente a causa del fatto che il vettore dannoso è stato installato manualmente da un insider.

Quindi il punto chiave è che si sia avverato il caso peggiore: un interno, con responsabilità nella sicurezza informatica, ha installato software dannoso nella rete che avrebbe dovuto proteggere.

Sandro Sanna mi aveva inviato un ulteriore link che riporta la notizia dell'arresto di due possibili responsabili, che avevano l'obiettivo di reperire informazioni relative ad un preciso progetto:
- https://www.startmag.it/innovazione/neuron-ecco-il-vero-bersaglio-dellattacco-hacker-a-leonardo/.

Ricordo che uno dei rischi delle valutazioni del rischio è la cosiddetta sindrome di Fort Apache: si pensa che i "cattivi" siano tutti fuori, mentre dentro ci sono solo i "buoni". Questo caso, veramente significativo, ci ricorda di stare molto attenti.

Sintesi dell'attacco SolarWinds

Per capire bene il caso SolarWinds raccomando l'articolo di Bruce Schneier:
- https://www.schneier.com/blog/archives/2020/12/russias-solarwinds-attack.html.

La prima parte descrive in modo estremamente sintetico, da uno dei più noti esperti di sicurezza informatica (che scrive anche benissimo, cosa molto rara) il caso.

La seconda parte è forse più "strategica" e per me meno interessante.

EU National capabilities assessment framework

Claudio Sartor (lo ringrazio) mi ha segnalato il "National capabilities assessment framework" di ENISA:
- https://www.enisa.europa.eu/publications/national-capabilities-assessment-framework.

Mi astengo dal commentarlo perché finora mi sono occupato di sicurezza per organizzazioni private o pubbliche, non a livello nazionale. Però credo che possa essere di interesse per molti.

In particolare, noto che il livello di maturità non è determinato dalla quantità di documentazione prodotta e questo mi sembra un approccio migliore rispetto ad altre pubblicazioni del genere.

EU Cloud Certification Scheme

Enisa ha avviato la consultazione pubblica per lo schema di certificazione di sicurezza informatica per i servizi cloud (ringrazio Giovanni Francescutti di DNV GL Business Assurance e Giancarlo Caroti di Neumus per avermelo segnalato):
- https://www.enisa.europa.eu/news/enisa-news/cloud-certification-scheme.

Ricordo brevemente che questo schema nasce per le certificazioni promosse dal Cybersecurity act europeo. Questo Regolamento prevede quindi che ENISA proponga degli schemi di certificazione per la sicurezza dei prodotti e servizi informatici. Alcuni schemi sono già attivi (il più celebre è quello noto come Common Criteria, ISO/IEC 15408), ma non sotto il cappello del Cybersecurity act. Ad ora l'unico schema candidato e ufficiale e proprio questo per i servizi cloud.

Va detto che lo schema non necessariamente si baserà sul modello già noto per le certificazioni dei sistemi di gestione (ISO/IEC 27001, per intenderci), ma richiede che ogni Stato membro indichi una NCCA (National cybersecurity certification authority). Non mi risulta che in Italia sia stata ancora indicata. Se però qualcuno ha notizie più aggiornate, gli chiedo di farmele avere.

Per quanto riguarda questa bozza, ho analizzato soprattutto l'Annex A, con i requisiti che devono rispettare i CSP (cloud service provider) che intendono certificarsi. In generale mi sembra scritto male, con molte imprecisioni, ripetizioni e anche cose decisamente discutibili. Vale comunque la pena leggerselo e studiarselo per avere una buona idea dei requisiti che dovrebbero rispettare i CSP.

Spero poi che la versione finale del documento sarà molto migliore di questa bozza.

A questo proposito rimango perplesso su una consultazione pubblica di un documento che ha molti punti dichiaratamente ancora in fase di elaborazione (vedi Annex E e G).

Per quanto riguarda le modalità di verifica, ho letto le appendici senza la dovuta attenzione e quindi è meglio che mi astengo dal commentarle.

DFA Open Day 2021

Il 29 gennaio pomeriggio ci sarà il DFA Open Day:
- http://www.perfezionisti.it/open-day/dfa-open-day-2021/.

DFA è un'associazione che raccoglie consulenti, legali, esperti di privacy e tecnici di digital forensics. Ne sono presidente da 2 anni e sono molto contento di questa edizione. Spero parteciperete numerosi.

Io non tengo nessun intervento (tranne uno sconnesso balbettio che sono costretto a fare in virtù del mio ruolo): sarà molto più interessante ascoltare quelli degli altri.

Dig.eat 2021

Parteciperò al Dig.eat 2021 con una breve relazione sulla storia degli standard e della normativa in materia di sicurezza delle informazioni.

Il Dig.eat sarà dal 18 gennaio al 12 febbraio e il mio intervento sarà proprio il 18 gennaio (ore 15). In apertura, quando la gente non avrà ancora ben capito che è partita l'iniziativa.

Mi sono divertito molto a fare il messaggio di invito (ne avevo fatti 3 ed era previsto che ne selezionassero uno... invece...):
- https://www.linkedin.com/posts/anorc_digeat2021-digitalizzazione-activity-6749980650977144832-sCdZ.

Per iscriversi:
- https://anorc.eu/dig-eat/.

Difetto: per vedere il programma della manifestazione è necessario iscriversi.

Lezioni dall'attacco SolarWinds

A inizio dicembre è stato individuato un attacco verso il software SolarWinds Orion, usato per la gestione delle reti. Questo software è usato in molte realtà, in particolare presso i fornitori di servizi di sicurezza. La sua compromissione ha permesso agli attaccanti di creare backdoor presso gli utilizzatori. Sembra poi che forse altri software e servizi, non solo SolarWinds Orion, sono stati compromessi.

Il mio riassunto è molto sintetico. Questo, in inglese, è un po' più approfondito, anche se non troppo:
- https://www.darkreading.com/5-key-takeaways-from-the-solarwinds-breach/d/d-id/1339764.

L'articolo che ho segnalato permette anche di individuare utili lezioni per tutti. Infatti, quando sono venuto a conoscenza dell'attacco, ho inizialmente pensato che fosse importante, ma dimostrava solo che anche i prodotti di sicurezza possono essere anch'essi vettori di attacco, ma questo lo sapevamo già da parecchio tempo. Invece, ecco qui due delle lezioni proposte:
- gli strumenti di sicurezza e di gestione dei sistemi e della rete informatica non dovrebbero essere tutti integrati in un'unica piattaforma;
- gli ambienti di sviluppo, non solo quelli di produzione, vanno considerati critici per la sicurezza (ma anche questo lo sapevamo già).

Privacy: nuova pagina del Garante per notificare le violazioni

Il Garante lancia un nuovo servizio online per la notifica di violazioni di dati personali:
- https://servizi.gpdp.it/databreach/s/.

Interessante non solo la semplificazione della procedura (grazie al personale del Garante, che dimostra sempre più, con il passare degli anni, di sapersi interfacciare con le parti interessate), ma anche la procedura di auto-valutazione.

ENISA Artificial Intelligence Cybersecurity Challenges

ENISA ha pubblicato il documento "AI cybersecurity challenges" (grazie a Chiara Ponti degli Idraulici della privacy):
- https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges.

Non avevo mai parlato di intelligenza artificiale perché è una materia che ignoravo completamente. Adesso ne so qualcosa in più perché sto partecipando (come correttore di bozze, vista la mia incompetenza) a un libro in materia che uscirà a marzo. Così adesso ne so un pochino, almeno per evitare di annaspare quando vedo l'acronimo IA (o AI) al di fuori dei film e dei libri di fantascienza.

Devo dire, con sollievo, che gli autori della nostra pubblicazione avevano già considerato i punti presentati da ENISA. Anzi, in alcuni casi forse ENISA va troppo nei dettagli e ogni tanto si rischia di perdere di vista l'obiettivo dell'analisi. Però ci sono cose molto interessanti e ne raccomando la lettura.

GDPR e linee guida per lo sviluppo del CNIL

Pietro Calorio degli Idraulici della privacy mi ha segnalato la pubblicazione del "GDPR Guida per sviluppatori: La CNIL pubblica una GDPR guida per sviluppatori". Essa è la traduzione italiana della guida che avevo già commentato a giugno:
- http://blog.cesaregallotti.it/2020/06/gdpr-developers-guide-del-cnil.html.

Per chi volesse la versione originale in francese, in versione 1.0.1, è su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

Le recenti versioni in inglese e in italiano sono anch'esse su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

L'attuale versione è decisamente molto migliore di quella che avevo letto a giugno. Ancora una volta sono accennati molti elementi per la sicurezza dello sviluppo e delle applicazioni e quindi le persone interessate dovrebbero approfondirli con i link messi a disposizione. E', insomma, una lettura che raccomando.

La guida è molto concentrata sul processo di sviluppo e sulla sicurezza dell'ambiente di sviluppo, mentre i requisiti (funzionali e tecnici) da considerare per le applicazioni sono molto pochi. Speriamo nelle prossime versioni.

Webinar sulle nuove regole per i conservatori

Di conservazione e delle nuove regole pubblicate da AgID avevo parlato a suo tempo:
- http://blog.cesaregallotti.it/2020/09/nuove-linee-guida-agid-sulla-gestione.html.

Segnalo quindi questo webinar organizzato da ANORC in cui sono approfonditi alcuni aspetti:
- https://www.youtube.com/watch?v=_E-gUQS1e_M.

Segnalo in particolare il secondo intervento di Patrizia Gentili di AgID, dal minuto 44 al minuto 125, perché permette di capire le scelte fatte per le nuove regole.

Privacy e videosorveglianza: FAQ del Garante

Il Garante ha aggiornato le sue FAQ sulla videosorveglianza per adeguarle alle linee guida dell'EDPB.

Per completezza, qui segnalo l'URL della pagina del Garante sulla videosorveglianza da dove si può accedere alle FAQ (e ad altre risorse):
- https://www.garanteprivacy.it/temi/videosorveglianza.

Delle linee guida dell'EDPB avevo scritto quando furono pubblicate (febbraio 2020):
- http://blog.cesaregallotti.it/2020/02/linee-guida-edpb-su-videosorveglianza.html.

Ringrazio Franco Vincenzo Ferrari del DNV GL per la segnalazione.

ISO/IEC 27035 sugli incidenti ICT

A settembre è stata pubblicata la norma ISO/IEC 27035-3 dal titolo "Information technology — Information security incident management — Part 3: Guidelines for ICT incident response operations":
- https://www.iso.org/standard/74033.html.

Questa norma, rispetto alle altre 2 parti della ISO/IEC 27035, si concentra sulla gestione degli incidenti di tipo informatico.

Ci sono cose interessanti, per esempio sulle attività di analisi e sulle diverse possibili reazioni. Però la norma è molto confusa e gli argomenti sono organizzati malissimo, con molte ripetizioni e incongruenze. Peccato.

Privacy: sui cookie wall (seconda puntata)

Continuo a occuparmi delle modalità con cui i siti web gestiscono i cookie. Questo articolo, dal titolo "Cookie: consenso dell'interessato al legittimo interesse del Titolare" tratta della pratica, ora sempre più diffusa, di installare cookie sulla base del legittimo interesse e non del consenso:
- https://www.altalex.com/documents/news/2020/12/03/cookie-consenso-interessato-legittimo-interesse-titolare.

Io aggiungo che molti siti distribuiscono in modo a me incomprensibile le opzioni sui cookie: in parte sul consenso, in parte sul legittimo interesse. Forse per confondere l'utente o per altri motivi che non ho approfondito?

Aggiungo inoltre che, in caso di diniego del consenso, il cookie wall mi si ripresenta ogni volta che ritorno su certi siti. Cosa che non succede a chi fornisce un consenso positivo. Penso che anche questa sia una pratica scorretta.

L'articolo mi è stato segnalato da Costanza Mottino degli Idraulici della privacy e la ringrazio.

La privacy ai tempi del COVID - Un piccolo caso

Segnalo questo "piccolo" incidente per cui è stato mandato un reclamo (o una segnalazione di violazione) al Garante.

Penso sia interessante per ricordarci come la privacy richieda attenzione anche nelle cose apparentemente più semplici.

In una scuola un bambino ha segnalato la propria positività al COVID. Allora la scuola ha fatto una comunicazione in bacheca raccomandando a tutti i suoi compagni di classe di fare il tampone e fornendo indicazioni su dove andare.

Però... la circolare in bacheca riportava i destinatari: tutti gli alunni della classe, tranne il positivo!

Guida (parziale) alla privacy nel mondo

Claudio Sartor, che ringrazio, mi ha scritto quanto segue.

Ho letto il suo articolo in merito alle raccomandazioni dell'EDPB per i trasferimenti extra SEE (http://blog.cesaregallotti.it/2020/11/privacy-e-edpb-raccomandazioni-per-i.html). Sebbene al momento anche io non sia al corrente di un sito contenente "tutti i 200 Paesi del mondo con indicate le caratteristiche da considerare quando vi si vogliono esportare dati personali", segnalo il lavoro "Deloitte Asia Pacific Privacy Guide" che almeno indirizza l'area Asia Pacific (APAC):
- https://www2.deloitte.com/nz/en/pages/risk/articles/deloitte-asia-pacific-privacy-guide.html.

In effetti il documento è molto interessante, anche se forse è troppo prudente nell'esplicitare le criticità relative alla privacy e presenti nei Paesi considerati.

ENISA Guidelines for Securing the IoT

ENISA ha pubblicato nuove linee guida sulla sicurezza dell'IoT dal titolo "Guidelines for Securing the Internet of Things":
- https://www.enisa.europa.eu/publications/guidelines-for-securing-the-internet-of-things.

Introduce alcuni concetti che mancavano dalla precedente "Good practices for security of IoT: Secure Software Development Lifecycle", dedicata al solo software e che segnalai a suo tempo
(http://blog.cesaregallotti.it/2019/11/enisa-good-practices-for-security-of-iot.html). Questa guida tratta di tutti componenti dell'IoT, inclusi quelli fisici.

Commento: apprezzo molto questi lavori di ENISA. Purtroppo però l'organizzazione dei documenti di ENISA rende difficile capire i collegamenti tra loro e questo è un peccato.

Privacy e EDPB: Linee guida sulla privacy by design e by default

Mi hanno segnalato la pubblicazione della versione 2.0 delle "Guidelines 4/2019 on Article 25: Data Protection by Design and by Default":
- https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en.

La lettura è molto interessante e in qualche modo riassume efficacemente molti concetti del GDPR. Però attenzione che non si tratta di una guida alle misure di sicurezza. Queste sono trattate in modo molto sommario e con un solo esempio al punto 3.8 quando parla di integrità e riservatezza.

Un'altra cosa mi ha dato da pensare ed è il suggerimento di determinare KPI per valutare l'efficacia delle misure privacy. Qui l'EDPB, purtroppo, dà ascolto ai cattedradici e promuove KPI quantitativi e qualitativi, senza però proporne di veramente significativi. Gli esempi per i quantitativi sono: percentuali di falsi positivi e falsi negativi (senza però dire di cosa), riduzione dei reclami, riduzione dei tempi di risposta agli interessati quando esercitano i propri diritti (notare che questi KPI sono dichiarati male, visto che le "riduzioni" sono obiettivi che, inoltre, oltre un certo limite, dovrebbero diventare "mantenimento"). Gli esempi per i qualitativi sono talmente generici che non aiutano molto. Però poi arriva la vera raccomandazione appropriata e applicabile: dimostrare le ragioni per cui le misure scelte si ritengono efficaci (ossia, traduco io, presentare una valutazione del rischio).

Infine: mi fa specie vedere che anche l'EDPB fa un uso inutile e scorretto di iniziali maiuscole, soprattutto quando il GDPR, da questo punto di vista, è corretto.

Comunque sia: raccomando la lettura di queste linee guida per la loro ottima sintesi (38 pagine, inclusive di copertina e indice), il rigore, la completezza e la pragmatica. Al di là delle mie insignificanti critiche, questo è un documento esemplare.

Privacy e EDPB: raccomandazioni per i trasferimenti extra SEE

L'EDPB ha messo in consultazione pubblica le raccomandazioni sui trasferimenti dei dati personali al di fuori dello SEE: "Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data":
- https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/recommendations-012020-measures-supplement-transfer_en.

Innanzi tutto ricordiamoci che non è ancora un documento ufficiale, ma in consultazione pubblica.

Non tratta solo del trasferimento dei dati negli USA, ma è un'opinione più generale. E sono generali anche le raccomandazioni, tra cui quella di verificare per bene la normativa del Paese importatore, e non sono forniti strumenti semplici da consultare. Ovviamente il sogno sarebbe un sito con tutti i 200 Paesi del mondo con indicate le caratteristiche da considerare quando vi si vogliono esportare dati personali. Devo dire che siamo ancora lontanissimi da questo sogno e organi come l'EDPB dovrebbero farsi carico di queste necessità, visto che non è pensabile che migliaia di aziende (e non parlo dei DPO, le cui competenze sono troppo spesso dubbie sulle basi e quindi non possiamo aspettarci molto quando si tratta di un argomento complesso come questo) si facciano le proprie analisi di adeguatezza così come suggerite.

Grazie a Glauco Rampogna degli Idraulici della privacy per la segnalazione.

Privacy: sui cookie wall

Segnalo questo interessante video di Pietro Calorio su LinkedIn su come funzionano (male) i cookie wall:
- https://www.linkedin.com/posts/pietrocalorio_privacy-dataprotection-eprivacy-activity-6732293325866504192-j1b5.

Il video è artigianale, ma fa vedere chiaramente come sono fatti male i cookie wall. Nella migliore delle ipotesi sono estenuanti per l'utente che li rifiuta. Ne sono testimone ogni volta che vado sui siti di Amazon e molti altri perché ogni volta mi chiedono di confermare le scelte (cosa che non fanno con chi accetta i loro cookie).

Furto di dati a causa di un server AWS mal configurato

La notizia, dal SANS NewsBites del 10 novembre, è che sono stati violati 24,4 GB di dati relativi a ospiti di hotel a causa di un AWS S3 bucket mal configurato:
- https://www.websiteplanet.com/blog/prestige-soft-breach-report/.

Sul SANS ricordano che sono disponibili linee guida per configurare in modo sicuro i server sul cloud. Quello del CIS specifico per AWS:
- https://www.cisecurity.org/blog/cis-benchmarks-september-2020-update/.

La stessa Amazon mette a disposizione strumenti e linee guida per la corretta configurazione e verifica dei server:
- https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html.

Non so esattamente quale errore di configurazione sia stato sfruttato, né so se è stato frutto di distrazione o di incompetenza. Vedo però che ancora molti sottovalutano l'importanza di una corretta configurazione dei server cloud. Allora è bene ripeterlo: la configurazione iniziale dei server cloud non è ottimale per la sicurezza e quindi vanno sempre previste attività di hardening e quindi chi si occupa di questi server deve avere (o acquisire) le necessarie competenze.

Allegati nocivi per email

Mi hanno fatto notare che gli incidenti informatici registrati dovuti ad allegati nocivi alle email hanno avuto come effetto la riconfigurazione di alcuni servizi.

Un buon esempio è la pagina di Actalis che elenca gli allegati vietati per il loro servizio PEC:
- https://www.actalis.it/news-eventi/tipi-di-file-che-non-e-possibile-allegare-ad-un-messaggio-pec.aspx.

MELANI Rapporto semestrale 2020/1

Melani è la Centrale d'annuncio e d'analisi per la sicurezza dell'informazione svizzera. Ogni 6 mesi pubblica un interessantissimo rapporto con indicati eventi, minacce e raccomandazioni relativi alla sicurezza informatico. Io sono estimatore di questo rapporto che ormai da molti anni si conferma pragmatico e preciso.

E' stato pubblicato il rapporto relativo al primo semestre 2020 ed è concentrato su come l'emergenza COVID-19 sia stata sfruttata da malintenzionati:
- https://www.melani.admin.ch/melani/it/home/dokumentation/rapporti/rapporti-di-situazione/rapporto-semestrale-2020-1.html.

Il bello di questo rapporto è che parla anche di molto altro.

Multa per smantellamento scorretto di data center

Lo smantellamento scorretto di un data centre può costare caro:
- https://www.linkedin.com/posts/nicola-vanin-b03a5451_datacenter-morganstanley-rischio-activity-6720715622830944256-XjGS.

Il post non fornisce i dettagli esatti (chi ha dato la multa e quale esattamente è stata la violazione), ma sono interessanti le considerazioni: più difficile della costruzione di un data centre è il suo smantellamento perché può comportare l'interruzione imprevista di attività. Quindi, prima di procedere, è necessario inventariare correttamente le risorse e le loro dipendenze.

Il modello Emmental per valutare gli eventi

Ho trovato divertente questa vignetta che presenta il modello Emmental per la difesa da COVID-19 (i nordamericani, ahinoi, dicono "Swiss cheese"):
- https://t.co/0vFX7vaHIS.

Mi sembra una bella rappresentazione del concetto di "difesa in profondità", per cui un solo livello di protezione non è sufficiente.

Ho poi cercato di approfondire la cosa e ho trovato questo articolo:
- https://blog.enterprisetraining.com/swiss-cheese-accident-causation-model/.

Ed ecco quali sono le lezioni che fornisce il modello Emmental:
- gli incidenti sono spesso causati dalla convergenza di più fattori;
- i fattori possono essere di molti tipi, dai comportamenti scorretti dei singoli a errori organizzativi;
- fattori molto importanti sono gli "errori latenti", che rimangono dormienti fino a quando non sono attivati da errori attivi;
- gli esseri omani sono inclini agli errori e quindi richiedono sistemi ben progettati e realizzati per prevenirli e mitigarli.

Ho letto un altro articolo dal titolo "Revisiting the Swiss cheese model of accidents":
- https://www.researchgate.net/publication/285486777_Revisiting_the_Swiss_Cheese_Model_of_Accidents.

Questo propone un'idea interessante: affinché si verifichi un incidente, devono verificarsi:
- difese inadeguate;
- comportamenti scorretti;
- precursori psicologici per i comportamenti scorretti;
- carenze organizzative (line management deficencies);
- decisioni errate della Direzione.

Sarebbero da approfondire i "precursori psicologici per i comportamenti scorretti".

Concludo sperando che qualcuno faccia (e me lo faccia vedere!) un disegno altrettanto bello di quello che ho segnalato inizialmente, ma dedicato alla sicurezza delle informazioni.

Guida NIST per la sicurezza dello storage

Il NIST ha pubblicato la SP 800-209 "Security Guidelines for Storage Infrastructure":
- https://csrc.nist.gov/publications/detail/sp/800-209/final.

E' un documento molto tecnico, ma utile a chiunque si occupa di sicurezza. Soprattutto dovrebbe essere noto a chi amministra gli le infrastrutture di storage (anche se queste persone sembrano solitamente disinteressate a documenti di questo tipo).

Lo stile di scrittura ISO

Sono molto attratto dalle regole di stile, non solo per ragioni professionali, ma anche per curiosità verso le regole necessarie alla nostra quotidianità (per esempio, sono un cultore de "Il saper vivere" di Donna Letizia). Quindi mi sono letto con molto piacere il "ISO house style" per la redazione degli standard:
- https://www.iso.org/ISO-house-style.html.

Al di là dei miei gusti personali, penso sia corretto usare questo riferimento per controllare meglio la scrittura dei propri documenti: uso delle maiuscole, delle abbreviazioni e degli acronimi, redazione della bibliografia, scrittura delle liste numerate e non numerate eccetera.

Imparare a imparare

Segnalo questo articolo di cui Anna Gallotti (mia sorella) è coautrice. Il titolo è "Imparare ad imparare: Fattori che permettono e facilitano il processo di apprendimento":
- http://share-coach.bmetrack.com/c/v?e=112EEA4&c=98BAC&t=0&l=3ADF5DA4&email=HuT9fCkN5V9LzXF31Fidn0kDNvJcItyC5mrjfCIPaW83Ih4P1WxctQ%3D%3D.

Credo ci siano cose molto interessanti e utili, soprattutto quando bisogna formare su qualità, sicurezza e privacy.

In particolare ho sottolineato questo passaggio: "Se è vero che ci sviluppiamo avventurandoci fuori dalla nostra zona di comfort, dovremmo stare attenti a non andare troppo oltre: l'apprendimento ottimale avviene quando ci troviamo alla giusta congiunzione tra sfida e competenza, dove non siamo appesantiti dall'ansia da una parte o dalla noia dall'altra". E quindi ripenso alle attività di formazione in cui ho fornito troppe tracce teoriche o troppi elementi lontani dalle competenze dei partecipanti.

Pubblicato il Regolamento in materia di perimetro di sicurezza nazionale cibernetica

E' stato pubblicato il DPCM 131 del 2020, "Regolamento in materia di perimetro di sicurezza nazionale cibernetica", come previsto dal DL 105 del 2019. Si trova (grazie a Glauco Rampogna degli Idraulici della privacy) sulla Gazzetta Ufficiale:

- https://www.gazzettaufficiale.it/eli/id/2020/10/21/20G00150/sg.

Come per il Regolamento NIS, richiede che alcuni ministeri (e la Presidenza del Consiglio dei ministri) individuino i "soggetti inclusi nel perimetro" e che poi questi rispettino misure di sicurezza, già previste dal DL 105 del 2019 (non mi risulta siano già state pubblicate).

Non c'è molto di più in questo DPCM. Mi lascia molto perplesso l'obbligo, per i soggetti inclusi nel perimetro, di trasmettere "l'architettura e la componentistica relative ai beni ICT" alla Presidenza del Consiglio dei ministri e al Ministero dello sviluppo economico. Infatti o queste informazioni sono critiche, e pertanto non è bene che siano diffuse, oppure un po' inutili, e pertanto si sta chiedendo un inutile e costoso lavoro burocatico ai soggetti (che dovrebbero spendere soldi ed energie in altri adempimenti).

Sull'uso improprio del termine "cibernetica": sbagliare è umano, mentre la perserveranza continua a lasciarmi sbigottito.

ENISA Threat Landscape 2020

Franco Vincenzo Ferrari di DNV GL mi ha segnalato la pubblicazione dell'ENISA Threat Landscape 2020:
- https://www.enisa.europa.eu/topics/threat-risk-management/threats-and-trends?tab=publications.

Come rendere complicate le cose: bisogna iniziare a leggere "The year in review", che fornisce una guida per orientarsi tra le altre 21 pubblicazioni. La pagina delle pubblicazioni, ovviamente, non le elenca in un ordine logico, ma casuale (per esempio il "The year in review" è presentato come penultimo documento e non come primo). Non è disponibile un unico file con tutti i documenti in ordine.

A questo punto ci metterò troppo tempo a consultarlo e non so se proseguirò nella lettura. Gli altri anni avevo apprezzato il lavoro fatto e quasi sicuramente lo farei anche quest'anno, ma non sopporto questa inutile prolissità e complicazione.

Azure Defender for IoT

Microsoft ha pubblicato una versione per "public review" del suo nuovo prodotto agentless per la sicurezza delle reti IoT e OT:
- https://techcommunity.microsoft.com/t5/microsoft-security-and/azure-defender-for-iot-is-now-in-public-preview/ba-p/1784329.

Non faccio pubblicità a prodotti o aziende, però questo prodotto mi sembra molto interessante. Forse ne esistono di analoghi, ma finora non ne avevo incontrati. Come minimo, vanno capite le funzionalità offerte.

Provvedimento verso l'Azienda Ospedaliera Cardarelli - Altre considerazioni

Avevo scritto sul Provvedimento verso l'AO Cardarelli:
- http://blog.cesaregallotti.it/2020/10/provvedimento-del-garante-verso.html.

Con Pierfrancesco Maistrello abbiamo ragionato ulteriormente su alcuni particolari.

Il primo riguarda la multa comminata al fornitore (ossia "responsabile", che però aveva insistito, scorrettamente, per essere identificato come titolare) di 60 mila Euro. Questa multa è più del triplo della cifra (17.135 Euro netti) con cui si era aggiudicato la gara, come ha trovato Pierfrancesco Maistrello sul portale della trasparenza dell'AO.

Quindi, sempre Pierfrancesco Maistrello, suggerisce la frase a effetto: "Se pensate di aver fatto un affare, ricordatevi che non considerare i rischi privacy vi può costare anche 3 volte quello che avete fatturato".

Inoltre conveniamo sul fatto che il ruolo di responsabile è generalmente più conveniente di un'autoinflitta titolarità.

In caso di mancata nomina (ossia di clausole contrattuali tra titolare e responsabile come da Art. 28 del GDPR), che fare? Dopo aver valutato se sia opportuno effettuare lo stesso il trattamento, è comunque opportuno ragionare operativamente "come se" si stesse operando da titolare, quindi ovviando alle mancanze del committente, soprattutto in tema di misure di sicurezza, oltre a segnalare l'anomalia al titolare vero e proprio.

Da parte mia noto che il rischio è solo citato, mentre la valutazione dell'adeguatezza delle misure segue più il principio per cui una violazione dimostra che le misure non sono adeguate. Non sembra che il Garante abbia chiesto una valutazione del rischio né che le aziende coinvolte l'abbiano presentata.

Pierfrancesco pensa che "la valutazione del rischio è un adempimento raro e la fanno solo i più virtuosi". Però, se non viene mai citata dai provvedimenti sanzionatori, almeno per segnalarne la mancanza, l'approccio basato sulla valutazione del rischio sarà ritenuto inutile. Nel Provvedimento verso Unicredit del dicembre 2018 (https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9076378) e in altri se ne fa un accenno, ma molto difficile da cogliere.

Ho guardato i recenti casi di violazione sul sito dell'EDPB e risulta solo un caso in cui l'autorità norvegese rileva che la valutazione del rischio non era stata ancora completata. Negli altri casi che ho guardato (due finlandesi e una danese), non è citata. Per contro, nel celebre caso della multa a British Airways (https://ico.org.uk/action-weve-taken/enforcement/british-airways/), mi sembra sia citata la valutazione del rischio (punto 6.22, parzialmente censurato) e quindi è chiaro che in questo caso l'approccio è considerato.

Purtroppo, infine, non sembra che vengano pubblicati i provvedimenti relativi ai data breach e senza sanzioni. Sarebbero interessanti da consultare per conoscere i casi positivi e poterli prendere come esempio.

NISTIR 8286 sull'integrazione tra Cybersecurity Enterprise Risk Management

Il NIST ha pubblicato il documento NISTIR 8286 "Integrating Cybersecurity and Enterprise Risk Management (ERM)":
- https://csrc.nist.gov/publications/detail/nistir/8286/final.

Stavo per classificarlo come "troppo verboso e senza elementi nuovi (incluso un calcolo del rischio "quantitativo" che quantitativo non è)".

Ma arrivato a pagina 55, ecco un esempio di "Notional Enterprise Risk Register": una tabella in cui sono elencati i rischi identificati, senza che siano esaustivi e con un calcolo semplicissimo per il livello di rischio ("Exposure rating").

Questo esempio ci mostra come una valutazione del rischio possa essere molto semplice, senza dover necessariamente usare software o calcoli complessi. Ovviamente ritengo scorretto l'approccio "non esaustivo" per l'identificazione dei rischi, ma penso sia utile considerare questo esempio.

Uso improprio di Excel e perdita di dati

Pietro Calorio degli Idraulici della privacy ha condiviso questa notizia:
- https://www.theguardian.com/politics/2020/oct/05/how-excel-may-have-caused-loss-of-16000-covid-tests-in-england.

Riassunto: la sanità inglese consolidava i dati dei test COVID-19 su un foglio Excel. Però Excel può trattare un massimo di un milione circa di righe (65mila nelle vecchie versioni). Il risultato è che molte righe sono state perse dal foglio usato.

Un bell'esempio di perdita di integrità.

Aggiornamento dei controlli NIST per la sicurezza IT nel manifatturiero

Il NIST ha aggiornato il proprio "Cybersecurity Framework Manufacturing" ed è alla versione 1.1:
- https://csrc.nist.gov/publications/detail/nistir/8183/rev-1/final.

Avrei preferito qualche approfondimento in più sulle specificità del settore manifatturiero (il cosiddetto OT) rispetto all'informatica cosiddetta d'ufficio, ma già questa pubblicazione è molto utile.

Guide to Business Continuity & Resilience di Protiviti

Protiviti ha pubblicato una "Guide to Business Continuity & Resilience":
- https://www.protiviti.com/US-en/business-continuity-faq.

Non mi ha pienamente soddisfatto perché non è abbastanza pragmatica (con esempi e modelli) per essere uno strumento veramente utile e spazia troppo tra argomenti di base e considerazioni avanzate per essere utile a chi la materia la conosce già. La struttura a domande e risposte rende poi il tutto poco chiaro.

Però ci sono alcune cose interessanti, in particolare per i settori considerati (servizi finanziari, sanità, informatica, commercio al dettaglio, energia, manifattura e pubblica amministrazione).

NIST Security and Privacy Controls - Un commento

Avevo segnalato poco tempo fa la pubblicazione dell'aggiornamento della SP 800-53 "Security and Privacy Controls for Information Systems and Organizations":
- http://blog.cesaregallotti.it/2020/09/nist-security-and-privacy-controls.html.

Giulio Boero l'ha letta più approfonditamente di quanto abbia fatto io e mi dice che forse l'aggiornamento di maggior rilievo rispetto alla precedente edizione è l'aggiunta di alcuni controlli volti a contrastare le nuove minacce, come p.e. quelli per la resilienza, la progettazione sicura dei sistemi, il governo della sicurezza e della privacy e della responsabilizzazione.

Giulio scrive: << Non mi piace (lo dichiaro apertamente a costo di attirarmi critiche accese) l'approccio alla protezione dei dati personali. Non è aggiungendo la parola "privacy" al titolo del documento, né tantomeno inserendo il termine "privacy" in ogni descrizione di controllo (anche in modo abbastanza opinabile) che si tratta di data protection. Confido nella sibillina frase del NIST, in coda ai punti "to do": "Control mappings to the Cybersecurity Framework and Privacy Framework (available soon)">>.

Provvedimento del Garante verso l'Azienda Ospedaliera Cardarelli di Napoli

Segnalo due provvedimenti del Garante tra loro correlati. Uno verso l'Azienda Ospedaliera Cardarelli di Napoli:
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9461168.

L'altro verso il fornitore della stessa AO:
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9461321.

Per un riassunto, si può vedere l'articolo nella newsletter del Garante del 30 settembre 2020:
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9461344.

Questa sentenze mi interessano perché sono sanzionati:
1- l'uso di informativa "troppo breve";
2- l'uso scorretto della base giuridica del consenso (in questo caso, direi, il consenso è stato usato per il principio "non si sa mai", ma questo non è lecito);
3- l'attribuzione al fornitore di ruolo di titolare, mentre invece è responsabile (purtroppo molti fornitori di servizi si impongono come titolari dei trattamenti, nonostante siano da considerare come responsabili);
4- l'assenza nella documentazione contrattuale delle clausole richieste dall'art. 28 del GDPR (pratica molto diffusa quando la "nomina a responsabile" è vista come cosa a parte rispetto al contratto, a mio parere anche per colpa dei consulenti privacy che troppo spesso cercano di affermarsi come "speciali" e scollegati dal resto delle attività dell'organizzazione);
5- la conseguente assenza di istruzioni dal titolare al responsabile per assicurare la sicurezza dei dati.

Notare infine che al titolare è stato ordinato di pagare una multa di 80 mila euro, mentre al responsabile, anche perché ha agito in modo non previsto dal GDPR, una multa di 60mila euro. Questo dovrebbe ricordare che imporsi come titolare non è sempre la scelta più opportuna.

Guida NSA per i prodotti di autenticazione a più fattori

NSA ha pubblicato una guida dal titolo "Selecting Secure Multi-factor Authentication Solutions":
- https://www.nsa.gov/News-Features/News-Stories/Article-View/Article/2356020/nsa-releases-cybersecurity-guidance-selecting-and-safely-using-multifactor-auth/.

E' sicuramente molto tecnica e le analisi non si concludono con un giudizio sintetico. Per questo va letta con molta attenzione.

Ricordo che il ricorso a strumenti di MFA è sempre più necessario, soprattutto (ma non solo!) per chi ha ampi privilegi sui sistemi e può accedervi da remoto. Purtroppo queste tecnologie sono ancora sottovalutate da molti.

Sentenza sul controllo genitori su cellulari e pc degli adolescenti

Si è diffusa in questi giorni la notizia della sentenza del Tribunale di Parma che dispone che spetta a entrambi i genitori monitorare con costanza smartphone e pc dei figli minorenni anche attraverso filtri di controllo. Ringrazio Luca de Grazia per avermi segnalato la notizia.

Un articolo di giornale:
- https://www.ilsole24ore.com/art/i-genitori-devono-controllare-smartphone-e-pc-figli-adolescenti-ADvHxLn.

Un articolo di stampo più legale:
- https://www.studiocataldi.it/articoli/39789-i-genitori-devono-controllare-pc-e-smartphone-dei-figli-adolescenti.asp.

Non penso che il monitoraggio costante sia una buona strategia educativa, né penso che sia compito di un tribunale imporre strategie educative. E comunque tutto ciò non rientra tra le mie competenze professionali (anche se fare il genitore è comunque una professione).

Mi sembra però una sentenza molto discutibile perché impone misure di monitoraggio (meno efficaci di quelle di prevenzione) e una forma di educazione volta ad abituare i giovani alla vigilanza continua. Roba tipica dei nostri tempi e che continuo a non condividere.

Linee guida EDPB su titolare e responsabile - Un commento

Avevo segnalato la pubblicazione delle linee guida EDPB su titolare e responsabile (http://blog.cesaregallotti.it/2020/09/linee-guida-edpb-su-titolare-e.html). Segnalo questo articolo più analitico:
- https://www.key4biz.it/titolari-contitolari-responsabili-cosa-indicano-le-nuove-linee-guida-edpb/322063/.

Libro sulla ISO 9001:2015

Un mio cliente (Cinzia Alberici di OCS Alberici) mi ha segnalato un buon libro per capire come funziona la ISO 9001:2015. Mi piace segnalarlo anche se dopo quasi 5 anni dalla pubblicazione. Il libro si intitola "UNI EN ISO 9001:2015: Linea guida operativa":
- https://www.edizionidelfaro.it/libro/uni-en-iso-90012015.

Si tratta di un libro molto pragmatico e utile. Forse la parte di pianificazione (in particolare la gestione del rischio relativo all'efficacia del sistema di gestione) è troppo poco approfondita, ma sicuramente questo è un ottimo libro per chi vuole iniziare a conoscere la ISO 9001, essenziale anche a chi si occupa di sicurezza delle informazioni e privacy (molti principi della qualità vanno applicati anche in questi ambiti).

Consenso e legittimo interesse

Ultimamente sto notando, insieme agli Idraulici della privacy, molti siti web che chiedono il consenso per gli interessi legittimi del titolare (in realtà questo viene proposto come possibile "opposizione al legittimo interesse").

Questi siti elencano delle finalità per cui è richiesto il "normale" consenso e poi delle finalità per cui è dichiarato l'interesse legittimo e per le quali è richiesto all'interessato di esprimere la propria volontà di opporsi (il tipico "opt-out" al legittimo interesse).

Ricordo che consenso e interesse legittimo sono due delle basi legali per cui un titolare può trattare i dati. Se la base legale per una certa finalità è l'interesse legittimo allora, ovviamente, non deve essere richiesto il consenso. Su questo, in effetti, il GDPR presenta due meccanismi tra loro potenzialmente in conflitto.

Esempi che ho recentemente verificato sono https://www.corriere.it/ (Italia), https://www.theguardian.com/international (UK) e https://www.computerweekly.com (USA).

Almeno in alcuni casi, concordo con Pietro Calorio degli Idraulici della privacy secondo cui questa è una pratica per nascondere alcune richieste di consenso e per rendere più difficile il rifiuto, visto che, per questi consensi al legittimo interesse, non viene mostrato il pulsante "rifiuta tutto", come invece succede per i consensi "normali". Queste piattaforme che permettono questo giochino non possono considerarsi privacy by design perché non consentono un trattamento corretto.

 Ringrazio ulteriormente Pietro per avermi segnalato un mio grande errore di interpretazione del GDPR (spero di aver corretto per bene).

Ospedale attaccato da ransomware e morte di una donna

La notizia è circolata in questi giorni. Sandro Sanna me l'ha segnalata per primo con questo articolo:
- https://www.repubblica.it/tecnologia/sicurezza/2020/09/18/news/germania_donna_muore_durante_attacco_ransomware_all_ospedale-267735262/.

E' sicuramente difficile immaginare, progettare e realizzare, per infrastrutture di questo tipo, un piano di continuità operativa che permetta di proseguire le attività critiche anche in assenza di sistemi informatici e di attacchi ransomware. Però non viene neanche citato e questo mi lascia molto perplesso.

Questo articolo, in inglese, mi sembra decisamente più approfondito del precedente:
- https://www.scmagazine.com/home/security-news/ransomware/lessons-from-the-ransomware-death-cyber-emergency-preparedness-critical/.

NIST Security and Privacy Controls

Il NIST ha pubblicato l'aggiornamento della SP 800-53 "Security and Privacy Controls for Information Systems and Organizations":
- https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final.

Si tratta di una lettura impegnativa, visto che i controlli sono descritti da pagina 35 a pagina 393. Va detto che sono presenti certe astrazioni, ma, rispetto ad altri, anche molte indicazioni pragmatiche.

Privacy accountability framework dell'ICO

Antonio Salis (ringrazio) mi ha segnalato l'Accountability framework dell'ICO (il Garante inglese):
- https://ico.org.uk/for-organisations/accountability-framework/introduction-to-the-accountability-framework/.

Devo dire che ad un approccio superficiale non è chiarissimo come usarlo, ma ecco qui:
- ci sono alcune pagine web (menu a sinistra) con spiegati gli aspetti da considerare, ognuno con dei "modi per soddisfare le aspettative" e delle domande a cui si dovrebbe rispondere "sì";
- in un'altra pagina (https://ico.org.uk/for-organisations/accountability-framework-self-assessment/) è possibile scaricare un Excel (Accountability tracker) in cui rispondere ai "modi per soddisfare le aspettative".

A me lascia perplesso: troppe domande che si concretizzano, in realtà, su poche cose e, sui punti meno ovvi, non presentano esempi o spiegazioni per i non addetti. Insomma, mi sembra un altro ennesimo modo di ripresentare il GDPR, senza però reale utilità. Non vorrei essere io troppo schizzinoso.

Nuove linee guida AgID sulla gestione dei documenti informatici

A inizio settembre AgID ha pubblicato una nuova edizione delle "Linee Guida sulla formazione, gestione e conservazione dei documenti informatici":
- https://trasparenza.agid.gov.it/archivio19_regolamenti_0_5385.html.

Ho cercato di capire la questione con Franco Vincenzo Ferrari di DNV GL. Grazie a lui, vi segnalo questo articolo che secondo me è il più chiaro e completo in merito ai cambiamenti intervenuti sulla materia, di interesse per il pubblico e per il privato:
https://www.agendadigitale.eu/documenti/conservazione-dei-documenti-ecco-tutte-le-regole-nelle-linee-guida-agid/.

Stato delle norme ISO/IEC 270xx - Settembre 2020

Si è appena concluso il 63mo meeting dell'ISO/IEC JTC 1 SC 27. Doveva essere a Varsavia, ma si è invece tenuto tutto in ambiente virtuale.

La delegazione italiana era composta da 7 persone, tra cui: Fabio Guasconi (Presidente, che ringrazio per avermi segnalato qualche errore in questo mio commento), Alessandro Cosenza e me stesso.

Ricordo che gli stati delle norme sono: WD - CD - DIS - FDIS - IS (pubblicazione).

Per quanto riguarda le norme del WG 1, non ci sono grosse novità. Mi limito, come al solito, ad indicare lo stato di avanzamento di alcune norme
- ISO/IEC 27002 (controlli di sicurezza): sono proseguiti i lavori e la norma è rimasta in stato CD e si spera di pubblicarla a ottobre 2021;
- ISO/IEC 27005 (sul risk management): sono proseguiti i lavori e la norma è rimasta in stato di CD; ancora una volta è oggetto di molte discussioni, e si spera di pubblicarla entro dicembre 2022 (due finale!);
- ISO/IEC 27013 (relazioni tra ISO/IEC 20000-1 e ISO/IEC 27001): sono proseguiti i lavori, passa in stato DIS e si spera di pubblicare entro dicembre 2021.

A breve verranno pubblicate le norme ISO/IC 27101 (sullo sviluppo di framework di cybersecurity) e 27022 (sui processi di sicurezza delle informazioni), ma non ne ho seguito i lavori.

La norma con i requisiti di accreditamento degli organismi di certificazione per svolgere gli audit ISO/IEC 27701 era denominata ISO/IEC 27558 e sarà sicuramente rinominata ISO/IEC 27006-2. Sarà pubblicata entro fine anno.

La ISO/IEC 27006-2 sarà una Technical specification. I lavori sono stati fatti molto in fretta al fine di regolamentare quanto prima un mercato potenzialmente molto vasto. Ci sono alcune cose che ho apprezzato, altre meno e altre ancora che saranno migliorate nelle future edizioni, ma per intanto abbiamo una buona norma per avviare le certificazioni ISO/IEC 27701 accreditate.

L'attuale ISO/IEC 27006 sarà numerata ISO/IEC 27006-1 e partiranno i lavori di revisione.

Per quanto riguarda le norme del WG 5 (privacy), segnalo:
- per la ISO/IEC 29134 (sulla PIA) è stato proposto un amendement, ma solo per questioni puramente formali (a mio parere scorrettamente, in quanto non è possibile fare più di 2 Amendement e già altre volte sono stati riscontrati errori sostanziali per cui non era più possibile produrre correzioni);
- ho partecipato, anche se troppo poco, alle interessantissime discussioni sulla norma ISO/IEC 27557 (che uscirà non prima di fine 2022) incentrata sul "rischio privacy organizzativo", distinguendo così tra valutazioni del rischio privacy per l'organizzazione e per gli interessati.

Per il WG 4, che si occupa di norme più tecniche, ho smesso di interessarmi a quelle sull'IoT perché non c'è un vero senso di direzione e i documenti finora prodotti sono troppo teorici. Da questo punto di vista, preferisco seguire, seppur da lontano, i lavori di ENISA.

Il prossimo meeting sarà ad aprile a Sanpietroburgo o nel cyberspazio, a seconda di come andrà l'emergenza COVID.

Pubblicato "Un piccolo libro sulla privacy, il GDPR e come attuarlo"

Si intitola proprio così: "Un piccolo libro sulla privacy, il GDPR e come attuarlo".

Lo trovate in formato digitale (consiglio il sito della piattaforma di auto-pubblicazione che abbiamo usato):
- https://store.streetlib.com/it/idraulici-della-privacy/un-piccolo-libro-sulla-privacy-il-gdpr-e-come-attuarlo.

In formato cartaceo (su un'altra piattaforma di auto-pubblicazione che abbiamo usato):
- https://www.lulu.com/it/shop/idraulici-della-privacy-/un-piccolo-libro-sulla-privacy-il-gdpr-e-come-attuarlo/paperback/product-m5gq84.html.

Qualcuno vuole leggere la quarta di copertina? Eccola: "Un libro breve e di taglio pratico (poca teoria, molti esempi) su come applicare il GDPR.

Gli Idraulici della privacy sono un gruppo selezionato di consulenti e  manager in ambito della protezione dei dati personali che quotidianamente si  sporcano le mani per affrontare, se serve anche con spirito da artigiani, le necessità dei propri clienti o colleghi. I membri del gruppo condividono le criticità che incontrano, propongono interpretazioni normative, si scambiano e raccontano esperienze ed elaborano chiavi di lettura sulle più varie e diverse tematiche privacy. Questo confronto costante permette al singolo professionista di arricchire le proprie conoscenze, gli strumenti e le soluzioni a sua disposizione per risolvere anche le situazioni più spinose.

Il ricavato di questo libro, completato nella prima metà del 2020 durante l'emergenza COVID-19, sarà devoluto in beneficenza".

I membri del gruppo (potete poi chiamarci per nome, come per i Beatles): Cesare Gallotti (curatore), Glauco Rampogna (revisore e curatore dell'epub), Stefania Algerio, Elia Barbujani, Fulvia Emegian, Pierfrancesco Maistrello, Ferruccio Militello, Nicola Nuti, Monica Perego, Manuel A. Salvi.

Pubblicata la IEC 62443-3-2 per la valutazione del rischio per i sistemi IACS (OT)

E' stata pubblicata a giugno 2020 la norma "Security for industrial automation and control systems - Part 3-2: Security risk assessment for system design":
- https://webstore.iec.ch/publication/30727.

Essa presenta i requisiti per una valutazione del rischio tecnica dei sistemi informatici industriali (normalmente indicati come OT, ma indicati dalla norma IACS).

Ricordo che la 62443 è divisa in più parti: la prima per i concetti generali, la seconda per i sistemi di gestione, la terza per i sistemi OT e la quarta per le singole componenti.

Trovo interessante l'approccio di questa 62443-3-2 perché richiede di suddividere opportunamente il sistema in sottosistemi, in modo da assicurarne coerenza.

Alcune zone da tenere separate sono: sistemi di business, IACS, sistemi di sicurezza fisica delle persone (safety), dispositivi connessi temporaneamente, i dispositivi wireless, i dispositivi connessi da reti esterne.

Decreto semplificazioni - aggiornamento

Avevo scritto del DL Semplificazioni:
- http://blog.cesaregallotti.it/2020/09/decreto-semplificazioni.html.

Il 10 settembre è stata approvata la conversione in Legge. Bisognerà quindi vedere se e come saranno confermate le misure che avevo segnalato.

Ulteriori riflessioni, quando sarà disponibile su Normattiva (www.normattiva.it) il testo definitivo o quando ci saranno articoli interessanti.

Linee guida EDPB su titolare e responsabile

L'EDPB ha adottato il 2 settembre le "Guidelines 07/2020 on the concepts of controller and processor in the GDPR":
-  https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/guidelines-072020-concepts-controller-and-processor_en.

Sono decisamente importanti e dovrebbero essere sotto mano ogni volta.

Ancora oggi trovo organizzazioni per cui i responsabili sono quelli interni, mentre queste linee guida, per esempio, dicono che il responsabile è un'entità distinta rispetto al titolare.

Al momento in cui scrivo non mi risulta che sia stata ancora preparata una traduzione in italiano.

Il 18 luglio avevo segnalato le linee guida del novembre 2019 sul medesimo argomento dell'EDPS, ma ritengo che queste siano più significative, almeno perché successive.

Decreto semplificazioni

Il 17 luglio è entrato in vigore il DL 76/2020, detto "DL Semplificazione". Ci sono molte novità in materia di informatica e per queste segnalo l'articolo dal titolo "DL semplificazione 2020 cambia la PA digitale: ecco come":
- https://www.agendadigitale.eu/cittadinanza-digitale/dl-semplificazione-2020-come-cambia-la-pa-digitale/.

Sempre su Agenda Digitale ci sono altri articoli di Manca su questa materia e ne raccomando la lettura a chi ne è interessato.

La cosa più significativa, per me, riguarda i conservatori di documenti (conservazione a lungo termine di documenti digitali). Per questo ho chiesto aiuto a Franco Vincenzo Ferrari di DNV GL che mi ha raccomandato questo articolo dal titolo "DL Semplificazioni e conservazione dei documenti informatici delle PA: cosa cambia":
- https://www.agendadigitale.eu/cittadinanza-digitale/dl-semplificazione-2020-come-cambia-la-pa-digitale/.

In materia di conservazione, mi pare che si possa riassumere la situazione attuale con questo capoverso: "La sostanza delle modifiche necessarie si avrà solo dopo due provvedimenti attuativi in capo ad AgID".

Per intanto io aspetterei di vedere come avverrà la conversione in Legge, visto che spesso questo passaggio porta modifiche significative. Se non erro, questo dovrà avvenire entro metà ottobre.

Analisi Microsoft sul lavoro da remoto

Segnalo questo interessante post di Nicola Vanin su LinkedIn, dove riassume i risultati di un'analisi interna di Microsoft presso il proprio personale in merito al lavoro da remoto (il cosiddetto "smart working"):
- https://www.linkedin.com/posts/nicola-vanin-b03a5451_microsoft-brutale-infinita-activity-6693148405046280192-BNPx.

Aggiungo solo che la ricerca completa di Microsoft si trova qui:
- https://insights.office.com/workplace-analytics/microsoft-analyzed-data-on-its-newly-remote-workforce/.

Chi sta trasmettendo ancora dati personali negli USA?

Segnalo un interessantissimo post di Nicola Vanin su LinkedIn dal titolo "Chi sta trasmettendo ancora dati personali negli USA?":
- https://www.linkedin.com/posts/nicola-vanin-b03a5451_trasmettendo-personali-usa-activity-6701723919822462976-FCHA.

Aggiungo che in effetti le linee guida di European Data Protection Board non aiutano (ancora) bene a capire. A luglio avevano promesso aggiornamenti e spero arrivino presto.

US Clean network program

Sandro Sanna mi ha segnalto alcuni articoli in merito all'US Clean network program.

Il primo è in Italiano e ha titolo "Trump firma il decreto che vieta TikTok e WeChat negli Stati Uniti":
http://amp.ilsole24ore.com/pagina/ADR3pLi.

Il secondo è la pagina sull'iniziativa The Clean Network dell'US Department of State, ovviamente favorevole all'iniziativa:
- https://www.state.gov/the-clean-network/.

Il terzo è molto critico sull'iniziativa e ha titolo "The Hidden, Dirty Secrets Behind the US Clean Network Program" (e mi si scusi, ma mi lascia starnito il fatto che l'autore abbia un nome che suona cinese; non metto in dubbio le sue competenze e la sua integrità, ma tutto suona assurdo):
- https://www.globaltimes.cn/content/1197211.shtml.

Pensavo di non aver nulla da dire in merito, anche perché non so nulla in merito. So solo che la guerra sul 5G non è tanto sulla sicurezza, ma economica (visto che ovviamente l'acquisto di apparati 5G fatti negli USA favorirebbe l'industria statunitense!) e che puntare il dito sui social e sugli IM cinesi non toglie i dubbi sui social e sugli IM statunitensi.

Ed è proprio su queste cose che ho un'idea strana nella testa: perché ci facciamo tante paranoie sulla sicurezza dei servizi cinesi (e anche a quelli italiani) e invece diamo tutti i nostri dati agli statuntensi? Le aziende usano sempre più i servizi pubblici e gratuiti, anche per scambiarsi dati molto critici, senza pensare a quanto questi siano oggetto di analisi da parte di soggetti non identificati. Ecco quindi che penso che dovremmo farci un "programma di pulizia informatica" anche in casa e in azienda. Ma non è per niente facile e forse, oggi, impossibile.

Foto del registro accessi (violazioni)

Mi dicono che un'associazione ha denunciato una violazione di dati personali (data breach) al Garante perché un socio ha fotografato il registro degli accessi.

Mi sembra che la decisione di inoltrare la notifica al Garante sia un po' eccessiva, ma sappiamo bene che la paura (ingiustificata, a mio parere, in questo caso) di sanzioni porta a questo e altro.

Però... io in questo vedo alcune piccole lezioni di sicurezza delle informazioni:
- suppongo che il registro fosse cartaceo e quindi questo ci ricorda che la sicurezza delle informazioni e la privacy non riguardano solo i dati digitali e quindi la cybersecurity, ma anche altri dati;
- in molte organizzazioni i registri degli accessi sono usati male, lasciati in mano alle persone che entrano e senza alcun controllo di quanto scrivono e delle successive uscite; in questi casi sarebbe opportuno riflettere sulla loro reale utilità;
- bisognerebbe riflettere sui tempi di conservazione anche per dati di questo tipo.

Requisiti per l'accreditamento degli OdC per le certificazioni GDPR

Il 29 luglio 2020, il Garante per la privacy ha approvato la delibera con titolo "Requisiti aggiuntivi di accreditamento degli organismi di certificazione":
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9445086.

Li ho letti molto superficialmente perché si tratta dei requisiti per gli organismi di certificazione e non per organizzazioni che intendono ottenere un "bollino GDPR". Certamente è utile e interessante sapere che si stanno facendo passi avanti verso l'attivazione di un meccanismo di certificazione, ma questa deve ancora avvenire.

Infatti mancano i "criteri approvati dal Garante o dal Comitato europeo per la protezione dei dati (di seguito "Comitato") in conformità dell'articolo 43, paragrafo 2, lettera b) e dell'articolo 42, paragrafo 5 del Regolamento", ossia i requisiti che devono rispettare i servizi (o i processi o i prodotti) da certificare.

Sottolineo che, con il testo sopra riportato, la Delibera ribadisce il fatto che i criteri devono essere approvati dal Garante o dall'EDPB, non da altre entità (p.e. Accredia, che su questo argomento ha già fatto un passo falso qualche tempo fa).

Quindi: a meno che non lavoriate per un organismo di certificazione, è inutile che vi agitiate. Ovviamente è utile tenere monitorata la situazione.

Ringrazio Monica Perego che, incurante della prossimità a Ferragosto, ha dato la notizia agli Idraulici della privacy il 13 agosto e a Franco Ferrari di DNV GL che invece me l'ha comunicata il 4 settembre.

Valutazione del rischio dei fornitori: strumento del NIST

Il NIST ha recentemente pubblicato il documento NISTIR 8272 "Impact Analysis Tool for Interdependent Cyber Supply Chain Risks":
- https://csrc.nist.gov/publications/detail/nistir/8272/final.

Il documento è accompagnato da un applicativo per Windows, Mac OS e Linux.

Non sono riuscito ad approfondire molto l'approccio perché dovrei soprattutto avere modo di usare lo strumento. Ad una prima lettura mi sembra valido, anche se ho sempre molte riserve quando si tratta di "tool per la valutazione del rischio".

Penso però che possa essere significativo per realtà di grandi dimensioni, coinvolte in numerosi progetti IT o con molti prodotti IT da acquistare e dove l'investimento nell'analisi permette di allocare correttamente le risorse per controllare il rischio; per realtà di piccole o medie dimensioni, dove analisi complesse non forniscono informazioni significative, è sicuramente consigliabile un approccio molto più snello, visto che è più semplice vedere dove il rischio è più elevato e quindi dove investire più risorse per controllarlo.

Invalidato il Privacy Shield - Parte 3 - Le FAQ dell'EDPB

L'EDPB (ossia l'organismo di cooperazione dei garanti privacy europei) ha pubblicato le FAQ sulla sentenza Schrems II, che pone molti limiti sui trasferimenti di dati personali negli USA:
- https://edpb.europa.eu/our-work-tools/our-documents/other/frequently-asked-questions-judgment-court-justice-european-union_en.

Grazie a Chiara Ponti degli Idraulici della privacy per aver condiviso il link.

Sicuramente i trasferimenti sotto Privacy shield non sono più validi. Anzi, sono illegali sin dal 16 luglio 2020.

Come ho già scritto, potrebbero essere usate le SCC (Standard contractual clauses o, in italiano, Clausole contrattuali tipo), ma anche quelle hanno dei problemi perché se la legislazione del Paese importatore non offre le garanzie legali presenti in Europa, un contratto tra privati non può migliorare la situazione. Stessa questione per le BCR (Binding corporate rules o, in italiano, norme vincolanti d'impresa).

Mi sembra che i capoversi fondamentali del documento dell'EDPB siano: "The EDPB is currently analysing the Court's judgment to determine the kind of supplementary measures that could be provided in addition to SCCs or BCRs, whether legal, technical or organisational measures, to transfer data to third countries where SCCs or BCRs will not provide the sufficient level of guarantees on their own. The EDPB is looking further into what these supplementary measures could consist of and will provide more guidance".

Traduco: se non sanno loro cosa fare per assicurare la validità delle SCC e BCR anche in Paesi con legislazione che non assicura un adeguato livello di protezione ai dati personali, io aspetto che lo sappiano e ce lo dicano.

Infine non mi pare dica niente sulle società di servizi informatici statunitensi che però assicurano l'uso di data center in Europa. E' sufficiente questa garanzia sull'uso di data center in Europa o no? Bisogna infatti dire che molti contratti con questi grandi fornitori di servizi IT non assicurano il completo rispetto della locazione geografica, come indicato dall'analisi di EDPS sui servizi Microsoft (che avevo già segnalato a suo tempo):
- https://edps.europa.eu/sites/edp/files/publication/20-07-02_edps_euis_microsoft_contract_investigation_en.html.

Un piccolo libro sulla privacy, il GDPR e come attuarlo

Speravo di pubblicare un libro sulla privacy prima della fine di luglio in modo da fornire una lettura per il mare ai più temerari. Purtroppo non ce l'ho fatta.

Il libro non è mio, ma degli Idraulici della privacy, di cui faccio parte. E' partito da una mia idea e io ho l'onere di pubblicarlo materialmente (lo farò su Streetlib, come il mio "Sicurezza delle informazioni"), ma è un prodotto collettivo.

Quindi questo messaggio è una forma di provino, come si chiamavano un tempo.

Il librino non produrrà niente di troppo originale, ma vuole essere decisamente pratico e indicare una strada per applicare il GDPR almeno nei casi più comuni. Io mi sono divertito molto a partecipare perché ho avuto modo di imparare cose che avevo trascurato o, in alcuni casi, capito male.

Infine, e questa è la cosa più importante, il ricavato andrà tutto in beneficenza. Il libro è nato durante la clausura e questa esperienza ci ha fatto capire che, se possiamo, dobbiamo aiutare chi ne ha bisogno. Non abbiamo ancora deciso a chi, ma lo decideremo tutti insieme.

Quindi: spero di potervi invitare ad acquistare il libro, disponibile in tutti i negozi online, in formato epub e pdf (e forse cartaceo) dai primi di agosto.

Invalidato il Privacy Shield - Parte 2

Sulla caduta del Privacy Shield avevo già scritto poco tempo fa.

Pierfrancesco Maistrello mi ha segnalato il sito di Schrems, ossia quello che ha provocato la caduta:
- https://noyb.eu/en/next-steps-eu-companies-faqs.

Qui si pongono molti problemi. Insomma, mentre alcuni dicono che è sufficiente usare le SCC o verificare se il fornitore assicura l'uso di server in Europa, perché, essendo società statunitensi, rientrano nel FISA 702 che è una della cause per cui il Privacy Shield è caduto.

Aggiungo che anche i servizi applicativi sono colpiti da questa sentenza: Salesforce, Hubspot, MailChimps, tutte le email su Google, Sharepoint e OneDrive, WeTransfer e così via. E penso che anche i servizi di Zoom, GoToMeeting e compagnia che ci hanno tenuto compagnia durante la clausura
siano colpiti.

Potrei sempre sbagliarmi.

Su Web Ius Law c'è un podcast con Alessandro Del Ninno:
- https://webradioiuslaw.it/speciale-adeguamento-privacy-tutto-quello-che-volevi-sapere-sulle-clausole-contrattuali-standard/.

Luca Bolognini e Giovanni Ziccardi hanno fatto un podcast di 90 minuti (grazie sempre a Pierfrancesco Maistrello per il link):
- https://zerodays.podbean.com/e/luca-bolognini-spiega-da-zero-il-caso-schrems-ii-e-il-trasferimento-dei-dati-allestero-nel-gdpr/.

Venerdì 24 alle 14 ci sarà un ulteriore podcast sempre con Luca Bolognini e Giovanni Ziccardi (non so come sarà accessibile dopo quella data):
- https://www.istitutoitalianoprivacy.it/2020/07/22/open-webinar-sugli-impatti-della-sentenza-della-corte-di-giustizia-ue-schrems-ii/.

Io purtroppo sono più un lettore che un ascoltatore e quindi non ho approfondito a sufficienza la questione. Spero che:
1- il Garante si esprima in merito per aiutare a capire e agire;
2- qualcuno scriva articoli significativi sulla questione (per il momento non ne ho visti, ma se qualcuno me li segnala gliene sarò grato).

Privacy: organismi di monitoraggio dei codici di condotta

Sandro Sanna mi ha segnalato il fatto che il Garante ha stabilito i requisiti di accreditamento degli organismi di monitoraggio dei codici di condotta:
- https://gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9432569.

Sandro nutre il timore che questi codici di condotta potrebbero poi essere utilizzati malamente come certi certificati.

Io penso che il rigore con cui opereranno gli Odm dipenderà da come il Garante li controllerà. Se sono controllati con superficialità dagli OdM, allora questi codici di condotta saranno applicati malamente.

Il mio timore è che le regole non prevedono un controllo molto significativo degli OdM: mi pare soprattutto di tipo documentale e non c'è alcun impegno in merito alle verifiche che il Garante si propone di fare sul campo, solo possibilità generiche nel caso emergano elementi che richiedono dei  controlli. Mi pare anche che manchino regole in merito alla gestione delle  non conformità rilevate dal Garante.

Io sono abituato alle regole degli organismi di certificazione dei sistemi  di gestione, quindi questo approccio mi lascia perplesso. Ma chissà che invece non sia più efficace.

Linee guida EDPS su titolare, responsabile e contitolare

Ricordavo la pubblicazione di Linee guida su titolare, responsabile e contitolare, ma non riuscivo più a trovarle. Poi ho scoperto il perché: pensavo fossero state pubblicate dall'EDPB o dal precedente WP 29, mentre erano state pubblicate dall'EDPS (ossia, per farla breve, dal DPO delle istituzioni europee).

Il documento ha titolo "EDPS Guidelines on the concepts of controller, processor and joint controllership" e si trova qui (in inglese, francese e tedesco):
- https://edps.europa.eu/data-protection/our-work/publications/guidelines/concepts-controller-processor-and-joint_en.

Inizialmente le avevo ignorate in quanto ovvie. Però poi ci si trova sempre davanti ai "casi particolari" e queste linee guida possono tornare utili.

Ringrazio Glauco Rampogna che le ha (ri)segnalate agli Idraulici della privacy.

Invalidato il Privacy Shield per i trasferimenti dei dati negli USA

Notizia importantissima, è l'invalidamento del Privacy Shield. Per trasferire i dati negli USA (principalmente per usare i grandi fornitori di servizi informatici o di supporto) era ritenuta adeguata l'adesione al Privacy Shield dell'organizzazione ricevente. Nel 2015 era già stato invalidato il protocollo Safe Harbour, predecessore del Privacy Shield.

La sentenza completa della Court of Justice of the European Union del 16 luglio 2020 è qui (grazie a Gianluca Dalla Riva degli Idraulici della privacy):
- https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62018CJ0311.

Il comunicato dell'EDPS conferma l'appoggio alla posizione presa, ma non illumina su cosa fare:
- https://edps.europa.eu/press-publications/press-news/press-releases/2020/edps-statement-following-court-justice-ruling-case_en.

Per capire cosa fare, si possono leggere i comunicati stampa della Corte stessa:
- Italiano: https://curia.europa.eu/jcms/jcms/p1_3117876/en/;
- Inglese: https://curia.europa.eu/jcms/jcms/p1_3117870/en/.

In sostanza: usare le clausole contrattuali tipo.

Ci vorrà del tempo prima che i fornitori di servizi informatici stabiliti negli USA adeguino le proprie condizioni contrattuali alle clausole contrattuali tipo (qualcuno mi aiuterà, spero, a capire perchè abbiano fatto tutto il pasticcio del Privacy Shield piuttosto che usare le clausole contrattuali tipo). Fino a quel momento non si potranno usare servizi siti negli USA.

Chi invece usa servizi gestiti dagli USA ma su server in Europa (ossia, se ha scelto l'opzione dei server in Europa per esempio per i servizi IaaS e PaaS di Google, AWS e Azure) dovrebbe essere già a posto, ma sono pronto a essere smentito.