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.
Iscriviti a:
Post (Atom)