giovedì 31 maggio 2018

5 luglio 2018: DFA open day su GDPR, digital forensics e altro

Il Programma del DFA Open Day del 5 luglio 2018 è online!
- http://www.perfezionisti.it/open-day/dfa-open-day-2018/.

Si parlerà di social engineering, digital forensics e deep web, social media e riconoscimenti, privacy e intelligenza artificiale e infine GDPR.

Poco GDPR? Beh... era ora si ricominciasse ad alzare lo sguardo anche ad altri argomenti.

DFA è l'associazione di cui sono (per puro caso) Presidente e mi farebbe tanto piacere che partecipiate numerosi. Organizziamo questo evento da anni ed è sempre stata un'occasione bellissima di incontri e discussioni tra esperti e "tecnici", senza alcuno spazio per i venditori di alcun genere (io sono presidente solo da pochi mesi e quindi il merito di tutta questa bellezza non è certo mio, ma dell'associazione nel suo complesso).

Per dire quanto il mio ruolo è immeritato, segnalo che quest'anno non ci sarò. I miei amici (professionisti che sono diventati miei amici negli anni) sanno sicuramente il perché :-)

GDPR e i ritardi dei "guru"

Scusate lo sfogo che segue.

Tutto nasce da questo post di Pizzetti su LinkedIn (segnalatomi dagli Idraulici della privact e anche da Fabrizio Morandi), molto critico sulle certificazioni privacy:
https://www.linkedin.com/feed/update/urn:li:activity:6407501108947886080.

Non posso fare altro che essere d'accordo con Pizzetti.

Personalmente dico le stesse cose (anche se peggio e meno autorevolmente) da anni. E chiunque aveva le competenze adeguate avrebbe dovuto dire da subito certe cose (da quando nel 2012 hanno cominciato a dire che il GDPR sarebbe stato approvato "domani", nel 2014 hanno promosso le "certificazioni DPO", nel 2016 le "certificazioni GDPR per le aziende").

E da ieri bisognava dire che non va chiesto il DPO (a norma di GDPR) in tutte le organizzazioni, non va fatta la PIA per ogni trattamento e non vanno inviate "nomine" a responsabile come se fossero spam.

Scusate lo sfogo, ma sono sicuro di non essere il solo che dice queste cose da anni (non sono particolarmente intelligente, competente o attento), ma la sensazione di esserlo c'è... E allora dove stanno tutti questi guru che non fanno chiarezza come dovrebbero? Forse troppo interessati a vendere corsi, consulenze o chissà che altro?

PS: avrei voluto tirare qualcosa a Modafferi quando in un intervento ha detto che per il Garante il Responsabile è sempre stato "esterno"... ma non ce lo hanno detto fino a pochi mesi fa. E chi in questi anni faceva notare che i requisiti del Codice erano incongruenti se applicabili a responsabili interni e esterni?

lunedì 28 maggio 2018

Rettifiche al GDPR

Sono state pubblicate le ultime rettifiche al GDPR. Per visualizzarle, si può ricercare nella pagina di Eur Lex:
https://eur-lex.europa.eu/homepage.html?locale=it.

Si tratta di correzioni, quindi nulla di sostanziale.

Il testo consolidato purtroppo non è ancora disponibile.

domenica 27 maggio 2018

Dlgs 51/2018 da Direttiva privacy 2016/680

Per chi si fosse dimenticato, il GDPR (numero 679 del 2016), regolamento "generale", era accompagnato da una Direttiva "specifica" per i dati trattati dalle "autorità competenti a fini di prevenzione, indagine, accertamento e perseguimento di reati o esecuzione di sanzioni penali".

È stato quindi pubblicato nella Gazzetta Ufficiale n. 119 del 24 maggio 2018 il decreto legislativo 18 maggio 2018, n. 51 che attua la direttiva UE 27 aprile 2016 n. 2016/680. Il D.Lgs. 51/2018 entrerà in vigore l'8 giugno 2018:
- http://www.gazzettaufficiale.it/eli/id/2018/05/24/18G00080/SG.

Ringrazio lo pseudoanonimizzato Idraulico della privacy NN per aver segnalato questa novità.

Privacy: bozza di "prassi" UNI per la certificazione GDPR

Fabio Guasconi mi segnala l'avvio della consultazione pubblica per una "Prassi di riferimento" (PdR) UNI relativa alla gestione della privacy:
- http://www.uni.com/index.php?option=com_content&view=article&id=7144:gestione-della-privacy-in-ambito-digitale-progetto-di-prassi-di-riferimento-ora-in-consultazione-pubblica&catid=171&Itemid=2612.

La PdR si compone di due parti. La prima è una "linea guida", ma è in sostanza un documento organizzato male, con molti errori anche tecnici (si parla di responsabili interni, tanto per intenderci). Nel caso migliore lo dichiarerei inutile.

La seconda parte (o "sezione") è invece importante perché si propone come riferimento per le certificazioni GDPR. Ho trovato qualche punto discutibile (mi fa ridere l'idea di "inventario ripetuto" e mi fa paura la descrizione dell'ambito con la descrizione dei dispositivi rimovibili), ma mi pare un buon prodotto.

Importante segnalare che questa PdR riguarderebbe il solo ambito ICT e quindi solo alcuni trattamenti o parti di essi.

Osservo che questa operazione è evidentemente la conseguenza della non felice storia italiana sulla "certificazione privacy", di cui scrissi a suo tempo:
- http://blog.cesaregallotti.it/2017/05/certificazioni-privacy-per-aziende-e-bs.html.

Ho il timore che venga fuori un'altra storia non felice. Infatti non mi risulta che il Garante abbia partecipato alla scrittura di questo documento e, se dovesse seguire il comportamento fin qui tenuto, non dovrebbe avallare uno schema nazionale, mentre Accredia vorrebbe avviare uno schema meno controverso di quello attuale. Vedremo, visto che le cose cambiano.

Per completezza segnalo che avevo chiesto di partecipare ai lavori (anche in quanto socio UNINFO), ma il promotore del gruppo di lavoro non ha voluto. Spero di non venire accusato di aver scritto dei giudizi spinto dalla delusione, ma di aver seguito lo stesso atteggiamento tenuto in altre occasioni.

Ultimissima nota: si tratta di bozze e come al solito ne sconsiglio la lettura a coloro che non hanno intenzione o che non hanno l'opportunità di partecipare attivamente alla consultazione.

sabato 26 maggio 2018

Security Development Lifecycle di Microsoft

Stefano Ramacciotti mi ha segnalato le pagine aggiornate di Microsoft sul Security Development Lifecycle di Microsoft.

La prima è il The Security Development Lifecycle Developer Starter Kit:
- https://www.microsoft.com/en-us/SDL/adopt/customsdltraining.aspx.

La seconda è il SDL process: Training:
- https://www.microsoft.com/en-us/SDL/process/training.aspx.

Credo di aver già, a suo tempo, segnalato il materiale MS sul SDL, sicuramente molto buono. Ora molto è cambiato in meglio e si trova molto materiale pratico, cosa sempre difficile da trovare (perché è facile dire "fate vulnerability test", meno capire con cosa).

Anche Stefano mi ha confermato di apprezzare l'approccio più pratico del sito rispetto al precedente.

Grazie a Stefano: finalmente qualcosa che non sia "GDPR"!!! Un po' di freschezza ci voleva...

venerdì 25 maggio 2018

25 maggio 2018: Privacy Spam Day

Non me lo aspettavo, ma il 25 maggio non è il "GDPR day", ma il "Privacy Spam Day":
  • tutti i clienti mi hanno inviato la loro email "noi abbiamo a cuore la tua privacy" (spesso di 6 o 7 pagine, quando convertita in un pdf formato A4);
  • tutti i mittenti di spam mi hanno chiesto di confermare la sottoscrizione al loro spam;
  • tanti editori di newsletter tecniche mi hanno chiesto di confermare la sottoscrizione alla loro newsletter;
  • tutti i clienti mi hanno inviato la loro "nomina a responsabile", inclusa la richiesta di nominare un DPO (spesso di 5 o 6 pagine e con un peso di almeno 2MB);
  • tutti i fornitori mi hanno inviato la loro "auto-nomina a responsabile", inclusa la richiesta di non chiedere troppi dettagli sulle loro misure di sicurezza, ma di fidarmi di loro e firmare il contratto.
Oggi ero da un cliente per risolvere i suoi ultimi dubbi e anche lui ha ricevuto tanto Privacy Spam.

E tutti i miei clienti hanno ricevuto Privacy Spam e me l'hanno inoltrato per chiedermi cosa fare di volta in volta.

Io ho anche avuto il tempo di scrivere un reclamo al Garante e qualcuno ha a sua volta inviato un reclamo al mio cliente (quello con cui stavo risolvendo gli ultimi dubbi).

E dimenticavo: tutti i miei contatti hanno scritto messaggi arguti sul GDPR (o inviato immagini) su Whatsapp, Facebook, LinkedIn e Twitter. Come sto facendo io adesso!

Quindi: buon Privacy Spam Day a tutti i miei amici, colleghi, contatti e follower!

mercoledì 23 maggio 2018

GDPR: Perché avere un DPO certificato (risposte)

Nel mio post dal titolo "GDPR: Perché avere un DPO certificato" (http://blog.cesaregallotti.it/2018/04/perche-avere-un-dpo-certificato.html), avevo ripetuto la domanda di Monica Perego: qual è il documento legislativo che stabilisce come la fornitura di un bene o la prestazione di un servizio, eseguita in conformità a norme UNI, CEI od equivalenti norme europee od internazionali, costituisce fornitura o prestazione a "regola d'arte"?

Alcuni mi hanno risposto (con toni anche accesi) che non esiste, per lo meno applicabile al DPO.

La risposta più interessante me l'ha inviata Mauro Caio di Emaze e la copio qui di seguito.

<< Il primo riferimento normativo che io ricordi e che ha spianato la strada alla legislazione in merito a Stato dell'arte e Norme (in quel caso CEI – Comitato Elettrotecnico Italiano) risale al 1968 (L. Legge 1 marzo 1968, n. 186). Il ricordo risale a quando ho avuto modo di partecipare ai lavori del CEI 64 (impianti elettrici) e 62-5 (apparecchiature elettromedicali).

Un buon link è https://www.certifico.com/news/22-news/news-generali/1956-regola-dell-arte-i
-riferimenti-normativi
>>.

Raccomando l'articolo perché è molto interessante, anche se applicabile ad altro contesto. Forse Biasiotti intendeva proprio quei "documenti legislativi", anche se non so (per ignoranza legale) quanto l'analogia possa reggere.

GDPR: qualche orrore (continuazione 01)

Dopo il mio post dal titolo "GDPR: qualche orrore" (http://blog.cesaregallotti.it/2018/05/gdpr-qualche-orrore.html), altri mi hanno segnalato delle chicche.

La prima è stata Miriam Carmassi (grazie!) direttamente sul mio blog: "tra gli orrori...dare data certa al registro dei trattamenti e al resto della documentazione predisposta mediante autoinvio per posta ordinaria... gli orrori del passato ritornano questa volta in nome del principio dell'accountability".

Aggiungo che io tutta questa accountability che permea il GDPR non la vedo. Il termine è usato solo una volta, ma la frase "l'accountability permea il  GDPR" è ormai diventata un classico. Le responsabilità erano comunque stabilite prima (anche se il termine "accountability" non appariva) e sono stabilite adesso e sono comunque materia importante.

Ultimo aggiornamento: un mio cliente (per un lavoro non correlato al GDPR, per il quale aveva già trovato un consulente) mi ha inviato via email, in quanto fornitore, un'informativa con richiesta di ritornare firmata. Come rendere dannoso un adempimento già non utile.

sabato 19 maggio 2018

GDPR: qualche orrore

A pochi giorni dall'entrata in vigore del GDPR, ovviamente le organizzazioni si stanno attrezzando (tantissime hanno aspettato l'ultimo mese!).

Gli orrori quindi si cominciano a vedere e si diffondono, dimostrando così quanto l'eccesso di entusiasmo o di isteria degli ultimi mesi o anni non abbiano fatto sempre bene. Molti esempi vengono anche da grandissime multinazionali, che evidentemente si sono affidate a consulenti dell'ultimo minuto e che hanno venduto loro soluzioni standard, per quanto sciocche esse siano.

Qui elenco qualche caso.

E alla fine fate come volete... ma non ditemi che la privacy è solo burocrazia inutile. Perché la burocrazia inutile se la sono voluta loro, non l'ha imposta il GDPR!

Rapporti con i dipendenti
Sono venuto a conoscenza di una nuova formula di "nomina ad incaricato". Visto che il GDPR non prevede "nomine" o "designazioni", qualcuno non ha voluto rinunciare (anche se poteva farlo sin dal Dlgs 196) al foglio di carta firmato singolarmente dal dipendente e gli ha messo il titolo di "designazione a persona autorizzata al trattamento dei dati personali".

La firma è anche richiesta quando sono inviate al personale le regole da seguire per assicurare la protezione dei dati personali. Io sono un promotore di tale regolamento, ma perché richiedere la firma per accettazione, quando per tutte le altre regole e procedure aziendali non è richiesta alcuna firma? Perché introdurre un processo "diverso"?

Ovviamente, è sempre in voga la richiesta di firma sull'informativa, anche se non richiesta. Alcuni, ahinoi, continuano anche a richiedere il consenso.

Credo che i dipendenti, in tutta la loro vita lavorativa, con l'eccezione del contratto di assunzione, firmino solo i documenti di "autorizzazione al trattamento dei dati personali", "regolamento per la protezione dei dati personali" e "informativa relativa al trattamento dei dati personali". Firma autografa, visto che siamo nel 2018...

Gestione dei fornitori
Si stanno diffondendo i questionari ai fornitori. Ma il GDPR non li richiede. Il GDPR richiede di stipulare contratti che impongano ai fornitori (responsabili del trattamento) l'attuazione di misure di sicurezza che il titolare ritiene adeguate.

Qualcuno mi dice che questi questionari servono a valutare il rischio del fornitore. Purtroppo è un'interpretazione sbagliata: il titolare deve valutare il rischio dei trattamenti, stabilire le misure "adeguate" e poi richiederne l'attuazione ai fornitori. Processo più logico di quello di inviare il  questionario, poi valutare il rischio, poi stabilire se il fornitore è adeguato, poi... poi cosa?

Se il fornitore non può accettare le clausole contrattuali, avvierà una negoziazione con il cliente, proponendo misure compensative, segnalando quelle non applicabili al trattamento affidato, eccetera. Forse questo è un processo troppo logico...

24 maggio: incontro del Garante

Il 24 maggio a Bologna è stato organizzato l'evento "Regolamento Ue. Il Garante incontra i Responsabili della Protezione dei Dati (RPD)":
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/7917099.

Io, grazie al solito Pierfrancesco Maistrello, mi ero iscritto per tempo.

Per chi fosse interessato, l'evento può essere seguito in streaming come riportato dalla pagina sopra indicata.

mercoledì 16 maggio 2018

Come è (im)possibile dimostrare che il proprio pc è stato compromesso

Da Crypto-Gram di maggio 2018: Micah Lee ha provato per 2 anni a trovare un metodo per verificare se il proprio pc portatile è stato compromesso. I risultati lasciano dei dubbi e dimostrano quanto sia  difficile verificare la  compromissione di un pc portatile:
https://theintercept.com/2018/04/28/computer-malware-tampering/.

Ancora una volta trovo conferma dell'impossibilità di avere certe misurazioni della sicurezza e valutazioni del rischio quantitative.

lunedì 14 maggio 2018

Traduzione ENISA handbook

Franco Vincenzo Ferrari di DNV GL Business Assurance mi ha segnalato la disponibilità di una traduzione in italiano dell'handbook di ENISA:
- https://www.amazon.it/clouddrive/share/ikQmbrXD7J6X2WlRXfqdXa3Cs10Mo2EqQlom5oWeUre?_encoding=UTF8&%2AVersion%2A=1&%2Aentries%2A=0&mgh=1.

Credo sia noto il mio apprezzamento per questa pubblicazione (anche se rileggendola con attenzione ho trovato qualche controllo che risente di un'impostazione teorica da torre di cristallo, ma si tratta di pochissimi casi).

Devo dire che il mio ego ha subito un tracollo: alcuni traduttori (con cui mi complimento) li conosco bene, ma non è da loro che mi è arrivata la notizia.

Direttiva NIS in vigore (ma non troppo)

La newsletter SANS Newsbites mi ha ricordato che il 10 maggio sarebbe dovuta entrare in vigore la Direttiva NIS (Networks and Information Systems).

In altre parole, i Paesi membri avrebbero dovuto approvare entro il 10 maggio una normativa nazionale (in Italia, un Decreto Legislativo) di recepimento della Direttiva. Non mi risulta che l'Italia l'abbia ancora fatto, anche se il Governo ha avuto la delega ad ottobre 2017 (ma sappiamo bene cose è successo nel nostro Paese da ottobre ad oggi).

La Direttiva riguarda gli adempimenti che alcuni erogatori di servizi essenziali (per esempio fornitura di elettricità, acqua, servizi sanitari e di trasporto passeggeri e merci) dovrebbero attuare per assicurare la sicurezza dei propri sistemi informatici.

Finita la sbornia da GDPR, molto dopo il 25 maggio, immagino, ci accorgeremo anche di questo adempimento.

Intanto possiamo studiarci la materia grazie agli... inglesi! Il National Cyber Security Centre ha infatti pubblicato una guida alla NIS:
- https://www.ncsc.gov.uk/guidance/nis-guidance-collection.

(Confesso che non ho capito se l'UK ha approvato un proprio provvedimento legislativo nazionale per recepire la Direttiva NIS, ma forse questo non è così importante).

Ius law web radio: Come stabilire le misure di sicurezza con la ISO/IEC 29151

Elia Barbujani di Ius law web radio mi ha intervistato su misure di sicurezza per la privacy e ISO/IEC 29115. La puntata (35 minuti) è qui:
- https://webradioiuslaw.it/speciale-adeguamento-privacy-come-stabilire-le-misure-di-sicurezza-secondo-la-iso29151/.

venerdì 11 maggio 2018

GDPR: Valutazione del rischio e PIA

Segnalo questo mio articolo su ICT Security Magazine dal titolo "Valutazione del rischio e PIA", sulle relazioni e le differenze tra valutazione del rischio relativo alla privacy e PIA:
- https://www.ictsecuritymagazine.com/articoli/valutazione-del-rischio-e-pia/.

GDPR: La mia lista

Fioccano in questi giorni le liste delle cose da fare per il GDPR.

Oggi vedo che finalmente in molti stanno "abbassando i toni", come in questo articolo (segnalatomi da Franco Vincenzo Ferrari):
- https://www.ilfattoquotidiano.it/2018/05/02/nuovo-regolamento-privacy-i-dieci-comandamenti-per-non-cadere-nei-tranelli/4328293/.

Io l'avevo detto nel maggio 2016:
- http://blog.cesaregallotti.it/2016/05/pubblicato-il-nuovo-regolamento-privacy.html.

Ma non avevo considerato la vera grande novità del GDPR: le sanzioni milionarie. Questa è la vera grande novità. Il resto sono solo isterie di "studiosi" o "consulenti" che vogliono vendere mega progetti ai clienti spaventati (o che non hanno capito niente... gli studiosi e i consulenti... non i clienti).

A dirla tutta: il GDPR semplifica di molto rispetto alla 196.

A chi interessa, ecco la mia check list delle cose da fare:
  • nei casi previsti dall'articolo 37, designare un DPO; in tutti gli altri casi, individuare un "referente privacy" (anche se non obbligatorio); tutte le altre cose vanno fatte con questa persona (ed eventualmente con altre);
  • fare il registro dei trattamenti (il mio modello è il VERA privacy, reperibile da http://www.cesaregallotti.it/Pubblicazioni.html); nessuno chiede di scrivere tanti dettagli, ma di riportare solo i trattamenti e le finalità (e altri dettagli, come richiesto dall'articolo );
  • fare una valutazione del rischio relativa alla privacy (si può sempre usare il VERA privacy per iniziare);
  • nei casi previsti dall'articolo 35 e dei trattamenti più "rischiosi", fare una valutazione del rischio specifica per quei trattamenti (DPIA o PIA; sempre con il VERA privacy, per iniziare);
  • riesaminare l'applicazione territoriale;
  • aggiornare le informative, includendo i tempi di conservazione, le modalità di reclamo e, soprattutto, le nuove basi legali (articolo 6 paragrafo 1 del GDPR); togliere anche i riferimenti precisi alla normativa (non servono a niente);
  • togliere i consensi non più necessari e documentare (firme non necessarie) quelli necessari (non necessario richiederlo nuovamente); rendere chiaro e "separato" il consenso privacy;
  • verificare che gli interessati possano revocare il consenso "con la stessa facilità con cui è accordato";
  • ricordare che il GDPR richiede di rispondere alle richieste degli interessati entro un mese (meglio documentare un processo);
  • riesaminare tutti i contratti con i fornitori a cui si trasmettono dati personali e, se necessario, aggiornarli (questo è l'adempimento non tecnologico più pesante) con quanto previsto dall'articolo 28 (avevo già preparato una lista dei punti da prevedere a inizio 2017; oggi penso che dovrei modificarla solo lievemente: http://blog.cesaregallotti.it/2017/01/gdpr-e-nomina-dei-responsabili-privacy.html); da prestare attenzione ai fornitori che trasferiscono dati in Paesi extra-UE (in questi casi, applicare quanto previsto dagli articolo 44 e successivi, che consolidano cose già previste dalla precedente normativa);
  • riesaminare e, se necessario, aggiornare gli accordi con i con-titolari (ricordando anche qui di prestare attenzione ai trasferimenti extra-UE);
  • documentare, per esempio in un mansionario, quali trattamenti sono autorizzati a svolgere le aree aziendali (questo sarebbe un raffinamento di quanto riportato nel registro);
  • stabilire un processo di riesame periodico delle autorizzazioni assegnate per accedere ai dati personali (processo già previsto dalle misure minime del D. Lgs. 196, ma ora ancora più importante perché "sostituisce" le nomine agli incaricati insieme al punto precedente);
  • predisporre un regolamento privacy (che può anche essere esteso alla sicurezza delle informazioni) per tutto il personale e i collaboratori autorizzati a trattare i dati personali, con misure "generali" e, se il caso, con misure specifiche per alcuni trattamenti (p.e. manutenzione software, gestione contatti di un contact centre);
  • stabilire un processo di gestione degli incidenti con impatto sui dati personali (data breach, articoli 33 e 34);
  • controllare che i dati possano essere forniti agli interessati in "formato portabile"; nella maggior parte dei casi vuol dire prevedere l'esportazione in un formato strutturato, di uso comune e leggibile da dispositivo automatico (ossia un testo ASCII, una tabella csv o un pdf); in alcuni specifici mercati è invece necessario prevedere altre soluzioni;
  • prevedere la cancellazione dei dati quando è terminato il periodo di conservazione, ricordando che il principio della conservazione perché "non si sa mai" non è incluso nel GDPR, anzi... è sanzionato; questo è sicuramente l'adempimento tecnico più pesante;
  • stabilire un processo di audit interni per la privacy (testare, verificare e valutare).

martedì 1 maggio 2018

Linee guida WP art. 29 su consenso e trasparenza

Confesso che leggo raramente le linee guida del WP Art. 29. Infatti solitamente ripetono cose già dette più volte. Lascio ad altri più pazienti (e spesso più competenti) di me il compito di leggerle e identificare eventuali punti originali.

In questo caso Pierfrancesco Maistrello mi è venuto in aiuto con due linee guida.

La prima è sul consenso. La linea guida si trova qui:
- http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=623051.

Ecco quello che mi scrive Pierfrancesco: "il capitolo 8 riporta una cosa ovvia, anche se ho visto molti casi in cui ovvia non è. Si dice che il consenso raccolto in ambito Direttiva 95/46 (ossia prima del GDPR) può essere valido, previa verifica delle caratteristiche della sua acquisizione. Io direi che se un titolare italiano ha disposto testi informativi conformi con la vigente legge dell'epoca, dovrebbe aver indicato le finalità in informativa e, conseguentemente, agganciato un consenso liberamente selezionabile (e firmabile in caso di trattamento di dati sensibili). Chi invece ha fatto il furbo dovrà correre ai ripari. Molto spesso i contatti del marketing sono stati raccolti nei modi più vari e oggi non è più possibile sapere se erano anche corretti".

Io aggiungo che molti uffici marketing mi chiedono perché non giudicare validi i contatti che hanno ricevuto email promozionali gli scorsi anni e non hanno mai seguito la (semplice) procedure di cancellazione. Non saprei rispondere in modo più intelligente di "se non avete prova del consenso prestato con un'azione "positiva", quel contatto dovreste cancellarlo".

La seconda pubblicazione è sulla trasparenza. Si trova a questo link:
- http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=622227.

Pierfrancesco mi segnala: "anche qui niente di nuovissimo, mi pare, almeno per chi si è letto il GDPR. In realtà sarebbe importante leggere tutto il documentone, che parte descrivendo l'importanza del primo tassello (cosa che io dico sempre): l'informativa deve essere comprensibile a chi la legge in relazione ai dati che riguardano proprio lui….ma so che è inutile parlarne a te, che la pensi esattamente così da sempre, mi pare…".

Ha ragione a dire che la penso così da sempre. Dubito però di essere stato capace di scrivere un'informativa facilmente comprensibile al cosiddetto "uomo della strada". Ma potrò imparare.

Stato delle norme ISO/IEC 270xx - Aprile 2018

Il 20 aprile a Wuhan (Cina) si è concluso l'incontro semestrale del ISO/IEC JTC 1 SC 27, ossia del comitato che si occupa della redazione delle norme della serie ISO/IEC 27000.

Ho trovato l'incontro povero di argomenti di mio interesse. Darò quindi conto delle (poche) cose emerse.

Per quanto riguarda i lavori sulle norme della privacy, i lavori sulla ISO/IEC 27552 (ossia lo standard che potrebbe essere quello su cui sarà basata la "certificazione GDPR") sono proseguiti e verrà prodotto un secondo CD. In parole molto povere: i lavori stanno proseguendo come previsto in precedenza, con pubblicazione della norma prevista a fine 2019.

Altra norma che è ritenuta molto interessante è la ISO/IEC 27018 (Code of practice for PII protection in public clouds acting as PII processors). E' programmata una sua nuova versione a breve per allinearla alle altre norme uscite in questi anni. Purtroppo mi risulta non siano state fatte riflessioni approfondite sulle sovrapposizioni tra questa norma e la ISO/IEC 27552.

Altri lavori sono proseguiti (ma non ho potuto seguirli perché arrivato tardi per problemi vari). In particolare sulla nuova edizione della ISO/IEC 29101 (Privacy Architecture Framework) e la ISO/IEC 27550 (Privacy engineering for system life cycle processes).

Lascio in coda le attività del WG 1, ossia quelle più strettamente collegate alla ISO/IEC 27001. Segnalo le cose per me più interessanti:
- c'è stato un incontro di discussione sulla "utilità del SOA", in cui sono emersi i diversi punti di vista;
- sono continuati i lavori preparatori per la prossima versione della ISO/IEC 27002;
- sono continuate le discussioni per la futura ISO/IEC 27005;
- sono state fatte alcune riflessioni sulla ISO/IEC 27006 perché alcuni punti sono risultati ambigui;

Stanno inoltre avanzando i lavori su alcune norme relative alla cybersecurity. In particolare, anche se non ci ho partecipato, trovo molto interessante la futura norma ISO/IEC 27102 sulle cyber-assicurazioni.

Per quanto riguarda i partecipanti, ho solo i numeri del WG 1 (i gruppi sono 5 e il WG 1 è il più numeroso): 98 esperti da 21 Paesi. La delegazione italiana (per i soli WG 1 e WG 5) era composta da ben (!) tre persone.