Ho pubblicato le nuove versioni (in inglese e italiano) di VERA, il mio foglio di calcolo per la valutazione del rischio relativo alla sicurezza delle informazioni. Siamo alla 4.4.
Non grandi cambiamenti, tranne l'aggiunta di una minaccia ("perdita di fornitori").
Ho poi corretto alcuni (troppi!) errori di battitura, sia in italiano sia in inglese. Nessuno me li aveva mai segnalati. Forse nessuno li aveva mai notati?
Per questa versione ringrazio Ivana Catic, Andrea Colato, Vito Losacco, Luciano Quartarone e Giovanni Sadun. Non ho usato tutti i loro suggerimenti, ma sono stati utili e interessanti.
Trovate il file qui:
http://www.cesaregallotti.it/Pubblicazioni.html.
martedì 31 ottobre 2017
mercoledì 18 ottobre 2017
ISO/IEC 27007 per gli audit ISO/IEC 27001
E' stata pubblicata la nuova edizione della ISO/IEC 27007 dal titolo "Guidelines for information security management systems auditing":
- https://www.iso.org/standard/67398.html.
Il documento riporta requisiti aggiuntivi rispetto alla ISO 19011. Le pagine sono tante perché è stata aggiunta un'Appendice con interpretazioni di alcuni requisiti della ISO/IEC 27001, compito svolto già dalla ISO/IEC 27003.
Parere personale: non la trovo utile.
- https://www.iso.org/standard/67398.html.
Il documento riporta requisiti aggiuntivi rispetto alla ISO 19011. Le pagine sono tante perché è stata aggiunta un'Appendice con interpretazioni di alcuni requisiti della ISO/IEC 27001, compito svolto già dalla ISO/IEC 27003.
Parere personale: non la trovo utile.
Mio articolo sui requisiti di sicurezza delle applicazioni
Questo, dal titolo " Sviluppo sicuro delle applicazioni: i requisiti" l'ho scritto io:
https://www.ictsecuritymagazine.com/articoli/sviluppo-sicuro-delle-applicazioni-requisiti/.
https://www.ictsecuritymagazine.com/articoli/sviluppo-sicuro-delle-applicazioni-requisiti/.
martedì 17 ottobre 2017
Linee guida WP 29 sulla DPIA
Premetto che, come spesso succede ultimamente, devo ringraziare Pierfrancesco Maistrello per la segnalazione e lo scambio di idee.
La notizia è che il Art. 29 WP ha pubblicato le sue linee guida sulla DPIA (Data privacy impact assessment). Si trovano alla pagina seguente, con il lungo titolo di "Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is "likely to result in a high risk" for the purposes of Regulation 2016/679, wp248rev.01":
- http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083.
L'Art. 29 WP è paragonabile al "centro studi europeo sulla privacy", è collegato alla Commissione europea e i suoi pareri sono molto importanti.
Meglio ricordare che non tutti i titolari (o responsabili) devono predisporre una DPIA. La linea guida fornisce una tabella molto interessante in cui elenca alcuni trattamenti e se per loro è necessaria o meno una DPIA. E' bene comunque ricordare che è previsto che il Garante pubblichi un elenco più esaustivo di trattamenti per cui predisporre una DPIA.
Per il resto, il documento non specifica "come" fare una DPIA (per quello fornisce dei riferimenti in Annex 1), ma solo alcuni principi generali. Importante comunque l'Annex 2, che propone una lista delle caratteristiche che deve avere la DPIA.
Il messaggio, in sostanza, sembra essere: fatela come volete, purché rispetti i punti dell'Annex 2.
In questi giorni il WP 29 ha pubblicato le bozze di altre linee guida (sul data breach e sulla profilazione). Non le commento perché, appunto, sono in bozza.
La notizia è che il Art. 29 WP ha pubblicato le sue linee guida sulla DPIA (Data privacy impact assessment). Si trovano alla pagina seguente, con il lungo titolo di "Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is "likely to result in a high risk" for the purposes of Regulation 2016/679, wp248rev.01":
- http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083.
L'Art. 29 WP è paragonabile al "centro studi europeo sulla privacy", è collegato alla Commissione europea e i suoi pareri sono molto importanti.
Meglio ricordare che non tutti i titolari (o responsabili) devono predisporre una DPIA. La linea guida fornisce una tabella molto interessante in cui elenca alcuni trattamenti e se per loro è necessaria o meno una DPIA. E' bene comunque ricordare che è previsto che il Garante pubblichi un elenco più esaustivo di trattamenti per cui predisporre una DPIA.
Per il resto, il documento non specifica "come" fare una DPIA (per quello fornisce dei riferimenti in Annex 1), ma solo alcuni principi generali. Importante comunque l'Annex 2, che propone una lista delle caratteristiche che deve avere la DPIA.
Il messaggio, in sostanza, sembra essere: fatela come volete, purché rispetti i punti dell'Annex 2.
In questi giorni il WP 29 ha pubblicato le bozze di altre linee guida (sul data breach e sulla profilazione). Non le commento perché, appunto, sono in bozza.
lunedì 16 ottobre 2017
Riconoscimento facciale e video porno
Letta da un certo punto di vista, la notizia (da Crypto-Gram di ottobre) è divertente: Pornhub vuole attivare un software per riconoscere gli attori (così gli utenti possono seguire i loro favoriti) e le posizioni:
- https://motherboard.vice.com/en_us/article/a3kmpb/facial-recognition-for-porn-stars-is-a-privacy-nightmare-waiting-to-happen.
Il problema sono gli attori amatoriali: un software del genere potrebbe collegarli alla loro identità reale.
Problema simile (sempre da Crypto-Gram) riguarda le persone che hanno due identità su Facebook. Il caso specifico riguarda chi offre servizi di sesso con un'identità e poi vive il resto della vita con un'altra. Facebook riesce comunque a capirlo e suggerisce ai contatti di un'identità di connettersi anche all'altra:
- https://gizmodo.com/how-facebook-outs-sex-workers-1818861596.
Certo, a molti questo fa sorridere. Ma software che sanno riconoscere le facce e software che sanno collegare cose tra loro scollegate su Internet (ma collegate nella vita reale)... pensiamoci...
- https://motherboard.vice.com/en_us/article/a3kmpb/facial-recognition-for-porn-stars-is-a-privacy-nightmare-waiting-to-happen.
Il problema sono gli attori amatoriali: un software del genere potrebbe collegarli alla loro identità reale.
Problema simile (sempre da Crypto-Gram) riguarda le persone che hanno due identità su Facebook. Il caso specifico riguarda chi offre servizi di sesso con un'identità e poi vive il resto della vita con un'altra. Facebook riesce comunque a capirlo e suggerisce ai contatti di un'identità di connettersi anche all'altra:
- https://gizmodo.com/how-facebook-outs-sex-workers-1818861596.
Certo, a molti questo fa sorridere. Ma software che sanno riconoscere le facce e software che sanno collegare cose tra loro scollegate su Internet (ma collegate nella vita reale)... pensiamoci...
mercoledì 11 ottobre 2017
Contratti fornitori - una presentazione
Segnalo questa presentazione del Club 27001 dal titolo "Contrôle des prestataires: Erreurs à ne pas commettre" (in francese):
- http://www.club-27001.fr/precedentes-reunions/paris/214-21-septembre-2017-transparents.html
L'ho trovata interessante soprattutto per quanto riguarda le riflessioni sul "diritto di audit". In effetti, spesso troviamo sui contratti una clausola molto generica e semplice. Invece la presentazione ci ricorda di considerare:
- quanti audit prevedere ciascun anno (e possibilità di cambiare la frequenza);
- tempi di preavviso e casi di audit straordinari o a sorpresa;
- garanzie sulla riservatezza delle informazioni raccolte durante l'audit;
- modalità di gestione dei rilievi di audit;
- conseguenze delle non conformità (fino alla rescissione del contratto.
Ho trovato altre cose interessanti nella presentazione e quindi la segnalo.
- http://www.club-27001.fr/precedentes-reunions/paris/214-21-septembre-2017-transparents.html
L'ho trovata interessante soprattutto per quanto riguarda le riflessioni sul "diritto di audit". In effetti, spesso troviamo sui contratti una clausola molto generica e semplice. Invece la presentazione ci ricorda di considerare:
- quanti audit prevedere ciascun anno (e possibilità di cambiare la frequenza);
- tempi di preavviso e casi di audit straordinari o a sorpresa;
- garanzie sulla riservatezza delle informazioni raccolte durante l'audit;
- modalità di gestione dei rilievi di audit;
- conseguenze delle non conformità (fino alla rescissione del contratto.
Ho trovato altre cose interessanti nella presentazione e quindi la segnalo.
mercoledì 4 ottobre 2017
Il caso dello spesometro
Da un tweet di @a_oliveri segnalo questo breve articolo sul "caso spesometro" che è finito anche sui giornali:
- https://www.avvenire.it/economia/pagine/spesometro-bloccato-il-sito.
Come è noto non riporto solitamente notizie di attacchi. Ma questa mi permette di ricordare che è corretto pensare agli attacchi e agli hacker e alle intrusioni da Internet, ma è necessario pensare anche agli interni o ai fornitori che fanno errori o che installano aggiornamenti dei software. Anzi, forse questi sono i più difficili da controllare ("dagli amici mi guardi Iddio, che ai nemici ci penso io").
- https://www.avvenire.it/economia/pagine/spesometro-bloccato-il-sito.
Come è noto non riporto solitamente notizie di attacchi. Ma questa mi permette di ricordare che è corretto pensare agli attacchi e agli hacker e alle intrusioni da Internet, ma è necessario pensare anche agli interni o ai fornitori che fanno errori o che installano aggiornamenti dei software. Anzi, forse questi sono i più difficili da controllare ("dagli amici mi guardi Iddio, che ai nemici ci penso io").
giovedì 28 settembre 2017
Attacco a CCleaner
Un altro attacco che ho trovato interessante è quello a CCleaner:
- https://www.bleepingcomputer.com/news/security/ccleaner-compromised-to-distribute-malware-for-almost-a-month/;
- https://www.bleepingcomputer.com/news/security/avast-publishes-full-list-of-companies-affected-by-ccleaner-second-stage-malware/.
CCleaner è un'utilità che facilita la pulizia di disco, memoria e configurazioni di Windows. Qualcuno si è introdotto nei server di sviluppo e ha inserito del codice dannoso nei sorgenti di CCleaner.
Certamente gli attacchi possono essere più numerosi verso chi sviluppa prodotti di sicurezza (anche se CCleaner non è propriamente un prodotto di sicurezza), ma questo poteva capitare a tanti. Soprattutto in pochi, a differenza del produttore di CCleaner (da poco acquisito da Avast), si sarebbero accorti del problema.
Quindi: prestare attenzione ai prodotti che si installano sui propri pc e sulla propria rete. Soprattutto attenzione, come purtroppo fanno molti sistemisti, a installare prodotti in prova sulla rete aziendale.
L'attacco è stato rilevato grazie alla "recente" installazione del prodotto Morphisec della Cisco. Quindi ho un dubbio di quale sia la causa e quale l'effetto. Ma mi rendo conto che sto esagerando. Forse ;-)
- https://www.bleepingcomputer.com/news/security/ccleaner-compromised-to-distribute-malware-for-almost-a-month/;
- https://www.bleepingcomputer.com/news/security/avast-publishes-full-list-of-companies-affected-by-ccleaner-second-stage-malware/.
CCleaner è un'utilità che facilita la pulizia di disco, memoria e configurazioni di Windows. Qualcuno si è introdotto nei server di sviluppo e ha inserito del codice dannoso nei sorgenti di CCleaner.
Certamente gli attacchi possono essere più numerosi verso chi sviluppa prodotti di sicurezza (anche se CCleaner non è propriamente un prodotto di sicurezza), ma questo poteva capitare a tanti. Soprattutto in pochi, a differenza del produttore di CCleaner (da poco acquisito da Avast), si sarebbero accorti del problema.
Quindi: prestare attenzione ai prodotti che si installano sui propri pc e sulla propria rete. Soprattutto attenzione, come purtroppo fanno molti sistemisti, a installare prodotti in prova sulla rete aziendale.
L'attacco è stato rilevato grazie alla "recente" installazione del prodotto Morphisec della Cisco. Quindi ho un dubbio di quale sia la causa e quale l'effetto. Ma mi rendo conto che sto esagerando. Forse ;-)
Attacco a Verizon (e ai server sul cloud)
In questi giorni le notizie di attacco sono numerose.
Una su Deloitte: http://money.cnn.com/2017/09/25/technology/deloitte-hack-cybersecurity-guardian/index.html (da tweet di @stevedeft; probabilmente per un server DNS non in completa sicurezza con servizi RDP aperti su Internet);
Una sulla SEC: http://money.cnn.com/2017/09/21/news/sec-edgar-hack/index.html?iid=EL.
La più interessante, a mio parere, è quello di Verizon (dal Sans NewsBites): http://www.zdnet.com/article/another-verizon-leak-exposed-confidential-data-on-internal-systems/.
Infatti l'attacco a Verizon è avvenuto su server sul cloud AWS. Uno studio più ampio (accennato su
https://www.cyberscoop.com/verizon-wireless-s3-bucket-public-access-kromtech/) dimostra che sono tantissimi i server S3 non correttamente configurati.
Qui ripeto quanto già detto in altre occasioni e con altre parole: il cloud non è il bene né il male; purtroppo molti comprano server in cloud senza capire di cosa si tratta; pensano di risparmiare, fino a pensare di non avere più bisogno di sistemisti capaci di fare il loro lavoro (ho visto casi del genere). Invece un server in cloud va configurato e mantenuto come gli altri, senza poter risparmiare chissà quali cifre.
Una su Deloitte: http://money.cnn.com/2017/09/25/technology/deloitte-hack-cybersecurity-guardian/index.html (da tweet di @stevedeft; probabilmente per un server DNS non in completa sicurezza con servizi RDP aperti su Internet);
Una sulla SEC: http://money.cnn.com/2017/09/21/news/sec-edgar-hack/index.html?iid=EL.
La più interessante, a mio parere, è quello di Verizon (dal Sans NewsBites): http://www.zdnet.com/article/another-verizon-leak-exposed-confidential-data-on-internal-systems/.
Infatti l'attacco a Verizon è avvenuto su server sul cloud AWS. Uno studio più ampio (accennato su
https://www.cyberscoop.com/verizon-wireless-s3-bucket-public-access-kromtech/) dimostra che sono tantissimi i server S3 non correttamente configurati.
Qui ripeto quanto già detto in altre occasioni e con altre parole: il cloud non è il bene né il male; purtroppo molti comprano server in cloud senza capire di cosa si tratta; pensano di risparmiare, fino a pensare di non avere più bisogno di sistemisti capaci di fare il loro lavoro (ho visto casi del genere). Invece un server in cloud va configurato e mantenuto come gli altri, senza poter risparmiare chissà quali cifre.
venerdì 22 settembre 2017
Il caso Equifax
Il primo a darmi notizia del caso Equifax è stato Sandro Sanna:
- http://money.cnn.com/2017/09/08/technology/equifax-hack-qa/.
Questo è un articolo più approfondito di Bloomberg (grazie a un tweet di @carolafrediani):
- https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros.
Equifax è un'azienda che raccoglie dati da varie compagnie (carte di credito, banche, eccetera) e fornisce valutazioni sulla situazione economica delle persone. Immagino sia ad una centrale del rischio.
Da quello che ho capito, gli attaccanti hanno sfruttato una vulnerabilità nota e pericolosa di Apache e sono riusciti ad accedere al sistema informatico di Equifax, ossia ai dati di 143 milioni di cittadini USA (pare ci siano anche dati di cittadini UK e chissà di chi altro).
Il caso è ovviamente esploso anche perché hanno scoperto che il responsabile della sicurezza informatica era una persona senza competenze tecnologiche (grazie ad Alberto Viganò per questa segnalazione):
- http://www.marketwatch.com/story/equifax-ceo-hired-a-music-major-as-the-companys-chief-security-officer-2017-09-15.
Alberto ha subito pensato ai nostri futuri DPO, spesso con competenze incerte.
Il caso, secondo me, è molto semplice, anche se la semplicità è nascosta dal polverone mediatico. Bisogna aggiornare dei server, ma nessuno lo fa perché bisogna interrompere il servizio per qualche tempo, richiede tempo, è noioso, ci sono cose più interessanti da fare. Il responsabile della sicurezza (anche se con competenze inadeguate), magari ha segnalato il problema, ha chiesto soldi per segmentare meglio la rete, ha telefonato ogni giorno ai sistemisti perché facessero gli aggiornamenti, ha chiesto ogni giorno ai "capi" di autorizzare l'interruzione del servizio per un'oretta. Ma tutti avevano cose più interessanti da fare e la manutenzione della "macchina IT" aveva priorità bassissima.
Anche noi, nel nostro piccolo, non abbiamo voglia di portare l'automobile a fare il tagliando o la revisione periodica e neanche il cambio gomme stagionale. Però lo facciamo perché sappiamo che è importante per la nostra sicurezza e perché le forze dell'ordine potrebbero bloccarci la macchina.
Semplicemente, i "capi" delle aziende non sono consapevoli di questo. Non si rendono conto che i sistemi informatici sono oggetti potentissimi ma anche delicatissimi e che richiedono manutenzione.
Semplice. L'avevo già detto, ma lo sappiamo tutti (basta parlare per qualche minuto di IT con qualunque manager italiano o straniero). E quindi la notizia dov'è? Solo nei numeri elevati di questo ennesimo caso.
- http://money.cnn.com/2017/09/08/technology/equifax-hack-qa/.
Questo è un articolo più approfondito di Bloomberg (grazie a un tweet di @carolafrediani):
- https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros.
Equifax è un'azienda che raccoglie dati da varie compagnie (carte di credito, banche, eccetera) e fornisce valutazioni sulla situazione economica delle persone. Immagino sia ad una centrale del rischio.
Da quello che ho capito, gli attaccanti hanno sfruttato una vulnerabilità nota e pericolosa di Apache e sono riusciti ad accedere al sistema informatico di Equifax, ossia ai dati di 143 milioni di cittadini USA (pare ci siano anche dati di cittadini UK e chissà di chi altro).
Il caso è ovviamente esploso anche perché hanno scoperto che il responsabile della sicurezza informatica era una persona senza competenze tecnologiche (grazie ad Alberto Viganò per questa segnalazione):
- http://www.marketwatch.com/story/equifax-ceo-hired-a-music-major-as-the-companys-chief-security-officer-2017-09-15.
Alberto ha subito pensato ai nostri futuri DPO, spesso con competenze incerte.
Il caso, secondo me, è molto semplice, anche se la semplicità è nascosta dal polverone mediatico. Bisogna aggiornare dei server, ma nessuno lo fa perché bisogna interrompere il servizio per qualche tempo, richiede tempo, è noioso, ci sono cose più interessanti da fare. Il responsabile della sicurezza (anche se con competenze inadeguate), magari ha segnalato il problema, ha chiesto soldi per segmentare meglio la rete, ha telefonato ogni giorno ai sistemisti perché facessero gli aggiornamenti, ha chiesto ogni giorno ai "capi" di autorizzare l'interruzione del servizio per un'oretta. Ma tutti avevano cose più interessanti da fare e la manutenzione della "macchina IT" aveva priorità bassissima.
Anche noi, nel nostro piccolo, non abbiamo voglia di portare l'automobile a fare il tagliando o la revisione periodica e neanche il cambio gomme stagionale. Però lo facciamo perché sappiamo che è importante per la nostra sicurezza e perché le forze dell'ordine potrebbero bloccarci la macchina.
Semplicemente, i "capi" delle aziende non sono consapevoli di questo. Non si rendono conto che i sistemi informatici sono oggetti potentissimi ma anche delicatissimi e che richiedono manutenzione.
Semplice. L'avevo già detto, ma lo sappiamo tutti (basta parlare per qualche minuto di IT con qualunque manager italiano o straniero). E quindi la notizia dov'è? Solo nei numeri elevati di questo ennesimo caso.
giovedì 21 settembre 2017
Nuove specifiche NIST per le password
Considerazioni sulle nuove specifiche NIST per le password le avevo già scritte in questo blog.
Sullo stesso argomento ho scritto un articolo per ICT Security Magazine un poco più lungo del post originario. L'articolo ha titolo "Nuove specifiche NIST per le password":
https://www.ictsecuritymagazine.com/articoli/nuove-specifiche-nist-le-password/.
Sullo stesso argomento ho scritto un articolo per ICT Security Magazine un poco più lungo del post originario. L'articolo ha titolo "Nuove specifiche NIST per le password":
https://www.ictsecuritymagazine.com/articoli/nuove-specifiche-nist-le-password/.
lunedì 18 settembre 2017
Il Garante privacy e i requisiti del DPO
La newsletter del Garante (e Franco Ferrari del DNV GL, che ringrazio) mi segnalano questo articolo dal titolo "Regolamento privacy, come scegliere il responsabile della protezione dei dati":
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/6826945#1.
Mi pare divertente leggere che "Non sono richieste attestazioni formali sul possesso delle conoscenze o l'iscrizione ad appositi albi professionali". Lo dicevo da tempo.
Trovo che la corsa alle certificazioni non sempre sia giustificata. Vorrei si promuovessero dei corsi seri e dei momenti di approfondimento, anche senza certificazioni e senza spargimenti di terrore per l'entrata in vigore del GDPR.
Nota: un momento di approfondimento è quello che abbiamo organizzato come DFA il 27 settembre
(http://www.perfezionisti.it/open-day/dfa-open-day-2017/). I posti (gratuiti) sono esauriti e l'associazione è senza cassa; quindi posso anche fare questa pubblicità!
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/6826945#1.
Mi pare divertente leggere che "Non sono richieste attestazioni formali sul possesso delle conoscenze o l'iscrizione ad appositi albi professionali". Lo dicevo da tempo.
Trovo che la corsa alle certificazioni non sempre sia giustificata. Vorrei si promuovessero dei corsi seri e dei momenti di approfondimento, anche senza certificazioni e senza spargimenti di terrore per l'entrata in vigore del GDPR.
Nota: un momento di approfondimento è quello che abbiamo organizzato come DFA il 27 settembre
(http://www.perfezionisti.it/open-day/dfa-open-day-2017/). I posti (gratuiti) sono esauriti e l'associazione è senza cassa; quindi posso anche fare questa pubblicità!
Accesso del datore di lavoro a email e IM - Sentenza Barbulescu
Interessante caso della Corte di giustizia europea che verrà ricordato, penso, come "Sentenza Barbulescu".
Vediamo se ho capito bene (in caso contrario, scrivetemi):
- Barbulescu lavora per un'azienda, che gli chiede di aprire un account all'instant messaging di Yahoo per comunicare con i clienti;
- Barbulescu usa lo stesso account per scambiare messaggi con la fidanzata e il fratello;
- l'azienda se ne accorge, si legge e stampa 45 pagine (!) di messaggi di Barbulescu e lo licenzia;
- Barbulescu fa ricorso fino alla Corte di giustizia europea;
- la Corte di giustizia europea, a dicembre 2016, dà ragione all'azienda;
- la Grand chamber of human rights, a settembre 2017, dà invece ragione a Barbulescu (comminando però una multa molto bassa).
A me interessa capire cosa ha fatto l'azienda per dimostrare la propria ragione. Ossia le misure ritenute "corrette" dai giudici. Quindi, dalla sentenza della Corte di giustizia europea, ricavo quanto segue:
- l'azienda, nel regolamento interno, aveva ben specificato che era vietato l'uso dei pc aziendali per scopi personali;
- Barbulescu aveva asserito di aver usato il proprio account Yahoo solo per scopi di lavoro (non solo mentendo, ma dichiarando quindi che Yahoo non riguardava dati personali e poi, illogicamente, da qualche punto di vista, lamentandosi dell'invasione della propria privacy);
- comunque l'azienda, licenziandolo, non ha menzionato nelle motivazioni il contenuto dei messaggi, ma solo al fatto che fossero "non di lavoro";
- l'azienda aveva "limitato" l'indagine al solo account di Yahoo (non al pc o altro) e in un tempo limitato (pochi giorni e solo in orario di lavoro) e quindi in modo "limitato e proporzionato".
La Grand chamber, per contro, mi pare abbia notato che il regolamento interno non specificava le modalità di controllo delle comunicazioni Internet (ossia di come l'azienda intendesse verificare email, IM, eccetera).
Ricordo che, fino ad un certo punto, non sono favorevole al controllo dei lavoratori. Ma è importante capire come si può agire in caso di abuso.
La sentenza della Grand chamber (grazie a Pierfrancesco Maistrello):
- http://www.dirittoegiustizia.it/allegati/PP_INTERN_CEDU_milizia_s_4.pdf.
Un articolo segnalato da Pierfrancesco Maistrello:
- https://strasbourgobservers.com/2016/12/20/resuscitating-workplace-privacy-a-brief-account-of-the-grand-chamber-hearing-in-barbulescu-v-romania/.
Un articolo di Altalex:
- http://www.altalex.com/documents/news/2017/09/06/datore-controllo-mail-lavoratore.
La notizia l'ho avuta inizialmente da ictBusiness.it, ma l'articolo non mi era chiaro (infatti il solito Pierfrancesco Maistrello mi ha dovuto correggere):
- http://www.ictbusiness.it/cont/news/email-dei-lavoratori-controllate-l-europa-dice-si-con-limiti/40030/1.html.
La sentenza di dicembre (il primo link segnalato da Qwant che permette di scaricarla):
- http://www.federalismi.it/nv14/articolo-documento.cfm?Artid=31234.
Infine una domanda: ora quale sentenza dovrà essere seguita? Quella della Corte di giustizia o quella della Grand chamber?
Vediamo se ho capito bene (in caso contrario, scrivetemi):
- Barbulescu lavora per un'azienda, che gli chiede di aprire un account all'instant messaging di Yahoo per comunicare con i clienti;
- Barbulescu usa lo stesso account per scambiare messaggi con la fidanzata e il fratello;
- l'azienda se ne accorge, si legge e stampa 45 pagine (!) di messaggi di Barbulescu e lo licenzia;
- Barbulescu fa ricorso fino alla Corte di giustizia europea;
- la Corte di giustizia europea, a dicembre 2016, dà ragione all'azienda;
- la Grand chamber of human rights, a settembre 2017, dà invece ragione a Barbulescu (comminando però una multa molto bassa).
A me interessa capire cosa ha fatto l'azienda per dimostrare la propria ragione. Ossia le misure ritenute "corrette" dai giudici. Quindi, dalla sentenza della Corte di giustizia europea, ricavo quanto segue:
- l'azienda, nel regolamento interno, aveva ben specificato che era vietato l'uso dei pc aziendali per scopi personali;
- Barbulescu aveva asserito di aver usato il proprio account Yahoo solo per scopi di lavoro (non solo mentendo, ma dichiarando quindi che Yahoo non riguardava dati personali e poi, illogicamente, da qualche punto di vista, lamentandosi dell'invasione della propria privacy);
- comunque l'azienda, licenziandolo, non ha menzionato nelle motivazioni il contenuto dei messaggi, ma solo al fatto che fossero "non di lavoro";
- l'azienda aveva "limitato" l'indagine al solo account di Yahoo (non al pc o altro) e in un tempo limitato (pochi giorni e solo in orario di lavoro) e quindi in modo "limitato e proporzionato".
La Grand chamber, per contro, mi pare abbia notato che il regolamento interno non specificava le modalità di controllo delle comunicazioni Internet (ossia di come l'azienda intendesse verificare email, IM, eccetera).
Ricordo che, fino ad un certo punto, non sono favorevole al controllo dei lavoratori. Ma è importante capire come si può agire in caso di abuso.
La sentenza della Grand chamber (grazie a Pierfrancesco Maistrello):
- http://www.dirittoegiustizia.it/allegati/PP_INTERN_CEDU_milizia_s_4.pdf.
Un articolo segnalato da Pierfrancesco Maistrello:
- https://strasbourgobservers.com/2016/12/20/resuscitating-workplace-privacy-a-brief-account-of-the-grand-chamber-hearing-in-barbulescu-v-romania/.
Un articolo di Altalex:
- http://www.altalex.com/documents/news/2017/09/06/datore-controllo-mail-lavoratore.
La notizia l'ho avuta inizialmente da ictBusiness.it, ma l'articolo non mi era chiaro (infatti il solito Pierfrancesco Maistrello mi ha dovuto correggere):
- http://www.ictbusiness.it/cont/news/email-dei-lavoratori-controllate-l-europa-dice-si-con-limiti/40030/1.html.
La sentenza di dicembre (il primo link segnalato da Qwant che permette di scaricarla):
- http://www.federalismi.it/nv14/articolo-documento.cfm?Artid=31234.
Infine una domanda: ora quale sentenza dovrà essere seguita? Quella della Corte di giustizia o quella della Grand chamber?
venerdì 15 settembre 2017
Rasperry Pi e la insecurity by default
Bruce Schneier ha segnalato una guida per mettere in sicurezza i computer Rasperry Pi, ossia i dispositivi più diffusi per sviluppare gli oggetti dell'Internet of things.
Il post di Bruce Schneier:
https://www.schneier.com/blog/archives/2017/09/securing_a_rasp.html.
L'articolo "Take These Steps to Secure Your Raspberry Pi Against Attackers":
https://makezine.com/2017/09/07/secure-your-raspberry-pi-against-attackers/.
Il punto, come dice Bruce Schneier, non è tanto studiare come mettere in sicurezza un Rasperry Pi, quanto notare la difficoltà per farlo. Purtroppo la difficoltà a metterli in sicurezza è comune a tutti i computer. Forse il Windows, pur con tutti i suoi problemi, è tra i più semplici e questo dà l'idea del problema. Continuiamo infatti a produrre, comprare e usare prodotti difficili da mettere in sicurezza.
La security-by-design (e quindi la privacy-by-design) è quindi un'utopia. L'insecurity-by-design è invece quello che c'è. Rendiamocene conto e cerchiamo di conviverci.
Il post di Bruce Schneier:
https://www.schneier.com/blog/archives/2017/09/securing_a_rasp.html.
L'articolo "Take These Steps to Secure Your Raspberry Pi Against Attackers":
https://makezine.com/2017/09/07/secure-your-raspberry-pi-against-attackers/.
Il punto, come dice Bruce Schneier, non è tanto studiare come mettere in sicurezza un Rasperry Pi, quanto notare la difficoltà per farlo. Purtroppo la difficoltà a metterli in sicurezza è comune a tutti i computer. Forse il Windows, pur con tutti i suoi problemi, è tra i più semplici e questo dà l'idea del problema. Continuiamo infatti a produrre, comprare e usare prodotti difficili da mettere in sicurezza.
La security-by-design (e quindi la privacy-by-design) è quindi un'utopia. L'insecurity-by-design è invece quello che c'è. Rendiamocene conto e cerchiamo di conviverci.
martedì 5 settembre 2017
Articolo su eIDAS
Fabrizio Cirilli (PDCA S.r.l.) mi ha segnalato un articolo dal titolo "Regolamento eIDAS (EU 910/2014) e direttive italiane in materia di digitalizzazione", che ha scritto con Riccardo Bianconi (ispettore Accredia). Si trova sulla rivista KnowIT (bisogna registrarsi per scaricarla):
- https://www.knowit.clioedu.it/rivista.
Personalmente, sarei stato più esplicito in alcune considerazioni (nell'articolo si accenna allo sforzo necessario per vedere tutti gli HSM e alle eccessive ridondanze delle check list AgID). In particolare avrei indicato anche alcune questioni relative al controllo dei fornitori, a mio parere non corrette, come già detto in altre occasioni (http://blog.cesaregallotti.it/2015/10/per-agid-linformatica-e-ferma-agli-anni.html).
Però penso che questo articolo sia un buon riferimento per ragionare in merito all'applicazione del Regolamento eIDAS in Italia.
- https://www.knowit.clioedu.it/rivista.
Personalmente, sarei stato più esplicito in alcune considerazioni (nell'articolo si accenna allo sforzo necessario per vedere tutti gli HSM e alle eccessive ridondanze delle check list AgID). In particolare avrei indicato anche alcune questioni relative al controllo dei fornitori, a mio parere non corrette, come già detto in altre occasioni (http://blog.cesaregallotti.it/2015/10/per-agid-linformatica-e-ferma-agli-anni.html).
Però penso che questo articolo sia un buon riferimento per ragionare in merito all'applicazione del Regolamento eIDAS in Italia.
Software, controllo dei lavoratori e Ispettorato del Lavoro
Segnalo questo articolo di Filodiritto dal titolo "Controllo dei lavoratori - Ispettorato Nazionale del Lavoro: alcuni software di gestione dell'attività dei Call Center configurano un controllo a distanza dei lavoratori":
- https://www.filodiritto.com/news/2017/controllo-dei-lavoratori-ispettorato-nazionale-del-lavoro-alcuni-software-di-gestione-dellattivita-dei-call-center.html.
Ho trovato molto interessante la terza pagina, dove sono riassunte le due tipologie di software che possono comportare il controllo dei lavoratori e le quanto è necessario fare.
- https://www.filodiritto.com/news/2017/controllo-dei-lavoratori-ispettorato-nazionale-del-lavoro-alcuni-software-di-gestione-dellattivita-dei-call-center.html.
Ho trovato molto interessante la terza pagina, dove sono riassunte le due tipologie di software che possono comportare il controllo dei lavoratori e le quanto è necessario fare.
martedì 29 agosto 2017
Pubblicata ISO/IEC 29151
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.
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.
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...
Iscriviti a:
Post (Atom)