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 ;-)
giovedì 28 settembre 2017
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...
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.
Iscriviti a:
Post (Atom)