Fabio Guasconi di Bl4ckSwan mi ha informato che è stata pubblicata la ISO/IEC 29151 dal titolo "Code of practice for personally identifiable information protection":
https://www.iso.org/standard/62726.html.
E' applicabile ai soli titolari dei trattamenti (e non mi sembra una buona idea).
Si tratta di un'estensione dei controlli della ISO/IEC 27002. Per alcuni dei controlli già previsti dalla ISO/IEC 27002 sono indicate ulteriori indicazioni per l'attuazione. In Annex A sono poi riportati controlli aggiuntivi rispetto a quelli già presenti nella ISO/IEC 27002.
Questo documento potrebbe essere usato dalle organizzazioni già certificate ISO/IEC 27001 per estendere la propria Dichiarazione di applicabilità (o Statement of applicability). Questo poi potrebbe portare a certificazioni ISO/IEC 27001 basate "sui controlli riportati dalle ISO/IEC 27001 e ISO/IEC 29151" (non sono previste certificazioni ISO/IEC 29151).
Ora è anche in corso di discussione la ISO/IEC 27552, che dovrà estendere (non ridurre!) la ISO/IEC 27001 in modo che sia dedicata alla protezione dei dati personali. C'è da dire che i lavori su questa norma sono in stato ancora di "Working draft" e pertanto uscirà tra non meno di due anni.
martedì 29 agosto 2017
mercoledì 23 agosto 2017
ISO 18295 sui Costumer contact centre
Franco Ferrari di DNV GL mi ha segnalato la pubblicazione, a luglio 2017, della norma ISO 18295 dal titolo "Customer contact centres". Essa è divisa in due parti: la prima ("Requirements for customer contact centres") presenta i requisiti proprio di customer contact centre (CCC), mentre la seconda ("Requirements for clients using the services of customer contact centres") presenta i requisiti che dovrebbero attuare i clienti, interni o esterni, dei CCC.
Si tratta di norme certificabili. Non si tratta di norme di "sistemi di gestione", ma "di servizio", e pertanto non sono impostate come la ISO 9001:2015 o la ISO/IEC 27001:2013.
Prima di questa norma era disponibile la norma europea EN 15838 (dal titolo "Customer Contact Centres: Requirements for service provision"), ora abrogata. In Italia la EN 15838 andava integrata con la UNI 11200 (dal titolo "Servizi di relazione con il cliente, con il consumatore e con il cittadino, effettuati attraverso centri di contatto: Requisiti operativi per l'applicazione della UNI EN 15838:2010") e ora vedremo se questa norma nazionale avrà ancora ragione di esistere.
La UNI 11200 è comunque interessante perché riporta delle metriche più precise rispetto a quelle generiche delle norme europee e internazionali. In molti casi riporta anche dei valori di riferimento (o SLA).
Tecnicamente, le norme precedenti riguardavano solo l'erogazione dei servizi. Ora la parte 2 della ISO 18295 introduce requisiti anche per i clienti dei contact centre.
Segnalo quindi la presentazione di queste norme fatta dall'ISO: https://www.iso.org/news/ref2191.html.
Si tratta di norme certificabili. Non si tratta di norme di "sistemi di gestione", ma "di servizio", e pertanto non sono impostate come la ISO 9001:2015 o la ISO/IEC 27001:2013.
Prima di questa norma era disponibile la norma europea EN 15838 (dal titolo "Customer Contact Centres: Requirements for service provision"), ora abrogata. In Italia la EN 15838 andava integrata con la UNI 11200 (dal titolo "Servizi di relazione con il cliente, con il consumatore e con il cittadino, effettuati attraverso centri di contatto: Requisiti operativi per l'applicazione della UNI EN 15838:2010") e ora vedremo se questa norma nazionale avrà ancora ragione di esistere.
La UNI 11200 è comunque interessante perché riporta delle metriche più precise rispetto a quelle generiche delle norme europee e internazionali. In molti casi riporta anche dei valori di riferimento (o SLA).
Tecnicamente, le norme precedenti riguardavano solo l'erogazione dei servizi. Ora la parte 2 della ISO 18295 introduce requisiti anche per i clienti dei contact centre.
Segnalo quindi la presentazione di queste norme fatta dall'ISO: https://www.iso.org/news/ref2191.html.
27 settembre: DFA Open Day - GDPR e investigazioni aziendali
Io sono Consigliere di DFA e sono molto orgoglioso di presentarvi l'Open day 2017 dedicato a GDPR e investigazioni aziendali:
- http://www.perfezionisti.it/open-day/dfa-open-day-2017/.
Ci si può iscrivere gratuitamente, ma al momento in cui io sto scrivendo questo annuncio l'evento risulta "tutto esaurito". Magari si libereranno dei posti nei prossimi giorni:
- https://www.eventbrite.it/e/biglietti-dfa-open-day-2017-36684332827.
- http://www.perfezionisti.it/open-day/dfa-open-day-2017/.
Ci si può iscrivere gratuitamente, ma al momento in cui io sto scrivendo questo annuncio l'evento risulta "tutto esaurito". Magari si libereranno dei posti nei prossimi giorni:
- https://www.eventbrite.it/e/biglietti-dfa-open-day-2017-36684332827.
Ritirata la ISO/IEC 27015
Franco Ferrari di DNV GL mi ha segnalato che è stata ritirata la ISO/IEC 27015 dal titolo "Information security management guidelines for financial services":
https://www.iso.org/standard/43755.html.
Infatti sembra che i fornitori di servizi finanziari (soprattutto le banche) preferiscono appoggiarsi ad altri standard interni o di altra provenienza. Per esempio, mi risulta che la BCE (Banca centrale europea) si appoggia sul NIST Cybersecurity framework, di origine USA.
Questo lo trovo molto bizzarro: piuttosto che appoggiare uno standard internazionale, con procedure di approvazione aperte, alcune istituzioni preferiscono appoggiarsi a standard elaborati da strutture che sfuggono completamente al loro controllo. Contenti loro...
https://www.iso.org/standard/43755.html.
Infatti sembra che i fornitori di servizi finanziari (soprattutto le banche) preferiscono appoggiarsi ad altri standard interni o di altra provenienza. Per esempio, mi risulta che la BCE (Banca centrale europea) si appoggia sul NIST Cybersecurity framework, di origine USA.
Questo lo trovo molto bizzarro: piuttosto che appoggiare uno standard internazionale, con procedure di approvazione aperte, alcune istituzioni preferiscono appoggiarsi a standard elaborati da strutture che sfuggono completamente al loro controllo. Contenti loro...
Il flop della regolamentazione dei cookies
Fabrizio Monteleone di DNV GL mi ha segnalato uno studio dal titolo "Uncovering the Flop of the EU Cookie Law". L'ho trovato su questo sito:
https://scirate.com/arxiv/1705.08884.
Riassumo l'abstract. La Direttiva ePrivacy richiede che i siti web chiedano consenso esplicito agli utenti prima di usare i "tracking cookies". Gli autori hanno quindi analizzato più di 35.000 siti web e hanno scoperto che il 65% di questi siti installa i tracking cookies prima che l'utente possa accettarli esplicitamente. Gli autori sono convinti che le agenzie di controllo non facciano controlli, ma anche delle difficoltà di attuazione delle misure tecniche richieste.
https://scirate.com/arxiv/1705.08884.
Riassumo l'abstract. La Direttiva ePrivacy richiede che i siti web chiedano consenso esplicito agli utenti prima di usare i "tracking cookies". Gli autori hanno quindi analizzato più di 35.000 siti web e hanno scoperto che il 65% di questi siti installa i tracking cookies prima che l'utente possa accettarli esplicitamente. Gli autori sono convinti che le agenzie di controllo non facciano controlli, ma anche delle difficoltà di attuazione delle misure tecniche richieste.
martedì 22 agosto 2017
Del NIST e della lunghezza e complessità delle password
Il NIST ha pubblicato la SP 800-63B, una nuova versione della "Digital Identity Guidelines: Authentication and Lifecycle Management":
http://csrc.nist.gov/publications/PubsSPs.html.
In realtà vedo che ha pubblicato anche, nella stessa data, la SP 800-63C e la SP 800-63-3. Confesso che mi sono perso in questi documenti e non li ho letti. Però segnalo quanto richiamato dal SANS Newsbites (https://www.sans.org/newsletters/newsbites/xix/62#200), in particolare facendo riferimento al punto 5.1.1 del SP 800-63B, "Memorized secrets", e all'Appendix A: "il nuovo documento suggerisce di usare password lunghe, facili da ricordare e da cambiare solo quando si pensa siano state compromesse". Un autore della precedente guida del NIST dice che "rimpiange" la vecchia impostazione che richiedeva di usare password complesse (con lettere maiuscole, minuscole, numeri e caratteri speciali) e da cambiare almeno ogni 3 mesi.
Si ritiene preferibile lasciare liberi gli utenti di scegliere le proprie password, purché di almeno 8 caratteri e non presenti in una blacklist di password troppo facili (per esempio password già diffuse a seguito di altri attacchi, parole del dizionario, caratteri sequenziali o ripetuti, come 1234 e aaaa, parole derivate dal nome del servizio, dal nome dell'utente, dalla sua user-id o altri elementi). Infatti le password sono più spesso individuate attraverso attacchi di social engineering e non di forza bruta.
Per quanto riguarda la lunghezza, il NIST fa notare che questa non ha impatto sugli attacchi offline, visto che questi sono rivolti ai valori hash, indipendenti dall'input. Per gli attacchi online, bisogna invece prevedere altre misure di sicurezza, come il blocco dopo alcuni tentativi errati, valutando però la possibilità che un malintenzionato possa provare deliberatamente password errate per bloccare l'utente. E' comunque raccomandata una lunghezza minima di 8 caratteri.
Per quanto riguarda la complessità, il NIST segnala che spesso gli utenti riescono ad aggirare la richiesta con scelte banali, per esempio usando al posto di "password" la stringa "Password1". In altri casi, la complessità porta gli utenti a scrivere le proprie password, annullando (o peggiorando) la misura.
Personalmente ho qualche perplessità e devo ancora pensare ai pro e ai contro di queste proposte. Per esempio, il cambio periodico della password è necessario negli ambienti in cui gli utenti si scambiano le password (anche se proibito o sconsigliato) o le usano su strumenti non personali o aziendali (e quindi ricavabili dalla cache dello strumento).
In Italia, comunque, sono ancora vigenti le misure minime del Codice della privacy che impone una lunghezza minima di 8 caratteri, un minimo di complessità e il cambio ogni 3 o 6 mesi. Vedremo dopo le modifiche che saranno apportate al Codice e ai Provvedimenti (e Linee guida) del Garante privacy.
Nota: un articolo simile l'ho proposto a https://www.ictsecuritymagazine.com/ (finora non risulta pubblicato).
http://csrc.nist.gov/publications/PubsSPs.html.
In realtà vedo che ha pubblicato anche, nella stessa data, la SP 800-63C e la SP 800-63-3. Confesso che mi sono perso in questi documenti e non li ho letti. Però segnalo quanto richiamato dal SANS Newsbites (https://www.sans.org/newsletters/newsbites/xix/62#200), in particolare facendo riferimento al punto 5.1.1 del SP 800-63B, "Memorized secrets", e all'Appendix A: "il nuovo documento suggerisce di usare password lunghe, facili da ricordare e da cambiare solo quando si pensa siano state compromesse". Un autore della precedente guida del NIST dice che "rimpiange" la vecchia impostazione che richiedeva di usare password complesse (con lettere maiuscole, minuscole, numeri e caratteri speciali) e da cambiare almeno ogni 3 mesi.
Si ritiene preferibile lasciare liberi gli utenti di scegliere le proprie password, purché di almeno 8 caratteri e non presenti in una blacklist di password troppo facili (per esempio password già diffuse a seguito di altri attacchi, parole del dizionario, caratteri sequenziali o ripetuti, come 1234 e aaaa, parole derivate dal nome del servizio, dal nome dell'utente, dalla sua user-id o altri elementi). Infatti le password sono più spesso individuate attraverso attacchi di social engineering e non di forza bruta.
Per quanto riguarda la lunghezza, il NIST fa notare che questa non ha impatto sugli attacchi offline, visto che questi sono rivolti ai valori hash, indipendenti dall'input. Per gli attacchi online, bisogna invece prevedere altre misure di sicurezza, come il blocco dopo alcuni tentativi errati, valutando però la possibilità che un malintenzionato possa provare deliberatamente password errate per bloccare l'utente. E' comunque raccomandata una lunghezza minima di 8 caratteri.
Per quanto riguarda la complessità, il NIST segnala che spesso gli utenti riescono ad aggirare la richiesta con scelte banali, per esempio usando al posto di "password" la stringa "Password1". In altri casi, la complessità porta gli utenti a scrivere le proprie password, annullando (o peggiorando) la misura.
Personalmente ho qualche perplessità e devo ancora pensare ai pro e ai contro di queste proposte. Per esempio, il cambio periodico della password è necessario negli ambienti in cui gli utenti si scambiano le password (anche se proibito o sconsigliato) o le usano su strumenti non personali o aziendali (e quindi ricavabili dalla cache dello strumento).
In Italia, comunque, sono ancora vigenti le misure minime del Codice della privacy che impone una lunghezza minima di 8 caratteri, un minimo di complessità e il cambio ogni 3 o 6 mesi. Vedremo dopo le modifiche che saranno apportate al Codice e ai Provvedimenti (e Linee guida) del Garante privacy.
Nota: un articolo simile l'ho proposto a https://www.ictsecuritymagazine.com/ (finora non risulta pubblicato).
domenica 23 luglio 2017
Certificazioni ISO/IEC 27018
Accredia ha pubblicato un regolamento per le "certificazioni" ISO/IEC 27018 (grazie a Franco Ferrari di DNV GL per la notizia):
http://www.accredia.it/extsearch_documentazione.jsp?area=55&ID_LINK=331&page=118&IDCTX=5549&id_context=5549.
Purtroppo ci sono stati casi in passato (e nel presente) di certificazioni rispetto a questa linea guida, con anche marchi di accreditamento. Sappiamo bene che le linee guida non sono certificabili.
Accredia ha messo un punto fermo e questo è un bene. Però non concordo con l'impostazione. Infatti la ISO/IEC 27018 fa parte di quelle norme di "estensione" dei controlli ISO/IEC 27002 e non dovrebbe essere trattata a parte. Ci dovremo quindi aspettare regole per la 27017, 27011, 27019, 27799 e la futura ISO/IEC 29151 (quella sulla privacy)?
Il fatto che continua a sfuggire è che la ISO/IEC 27006 permette di scrivere su un certificato ISO/IEC 27001 che il SOA include i controlli della ISO/IEC 27018 o di altre norme di "estensione" della ISO/IEC 27002. Anzi, si potrebbero citare anche controlli diversi, come quelli del NIST Cybersecurity framework. E quindi questa circolare riguarda solo un caso particolare e non aiuta ad impostare il lavoro in modo coerente e utile per il futuro. Un'altra occasione persa, ahinoi.
http://www.accredia.it/extsearch_documentazione.jsp?area=55&ID_LINK=331&page=118&IDCTX=5549&id_context=5549.
Purtroppo ci sono stati casi in passato (e nel presente) di certificazioni rispetto a questa linea guida, con anche marchi di accreditamento. Sappiamo bene che le linee guida non sono certificabili.
Accredia ha messo un punto fermo e questo è un bene. Però non concordo con l'impostazione. Infatti la ISO/IEC 27018 fa parte di quelle norme di "estensione" dei controlli ISO/IEC 27002 e non dovrebbe essere trattata a parte. Ci dovremo quindi aspettare regole per la 27017, 27011, 27019, 27799 e la futura ISO/IEC 29151 (quella sulla privacy)?
Il fatto che continua a sfuggire è che la ISO/IEC 27006 permette di scrivere su un certificato ISO/IEC 27001 che il SOA include i controlli della ISO/IEC 27018 o di altre norme di "estensione" della ISO/IEC 27002. Anzi, si potrebbero citare anche controlli diversi, come quelli del NIST Cybersecurity framework. E quindi questa circolare riguarda solo un caso particolare e non aiuta ad impostare il lavoro in modo coerente e utile per il futuro. Un'altra occasione persa, ahinoi.
sabato 22 luglio 2017
Libro "Privacy & audit"
Mi piace consigliare il libro "Privacy & audit" di Fulvia Emegian, Monica Perego:
http://shop.wki.it/Ipsoa/Libri/Privacy_Audit_s559485.aspx (link della casa editrice).
Ovviamente ho trovato qua e là qualche piccola imprecisione (!), ma l'ho trovato ben fatto: ben raccontato e con molti esempi (veramente tanti, con anche tracce di audit svolti). E poi mi trovo d'accordo con l'approccio proposto sia per gli adempimenti privacy sia per l'esecuzione degli audit.
Ho conosciuto Fulvia e Monica e ci siamo scambiati i libri. Meno male che non è stata quella situazione imbarazzante per cui qualcuno ti regala il suo libro e a te non piace!
Monica è formatrice presso corsi per DPO, che ho sempre sconsigliato (e ci sono altre cose che chi mi conosce potrebbe trovare interessanti). Però sia Fulvia sia Monica sono molto preparate, brave e entusiaste e il libro è fatto bene.
Conclusione: sono ben contento di fare questa pubblicità estiva (d'altra parte non ci guadagno niente).
http://shop.wki.it/Ipsoa/Libri/Privacy_Audit_s559485.aspx (link della casa editrice).
Ovviamente ho trovato qua e là qualche piccola imprecisione (!), ma l'ho trovato ben fatto: ben raccontato e con molti esempi (veramente tanti, con anche tracce di audit svolti). E poi mi trovo d'accordo con l'approccio proposto sia per gli adempimenti privacy sia per l'esecuzione degli audit.
Ho conosciuto Fulvia e Monica e ci siamo scambiati i libri. Meno male che non è stata quella situazione imbarazzante per cui qualcuno ti regala il suo libro e a te non piace!
Monica è formatrice presso corsi per DPO, che ho sempre sconsigliato (e ci sono altre cose che chi mi conosce potrebbe trovare interessanti). Però sia Fulvia sia Monica sono molto preparate, brave e entusiaste e il libro è fatto bene.
Conclusione: sono ben contento di fare questa pubblicità estiva (d'altra parte non ci guadagno niente).
giovedì 20 luglio 2017
Il Garante si diverte
Segnalo, grazie a Giulia Zanchettin, che il Garante ha pubblicato "Estate in privacy", ossia consigli per tutti da seguire durante l'estate (e non solo):
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3240343.
Mi sembrano regole banali, ma ben presentate.
Confesso che stavo ignorando completamente la notizia (semplicemente perché i miei lettori sono principalmente professionisti della sicurezza), ma è vero che un ripasso delle regole di base non guasta mai (sono purtroppo tanti i professionisti della sicurezza che scrivono tweet quando atterrano a Hong Kong, Parigi, Londra, New York eccetera, non preoccupandosi di potenziali ladri interessati a sapere quando non sono a casa).
Inoltre il titolo di Giulia ("Il Garante si diverte") era troppo bello per essere ignorato.
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3240343.
Mi sembrano regole banali, ma ben presentate.
Confesso che stavo ignorando completamente la notizia (semplicemente perché i miei lettori sono principalmente professionisti della sicurezza), ma è vero che un ripasso delle regole di base non guasta mai (sono purtroppo tanti i professionisti della sicurezza che scrivono tweet quando atterrano a Hong Kong, Parigi, Londra, New York eccetera, non preoccupandosi di potenziali ladri interessati a sapere quando non sono a casa).
Inoltre il titolo di Giulia ("Il Garante si diverte") era troppo bello per essere ignorato.
Report sicurezza di Lloyds of London
Segnalo (grazie a Stefano Ramacciotti) il "Emerging Risk Report on Cyber Insurance" (sottotitolo "Counting the cost: Cyber exposure decoded") della Lloyds of London:
- https://www.lloyds.com/news-and-insight/risk-insight/library/technology/countingthecost.
Mi affido al commento del SANS: "il rapporto, in definitiva, suggerisce di trattare gli attacchi IT come disastri naturali, non come crimini "tradizionali".
Inoltre il report presenta due esempi: per il primo (fornitore di servizi cloud) con l'assicurazione si recuperano il 15% dei danni, mentre per il secondo (interruzione di un server critico) si recuperano il 7% dei danni. Tradotto: è sempre e comunque necessario attuare le "solite" misure di sicurezza preventiva.
- https://www.lloyds.com/news-and-insight/risk-insight/library/technology/countingthecost.
Mi affido al commento del SANS: "il rapporto, in definitiva, suggerisce di trattare gli attacchi IT come disastri naturali, non come crimini "tradizionali".
Inoltre il report presenta due esempi: per il primo (fornitore di servizi cloud) con l'assicurazione si recuperano il 15% dei danni, mentre per il secondo (interruzione di un server critico) si recuperano il 7% dei danni. Tradotto: è sempre e comunque necessario attuare le "solite" misure di sicurezza preventiva.
mercoledì 19 luglio 2017
Opinione del WP Art. 29 sulla privacy dei lavoratori
Ho notato la notizia in molti posti, ma non l'avevo ben considerata. Fino a quando ho letto questo articolo di Interlex:
- http://www.interlex.it/privacyesicurezza/ricchiuto43.html.
Ricordo che le opinioni del WP Art. 29 sono importanti, in quanto (mi scuso per l'imprecisione) espressione dei Garanti europei.
Inoltre avevo intravisto il punto "caldo" di questa opinione: è ritenuto non corretta la consultazione dei profili dei candidati sui social network da parte del potenziale datore di lavoro. Confesso che la cosa mi lascia perplesso: a mio parere, se una persona mette in pubblico i fatti suoi, legittima, di fatto, chiunque altro a giudicarlo. Comunque, sempre a mio parere, i potenziali datori di lavoro verificheranno sempre il profilo social di un candidato, ma non lo pubblicizzeranno.
Altri aspetti legati ai social network, che mi paiono invece molto pertinenti, sono: i capi non dovrebbero chiedere ai collaboratori la connessione (o la "amicizia"), i capi non dovrebbero obbligare i lavoratori a usare solo profili aziendali.
Inoltre, come già segnalato dall'articolo di Interlex, questa opinione non riguarda solo i dipendenti. E mi sembra corretto siano protetti tutti i lavoratori, a prescindere dal tipo di collaborazione subordinata che hanno.
Infine ho chiesto lumi a Pierfrancesco Maistrello, perché ricordavo un'altra recente "opinione" in merito alla privacy e ai lavoratori. E infatti mi ha confermato che nel 2015 era stata pubblicata dal "Comitato dei ministri" una raccomandazione:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4224268.
Inoltre Pierfrancesco mi fa notare che questa del WP Art. 29 è una "opinion" e non una "linea guida". Forse perché (opinione anche questa!) vuole aiutare i processi di adeguamento legislativo al GDPR dei singoli Stati.
- http://www.interlex.it/privacyesicurezza/ricchiuto43.html.
Ricordo che le opinioni del WP Art. 29 sono importanti, in quanto (mi scuso per l'imprecisione) espressione dei Garanti europei.
Inoltre avevo intravisto il punto "caldo" di questa opinione: è ritenuto non corretta la consultazione dei profili dei candidati sui social network da parte del potenziale datore di lavoro. Confesso che la cosa mi lascia perplesso: a mio parere, se una persona mette in pubblico i fatti suoi, legittima, di fatto, chiunque altro a giudicarlo. Comunque, sempre a mio parere, i potenziali datori di lavoro verificheranno sempre il profilo social di un candidato, ma non lo pubblicizzeranno.
Altri aspetti legati ai social network, che mi paiono invece molto pertinenti, sono: i capi non dovrebbero chiedere ai collaboratori la connessione (o la "amicizia"), i capi non dovrebbero obbligare i lavoratori a usare solo profili aziendali.
Inoltre, come già segnalato dall'articolo di Interlex, questa opinione non riguarda solo i dipendenti. E mi sembra corretto siano protetti tutti i lavoratori, a prescindere dal tipo di collaborazione subordinata che hanno.
Infine ho chiesto lumi a Pierfrancesco Maistrello, perché ricordavo un'altra recente "opinione" in merito alla privacy e ai lavoratori. E infatti mi ha confermato che nel 2015 era stata pubblicata dal "Comitato dei ministri" una raccomandazione:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4224268.
Inoltre Pierfrancesco mi fa notare che questa del WP Art. 29 è una "opinion" e non una "linea guida". Forse perché (opinione anche questa!) vuole aiutare i processi di adeguamento legislativo al GDPR dei singoli Stati.
Certificazioni privacy per aziende
Proseguo quanto già scritto in un precedente post:
(blog.cesaregallotti.it/2017/05/certificazioni-privacy-per-aziende-e-bs.html.
Infatti Pierfrancesco Maistrello, Franco Ferrari e Paolo Sferlazza mi hanno segnalato questo comunicato del Garante e Accredia:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6621723.
Riassunto (mio): lasciate perdere le certificazioni di persone e organizzazioni fino a quando non ve lo diciamo noi (poi... Accredia ha già accreditato un organismo di certificazione senza l'avallo del Garante, ma evito di fare il pignolo).
(blog.cesaregallotti.it/2017/05/certificazioni-privacy-per-aziende-e-bs.html.
Infatti Pierfrancesco Maistrello, Franco Ferrari e Paolo Sferlazza mi hanno segnalato questo comunicato del Garante e Accredia:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6621723.
Riassunto (mio): lasciate perdere le certificazioni di persone e organizzazioni fino a quando non ve lo diciamo noi (poi... Accredia ha già accreditato un organismo di certificazione senza l'avallo del Garante, ma evito di fare il pignolo).
ISO/IEC 27004:2016 sulle misurazioni
E' stata pubblicata a dicembre 2016 la nuova versione della ISO/IEC 27004 dal titolo "Information security management -- Monitoring, measurement, analysis and evaluation":
https://www.iso.org/standard/64120.html.
Sono stupito di non aver rilevato la notizia all'epoca. Infatti tengo molto a questa versione della ISO/IEC 27004, a cui ha contribuito molto Fabio Guasconi e anche io ho partecipato.
Questa versione è molto meno teorica della precedente e presenta ben 35 esempi di misurazioni per la sicurezza (c'è il mio zampino...). Non tutti questi indicatori mi convincono (per esempio quello che richiede di misurare il numero di riesami di Direzione), mentre altri sono più indicatori di avanzamento (per esempio percentuale degli audit interni rispetto a quelli programmati). Infine rimangono gli indicatori "veri" (per esempio disponibilità dei sistemi, tempi di intervento sugli incidenti), che sono pochi, come ho sempre sostenuto.
Ricordo infatti che il problema della sicurezza delle informazioni è che ha come obiettivo il "non verificarsi di eventi" e quindi non è possibile raccogliere molti dati utili per misurare.
https://www.iso.org/standard/64120.html.
Sono stupito di non aver rilevato la notizia all'epoca. Infatti tengo molto a questa versione della ISO/IEC 27004, a cui ha contribuito molto Fabio Guasconi e anche io ho partecipato.
Questa versione è molto meno teorica della precedente e presenta ben 35 esempi di misurazioni per la sicurezza (c'è il mio zampino...). Non tutti questi indicatori mi convincono (per esempio quello che richiede di misurare il numero di riesami di Direzione), mentre altri sono più indicatori di avanzamento (per esempio percentuale degli audit interni rispetto a quelli programmati). Infine rimangono gli indicatori "veri" (per esempio disponibilità dei sistemi, tempi di intervento sugli incidenti), che sono pochi, come ho sempre sostenuto.
Ricordo infatti che il problema della sicurezza delle informazioni è che ha come obiettivo il "non verificarsi di eventi" e quindi non è possibile raccogliere molti dati utili per misurare.
lunedì 17 luglio 2017
Fornitori di servizi per le aziende con i piedi per terra
Mio articolo dal titolo "Fornitori di servizi per le aziende con i piedi per terra":
- https://www.ictsecuritymagazine.com/articoli/fornitori-piedi-terra/.
- https://www.ictsecuritymagazine.com/articoli/fornitori-piedi-terra/.
sabato 8 luglio 2017
Lavori sul Codice privacy (e integrazione con il GDPR)
Monica Perego mi segnala questo emendamento ad un DDL in discussione al Parlamento:
http://www.senato.it/japp/bgt/showdoc/frame.jsp?tipodoc=Emendc&leg=17&id=1029112&idoggetto=1035671.
Questo il commento di Monica: "questa è la legge delega che non abroga il codice ma dice che va integrato con il Regolamento". Monica non lo dice, ma lo sottintende: avevano torto quelli che davano per abrogato il D. Lgs. 196 dopo l'entrata in vigore del GDPR (e purtroppo alcuni lo dicevano con troppa indisponenza).
http://www.senato.it/japp/bgt/showdoc/frame.jsp?tipodoc=Emendc&leg=17&id=1029112&idoggetto=1035671.
Questo il commento di Monica: "questa è la legge delega che non abroga il codice ma dice che va integrato con il Regolamento". Monica non lo dice, ma lo sottintende: avevano torto quelli che davano per abrogato il D. Lgs. 196 dopo l'entrata in vigore del GDPR (e purtroppo alcuni lo dicevano con troppa indisponenza).
Allagamento blocca i server del Tribunale di Napoli
Sandro Sanna mi segnala la seguente notizia, dal titolo "In tilt i sistemi informatici del Tribunale di Napoli, si torna alla carta":
http://www.ilmattino.it/napoli/cronaca/napoli_palazzo_giustizia_server_carta_tribunale-2550463.html.
Il suo commento: " c'è chi mette sempre nel risk assessment probabilità bassa è poi invece...".
http://www.ilmattino.it/napoli/cronaca/napoli_palazzo_giustizia_server_carta_tribunale-2550463.html.
Il suo commento: " c'è chi mette sempre nel risk assessment probabilità bassa è poi invece...".
Nuova versione della UNI 10459
Mi segnala Franco Ferrari di DNV GL che è stata pubblicata la UNI 10459:2017, aggiornamento della versione del 2015, dal titolo "Attività professionali non regolamentate - Professionista della security - Requisiti di conoscenza, abilità e competenza":
http://store.uni.com/magento-1.4.0.1/index.php/uni-10459-2017.html.
Franco mi segnala un articolo su Punto Sicuro, però non accessibile senza credenziali. Riporto però questa frase: "Questa nuova edizione della norma presenta dei miglioramenti, soprattutto di tipo formale, che mirano a rendere la norma sempre più leggibile ed aderente a una realtà in costante evoluzione, come la realtà degli scenari di rischio e delle strategie di attacco e difesa".
Ho chiesto lumi a Fabio Guasconi di Bl4ckSwan, che ha partecipato ai lavori. Mi ha detto che ha lavorato soprattutto "per evitare che ci fossero ambiguità tra il Security manager (che è in sostanza un CSO, con responsabilità di più alto livello in materia di sicurezza delle informazioni) e l'Information security manager".
Per questa figura ha anche uniformato la terminologia usata per riferirsi alla sicurezza delle informazioni con quella della ISO/IEC 27001 e richiamato i profili specifici della UNI 11621-4 con cui interfacciarsi, rimosso dove possibile le responsabilità e le competenze di dettaglio del Security manager sull'information security, lasciandogli quelle di più alto livello.
http://store.uni.com/magento-1.4.0.1/index.php/uni-10459-2017.html.
Franco mi segnala un articolo su Punto Sicuro, però non accessibile senza credenziali. Riporto però questa frase: "Questa nuova edizione della norma presenta dei miglioramenti, soprattutto di tipo formale, che mirano a rendere la norma sempre più leggibile ed aderente a una realtà in costante evoluzione, come la realtà degli scenari di rischio e delle strategie di attacco e difesa".
Ho chiesto lumi a Fabio Guasconi di Bl4ckSwan, che ha partecipato ai lavori. Mi ha detto che ha lavorato soprattutto "per evitare che ci fossero ambiguità tra il Security manager (che è in sostanza un CSO, con responsabilità di più alto livello in materia di sicurezza delle informazioni) e l'Information security manager".
Per questa figura ha anche uniformato la terminologia usata per riferirsi alla sicurezza delle informazioni con quella della ISO/IEC 27001 e richiamato i profili specifici della UNI 11621-4 con cui interfacciarsi, rimosso dove possibile le responsabilità e le competenze di dettaglio del Security manager sull'information security, lasciandogli quelle di più alto livello.
martedì 4 luglio 2017
ISO/IEC 29134 - Privacy impact assessment
E' stata pubblicata la ISO/IEC 29134:2017 dal titolo "Information technology -- Security techniques -- Guidelines for privacy impact assessment":
https://www.iso.org/standard/62289.html.
Ne ho già parlato in precedenza. Da notare che è, in sostanza, il recepimento ISO delle linee guida del CNIL sulla PIA (gratuite!):
www.cnil.fr/english/news-and-events/news/article/privacy-impact-assessments-the-cnil-publishes-its-pia-manual/.
Su questa norma ho qualche perplessità teorica (confusione su "fonti di rischio" e "minacce") e pratica (gli esempi non sono illuminanti). Però non ci ho minimamente lavorato, malgrado ne avessi la possibilità, e quindi non ho approfondito i perché di queste scelte.
https://www.iso.org/standard/62289.html.
Ne ho già parlato in precedenza. Da notare che è, in sostanza, il recepimento ISO delle linee guida del CNIL sulla PIA (gratuite!):
www.cnil.fr/english/news-and-events/news/article/privacy-impact-assessments-the-cnil-publishes-its-pia-manual/.
Su questa norma ho qualche perplessità teorica (confusione su "fonti di rischio" e "minacce") e pratica (gli esempi non sono illuminanti). Però non ci ho minimamente lavorato, malgrado ne avessi la possibilità, e quindi non ho approfondito i perché di queste scelte.
sabato 1 luglio 2017
Lavoro e dati giudiziari dei dipendenti
Il Garante privacy, con la sua ultima newsletter, ribadisce che le organizzazioni non possono trattare i dati giudiziari dei dipendenti (e neanche dei candidati) se non richiesto dalla legge o autorizzato dal Garante stesso.
La newsletter:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558875.
Il Provvedimento specifico:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558837.
In effetti, c'è la cattiva abitudine, in troppe imprese, di chiedere il casellario giudiziario. Questo non solo perché contrario alla normativa in vigore, ma perché i comportamenti passati di una persona non possono dare indicazioni su quelli futuri. In caso contrario, dovremmo pensare che le persone non potranno mai migliorare e neanche noi stessi; e quindi a che servirebbe studiare?
Forse sono fuori tema. Ma ci torno subito. Infatti è sbagliato pensare che il personale selezionato in quanto senza reati passati sia migliore di quello che è già stato oggetto di indagine. Sappiamo che una persona delinque spesso "in crescendo" e quindi un incensurato potrebbe già essere avviato per quella strada. Una persona che ha già scontato una pena, forse, riesce a riconoscere ed evitare di percorrere una certa strada, rinforzata anche dalla stabilità del posto di lavoro.
Inoltre non dobbiamo progettare controlli di sicurezza pensando che le persone interne siano tutte oneste (sindrome di Fort Apache). Questo è un errore: le persone possono compiere errori e possono anche peggiorare (non solo migliorare) e quindi i controlli di sicurezza devono essere progettati adeguatamente.
La newsletter:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558875.
Il Provvedimento specifico:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558837.
In effetti, c'è la cattiva abitudine, in troppe imprese, di chiedere il casellario giudiziario. Questo non solo perché contrario alla normativa in vigore, ma perché i comportamenti passati di una persona non possono dare indicazioni su quelli futuri. In caso contrario, dovremmo pensare che le persone non potranno mai migliorare e neanche noi stessi; e quindi a che servirebbe studiare?
Forse sono fuori tema. Ma ci torno subito. Infatti è sbagliato pensare che il personale selezionato in quanto senza reati passati sia migliore di quello che è già stato oggetto di indagine. Sappiamo che una persona delinque spesso "in crescendo" e quindi un incensurato potrebbe già essere avviato per quella strada. Una persona che ha già scontato una pena, forse, riesce a riconoscere ed evitare di percorrere una certa strada, rinforzata anche dalla stabilità del posto di lavoro.
Inoltre non dobbiamo progettare controlli di sicurezza pensando che le persone interne siano tutte oneste (sindrome di Fort Apache). Questo è un errore: le persone possono compiere errori e possono anche peggiorare (non solo migliorare) e quindi i controlli di sicurezza devono essere progettati adeguatamente.
lunedì 26 giugno 2017
Email ammissibile come prova
Segnalo questo articolo di Altalex dal titolo "Email ammissibile come prova anche senza la firma elettronica qualificata":
- http://www.altalex.com/documents/news/2017/01/23/email-ammissibile-come-prova-anche-senza-la-firma-elettronica-qualificata.
Il titolo dice già tutto.
- http://www.altalex.com/documents/news/2017/01/23/email-ammissibile-come-prova-anche-senza-la-firma-elettronica-qualificata.
Il titolo dice già tutto.
Iscriviti a:
Post (Atom)