Massimo Cottafavi di Spike Reply mi ha segnalato lo schema di Provvedimento
del Garante in materia di biometria:
-
http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3
132642
In particolare, mi ha segnalato le citazioni della ISO/IEC 27001. In poche
parole, il Garante prevede per le organizzazioni certificate ISO/IEC 27001
delle semplificazioni in materia di misure di sicurezza per gli strumenti
biometrici.
Non mi dilungo su alcune imprecisioni, la prima delle quali è che parla di
un'inesistente ISO/IEC 27001:2006 e che non prende in considerazione la
nuova norma del 2013 o la sua traduzione del 2014.
Il punto chiave è che sono esonerati dall'obbligo di istanza di verifica
preliminare le organizzazioni già certificate ISO/IEC 27001 che estendono il
proprio ambito di certificazione ai meccanismi crittografici. Per chi non è
certificato è disponibile un percorso diverso. Massimo Cottafavi riflette:
"se uno è certificato ma non intende ampliare l'ambito di certificazione
(per tanti motivi, il primo dei quali è il costo), apparentemente non può
neanche seguire la strada alternativa".
Penso che abbia ragione e spero che il Garante modifichi il Provvedimento
(ho mandato la riflessione seguendo la procedura).
Sicurezza delle informazioni, IT service management e qualità da Cesare Gallotti
lunedì 23 giugno 2014
sabato 14 giugno 2014
Libro "Sicurezza delle informazioni"
Finalmente ce l'ho fatta e ho pubblicato il mio libro "Sicurezza delle
informazioni". Si trova in formato pdf in alcune librerie on-line. Per il formato epub bisogna aspettare qualche giorno perché deve essere validato. Personalmente preferisco il formato pdf.
Nelle librerie che seguono c'è sicuramente, ma, quando il formato epub sarà validato, si troverà anche sui celeberrimi Amazon e Ibs:
- http://www.ultimabooks.it;
- http://libreriarizzoli.corriere.it
- http://www.bookrepublic.it
- http://www.deastore.com
- http://www.cubolibri.it
- http://www.hoepli.it
- http://www.libreriaebook.it
- http://www.biblonstore.it
- http://ebook.unita.it
La versione "giusta" è quella del 10 giugno e vi invito a guardare
l'anteprima per vedere gli argomenti trattati (analisi del rischio, ISO/IEC
27001 e non solo) e quindi decidere se vi interessa.
L'ho pubblicato come self-publisher tramite la piattaforma Narcissus.me. Un
nome un programma. Ed è stato molto divertente, anche se terribilmente faticoso.
informazioni". Si trova in formato pdf in alcune librerie on-line. Per il formato epub bisogna aspettare qualche giorno perché deve essere validato. Personalmente preferisco il formato pdf.
Nelle librerie che seguono c'è sicuramente, ma, quando il formato epub sarà validato, si troverà anche sui celeberrimi Amazon e Ibs:
- http://www.ultimabooks.it;
- http://libreriarizzoli.corriere.it
- http://www.bookrepublic.it
- http://www.deastore.com
- http://www.cubolibri.it
- http://www.hoepli.it
- http://www.libreriaebook.it
- http://www.biblonstore.it
- http://ebook.unita.it
La versione "giusta" è quella del 10 giugno e vi invito a guardare
l'anteprima per vedere gli argomenti trattati (analisi del rischio, ISO/IEC
27001 e non solo) e quindi decidere se vi interessa.
L'ho pubblicato come self-publisher tramite la piattaforma Narcissus.me. Un
nome un programma. Ed è stato molto divertente, anche se terribilmente faticoso.
venerdì 13 giugno 2014
Privacy e cookie
Il Garante privacy, con Provvedimento Generale dell'8 maggio 2014, ha
regolamentato l'uso dei cookie dei siti web:
-
http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3
118884
Ne faccio un brevissimo riassunto:
- per i cookie tecnici è richiesta l'informativa con le modalità più idonee;
- per i cookie di profilazione è richiesta l'informativa e il consenso; si
può presentare all'utente solo un'informativa breve (banner), purché sia
comunque disponibile un'informativa lunga.
Non mi pare cambi molto rispetto a quanto già fatto da molti siti web.
regolamentato l'uso dei cookie dei siti web:
-
http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3
118884
Ne faccio un brevissimo riassunto:
- per i cookie tecnici è richiesta l'informativa con le modalità più idonee;
- per i cookie di profilazione è richiesta l'informativa e il consenso; si
può presentare all'utente solo un'informativa breve (banner), purché sia
comunque disponibile un'informativa lunga.
Non mi pare cambi molto rispetto a quanto già fatto da molti siti web.
giovedì 12 giugno 2014
Draft ISO 9001:2015
La nuova ISO 9001 è allo stato DIS, ossia Draft. Secondo i miei calcoli, se
il consenso sarà sufficiente, a novembre sarà disponibile il final draft e a
inizio 2015 uscirà la nuova norma.
Devo dire che il lavoro mi sembra notevole, anche per i miglioramenti
introdotti all'HLS e all'esplicitazione di aspetti che nella ISO/IEC 27001
sono stati invece ritenuti "impliciti".
In molti hanno scritto sulle novità della norma, soprattutto sull'analisi
del rischio (a cui è anche dedicato un paragrafo nell'introduzione). Io vedo
anche sottolineati: l'attenzione al cliente, il controllo dei cambiamenti,
la conoscenza complessiva dell'organizzazione. Io sottolineo il fatto che
non si parla più di "risorse umane" ma di "persone" e lo trovo un bel
segnale.
Invito quanti vogliono condividere approfondimenti sulla nuova ISO 9001 a
segnalarmeli o inviarmeli.
Consiglio però di aspettare il final draft prima di trarre conclusioni
sull'attuazione della ISO 9001. Potrebbe infatti essere ampiamente
modificata, anche se in molti lo ritengono improbabile.
il consenso sarà sufficiente, a novembre sarà disponibile il final draft e a
inizio 2015 uscirà la nuova norma.
Devo dire che il lavoro mi sembra notevole, anche per i miglioramenti
introdotti all'HLS e all'esplicitazione di aspetti che nella ISO/IEC 27001
sono stati invece ritenuti "impliciti".
In molti hanno scritto sulle novità della norma, soprattutto sull'analisi
del rischio (a cui è anche dedicato un paragrafo nell'introduzione). Io vedo
anche sottolineati: l'attenzione al cliente, il controllo dei cambiamenti,
la conoscenza complessiva dell'organizzazione. Io sottolineo il fatto che
non si parla più di "risorse umane" ma di "persone" e lo trovo un bel
segnale.
Invito quanti vogliono condividere approfondimenti sulla nuova ISO 9001 a
segnalarmeli o inviarmeli.
Consiglio però di aspettare il final draft prima di trarre conclusioni
sull'attuazione della ISO 9001. Potrebbe infatti essere ampiamente
modificata, anche se in molti lo ritengono improbabile.
Social privacy
Franco Ferrari di DNV GL mi ha segnalato l'aggiornamento della pubblicazione
del Garante della privacy dal titolo " Social privacy. Come tutelarsi
nell'era dei social network":
-
http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3
140082
La pubblicazione è indirizzata ai "ragazzi", ma ci sono molti consigli utili
ed è sicuramente utile anche agli adulti (alcuni miei contatti
"professionali" su Facebook dovrebbero forse ricordarsi che non hanno
chiesto l'amicizia solo ai veri amici...).
del Garante della privacy dal titolo " Social privacy. Come tutelarsi
nell'era dei social network":
-
http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3
140082
La pubblicazione è indirizzata ai "ragazzi", ma ci sono molti consigli utili
ed è sicuramente utile anche agli adulti (alcuni miei contatti
"professionali" su Facebook dovrebbero forse ricordarsi che non hanno
chiesto l'amicizia solo ai veri amici...).
martedì 10 giugno 2014
DFA Open Day 2014 - Materiale
Vi segnalo il materiale del DFA Open Day 2014:
- http://www.perfezionisti.it/proposte-formative/dfa-open-day-2014/
E' stato un evento molto bello, con circa 100 persone e molti spunti
interessanti.
- http://www.perfezionisti.it/proposte-formative/dfa-open-day-2014/
E' stato un evento molto bello, con circa 100 persone e molti spunti
interessanti.
Presentazione sul rischio informatico
Enrico Luigi Toso di DB Consorzio mi ha inviato una interessante
presentazione dal titolo "Circolare Banca d'Italia 263 Cap. 8 – Il Rischio
informatico: Un inquadramento metodologico per favorire l'integrazione del
rischio informatico nella gestione del rischio operativo".
Lettura quanto meno impegnativa ma molto interessante e che consiglio perché
ci sono cose molto interessanti sulla valutazione del rischio, applicabili
anche in ambiente non bancario.
Qualche esempio: riflessione sul rapporto tra rendimento e rischio e sul
rapporto tra adeguamento normativo e rischio, suggerimento di analizzare il
rischio per processi e non per asset (anche se poi questi si ripresentano).
Non c'è solo questo, ovviamente.
Il materiale si troverà sul sito (sono richieste credenziali di accesso
fornite dopo registrazione):
- http://www.abieventi.it/eventi/2044/banche-e-sicurezza-2014/
presentazione dal titolo "Circolare Banca d'Italia 263 Cap. 8 – Il Rischio
informatico: Un inquadramento metodologico per favorire l'integrazione del
rischio informatico nella gestione del rischio operativo".
Lettura quanto meno impegnativa ma molto interessante e che consiglio perché
ci sono cose molto interessanti sulla valutazione del rischio, applicabili
anche in ambiente non bancario.
Qualche esempio: riflessione sul rapporto tra rendimento e rischio e sul
rapporto tra adeguamento normativo e rischio, suggerimento di analizzare il
rischio per processi e non per asset (anche se poi questi si ripresentano).
Non c'è solo questo, ovviamente.
Il materiale si troverà sul sito (sono richieste credenziali di accesso
fornite dopo registrazione):
- http://www.abieventi.it/eventi/2044/banche-e-sicurezza-2014/
domenica 8 giugno 2014
Google e diritto all'oblio
La notizia si è molto diffusa ed è questa: la Corte di Giustizia UE ha
stabilito che un motore di ricerca è un titolare di trattamenti di dati
personali e pertanto devono far sparire dalle ricerche le tracce della
persona che vuole essere "dimenticata":
-
http://www.repubblica.it/tecnologia/2014/05/13/news/causa_contro_google_cort
e_ue_motore_di_ricerca_responsabile_dati-85985943/
Mi sto chiedendo se questo sia un bene (se penso a persone accusate
ingiustamente di cui rimane traccia per sempre senza alcun collegamento a
notizie aggiornate) o un male.
Ad ogni modo, questa è la sentenza:
-
http://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:62012CJ0131&qi
d=1401432812901&from=EN
e questo è un commento critico alla sentenza:
-
http://www.filodiritto.com/note-critiche-alla-presunta-salvaguardia-del-diri
tto-alloblio-in-capo-a-chi-non-dovrebbe-e-non-potrebbe-il-motore-di-ricerca/
stabilito che un motore di ricerca è un titolare di trattamenti di dati
personali e pertanto devono far sparire dalle ricerche le tracce della
persona che vuole essere "dimenticata":
-
http://www.repubblica.it/tecnologia/2014/05/13/news/causa_contro_google_cort
e_ue_motore_di_ricerca_responsabile_dati-85985943/
Mi sto chiedendo se questo sia un bene (se penso a persone accusate
ingiustamente di cui rimane traccia per sempre senza alcun collegamento a
notizie aggiornate) o un male.
Ad ogni modo, questa è la sentenza:
-
http://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:62012CJ0131&qi
d=1401432812901&from=EN
e questo è un commento critico alla sentenza:
-
http://www.filodiritto.com/note-critiche-alla-presunta-salvaguardia-del-diri
tto-alloblio-in-capo-a-chi-non-dovrebbe-e-non-potrebbe-il-motore-di-ricerca/
Password codificate e password di default
Dal SANS Newbyte trovo questa deliziosa notizia: il Department of Homeland
Security (DHS) statunitense ha avvisato gli operatori dei pannelli stradali
Daktronics Vanguard che questi possono essere attaccati a causa delle
password codificate in essi.
Risposta della Daktronics Vanguard: "non si tratta di password codificate,
ma di password di default non modificate".
Due cattive pratiche al prezzo di una:
-
http://www.nextgov.com/cybersecurity/2014/06/flaw-lets-hackers-control-elect
ronic-highway-billboards/85849/
Security (DHS) statunitense ha avvisato gli operatori dei pannelli stradali
Daktronics Vanguard che questi possono essere attaccati a causa delle
password codificate in essi.
Risposta della Daktronics Vanguard: "non si tratta di password codificate,
ma di password di default non modificate".
Due cattive pratiche al prezzo di una:
-
http://www.nextgov.com/cybersecurity/2014/06/flaw-lets-hackers-control-elect
ronic-highway-billboards/85849/
OpenSSL - Ancora!
In tanti hanno scritto delle nuove vulnerabilità riscontrate su OpenSSL. Io
scelgo un link presentato dal SANS Newsbyte:
- http://www.theregister.co.uk/2014/06/05/openssl_bug_batch/
Sembra che, una volta trovato un nuovo giocattolo, tutti vogliano
divertirsi.
Un editor del SANS (Northcutt) dice: "se stai usando OpenSSL, non agitarti
perché i suoi sviluppatori ci stanno lavorando; se non stai usando OpenSSL,
ci si può chiedere se il tuo prodotto è sicuro".
Aggiungo quanto scritto da Stefano Ramacciotti in una discussione sul gruppo Sikurezza.org di LinkedIn: "Il problema non è la crittografia, ma la sua implementazione; il protocollo SSL è a posto; se dovessimo scrivere un nuovo programma per SSL, non solo si rischierebbe di sbagliare ancora nello sviluppo, ma anche nell'implementazione del protocollo stesso".
scelgo un link presentato dal SANS Newsbyte:
- http://www.theregister.co.uk/2014/06/05/openssl_bug_batch/
Sembra che, una volta trovato un nuovo giocattolo, tutti vogliano
divertirsi.
Un editor del SANS (Northcutt) dice: "se stai usando OpenSSL, non agitarti
perché i suoi sviluppatori ci stanno lavorando; se non stai usando OpenSSL,
ci si può chiedere se il tuo prodotto è sicuro".
Aggiungo quanto scritto da Stefano Ramacciotti in una discussione sul gruppo Sikurezza.org di LinkedIn: "Il problema non è la crittografia, ma la sua implementazione; il protocollo SSL è a posto; se dovessimo scrivere un nuovo programma per SSL, non solo si rischierebbe di sbagliare ancora nello sviluppo, ma anche nell'implementazione del protocollo stesso".
venerdì 30 maggio 2014
TrueCrypt
La notizia ha fatto subito il giro del mondo: gli sviluppatori di TrueCrypt hanno dichiarato la fine dello sviluppo e della manutenzione dello strumento più noto e affidabile per cifrare hard disk o singoli file e cartelle:
- http://krebsonsecurity.com/2014/05/true-goodbye-using-truecrypt-is-not-secure/
- http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/
Il sito ufficiale è questo:
- http://truecrypt.sourceforge.net
Alcuni suggeriscono strumenti come BitLocker di Windows e altre cose che mi sembrano molto meno intuitive e facili da utilizzare (con TrueCrypt è facilissimo creare una cartella cifrata da copiare-incollare quando se ne fa il backup).
Alcuni però sostengono che si tratti di un attacco al sito web di TrueCrypt e che la versione 7.2 pubblicata sia un falso. Quindi cosa fare? Io, non l'avessi già sul mio pc, scaricherei da qui la versione 7.1a (quella per Windows ha nome " TrueCrypt Setup 7.1a.exe"):
- https://github.com/DrWhax/truecrypt-archive
- http://krebsonsecurity.com/2014/05/true-goodbye-using-truecrypt-is-not-secure/
- http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/
Il sito ufficiale è questo:
- http://truecrypt.sourceforge.net
Alcuni suggeriscono strumenti come BitLocker di Windows e altre cose che mi sembrano molto meno intuitive e facili da utilizzare (con TrueCrypt è facilissimo creare una cartella cifrata da copiare-incollare quando se ne fa il backup).
Alcuni però sostengono che si tratti di un attacco al sito web di TrueCrypt e che la versione 7.2 pubblicata sia un falso. Quindi cosa fare? Io, non l'avessi già sul mio pc, scaricherei da qui la versione 7.1a (quella per Windows ha nome " TrueCrypt Setup 7.1a.exe"):
- https://github.com/DrWhax/truecrypt-archive
venerdì 23 maggio 2014
Accreditamento conservazione digitale (commenti)
In merito agli aggiornamenti relativi ai regolamenti sulla conservazione
digitale
(http://blog.cesaregallotti.it/2014/05/accreditamento-conservazione-digitale
.html), Franco Ruggieri mi ha inviato alcune considerazioni molto
interessanti che riporto.
E' vero che nel DPCM 3/12/2013 non c'è alcun riferimento allo ISO/IEC 27001,
mentre c'è nella successiva Circolare AgID 65/2014. Insomma: la Circolare
mette una pezza al buco del DPCM.
Faccio notare che è stato pubblicato da AgID un altro documento che ritengo
di estremo interesse per i conservatori che, però ha un titolo chilometrico:
"Accreditamento dei soggetti pubblici e privati che svolgono attività di
conservazione dei documenti
informatici - Requisiti di qualità e sicurezza per l'accreditamento e la
vigilanza"
Ebbene, questo documento esplode nei minimi particolari i requisiti da
rispettare, riportando per ognuno la clause dello OAIS (ISO 14721) e dello
ETSI TS 101 533-01. Insomma: la certificazione ISO/IEC 27001 potrà (o forse
"dovrà") essere fatta avvalendosi del TS 101 533-01 come punto di
riferimento per le misure di sicurezza da attuare. D'altronde ad oggi non
c'è altro documento a cui rifarsi per un conservatore.
Peccato che questo TS sia stato redatto (e tradotto da UNI nella serie
UNI/TS/TR 11465-1-2-3) nel 2012, quando cioè la versione ISO/IEC 27001 del
2013 ancora non era nata.
Aggiungo che, anche se il documento di "Requisiti di qualità e sicurezza per
l'accreditamento" è solo una linea guida, senza la forza né di una Circolare
né di uno strumento giuridico, è sempre un documento emesso da chi fa la
vigilanza. È quindi molto probabile che AgID si baserà su di esso e sui
documenti da esso referenziati.
C'è un altro punto: si fa riferimento al TS 101 533-01 come
"raccomandazione", mentre invece è una "specifica". Inoltre il DPCM si
riferisce all'elenco dove è riportato come "elenco di specifiche". In
definitiva: quanto indicato nella tabellona del documento "Requisiti di
qualità e sicurezza per l'accreditamento e la vigilanza" diventa cogente,
compresa la specifica ETSI TS 101 533-01.
Infine è buffo vedere che viene richiesta una certificazione ISO/IEC 27001,
con scadenza triennale, e poi è richiesto di presentare un certificato di
conformità ai requisiti tecnici (che comprendono il rispetto della ISO/IEC
27001 e della ISO 14721) ogni due anni.
digitale
(http://blog.cesaregallotti.it/2014/05/accreditamento-conservazione-digitale
.html), Franco Ruggieri mi ha inviato alcune considerazioni molto
interessanti che riporto.
E' vero che nel DPCM 3/12/2013 non c'è alcun riferimento allo ISO/IEC 27001,
mentre c'è nella successiva Circolare AgID 65/2014. Insomma: la Circolare
mette una pezza al buco del DPCM.
Faccio notare che è stato pubblicato da AgID un altro documento che ritengo
di estremo interesse per i conservatori che, però ha un titolo chilometrico:
"Accreditamento dei soggetti pubblici e privati che svolgono attività di
conservazione dei documenti
informatici - Requisiti di qualità e sicurezza per l'accreditamento e la
vigilanza"
Ebbene, questo documento esplode nei minimi particolari i requisiti da
rispettare, riportando per ognuno la clause dello OAIS (ISO 14721) e dello
ETSI TS 101 533-01. Insomma: la certificazione ISO/IEC 27001 potrà (o forse
"dovrà") essere fatta avvalendosi del TS 101 533-01 come punto di
riferimento per le misure di sicurezza da attuare. D'altronde ad oggi non
c'è altro documento a cui rifarsi per un conservatore.
Peccato che questo TS sia stato redatto (e tradotto da UNI nella serie
UNI/TS/TR 11465-1-2-3) nel 2012, quando cioè la versione ISO/IEC 27001 del
2013 ancora non era nata.
Aggiungo che, anche se il documento di "Requisiti di qualità e sicurezza per
l'accreditamento" è solo una linea guida, senza la forza né di una Circolare
né di uno strumento giuridico, è sempre un documento emesso da chi fa la
vigilanza. È quindi molto probabile che AgID si baserà su di esso e sui
documenti da esso referenziati.
C'è un altro punto: si fa riferimento al TS 101 533-01 come
"raccomandazione", mentre invece è una "specifica". Inoltre il DPCM si
riferisce all'elenco dove è riportato come "elenco di specifiche". In
definitiva: quanto indicato nella tabellona del documento "Requisiti di
qualità e sicurezza per l'accreditamento e la vigilanza" diventa cogente,
compresa la specifica ETSI TS 101 533-01.
Infine è buffo vedere che viene richiesta una certificazione ISO/IEC 27001,
con scadenza triennale, e poi è richiesto di presentare un certificato di
conformità ai requisiti tecnici (che comprendono il rispetto della ISO/IEC
27001 e della ISO 14721) ogni due anni.
martedì 20 maggio 2014
Delle definizioni di rischio (approfondimento 2)
Dopo gli articoli degli ultimi mesi, Andrea Rui mi ha inviato una
considerazione personale che trovo molto interessante perché distingue tra
una valutazione del rischio "economica", che quindi si basa sulla formula
"rischio = minaccia x conseguenze", e una "umana" che deve basarsi su altre
formule.
Copio e incollo la mail di Andrea e lo ringrazio.
<<
Il D.Lgs. 81/2008 ha un approccio al rischio totalmente diverso da quello
delle altre norme. La centralità del rischio non è sull'azienda, ma sul
lavoratore.
Una gestione del rischio per i lavoratori dal punto di vista economico
dovrebbe includere svariati aspetti, tra cui: costo derivante dall'assenza,
eventuali sanzioni penali, eventuali sanzioni civili, perdita di know how,
danno di immagine, aumento dei costi assicurativi, eventuale perdita di
appalti o di partecipazione a gare, criticità derivanti dall'assenza del
lavoratore, eccetera.
Al contrario, il rischio per il D.Lgs. 81/2008 è uno solo: che il lavoratore
si faccia male.
In sintesi, mentre per la ISO/IEC 27001 il rischio che un lavoratore si
possa fare male può essere accettabile (ed in particolari contesti
potenzialmente anche conveniente) dal punto di vista del business, non lo è
dal punto di vista della Legge.
Infatti le aziende tendono a delocalizzare dove la nostra legge non si
applica, e dove il costo per i danni alle persone sono inferiori ai costi da
sostenere per impedire che si verifichino gli incidenti e per minimizzarne
l'impatto.
>>
considerazione personale che trovo molto interessante perché distingue tra
una valutazione del rischio "economica", che quindi si basa sulla formula
"rischio = minaccia x conseguenze", e una "umana" che deve basarsi su altre
formule.
Copio e incollo la mail di Andrea e lo ringrazio.
<<
Il D.Lgs. 81/2008 ha un approccio al rischio totalmente diverso da quello
delle altre norme. La centralità del rischio non è sull'azienda, ma sul
lavoratore.
Una gestione del rischio per i lavoratori dal punto di vista economico
dovrebbe includere svariati aspetti, tra cui: costo derivante dall'assenza,
eventuali sanzioni penali, eventuali sanzioni civili, perdita di know how,
danno di immagine, aumento dei costi assicurativi, eventuale perdita di
appalti o di partecipazione a gare, criticità derivanti dall'assenza del
lavoratore, eccetera.
Al contrario, il rischio per il D.Lgs. 81/2008 è uno solo: che il lavoratore
si faccia male.
In sintesi, mentre per la ISO/IEC 27001 il rischio che un lavoratore si
possa fare male può essere accettabile (ed in particolari contesti
potenzialmente anche conveniente) dal punto di vista del business, non lo è
dal punto di vista della Legge.
Infatti le aziende tendono a delocalizzare dove la nostra legge non si
applica, e dove il costo per i danni alle persone sono inferiori ai costi da
sostenere per impedire che si verifichino gli incidenti e per minimizzarne
l'impatto.
>>
NIST SP 800-160 "Systems Security Engineering"
Il NIST ha reso pubblico il final draft della SP 800-160, dal titolo
"Systems Security Engineering: An Integrated Approach to Building
Trustworthy Resilient Systems":
- http://csrc.nist.gov/publications/PubsDrafts.html#800-160
Sono indeciso se leggerlo ora o aspettare la pubblicazione della versione
finale. Ad ogni modo, credo sia una lettura da fare.
"Systems Security Engineering: An Integrated Approach to Building
Trustworthy Resilient Systems":
- http://csrc.nist.gov/publications/PubsDrafts.html#800-160
Sono indeciso se leggerlo ora o aspettare la pubblicazione della versione
finale. Ad ogni modo, credo sia una lettura da fare.
Legale: uso di pc e mail aziendali per scopi personali
Enzo Ascione di Intesa Sanpaolo Group Services mi segnala una sentenza della
Corte di Cassazione (sez. lav. - sent. 18.3.2014 n. 6222) la cui sintesi è:
"L'uso di pc e mail aziendali per scopi personali non giustifica il
licenziamento".
In poche parole, il datore di lavoro ha esagerato, visto che "il contratto
collettivo applicato prevede per tali inadempimenti/infrazioni delle
sanzioni di tipo conservativo, quali la multa o la sospensione dal lavoro".
Copio ulteriormente da un commento alla sentenza: "In particolare, i giudici
della Suprema Corte di Cassazione hanno precisato che in tema di
licenziamento disciplinare, l'uso, anche quotidiano, della mail aziendale
per ragioni private, come anche l'installazione sul computer di programmi
che non sono inerenti all'attività lavorativa, non rappresentano violazioni
(inadempimenti) che di per sé sono sufficienti alla irrogazione del
licenziamento del dipendente".
Segnalo infine l'articolo su Filodiritto:
- http://www.filodiritto.com/cassazione-lavoro-luso-privato-del-computer-e-dellemail-aziendali-non-legittima-il-licenziamento
Corte di Cassazione (sez. lav. - sent. 18.3.2014 n. 6222) la cui sintesi è:
"L'uso di pc e mail aziendali per scopi personali non giustifica il
licenziamento".
In poche parole, il datore di lavoro ha esagerato, visto che "il contratto
collettivo applicato prevede per tali inadempimenti/infrazioni delle
sanzioni di tipo conservativo, quali la multa o la sospensione dal lavoro".
Copio ulteriormente da un commento alla sentenza: "In particolare, i giudici
della Suprema Corte di Cassazione hanno precisato che in tema di
licenziamento disciplinare, l'uso, anche quotidiano, della mail aziendale
per ragioni private, come anche l'installazione sul computer di programmi
che non sono inerenti all'attività lavorativa, non rappresentano violazioni
(inadempimenti) che di per sé sono sufficienti alla irrogazione del
licenziamento del dipendente".
Segnalo infine l'articolo su Filodiritto:
- http://www.filodiritto.com/cassazione-lavoro-luso-privato-del-computer-e-dellemail-aziendali-non-legittima-il-licenziamento
venerdì 16 maggio 2014
Stato delle norme ISO/IEC 270xx
Venerdì 11 aprile si è concluso a Hong Kong il 48mo meeting dell'SC 27
dell'ISO/IEC JTC 1. Come nel precedente meeting di ottobre 2013 hanno
partecipato circa 250 delegati, di cui 100 per il WG1 (ossia il gruppo che
si occupa delle norme della famiglia ISO/IEC 27000 e collegate alla ISO/IEC
27001). La delegazione italiana era composta da 4 persone: Fabio Guasconi
(Presidente SC 27 italiano), io per seguir i lavori del WG 1 insieme a
Fabio, Dario Forte per il WG 4 e Andrea Caccia per i WG 1 e 4 e come
rappresentante per ETSI.
In questo meeting del WG sono proseguiti i lavori sulle nuove ISO/IEC 27003,
27004, 27005, 27006, 27009, 27010, 27011, 27013 e 27017. Si è anche lavorato
sulle future edizioni della ISO/IEC 27000. Sono stati avviati i lavori
preliminari per le nuove edizioni delle ISO/IEC 27007, 27008, 27019 e per la
nuova ISO/IEC 27021 sulle competenze dei professionisti di sistemi di
gestione per la sicurezza delle informazioni.
Questo arido elenco di norme non rende giustizia di quanto successo: si è
discusso molto in un clima decisamente costruttivo e in modo che le esigenze
dei rappresentanti dei diversi Paesi e delle diverse parti interessate alle
norme (auditor, consulenti e organizzazioni) fossero ben espresse.
dell'ISO/IEC JTC 1. Come nel precedente meeting di ottobre 2013 hanno
partecipato circa 250 delegati, di cui 100 per il WG1 (ossia il gruppo che
si occupa delle norme della famiglia ISO/IEC 27000 e collegate alla ISO/IEC
27001). La delegazione italiana era composta da 4 persone: Fabio Guasconi
(Presidente SC 27 italiano), io per seguir i lavori del WG 1 insieme a
Fabio, Dario Forte per il WG 4 e Andrea Caccia per i WG 1 e 4 e come
rappresentante per ETSI.
In questo meeting del WG sono proseguiti i lavori sulle nuove ISO/IEC 27003,
27004, 27005, 27006, 27009, 27010, 27011, 27013 e 27017. Si è anche lavorato
sulle future edizioni della ISO/IEC 27000. Sono stati avviati i lavori
preliminari per le nuove edizioni delle ISO/IEC 27007, 27008, 27019 e per la
nuova ISO/IEC 27021 sulle competenze dei professionisti di sistemi di
gestione per la sicurezza delle informazioni.
Questo arido elenco di norme non rende giustizia di quanto successo: si è
discusso molto in un clima decisamente costruttivo e in modo che le esigenze
dei rappresentanti dei diversi Paesi e delle diverse parti interessate alle
norme (auditor, consulenti e organizzazioni) fossero ben espresse.
mercoledì 14 maggio 2014
DFA Open Day 2014 - 5 giugno 2014 - Milano
Il 5 giugno si terrà l'Open Day dell'associazione DFA, di cui sono
consigliere.
Sono molto orgoglioso del programma, che sarà pubblicato in forma completa
su:
- http://www.perfezionisti.it/proposte-formative/dfa-open-day-2014/.
Gli argomenti saranno soprattutto relativi a "OSINT e Investigazioni
Digitali" e "Security e Incident Response aziendale".
La partecipazione è gratuita. Programma in sintesi e modulo di
registrazione:
- http://dfaopenday2014.eventbrite.it/
consigliere.
Sono molto orgoglioso del programma, che sarà pubblicato in forma completa
su:
- http://www.perfezionisti.it/proposte-formative/dfa-open-day-2014/.
Gli argomenti saranno soprattutto relativi a "OSINT e Investigazioni
Digitali" e "Security e Incident Response aziendale".
La partecipazione è gratuita. Programma in sintesi e modulo di
registrazione:
- http://dfaopenday2014.eventbrite.it/
Guida rapida Scrum
Stefano Ramacciotti mi ha segnalato l'interessante pubblicazione "Scrum
Primer 2.0" e la sua traduzione in italiano:
-
http://www.greengegneria.it/index.php?option=com_content&view=article&id=135
Copio e incollo dalla breve presentazione: "Scrum è il modello di Sviluppo
Software Agile più diffuso al mondo. The Scrum Primer 2.0 è una delle guide
rapide su Scrum più note a chi si è avvicinato a questo modello di Sviluppo
Agile".
Primer 2.0" e la sua traduzione in italiano:
-
http://www.greengegneria.it/index.php?option=com_content&view=article&id=135
Copio e incollo dalla breve presentazione: "Scrum è il modello di Sviluppo
Software Agile più diffuso al mondo. The Scrum Primer 2.0 è una delle guide
rapide su Scrum più note a chi si è avvicinato a questo modello di Sviluppo
Agile".
venerdì 9 maggio 2014
Accreditamento conservazione digitale
Sandro Sanna e Vincenzo Mondelli mi hanno segnalato la pubblicazione della
Circolare 65 del 10 aprile 2014 dell'Agenzia per l'Italia digitale (AgID)
che riporta le modalità per l'accreditamento dei conservatori dei documenti
informatici.
Avevo accennato a suo tempo alla pubblicazione delle regole tecniche:
- http://blog.cesaregallotti.it/2014/04/regole-tecniche-protocollo-e.html
Mi era sfuggito però che tra le richieste fatte ai conservatori vi fosse la
certificazione ISO/IEC 27001. In realtà è divertente vedere come nelle
regole tecniche stabilite dal DPCM del 3 dicembre 2013 la richiesta è
esposta come possibilità ("il responsabile della conservazione può chiedere
di certificare la conformità..."), mentre nella documentazione richiesta
dall'AgID vi è il certificato ISO/IEC 27001 senza prevederne l'assenza.
Ho notato inoltre che la richiesta è fatta molto bene: richiedono la
certificazione rispetto all'edizione 2013 della norma, con riferimento anche
all'edizione precedente, specificano che deve includere la conservazione e
che il certificato deve essere rilasciato da un organismo di certificazione
accreditato (poco prima delle mail di Sandro e Vincenzo avevo ricevuto
un'altra e-mail che mi riferiva che un'Autorità europea aveva, ahimè,
chiesto le certificazioni ISO/IEC 27002 e 27005, come se esistessero...).
Circolare 65 del 10 aprile 2014 dell'Agenzia per l'Italia digitale (AgID)
che riporta le modalità per l'accreditamento dei conservatori dei documenti
informatici.
Avevo accennato a suo tempo alla pubblicazione delle regole tecniche:
- http://blog.cesaregallotti.it/2014/04/regole-tecniche-protocollo-e.html
Mi era sfuggito però che tra le richieste fatte ai conservatori vi fosse la
certificazione ISO/IEC 27001. In realtà è divertente vedere come nelle
regole tecniche stabilite dal DPCM del 3 dicembre 2013 la richiesta è
esposta come possibilità ("il responsabile della conservazione può chiedere
di certificare la conformità..."), mentre nella documentazione richiesta
dall'AgID vi è il certificato ISO/IEC 27001 senza prevederne l'assenza.
Ho notato inoltre che la richiesta è fatta molto bene: richiedono la
certificazione rispetto all'edizione 2013 della norma, con riferimento anche
all'edizione precedente, specificano che deve includere la conservazione e
che il certificato deve essere rilasciato da un organismo di certificazione
accreditato (poco prima delle mail di Sandro e Vincenzo avevo ricevuto
un'altra e-mail che mi riferiva che un'Autorità europea aveva, ahimè,
chiesto le certificazioni ISO/IEC 27002 e 27005, come se esistessero...).
Attacco a Orange
Fabrizio Monteleone di DNV GL mi ha segnalato questa notizia:
- http://www.bbc.com/news/technology-27322946
Dei malintenzionati hanno ottenuto accesso a dei database dell'operatore
francese di TLC Orange e ai dati anagrafici dei clienti. Apparentemente, non
sono stati compromessi dati critici come i numeri di carte di credito o le
password di accesso ai servizi. Ciò non ostante il danno può essere
consistente.
Non posso fare a meno di rilevare che Orange ha preferito aspettare del
tempo prima di rendere pubblico l'incidente, causando molto malcontento tra
i propri clienti. Inoltre, ho trovato molto inquietante che abbiano
dichiarato di non sapere se i dati fossero cifrati o meno.
- http://www.bbc.com/news/technology-27322946
Dei malintenzionati hanno ottenuto accesso a dei database dell'operatore
francese di TLC Orange e ai dati anagrafici dei clienti. Apparentemente, non
sono stati compromessi dati critici come i numeri di carte di credito o le
password di accesso ai servizi. Ciò non ostante il danno può essere
consistente.
Non posso fare a meno di rilevare che Orange ha preferito aspettare del
tempo prima di rendere pubblico l'incidente, causando molto malcontento tra
i propri clienti. Inoltre, ho trovato molto inquietante che abbiano
dichiarato di non sapere se i dati fossero cifrati o meno.
lunedì 5 maggio 2014
Presentazione ISO/IEC JTC 1/SC 27
Il ISO/IEC JTC 1/SC 27 è il comitato che si occupa, tra le altre cose, della
scrittura della ISO/IEC 27001.
E' stata predisposta una presentazione per illustrarne l'organizzazione, i
partecipanti, i progetti in corso e altro ancora. Il link è il seguente:
-
http://www.jtc1sc27.din.de/cmd?level=tpl-bereich&languageid=en&cmsareaid=sc2
7slides
scrittura della ISO/IEC 27001.
E' stata predisposta una presentazione per illustrarne l'organizzazione, i
partecipanti, i progetti in corso e altro ancora. Il link è il seguente:
-
http://www.jtc1sc27.din.de/cmd?level=tpl-bereich&languageid=en&cmsareaid=sc2
7slides
AdS che chiedono la password agli utenti
Segnalo questo articolo sul blog di Achab:
-
http://www.achab.it/blog/index.cfm/2014/4/chiedere-la-password-in-modo-sicur
o.htm
In poche parole, Achab ha condotto un sondaggio da cui emerge che solo il
24% degli amministratori di sistema non chiede mai la password agli utenti
dei sistemi che amministrano.
Provo a fare una lista del perché il restante 76% fa male:
- perché se gli utenti comunicano la propria password agli amministratori di
sistema, allora si sentono autorizzati a comunicarla ai colleghi, agli
amici, ai parenti...;
- perché se gli utenti sono abituati a comunicare la propria password agli
amministratori di sistema, allora non sembrerà loro strano inviargliela se
gliela richiedono via mail (e poi ci si chiede perché gli utenti abboccano
alle e-mail di phishing);
- perché se la password non è più segreta, si riduce il livello di certezza
con cui si riconosce chi ha fatto cosa sui sistemi informatici;
- perché spesso le password sono usate per accedere a dati personali e la
normativa vigente in materia di privacy richiede di mantenerla segreta;
- perché se la password non è più segreta, allora forse accedono persone non
autorizzate ai sistemi informatici aziendali.
Nell'ultimo punto ho scritto "forse", ma solo perché sono un ottimista.
Evito di commentare per iscritto, ma confermo che ho fatto qualche
riflessione sulle competenze di certi amministratori di sistema e sulle
configurazioni di certe reti aziendali.
L'articolo, tra le altre cose, ricorda una misura compensativa nel caso
vengano comunicate le password dagli AdS: tenere traccia dell'evento e
modificarle appena il lavoro è stato finito.
-
http://www.achab.it/blog/index.cfm/2014/4/chiedere-la-password-in-modo-sicur
o.htm
In poche parole, Achab ha condotto un sondaggio da cui emerge che solo il
24% degli amministratori di sistema non chiede mai la password agli utenti
dei sistemi che amministrano.
Provo a fare una lista del perché il restante 76% fa male:
- perché se gli utenti comunicano la propria password agli amministratori di
sistema, allora si sentono autorizzati a comunicarla ai colleghi, agli
amici, ai parenti...;
- perché se gli utenti sono abituati a comunicare la propria password agli
amministratori di sistema, allora non sembrerà loro strano inviargliela se
gliela richiedono via mail (e poi ci si chiede perché gli utenti abboccano
alle e-mail di phishing);
- perché se la password non è più segreta, si riduce il livello di certezza
con cui si riconosce chi ha fatto cosa sui sistemi informatici;
- perché spesso le password sono usate per accedere a dati personali e la
normativa vigente in materia di privacy richiede di mantenerla segreta;
- perché se la password non è più segreta, allora forse accedono persone non
autorizzate ai sistemi informatici aziendali.
Nell'ultimo punto ho scritto "forse", ma solo perché sono un ottimista.
Evito di commentare per iscritto, ma confermo che ho fatto qualche
riflessione sulle competenze di certi amministratori di sistema e sulle
configurazioni di certe reti aziendali.
L'articolo, tra le altre cose, ricorda una misura compensativa nel caso
vengano comunicate le password dagli AdS: tenere traccia dell'evento e
modificarle appena il lavoro è stato finito.
Ancora su HLS, Annex SL e Annex SC
A gennaio avevo scritto un breve articolo (ora modificato) sulla nuova
edizione delle Direttive ISO/IEC:
- http://blog.cesaregallotti.it/2014/01/annex-sl-o-annex-jc-o-mss-hls.html
L'articolo segnalava che l'HLS (ossia il testo base da utilizzare per tutte
le norme relative ai sistemi di gestione, su cui è basata la ISO/IEC
27001:2013 e su cui si baserà la futura versione della ISO 9001) si trovava
nell'Annex SC, mentre sulla ISO/IEC 27001 si fa riferimento a questo testo
come "Annex SL". Io ora penso sia meglio chiamarlo MSS HLS (management
system standards high level structure) per evitare confusioni.
In realtà ho fatto un errore: la ISO/IEC pubblica Direttive specifiche per
l'ISO e Direttive specifiche per il JTC 1 (il comitato dedicato alle
attività congiunte ISO e IEC, tra le quali vi è la scrittura della ISO/IEC
27001) e probabilmente altre Direttive specifiche per altri organismi.
Bene... nelle Direttive specifiche per l'ISO, di cui è stato pubblicato
recentemente l'aggiornamento, continua a riportare il MSS HLS in Annex SL,
mentre le Direttive specifiche per il JTC 1 lo riporta in Annex SC.
A complicare ulteriormente le cose, i due testi sono ora disallineati. In
particolare, nelle nuove direttive specifiche per l'ISO è stata eliminata la
definizione di "correzione" perché, in effetti, non presente nel resto del
testo (anche se è molto utile distinguere tra "correzione" e "azione
correttiva" e ricordare che la ISO 9001, come la ISO/IEC 27001, non richiede
assolutamente di attuare azioni correttive per ogni non conformità rilevata,
né confonde tra correzione e azione correttiva).
Le Direttive ISO/IEC sono disponibili a questo link:
-
http://www.iso.org/iso/home/standards_development/resources-for-technical-wo
rk/iso_iec_directives_and_iso_supplement.htm
Sono previste delle linee guida per l'uso del MSS HLS al seguente link, ma
al momento non ve ne sono (altra cosa che trovo ironica):
-
http://isotc.iso.org/livelink/livelink?func=ll&objId=16347818&objAction=brow
se&viewType=1
edizione delle Direttive ISO/IEC:
- http://blog.cesaregallotti.it/2014/01/annex-sl-o-annex-jc-o-mss-hls.html
L'articolo segnalava che l'HLS (ossia il testo base da utilizzare per tutte
le norme relative ai sistemi di gestione, su cui è basata la ISO/IEC
27001:2013 e su cui si baserà la futura versione della ISO 9001) si trovava
nell'Annex SC, mentre sulla ISO/IEC 27001 si fa riferimento a questo testo
come "Annex SL". Io ora penso sia meglio chiamarlo MSS HLS (management
system standards high level structure) per evitare confusioni.
In realtà ho fatto un errore: la ISO/IEC pubblica Direttive specifiche per
l'ISO e Direttive specifiche per il JTC 1 (il comitato dedicato alle
attività congiunte ISO e IEC, tra le quali vi è la scrittura della ISO/IEC
27001) e probabilmente altre Direttive specifiche per altri organismi.
Bene... nelle Direttive specifiche per l'ISO, di cui è stato pubblicato
recentemente l'aggiornamento, continua a riportare il MSS HLS in Annex SL,
mentre le Direttive specifiche per il JTC 1 lo riporta in Annex SC.
A complicare ulteriormente le cose, i due testi sono ora disallineati. In
particolare, nelle nuove direttive specifiche per l'ISO è stata eliminata la
definizione di "correzione" perché, in effetti, non presente nel resto del
testo (anche se è molto utile distinguere tra "correzione" e "azione
correttiva" e ricordare che la ISO 9001, come la ISO/IEC 27001, non richiede
assolutamente di attuare azioni correttive per ogni non conformità rilevata,
né confonde tra correzione e azione correttiva).
Le Direttive ISO/IEC sono disponibili a questo link:
-
http://www.iso.org/iso/home/standards_development/resources-for-technical-wo
rk/iso_iec_directives_and_iso_supplement.htm
Sono previste delle linee guida per l'uso del MSS HLS al seguente link, ma
al momento non ve ne sono (altra cosa che trovo ironica):
-
http://isotc.iso.org/livelink/livelink?func=ll&objId=16347818&objAction=brow
se&viewType=1
sabato 26 aprile 2014
Fondi ai progetti open source
Dal SANS NewsBites segnalo questa notizia: le più grandi società
tecnologiche hanno comunicato che contribuiranno economicamente alla
Linux Foundation's Core Infrastructure Initiative per aiutare i progetti
open source. Il bug Heartbleed ha portato alla ribalta la situazione di
OpenSSL: il codice è diffusissimo, ma il progetto riceve donazioni per circa
2.000 dollari all'anno ed è seguito da un addetto a tempo pieno:
-
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-
by-heartbleed-finally-agree-to-fund-openssl/
Trovo tutto questo stupendo: un tizio mantiene quasi gratuitamente un codice
che è utilizzato da tantissime società per guadagnare tanti tanti milioni di
dollari, senza che gliene diano neanche una briciola... fino al pasticcio,
ovviamente!
A questo proposito segnalo anche questo interessante articolo:
-
http://www.theregister.co.uk/2014/04/11/openssl_heartbleed_robin_seggelmann/
Ovviamente, per disperdere energie, qualcuno ha pensato bene di aprire un
nuovo progetto: LibreSSL. Non posso fare a meno di riflettere sulle
similitudini con i nostri partiti politici...
- http://threatpost.com/libressl-sticks-a-fork-in-openssl/105653
tecnologiche hanno comunicato che contribuiranno economicamente alla
Linux Foundation's Core Infrastructure Initiative per aiutare i progetti
open source. Il bug Heartbleed ha portato alla ribalta la situazione di
OpenSSL: il codice è diffusissimo, ma il progetto riceve donazioni per circa
2.000 dollari all'anno ed è seguito da un addetto a tempo pieno:
-
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-
by-heartbleed-finally-agree-to-fund-openssl/
Trovo tutto questo stupendo: un tizio mantiene quasi gratuitamente un codice
che è utilizzato da tantissime società per guadagnare tanti tanti milioni di
dollari, senza che gliene diano neanche una briciola... fino al pasticcio,
ovviamente!
A questo proposito segnalo anche questo interessante articolo:
-
http://www.theregister.co.uk/2014/04/11/openssl_heartbleed_robin_seggelmann/
Ovviamente, per disperdere energie, qualcuno ha pensato bene di aprire un
nuovo progetto: LibreSSL. Non posso fare a meno di riflettere sulle
similitudini con i nostri partiti politici...
- http://threatpost.com/libressl-sticks-a-fork-in-openssl/105653
2014 Data Breach Investigations Report
Anche quest'anno segnalo la pubblicazione del Data Breach Investigations
Report di Verizon:
- http://www.verizonenterprise.com/DBIR/2014/
La segnalazione l'ho avuta dalla newsletter SANS NewsBites che riporta un
link al seguente articolo (mi chiedo perché non riporti il link diretto al
report):
- http://www.nextgov.com/cybersecurity/2014/04/government-employees-cause-nearly-60-public-sector-cyber-incidents/82933/
Riassumo il riassunto del SANS: almeno metà degli incidenti registrati nel
settore pubblico sono dovuti al personale interno. Di questi, un terzo
riguarda incidenti "vari", tra cui e-mail inviate a persone sbagliate.
Spionaggio e sfruttamento di vulnerabilità dei siti web costituiscono meno
del 1% degli incidenti. I numeri delle imprese private sono diversi perché
gli incidenti nel settore pubblico devono essere documentati e quindi
piccoli errori molto frequenti predominano nella statistica.
Personalmente ritrovo le stesse difficoltà delle singole aziende che
vogliono elaborare statistiche sulla sicurezza delle informazioni: i dati
sono troppo eterogenei e variegati per ottenere qualcosa di realmente
significativo e, quindi, piuttosto che "misurare" è necessario "monitorare"
e "riferire"... ma di questo già scrissi a suo tempo
(http://blog.cesaregallotti.it/2013/04/se-non-lo-misuri-non-lo-conosci.html)
.
Report di Verizon:
- http://www.verizonenterprise.com/DBIR/2014/
La segnalazione l'ho avuta dalla newsletter SANS NewsBites che riporta un
link al seguente articolo (mi chiedo perché non riporti il link diretto al
report):
- http://www.nextgov.com/cybersecurity/2014/04/government-employees-cause-nearly-60-public-sector-cyber-incidents/82933/
Riassumo il riassunto del SANS: almeno metà degli incidenti registrati nel
settore pubblico sono dovuti al personale interno. Di questi, un terzo
riguarda incidenti "vari", tra cui e-mail inviate a persone sbagliate.
Spionaggio e sfruttamento di vulnerabilità dei siti web costituiscono meno
del 1% degli incidenti. I numeri delle imprese private sono diversi perché
gli incidenti nel settore pubblico devono essere documentati e quindi
piccoli errori molto frequenti predominano nella statistica.
Personalmente ritrovo le stesse difficoltà delle singole aziende che
vogliono elaborare statistiche sulla sicurezza delle informazioni: i dati
sono troppo eterogenei e variegati per ottenere qualcosa di realmente
significativo e, quindi, piuttosto che "misurare" è necessario "monitorare"
e "riferire"... ma di questo già scrissi a suo tempo
(http://blog.cesaregallotti.it/2013/04/se-non-lo-misuri-non-lo-conosci.html)
.
venerdì 25 aprile 2014
Storia e futuro della ISO 9001
Segnalo questo white paper del BSI dal titolo " The history and future of
ISO 9001 - Approaching change":
-
http://www.bsigroup.com/LocalFiles/en-GB/iso-9001/Revisions/ISO%209001%20Whi
tepaper%20-%20the%20history%20and%20future%20of%20ISO%209001.pdf
Il motivo per l'interesse è la storia, che avevo dimenticato: nata come BS
5750 e appoggiata dal Ministero della difesa UK, si occuapava della gestione
dei processi manifatturieri. Nel 1987 la BS 5750 fu recepita dall'ISO con il
codice 9001 e modificata per coprire più tipologie di business. L'edizione
ISO 9001:1994 era più orientata all'assicurazione qualità, con
l'introduzione delle azioni preventive. La successiva edizione ISO 9001:2000
introdusse l'approccio per processi e la loro misurazione. La ISO 9001:2008
è un raffinamento della versione del 2000.
Il white paper si dilunga sulle novità della futura versione prevista per il
2015. Questa è pura operazione di marketing sulla cui completa onestà ho
molto dubbi (il BSI promuove convegni a pagamento e l'acquisto dei draft
dello standard) . Infatti la norma si trova in stato di Committee Draft e
potrebbe subire consistenti cambiamenti da qui alla sua pubblicazione (come
peraltro ho sperimentato personalmente durante i lavori dell'SC 27 e in
particolare con la ISO/IEC 27001 e la ISO/IEC 27006). Pertanto, a meno che
non partecipiate ai lavori della futura ISO 9001 (in Italia è possibile
farlo attraverso l'UNI), il mio consiglio è di non far nulla.
ISO 9001 - Approaching change":
-
http://www.bsigroup.com/LocalFiles/en-GB/iso-9001/Revisions/ISO%209001%20Whi
tepaper%20-%20the%20history%20and%20future%20of%20ISO%209001.pdf
Il motivo per l'interesse è la storia, che avevo dimenticato: nata come BS
5750 e appoggiata dal Ministero della difesa UK, si occuapava della gestione
dei processi manifatturieri. Nel 1987 la BS 5750 fu recepita dall'ISO con il
codice 9001 e modificata per coprire più tipologie di business. L'edizione
ISO 9001:1994 era più orientata all'assicurazione qualità, con
l'introduzione delle azioni preventive. La successiva edizione ISO 9001:2000
introdusse l'approccio per processi e la loro misurazione. La ISO 9001:2008
è un raffinamento della versione del 2000.
Il white paper si dilunga sulle novità della futura versione prevista per il
2015. Questa è pura operazione di marketing sulla cui completa onestà ho
molto dubbi (il BSI promuove convegni a pagamento e l'acquisto dei draft
dello standard) . Infatti la norma si trova in stato di Committee Draft e
potrebbe subire consistenti cambiamenti da qui alla sua pubblicazione (come
peraltro ho sperimentato personalmente durante i lavori dell'SC 27 e in
particolare con la ISO/IEC 27001 e la ISO/IEC 27006). Pertanto, a meno che
non partecipiate ai lavori della futura ISO 9001 (in Italia è possibile
farlo attraverso l'UNI), il mio consiglio è di non far nulla.
giovedì 24 aprile 2014
Electronic Evidence Guide
E' stata recentemente pubblicata la "Guida alla prova digitale", traduzione
italiana della "Electronic Evidence Guide" del Council of Europe. Per
scaricare la guida dovete compilare il form online disponibile a questo
indirizzo:
-
https://docs.google.com/forms/d/1gwHSgAjlyKWT10FEh8JNIAt_OQBRaCV4Jgt_-SLUWhU
/viewform
La versione italiana nasce dallo sforzo congiunto delle associazioni Digital
Forensics Alumni, Tech and Law Center e DEFT Association. La guida è stata
presentata ieri a Deftcon 2014 e sarà nuovamente illustrata il prossimo 5
Giugno 2014 in occasione del DFA Open Day alla Statale di Milano.
La versione in inglese si trova a questo indirizzo:
-
http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/Documents/Ele
ctronic%20Evidence%20Guide/default_en.asp
La lettura è molto interessante anche per chi vuole capire meglio cos'è la
digital forensics e presenta numerosi casi ed esempi.
italiana della "Electronic Evidence Guide" del Council of Europe. Per
scaricare la guida dovete compilare il form online disponibile a questo
indirizzo:
-
https://docs.google.com/forms/d/1gwHSgAjlyKWT10FEh8JNIAt_OQBRaCV4Jgt_-SLUWhU
/viewform
La versione italiana nasce dallo sforzo congiunto delle associazioni Digital
Forensics Alumni, Tech and Law Center e DEFT Association. La guida è stata
presentata ieri a Deftcon 2014 e sarà nuovamente illustrata il prossimo 5
Giugno 2014 in occasione del DFA Open Day alla Statale di Milano.
La versione in inglese si trova a questo indirizzo:
-
http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/Documents/Ele
ctronic%20Evidence%20Guide/default_en.asp
La lettura è molto interessante anche per chi vuole capire meglio cos'è la
digital forensics e presenta numerosi casi ed esempi.
lunedì 21 aprile 2014
Delle definizioni di rischio (approfondimento)
Dopo il mio post "Delle definizioni di rischio"
(http://blog.cesaregallotti.it/2014/04/delle-definizioni-di-rischio.html),
Andrea Veneziani di Data Management mi ha proposto un approfondimento che
riporto di seguito (e lo ringrazio).
La definizione di rischio in seno al D. Lgs. 81/2008 può essere interpretato
come "probabilità che si verifichino degli eventi per cui si hanno dei danni
consistenti". In realtà si dovrebbe togliere la parola "consistenti" a meno
che non si voglia semplicemente dire "tangibili" ed in qualche modo
"misurabili" e non come si dovrebbe intendere "di notevole entità",
"ragguardevoli", "ricchi".
Infatti col D. Lgs. 81/2008 il focus è sulla salute e sicurezza dei
lavoratori per cui il rischio e soprattutto il concetto di "danno" è legato
alla salute misurabile in giorni di malattia o infortunio, che poi possono
essere quantificati in punti di invalidità. Il caso peggiore (caso morte)
non lo voglio contemplare, ma anche questo è configurabile come "misurabile"
secondo parametri assicurativi.
In buona sostanza anche un giorno di assenza dal lavoro per infortunio
causato potrebbe essere considerato un danno "consistente" ed andrebbe
contemplato, anche se fino a 20 gg. non è punibile penalmente. Si eccettuano
pertanto solo le piccole ferite guaribili senza grossi interventi da parte
di medici. Colgo l'occasione per citare che eventuali lesioni personali
colpose sopra i 20 gg. di calendario (causate da una non corretta
valutazione del rischio e azioni per ridurlo da parte del datore di lavoro)
potrebbero essere punibili con la reclusione fino a tre mesi….
In conclusione il "danno accettabile" spesso si riduce a "taglietti
provocati dalla carta" per i rischi da ufficio, mentre tutto il resto ahimè
andrebbe considerato come "consistente".
Da qui la differenza "logica" che deriva tra una definizione ISO del
concetto di rischio e quella data dal D. Lgs. 81/08. In quest'ultimo caso
l'asticella è tenuta ben focalizzata sui danni (anche minimi) anziché sulle
semplici valutazioni di accettabilità del rischio.
(http://blog.cesaregallotti.it/2014/04/delle-definizioni-di-rischio.html),
Andrea Veneziani di Data Management mi ha proposto un approfondimento che
riporto di seguito (e lo ringrazio).
La definizione di rischio in seno al D. Lgs. 81/2008 può essere interpretato
come "probabilità che si verifichino degli eventi per cui si hanno dei danni
consistenti". In realtà si dovrebbe togliere la parola "consistenti" a meno
che non si voglia semplicemente dire "tangibili" ed in qualche modo
"misurabili" e non come si dovrebbe intendere "di notevole entità",
"ragguardevoli", "ricchi".
Infatti col D. Lgs. 81/2008 il focus è sulla salute e sicurezza dei
lavoratori per cui il rischio e soprattutto il concetto di "danno" è legato
alla salute misurabile in giorni di malattia o infortunio, che poi possono
essere quantificati in punti di invalidità. Il caso peggiore (caso morte)
non lo voglio contemplare, ma anche questo è configurabile come "misurabile"
secondo parametri assicurativi.
In buona sostanza anche un giorno di assenza dal lavoro per infortunio
causato potrebbe essere considerato un danno "consistente" ed andrebbe
contemplato, anche se fino a 20 gg. non è punibile penalmente. Si eccettuano
pertanto solo le piccole ferite guaribili senza grossi interventi da parte
di medici. Colgo l'occasione per citare che eventuali lesioni personali
colpose sopra i 20 gg. di calendario (causate da una non corretta
valutazione del rischio e azioni per ridurlo da parte del datore di lavoro)
potrebbero essere punibili con la reclusione fino a tre mesi….
In conclusione il "danno accettabile" spesso si riduce a "taglietti
provocati dalla carta" per i rischi da ufficio, mentre tutto il resto ahimè
andrebbe considerato come "consistente".
Da qui la differenza "logica" che deriva tra una definizione ISO del
concetto di rischio e quella data dal D. Lgs. 81/08. In quest'ultimo caso
l'asticella è tenuta ben focalizzata sui danni (anche minimi) anziché sulle
semplici valutazioni di accettabilità del rischio.
Le frodi nella rete
Enrico Toso di DB Consorzio mi ha segnalato un interessante lavoro
presentato a Milano, al Security Summit 2014. Il titolo è "Le frodi nella
rete" e si trova a questo indirizzo:
- http://frodi.clusit.it/views/Homepage.html
La presentazione fatta al Security Summit si trova tra gli atti del 19
marzo:
- https://www.securitysummit.it/milano-2014/atti/atti-19-marzo/
Nel documento ho trovato interessante soprattutto la seconda parte, dove
sono analizzate le frodi tipiche di ogni settore (banche, telco,
assicurazioni, gaming, pagamenti on-line, mobile, carte di credito e
proprietà intelletuale) e sono indicate delle modalità per prevenirle e/o
rilevarle.
presentato a Milano, al Security Summit 2014. Il titolo è "Le frodi nella
rete" e si trova a questo indirizzo:
- http://frodi.clusit.it/views/Homepage.html
La presentazione fatta al Security Summit si trova tra gli atti del 19
marzo:
- https://www.securitysummit.it/milano-2014/atti/atti-19-marzo/
Nel documento ho trovato interessante soprattutto la seconda parte, dove
sono analizzate le frodi tipiche di ogni settore (banche, telco,
assicurazioni, gaming, pagamenti on-line, mobile, carte di credito e
proprietà intelletuale) e sono indicate delle modalità per prevenirle e/o
rilevarle.
giovedì 10 aprile 2014
Heartbleed (vulnerabilità in OpenSSL)
La minaccia oggi più discussa è chiamata Heartbleed.
In sostanza, se si usano delle versioni vulnerabili di OpenSSL si rischia
un'intrusione da parte di malintenzionati:
- http://heartbleed.com/
In sostanza, se si usano delle versioni vulnerabili di OpenSSL si rischia
un'intrusione da parte di malintenzionati:
- http://heartbleed.com/
giovedì 3 aprile 2014
Regole tecniche: protocollo e conservazione digitale
Sono state pubblicate le nuove regole tecniche in materia di protocollo per
la Pubblica Amministrazione e di conservazione sostitutiva.
Sono due provvedimenti importanti, soprattutto il secondo, applicabile anche
ai privati, perché stabilisce come deve essere fatto un sistema di
conservazione dei documenti informatici che assicuri l'identificazione certa
del soggetto che ha formato il documento e l'integrità del documento.
Le regole si trovano sulla pagina ufficiale dell'Agid:
-
http://www.agid.gov.it/notizie/protocollo-conservazione-digitale-gazzetta-le
-nuove-regole-tecniche
Segnalo anche un articolo in merito su iged.it (e mi lamento con chi si è
inventato il formato di lettura):
- http://issuu.com/stefanoforesti/docs/iged114_light/7?e=1523602/7213043
la Pubblica Amministrazione e di conservazione sostitutiva.
Sono due provvedimenti importanti, soprattutto il secondo, applicabile anche
ai privati, perché stabilisce come deve essere fatto un sistema di
conservazione dei documenti informatici che assicuri l'identificazione certa
del soggetto che ha formato il documento e l'integrità del documento.
Le regole si trovano sulla pagina ufficiale dell'Agid:
-
http://www.agid.gov.it/notizie/protocollo-conservazione-digitale-gazzetta-le
-nuove-regole-tecniche
Segnalo anche un articolo in merito su iged.it (e mi lamento con chi si è
inventato il formato di lettura):
- http://issuu.com/stefanoforesti/docs/iged114_light/7?e=1523602/7213043
Delle definizioni di rischio
Stefano Ramacciotti mi ha segnalato le diverse definizioni di rischio nelle
norme ISO e nella legislazione italiana:
- ISO Guide 73 (e anche ISO/IEC 27000): effetto dell'incertezza degli
eventi. Le note poi dicono che il rischio è spesso caratterizzato da una
combinazione di eventi potenziali e le loro conseguenze.
- il Dlgs 81: probabilità di raggiungimento del livello potenziale di danno
nelle condizioni di impiego o di esposizione ad un determinato fattore o
agente oppure alla loro combinazione;
- Direttiva Seveso III: probabilità che un determinato evento si verifichi
in un dato periodo o in circostanze specifiche.
Ecco quindi il mio (nostro) punto di vista.
La ISO Guide 73 usa la definizione di rischio legata agli "effetti", ossia
agli impatti. Essa è originata dalla formula "rischio = probabilità x
conseguenza". Esemplificando, essa deriva dall'uso del rischio così: se mi
rubano 10 penne all'anno di 1 Euro ciascuna, allora ho una perdita annua di
10 Euro all'anno; quindi il rischio relativo al furto di penne è pari a 10
euro all'anno.
La Direttiva Seveso III usa il termine rischio come sinonimo di minaccia.
Così come è scritta è una sciocchezza. Che senso ha valutare la probabilità
di una minaccia senza considerarne gli impatti? Si potrebbero avere minacce
estremamente probabili (pioggia e neve, per esempio) i cui impatti sono
risibili; i terremoti a Milano ci sono eccome, ma non hanno impatti perché
la pianura li attenua.
Però la prima definizione della Treccani (www.treccani.it) è proprio
"Eventualità di subire un danno" e quindi riguarda solo la minaccia. Ahinoi.
La definizione del Dlgs 81 è un poco più e pare voglia dire "probabilità che
si verifichino degli eventi per cui si hanno dei danni consistenti" e già
qui gli impatti si collegano ai danni. Mentre le norme ISO chiedono di
stabilire l'accettabilità del rischio (e quindi, potenzialmente, dei danni
complessivi annui, il Dlgs 81 chiede di stabilire il danno accettabile e poi
di valutare le minacce (i rischi, in quel caso) che li potrebbero provocare.
norme ISO e nella legislazione italiana:
- ISO Guide 73 (e anche ISO/IEC 27000): effetto dell'incertezza degli
eventi. Le note poi dicono che il rischio è spesso caratterizzato da una
combinazione di eventi potenziali e le loro conseguenze.
- il Dlgs 81: probabilità di raggiungimento del livello potenziale di danno
nelle condizioni di impiego o di esposizione ad un determinato fattore o
agente oppure alla loro combinazione;
- Direttiva Seveso III: probabilità che un determinato evento si verifichi
in un dato periodo o in circostanze specifiche.
Ecco quindi il mio (nostro) punto di vista.
La ISO Guide 73 usa la definizione di rischio legata agli "effetti", ossia
agli impatti. Essa è originata dalla formula "rischio = probabilità x
conseguenza". Esemplificando, essa deriva dall'uso del rischio così: se mi
rubano 10 penne all'anno di 1 Euro ciascuna, allora ho una perdita annua di
10 Euro all'anno; quindi il rischio relativo al furto di penne è pari a 10
euro all'anno.
La Direttiva Seveso III usa il termine rischio come sinonimo di minaccia.
Così come è scritta è una sciocchezza. Che senso ha valutare la probabilità
di una minaccia senza considerarne gli impatti? Si potrebbero avere minacce
estremamente probabili (pioggia e neve, per esempio) i cui impatti sono
risibili; i terremoti a Milano ci sono eccome, ma non hanno impatti perché
la pianura li attenua.
Però la prima definizione della Treccani (www.treccani.it) è proprio
"Eventualità di subire un danno" e quindi riguarda solo la minaccia. Ahinoi.
La definizione del Dlgs 81 è un poco più e pare voglia dire "probabilità che
si verifichino degli eventi per cui si hanno dei danni consistenti" e già
qui gli impatti si collegano ai danni. Mentre le norme ISO chiedono di
stabilire l'accettabilità del rischio (e quindi, potenzialmente, dei danni
complessivi annui, il Dlgs 81 chiede di stabilire il danno accettabile e poi
di valutare le minacce (i rischi, in quel caso) che li potrebbero provocare.
Normative e procedure
Come già scritto in precedenza, ho tenuto un intervento sulle tecniche di auditing per il Corso di perfezionamento in privacy e data
protection
- http://blog.cesaregallotti.it/2014/03/presentazione-audit.html
In quell'occasione spiegai che gli audit interni vanno condotti intervistando il personale e verificando le loro attività facendo riferimento alle procedure interne. Qualcuno mi ha chiesto: "ah... non sulla norma? non sul Codice Privacy e i Provvedimenti del Garante?".
La risposta è... nì.
Infatti, è mia opinione che il personale non possa essere chiamato a seguire un testo di Legge così com'è. Sia per carenza di competenze (alcuni articoli sono di difficile interpretazione anche a chi segue la materia da anni), sia perché ogni organizzazione è diversa dall'altra e l'attuazione dei requisiti normativi varia di volta in volta. Per esempio, chi deve fare il riesame delle utenze con accesso ai dati personali (gli amministratori di sistema o i responsabili dei diversi uffici)? come deve essere attuato operativamente il meccanismo di "custodia delle password"? che livello di controllo va esercitato sui fornitori? eccetera.
Quindi: il requisito normativo deve essere riportato in procedure (o istruzioni o regolamenti) a cui il personale deve attenersi.
Quindi l'audit dovrebbe essere diviso in due parti: la prima, a tavolino, per verificare se i requisiti normativi sono stati incorporati correttamente nelle procedure; la seconda, sul campo, per verificare se le procedure sono seguite dalle persone.
- http://blog.cesaregallotti.it/2014/03/presentazione-audit.html
In quell'occasione spiegai che gli audit interni vanno condotti intervistando il personale e verificando le loro attività facendo riferimento alle procedure interne. Qualcuno mi ha chiesto: "ah... non sulla norma? non sul Codice Privacy e i Provvedimenti del Garante?".
La risposta è... nì.
Infatti, è mia opinione che il personale non possa essere chiamato a seguire un testo di Legge così com'è. Sia per carenza di competenze (alcuni articoli sono di difficile interpretazione anche a chi segue la materia da anni), sia perché ogni organizzazione è diversa dall'altra e l'attuazione dei requisiti normativi varia di volta in volta. Per esempio, chi deve fare il riesame delle utenze con accesso ai dati personali (gli amministratori di sistema o i responsabili dei diversi uffici)? come deve essere attuato operativamente il meccanismo di "custodia delle password"? che livello di controllo va esercitato sui fornitori? eccetera.
Quindi: il requisito normativo deve essere riportato in procedure (o istruzioni o regolamenti) a cui il personale deve attenersi.
Quindi l'audit dovrebbe essere diviso in due parti: la prima, a tavolino, per verificare se i requisiti normativi sono stati incorporati correttamente nelle procedure; la seconda, sul campo, per verificare se le procedure sono seguite dalle persone.
SCADA e Ufficio acquisti
Sul gruppo LinkedIn Italian Security Professional è stata
lanciata una discussione sugli SCADA, ossia sui sistemi industriali, prendendo
lo spunto dalla presentazione di Alessio L.R. Pennasilico e Cristiano Cafferata
al Security Summit di Milano 2014 dal titolo " Quando il frigorifero
inizia ad inviare Phishing, forse andrebbe rivalutata la strategia di security":
Ci tengo a copiare e incollare un ottimo intervento che
condivido al 100% (sarà che in questo periodo sono coinvolto in un paio di
attività in ambienti manifatturieri):
<<
1) Bisogna lavorare sul procurement. Gli apparati e i
sistemi devono rispondere a requisiti di sicurezza. Corretto prendersela con
produttori poco attenti e sensibili, ma ancor peggio c'è chi questi apparati li
compra. Anni fa l'ignoranza era una buona scusa, ora non più
2) Se non si possono fare modifiche, il cliente dovrebbe
valutare il costo/beneficio di passare a soluzioni più sicure, se non subito,
al prossimo upgrade tecnologico. Informerei il vendor e il venditore, anche se
questo potrebbe portare a poco.
Il settore dovrebbe lavorare su standard specifici, in
modo da "certificare" i prodotti compliant e aiutare gli operatori
nella scelta. C'è ancora MOLTA strada da fare.
>>
E una risposta a questo commento è anch'essa molto interessante
(parafraso un poco):
<<
E' vero: il procurement va citato, ma se non ha delle
linee guida in materia di sicurezza, beh, il "fallo" è dietro
l'angolo.
>>
Dlgs 21/2014 - Contratti a distanza e Codice del consumo
Da Altalex segnalo le modifiche al Codice del consumo per
quanto riguarda i contratti a distanza introdotti dal Dlgs 21/2014 di
recepimento della Direttiva Europea 2011/83/UE:
In sintesi e copiando quanto riportato da Altalex, e
ricordando che l'informativa precontrattuale comprende tutte le clausole da
prevedere anche negli acquisti Internet, le maggiori novità sono:
- obbligo di informativa precontrattuale più gravoso
rispetto al precedente e di forma scritta;
- diritto di ripensamento: il consumatore può recedere
dall'acquisto entro 14 giorni ma se l'informativa è incompleta ha 12 mesi;
- restituzione del prodotto: il consumatore ha la
possibilità di restituire il prodotto, anche se deteriorato.
L'articolo di Filodiritto è più esaustivo:
Stato Regolamento europeo privacy
Da Filodiritto segnalo questo articolo sul Regolamento in materia di protezione dei dati personali:
In sintesi, c'eravamo
quasi, ma il Parlamento è in scadenza e passerà la pratica al futuro (elezioni
in Italia il 25 maggio). Ricordo che l'UK sta spingendo per posticipare il più
possibile l'approvazione di questo provvedimento.
Password sempre necessarie?
Da una discussione sul gruppo LinkedIn "Italian Security Professional", trovo
questo interessantissimo intervento di Luca Savoldi che permette di riflettere
sulla necessità o meno delle password. La conclusione, mia, è ovvia: sono
sempre necessarie, ma ci possono essere alcune limitate e controllate
eccezioni.
<<
Dimostrazione che anche l'IT e la sicurezza IT, se non pensata
per l'ambiente industriale, può essere pericolosa. La regola fondamentale e
imprescindibile in ambienti SCADA è che la Security (IT) deve supportare la
Safety e quindi i sistemi di Safety.
In una sala controllo di un importante
raffineria si conclude l'audit di importante ente inglese che si occupa di dare
la valutazione agli impianti industriali. Viene assegnato un bollone rosso
perché le postazioni della sala controllo non rispettano le policy di sicurezza
per le password degli account di dominio (nominale, 7 o 11 caratteri,
maiuscola, numero, carattere speciale, logoff automatico).
Con quale criterio
si può pensare di assegnare una simile policy ad una postazione la cui priorità
è l'accessibilità in caso di emergenza?
La sala controllo ha un controllo
accessi con badge nominale e riconoscimento visivo. Solo 10 persone possono
entrare. L'interno è ovviamente videosorvegliato. Per cui chi è dentro ad
operare è un operatore riconosciuto.
Pensate se per caso succede un'emergenza
e bisogna premere il comando di apertura o chiusura di una valvola per impedire
un esplosione. Bisogna intervenire in tempi rapidissimi. E se nel momento di
panico l'operatore non riesce a digitare la sua password? o se sviene e deve
intervenire il collega sulla sua postazione?
<<
questo interessantissimo intervento di Luca Savoldi che permette di riflettere
sulla necessità o meno delle password. La conclusione, mia, è ovvia: sono
sempre necessarie, ma ci possono essere alcune limitate e controllate
eccezioni.
<<
Dimostrazione che anche l'IT e la sicurezza IT, se non pensata
per l'ambiente industriale, può essere pericolosa. La regola fondamentale e
imprescindibile in ambienti SCADA è che la Security (IT) deve supportare la
Safety e quindi i sistemi di Safety.
In una sala controllo di un importante
raffineria si conclude l'audit di importante ente inglese che si occupa di dare
la valutazione agli impianti industriali. Viene assegnato un bollone rosso
perché le postazioni della sala controllo non rispettano le policy di sicurezza
per le password degli account di dominio (nominale, 7 o 11 caratteri,
maiuscola, numero, carattere speciale, logoff automatico).
Con quale criterio
si può pensare di assegnare una simile policy ad una postazione la cui priorità
è l'accessibilità in caso di emergenza?
La sala controllo ha un controllo
accessi con badge nominale e riconoscimento visivo. Solo 10 persone possono
entrare. L'interno è ovviamente videosorvegliato. Per cui chi è dentro ad
operare è un operatore riconosciuto.
Pensate se per caso succede un'emergenza
e bisogna premere il comando di apertura o chiusura di una valvola per impedire
un esplosione. Bisogna intervenire in tempi rapidissimi. E se nel momento di
panico l'operatore non riesce a digitare la sua password? o se sviene e deve
intervenire il collega sulla sua postazione?
<<
mercoledì 2 aprile 2014
Regolamento Agcom diritto d'autore online
Dal 31 marzo è entrato in vigore il Regolamento Agcom per la tutela del
Diritto d'autore online.
-
http://www.marchiebrevettiweb.it/29-diritto-di-autore/2397-entra-in-vigore-o
ggi-il-regolamento-per-la-tutela-del-diritto-d-autore-online.html
Esso prevede che i soggetti titolari o licenziatari di un diritto d'autore
possano segnalare all'Autorità le violazioni avvenute via Internet. Per
questo è a disposizione il sito:
- https://www.ddaonline.it
Notizia dal gruppo infotechlegale.it di LinkedIn.
Diritto d'autore online.
-
http://www.marchiebrevettiweb.it/29-diritto-di-autore/2397-entra-in-vigore-o
ggi-il-regolamento-per-la-tutela-del-diritto-d-autore-online.html
Esso prevede che i soggetti titolari o licenziatari di un diritto d'autore
possano segnalare all'Autorità le violazioni avvenute via Internet. Per
questo è a disposizione il sito:
- https://www.ddaonline.it
Notizia dal gruppo infotechlegale.it di LinkedIn.
Quaderno su PCI-DSS
Segnalo la pubblicazione del Quaderno Clusit "PCI-DSS: Payment Card
Industry. Data Security Standard" di Fabio Guasconi.
Il quaderno è aggiornato alla versione del PCI-DSS 3.0.
Ottimo per chi vuole cominciare a conoscere questo standard:
- http://clusit.it/download/index.htm
Industry. Data Security Standard" di Fabio Guasconi.
Il quaderno è aggiornato alla versione del PCI-DSS 3.0.
Ottimo per chi vuole cominciare a conoscere questo standard:
- http://clusit.it/download/index.htm
Rapporto Clusit 2014 e atti Security Summit
E' stato pubblicato il Rapporto Clusit 2014 sulla sicurezza informatica in
Italia. Confermo che è molto interessante:
- http://clusit.it/rapportoclusit/
Sono stati anche pubblicati gli atti del Security Summit:
- https://www.securitysummit.it/milano-2014/atti/
Confesso che non ho trovato cose molto interessanti in questi atti. Ma credo
sia un problema del formato "presentazione". Se però qualcuno vuole
segnalare qualcosa che mi sono perso, lo faccia!
Italia. Confermo che è molto interessante:
- http://clusit.it/rapportoclusit/
Sono stati anche pubblicati gli atti del Security Summit:
- https://www.securitysummit.it/milano-2014/atti/
Confesso che non ho trovato cose molto interessanti in questi atti. Ma credo
sia un problema del formato "presentazione". Se però qualcuno vuole
segnalare qualcosa che mi sono perso, lo faccia!
sabato 29 marzo 2014
Full disclosure mailing list
Questa non la conoscevo, ma sembra fondamentale: una mailing list dove sono
riportate le vulnerabilità dei sistemi informatici:
- http://insecure.org/news/fulldisclosure/
Notizia tratta dal SANS NewsBites.
riportate le vulnerabilità dei sistemi informatici:
- http://insecure.org/news/fulldisclosure/
Notizia tratta dal SANS NewsBites.
lunedì 17 marzo 2014
UNI CEI ISO/IEC 27001:2014
E' stata pubblicata la traduzione italiana della ISO/IEC 27001:2013.
Ahimè... non ce l'abbiamo fatta a pubblicarla con data 2013!
La trovate su http://store.uni.com.
Ahimè... non ce l'abbiamo fatta a pubblicarla con data 2013!
La trovate su http://store.uni.com.
Direttiva UE Network and Information Security (NIS)
Massimo Cottafavi di Security Reply mi ha segnalato questo articolo sulla
Direttiva Europea "Network and Information Security (NIS)":
-
http://www.networkworld.com/news/2014/031314-new-eu-cybersecurity-law-avoids
-279681.html
Massimo mi fornisce già un commento che copio e incollo: "Interessante
l'estensione dell'obbligo di data brech alle infrastrutture critiche anche
se ancora oggi questo termine viene utilizzato in modo improprio e con un
focus "parziale" rispetto a quelle che nella realtà potrebbero essere
considerate infrastrutture critiche. Da vedere poi i tempi di recepimento
della Direttiva a livello nazionale…".
Infatti, si intendono come strutture critiche solo quelle previste dal Dlgs
61 del 2011 (energia e trasporti); gli operatori di telecomunicazione non
sono ritenuti infrastrutture critiche (nel 2014!).
Direttiva Europea "Network and Information Security (NIS)":
-
http://www.networkworld.com/news/2014/031314-new-eu-cybersecurity-law-avoids
-279681.html
Massimo mi fornisce già un commento che copio e incollo: "Interessante
l'estensione dell'obbligo di data brech alle infrastrutture critiche anche
se ancora oggi questo termine viene utilizzato in modo improprio e con un
focus "parziale" rispetto a quelle che nella realtà potrebbero essere
considerate infrastrutture critiche. Da vedere poi i tempi di recepimento
della Direttiva a livello nazionale…".
Infatti, si intendono come strutture critiche solo quelle previste dal Dlgs
61 del 2011 (energia e trasporti); gli operatori di telecomunicazione non
sono ritenuti infrastrutture critiche (nel 2014!).
domenica 16 marzo 2014
Attacco a Target e uso scorretto dei controlli di sicurezza
Dal SANS NewsBites segnalo un articolo in merito all'attacco alla Target, un
fornitore di servizi collegati alle carte di credito:
-
http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic
-hack-of-credit-card-data#p1
L'attacco alla Target è avvenuto a fine 2013 e la notizia è stata pubblicata
da molte parti. Non mi dilungo, ma ricordo solo che dei malintenzionati sono
riusciti a rubare 40 milioni di numeri di carte di credito.
La cosa interessante, a mio parere, è soprattutto questa: Target aveva
superato l'audit PCI per gestire i dati delle carte di credito e aveva
installato il prodotto FireEye (da affiancare ad un prodotto Symantec) per
rilevare malware sui propri sistemi. Il prodotto FireEye era costato 1,6
milioni di dollari e ha funzionato: quando i malintenzionati avevano
installato il malware sui server della Target per poi recuperare i numeri di
carte di credito, FireEye ha lanciato allarmi al SOC e... nessuno ne ha
fatto nulla.
Qui si sono sommate due pratiche nefaste:
- certificarsi per avere il pezzo di carta e avviare progetti solo per dare
prove agli auditor (tra l'altro, allo stesso costo del miglioramento reale,
perché 1,6 milioni di dollari non sono uno scherzo);
- acquistare e, forse, installare prodotti (a costo elevato) e non pensare
ai processi.
Temo che, come sempre, nessuno imparerà la lezione.
fornitore di servizi collegati alle carte di credito:
-
http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic
-hack-of-credit-card-data#p1
L'attacco alla Target è avvenuto a fine 2013 e la notizia è stata pubblicata
da molte parti. Non mi dilungo, ma ricordo solo che dei malintenzionati sono
riusciti a rubare 40 milioni di numeri di carte di credito.
La cosa interessante, a mio parere, è soprattutto questa: Target aveva
superato l'audit PCI per gestire i dati delle carte di credito e aveva
installato il prodotto FireEye (da affiancare ad un prodotto Symantec) per
rilevare malware sui propri sistemi. Il prodotto FireEye era costato 1,6
milioni di dollari e ha funzionato: quando i malintenzionati avevano
installato il malware sui server della Target per poi recuperare i numeri di
carte di credito, FireEye ha lanciato allarmi al SOC e... nessuno ne ha
fatto nulla.
Qui si sono sommate due pratiche nefaste:
- certificarsi per avere il pezzo di carta e avviare progetti solo per dare
prove agli auditor (tra l'altro, allo stesso costo del miglioramento reale,
perché 1,6 milioni di dollari non sono uno scherzo);
- acquistare e, forse, installare prodotti (a costo elevato) e non pensare
ai processi.
Temo che, come sempre, nessuno imparerà la lezione.
sabato 15 marzo 2014
Prossimi appuntamenti
Il giovedì 20 marzo parlo al Security Summit di Milano, con Fabio Guasconi,
di "Le nuove norme della famiglia 27000":
- https://www.securitysummit.it/milano-2014/
Il 5 giugno organizzo, come membro del Consiglio direttivo di DFA
(www.perfezionisti.it), alla Statale di Milano, il DFA Open Day 2014 su
questi due argomenti:
- OSINT e Investigazioni Digitali
- Security e Incident Response aziendale
Maggiori informazioni saranno date nei prossimi mesi.
di "Le nuove norme della famiglia 27000":
- https://www.securitysummit.it/milano-2014/
Il 5 giugno organizzo, come membro del Consiglio direttivo di DFA
(www.perfezionisti.it), alla Statale di Milano, il DFA Open Day 2014 su
questi due argomenti:
- OSINT e Investigazioni Digitali
- Security e Incident Response aziendale
Maggiori informazioni saranno date nei prossimi mesi.
mercoledì 5 marzo 2014
Presentazione audit
Il 27 febbraio ho tenuto una lezione sugli audit presso la Facoltà di
giurisprudenza dell'Università statale di Milano per il modulo "Le ispezioni
e gli accertamenti del Garante: modalità di svolgimento, sanzioni comminate
e strategie di difesa " del Corso di perfezionamento in privacy e data
protection:
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2014-Audit.pdf
La pagina web da cui scaricarla:
- http://www.cesaregallotti.it/Pubblicazioni.html
giurisprudenza dell'Università statale di Milano per il modulo "Le ispezioni
e gli accertamenti del Garante: modalità di svolgimento, sanzioni comminate
e strategie di difesa " del Corso di perfezionamento in privacy e data
protection:
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2014-Audit.pdf
La pagina web da cui scaricarla:
- http://www.cesaregallotti.it/Pubblicazioni.html
Progettazione, ingegnerizzazione e sviluppo (ossia, "Parole")
A febbraio mi ero chiesto e avevo chiesto quali fossero le differenze tra
progettazione (design) e ingegnerizzazione (engineering):
- http://blog.cesaregallotti.it/2014/02/principi-di-sicurezza-per.html
Premetto che, in effetti, non avevo dubbi tra progettazione e
ingegnerizzazione, ma tra sviluppo (development) e ingegnerizzazione.
Scrivendo mi sono confuso (era S. Valentino...), ma poi le risposte di
Andrea Rui e Fabrizio Monteleone (DNV GL) mi hanno segnalato l'errore.
Fabrizio Monteleone mi ha anche ricordato che " la progettazione equivale a
ideare un prodotto sulla base di requisiti; l'ingegnerizzazione significa
cercare il miglior modo di realizzarlo (quali pezzi usare, possibilità di
riutilizzare cose di un prodotto simile, futura manutenzione, ....) prima di
poter rilasciare il progetto per la produzione". In poche parole:
"l'ingegneria del software cerca di fornire le regole per il processo di
produzione e quindi le regole di ingegnerizzazione sicura e le regole di
sviluppo sicuro sono la stessa cosa".
Altri, a cui ho confidato il medesimo dubbio, la pensano più o meno allo
stesso modo, ma usano il termine "sviluppo" solo per la realizzazione del
software, ossia per la codifica. Usano il termine "ingegnerizzazione" per
modellare sistemi, oggetti e database. Loro potrebbero ingegnerizzare senza
sviluppare. Non ho approfondito oltre, ma sicuramente dovranno configurare
dei sistemi per produrre il servizio ingegnerizzato.
Per Andrea Rui (e anche per la ISO 9001, che differenzia "progettazione e
sviluppo" e "realizzazione"), invece "lo sviluppo è quella fase che ti
porta dalle specifiche al prototipo; l'ingegnerizzazione è quella fase che
ti porta da questo al prodotto finale".
Rileggendo la NIST SP 800-27, vedo che i principi di ingegnerizzazione si
applicano a tutte le fasi del ciclo di vita di un sistema: initiation,
sviluppo o acquisizione, test e installazione, conduzione e manutenzione,
eliminazione.
Riassumendo: per Fabrizio Monteleone prima si ha la progettazione, poi
l'ingegnerizzazione e infine lo sviluppo; per Andrea Rui prima si ha la
progettazione, poi lo sviluppo e infine l'ingegnerizzazione; per la NIST SP
800-27, l'ingegnerizzazione comprende la progettazione e lo sviluppo.
Questo dimostra ancora una volta come in informatica sia opportuno
condividere per bene i termini con i propri interlocutori, perché ciascuno
potrebbe utilizzarli in modi diversi. Per esperienza, quando chiedo
spiegazioni sull'uso di certi termini, mi guardano come se fossi uno
sciocco, quando sono invece loro che non hanno idea di cosa succede al di
fuori del loro piccolo mondo. Citando Andrea Rui: " sui termini occorre
spesso fare delle mappature tra i diversi significati attribuiti da enti
diversi e dai diversi contesti d'uso (insomma, occorre introdurre i
namespaces!)".
Per concludere, cito ancora Andrea Rui che mi ha ribadito dei concetti
fondamentali, a prescindere dalla terminologia utilizzata: "trattandosi di
fasi distinte, a cui lavorano figure e persone diverse attraverso attività
diverse, occorre che per ciascuna siano analizzati i rischi e definite le
appropriate misure di sicurezza da adottare; inizialmente occorre
identificare i requisiti di sicurezza legati alle caratteristiche e
funzionalità; per quanto riguarda la realizzazione, occorre identificare a
priori tutti i requisiti di sicurezza che il processo di realizzazione
(analisi, sviluppo, ecc.) deve avere per assicurare che il processo di
gestione del ciclo di vita del prodotto non limiti o riduca la sicurezza
progettata".
progettazione (design) e ingegnerizzazione (engineering):
- http://blog.cesaregallotti.it/2014/02/principi-di-sicurezza-per.html
Premetto che, in effetti, non avevo dubbi tra progettazione e
ingegnerizzazione, ma tra sviluppo (development) e ingegnerizzazione.
Scrivendo mi sono confuso (era S. Valentino...), ma poi le risposte di
Andrea Rui e Fabrizio Monteleone (DNV GL) mi hanno segnalato l'errore.
Fabrizio Monteleone mi ha anche ricordato che " la progettazione equivale a
ideare un prodotto sulla base di requisiti; l'ingegnerizzazione significa
cercare il miglior modo di realizzarlo (quali pezzi usare, possibilità di
riutilizzare cose di un prodotto simile, futura manutenzione, ....) prima di
poter rilasciare il progetto per la produzione". In poche parole:
"l'ingegneria del software cerca di fornire le regole per il processo di
produzione e quindi le regole di ingegnerizzazione sicura e le regole di
sviluppo sicuro sono la stessa cosa".
Altri, a cui ho confidato il medesimo dubbio, la pensano più o meno allo
stesso modo, ma usano il termine "sviluppo" solo per la realizzazione del
software, ossia per la codifica. Usano il termine "ingegnerizzazione" per
modellare sistemi, oggetti e database. Loro potrebbero ingegnerizzare senza
sviluppare. Non ho approfondito oltre, ma sicuramente dovranno configurare
dei sistemi per produrre il servizio ingegnerizzato.
Per Andrea Rui (e anche per la ISO 9001, che differenzia "progettazione e
sviluppo" e "realizzazione"), invece "lo sviluppo è quella fase che ti
porta dalle specifiche al prototipo; l'ingegnerizzazione è quella fase che
ti porta da questo al prodotto finale".
Rileggendo la NIST SP 800-27, vedo che i principi di ingegnerizzazione si
applicano a tutte le fasi del ciclo di vita di un sistema: initiation,
sviluppo o acquisizione, test e installazione, conduzione e manutenzione,
eliminazione.
Riassumendo: per Fabrizio Monteleone prima si ha la progettazione, poi
l'ingegnerizzazione e infine lo sviluppo; per Andrea Rui prima si ha la
progettazione, poi lo sviluppo e infine l'ingegnerizzazione; per la NIST SP
800-27, l'ingegnerizzazione comprende la progettazione e lo sviluppo.
Questo dimostra ancora una volta come in informatica sia opportuno
condividere per bene i termini con i propri interlocutori, perché ciascuno
potrebbe utilizzarli in modi diversi. Per esperienza, quando chiedo
spiegazioni sull'uso di certi termini, mi guardano come se fossi uno
sciocco, quando sono invece loro che non hanno idea di cosa succede al di
fuori del loro piccolo mondo. Citando Andrea Rui: " sui termini occorre
spesso fare delle mappature tra i diversi significati attribuiti da enti
diversi e dai diversi contesti d'uso (insomma, occorre introdurre i
namespaces!)".
Per concludere, cito ancora Andrea Rui che mi ha ribadito dei concetti
fondamentali, a prescindere dalla terminologia utilizzata: "trattandosi di
fasi distinte, a cui lavorano figure e persone diverse attraverso attività
diverse, occorre che per ciascuna siano analizzati i rischi e definite le
appropriate misure di sicurezza da adottare; inizialmente occorre
identificare i requisiti di sicurezza legati alle caratteristiche e
funzionalità; per quanto riguarda la realizzazione, occorre identificare a
priori tutti i requisiti di sicurezza che il processo di realizzazione
(analisi, sviluppo, ecc.) deve avere per assicurare che il processo di
gestione del ciclo di vita del prodotto non limiti o riduca la sicurezza
progettata".
mercoledì 26 febbraio 2014
Malware The Mask
Da Crypto-Gram rilancio la notizia dell'individuazione di un nuovo malware
APT detto The Mask:
- http://www.wired.com/threatlevel/2014/02/mask/
Sembra che questo malware sia usato da 7 anni per spiare agenzie governative
soprattutto in Marocco e Brasile.
APT detto The Mask:
- http://www.wired.com/threatlevel/2014/02/mask/
Sembra che questo malware sia usato da 7 anni per spiare agenzie governative
soprattutto in Marocco e Brasile.
sabato 22 febbraio 2014
Standard ETSI per accessibilità
Da UNINFO ricevo la notizia della pubblicazione di alcuni nuovi standard
ETSI relativi all'accessibilità dei prodotti ICT. Il comunicato stampa, con
link alla pagina dove trovare gli standard:
- http://www.cencenelec.eu/News/Press_Releases/Pages/PR-2014-03.aspx
In particolare è stato pubblicato lo standard EN 301 549 dal titolo "
Accessibility requirements suitable for public procurement of ICT products
and services in Europe". Lo standard riporta molti requisiti tecnici per
rendere accessibili gli strumenti ICT a tutti.
ETSI relativi all'accessibilità dei prodotti ICT. Il comunicato stampa, con
link alla pagina dove trovare gli standard:
- http://www.cencenelec.eu/News/Press_Releases/Pages/PR-2014-03.aspx
In particolare è stato pubblicato lo standard EN 301 549 dal titolo "
Accessibility requirements suitable for public procurement of ICT products
and services in Europe". Lo standard riporta molti requisiti tecnici per
rendere accessibili gli strumenti ICT a tutti.
mercoledì 19 febbraio 2014
Libertà di link
Segnalo questo articolo di Filodiritto dal titolo " Corte di Giustizia:
libero link in libera rete, purché verso contenuti liberamente disponibili
nel sito linkato":
-
http://www.filodiritto.com/corte-di-giustizia-libero-link-in-libera-rete-pur
che-verso-contenuti-liberamente-disponibili-nel-sito-linkato
In sintesi: " Un sito internet può contenere al suo interno diversi "link"
(collegamenti internet) con cui rinvia a opere protette dal diritto
d'autore, liberamente accessibili in altri siti, senza il consenso dei
titolari del diritto".
Meno male: sono anni che lo faccio sul blog e sulla newsletter e non mi era
mai sorto il dubbio di commettere reato. Infatti non lo facevo, ma ora ne ho
la conferma al 100%.
libero link in libera rete, purché verso contenuti liberamente disponibili
nel sito linkato":
-
http://www.filodiritto.com/corte-di-giustizia-libero-link-in-libera-rete-pur
che-verso-contenuti-liberamente-disponibili-nel-sito-linkato
In sintesi: " Un sito internet può contenere al suo interno diversi "link"
(collegamenti internet) con cui rinvia a opere protette dal diritto
d'autore, liberamente accessibili in altri siti, senza il consenso dei
titolari del diritto".
Meno male: sono anni che lo faccio sul blog e sulla newsletter e non mi era
mai sorto il dubbio di commettere reato. Infatti non lo facevo, ma ora ne ho
la conferma al 100%.
ATM e dispositivi medici
Sul SANS NewsBites del 18 febbraio ci sono due notizie a mio parere
collegate.
La prima riguarda gli ATM (ossia i Bancomat): in un Paese ignoto, dei
malfattori sono riusciti a manomettere gli ATM e, inserendo una chiave USB,
ottenere i soldi:
-
http://www.darkreading.com/attacks-breaches/criminals-control-cash-out-banks
-atm-mac/240166070
La seconda i dispositivi medici negli ospedali: il US Department of Health
and Human Services (HHS) Office of Inspector General (OIG) ha deciso di
effettuare degli audit presso gli ospedali per verificare se i loro
dispositivi sono configurati per garantire un adeguato livello di sicurezza
ai dati dei pazienti:
-
http://www.govinfosecurity.com/oig-to-review-medical-device-security-a-6490
Cosa hanno in comune queste due notizie? Traduco liberamente e modifico un
poco il commento sul caso degli ATM di Murray, editor del SANS NewsBites:
"un tempo questi dispositivi erano solidi, presso dei locali controllati,
utilizzavano del software proprietario ad hoc, con reti e protocolli ad hoc,
condotti e gestiti dall'ente stesso. Oggi questi dispositivi sono come degli
elettrodomestici, siti in locali non sempre controllati, con software
solitamente installato su Windows, su reti e protocolli pubblici, condotti e
gestiti da terze parti. Questo ha fatto aumentare le possibilità di attacco
e le vulnerabilità; le notizie sugli attacchi possono essere drammatiche, ma
non sorprendenti".
Qui, a mio parere, è sottintesa un'altra conclusione. Provo a riassumerla,
insieme all'ipotesi: "sono cambiate le architetture dei dispositivi e i loro
interfacciamenti, ma produttori, installatori, manutentori e utilizzatori
continuano a progettarli, installarli, mantenerli e usarli come se ciò non
fosse mai successo".
collegate.
La prima riguarda gli ATM (ossia i Bancomat): in un Paese ignoto, dei
malfattori sono riusciti a manomettere gli ATM e, inserendo una chiave USB,
ottenere i soldi:
-
http://www.darkreading.com/attacks-breaches/criminals-control-cash-out-banks
-atm-mac/240166070
La seconda i dispositivi medici negli ospedali: il US Department of Health
and Human Services (HHS) Office of Inspector General (OIG) ha deciso di
effettuare degli audit presso gli ospedali per verificare se i loro
dispositivi sono configurati per garantire un adeguato livello di sicurezza
ai dati dei pazienti:
-
http://www.govinfosecurity.com/oig-to-review-medical-device-security-a-6490
Cosa hanno in comune queste due notizie? Traduco liberamente e modifico un
poco il commento sul caso degli ATM di Murray, editor del SANS NewsBites:
"un tempo questi dispositivi erano solidi, presso dei locali controllati,
utilizzavano del software proprietario ad hoc, con reti e protocolli ad hoc,
condotti e gestiti dall'ente stesso. Oggi questi dispositivi sono come degli
elettrodomestici, siti in locali non sempre controllati, con software
solitamente installato su Windows, su reti e protocolli pubblici, condotti e
gestiti da terze parti. Questo ha fatto aumentare le possibilità di attacco
e le vulnerabilità; le notizie sugli attacchi possono essere drammatiche, ma
non sorprendenti".
Qui, a mio parere, è sottintesa un'altra conclusione. Provo a riassumerla,
insieme all'ipotesi: "sono cambiate le architetture dei dispositivi e i loro
interfacciamenti, ma produttori, installatori, manutentori e utilizzatori
continuano a progettarli, installarli, mantenerli e usarli come se ciò non
fosse mai successo".
lunedì 17 febbraio 2014
ISO/IEC 27000:2014 (errata corrige)
Avevo precedentemente annunciato la pubblicazione della ISO/IEC 27000:2012,
ma volevo annunciare la pubblicazione della versione del 2014. Grazie a
Franco Ruggieri e Fabio Guasconi per avermi avvisato per primi.
Mi scuso con tutti e confermo che la norma si può trovare a questo link:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
ma volevo annunciare la pubblicazione della versione del 2014. Grazie a
Franco Ruggieri e Fabio Guasconi per avermi avvisato per primi.
Mi scuso con tutti e confermo che la norma si può trovare a questo link:
- http://standards.iso.org/ittf/PubliclyAvailableStandards/
sabato 15 febbraio 2014
Ragazzi in rete
I ragazzi, come recentemente si è letto sulle prime pagine dei giornali, si
suicidano a causa del cyberbullismo:
-
http://www.corriere.it/cronache/14_febbraio_12/cerca-aiuto-online-ma-insulta
no-suicida-14-anni-c48f9e5a-93a8-11e3-84f1-d7c36ce692b4.shtml
Queste notizie non possono non turbarci.
Stefano Ramacciotti, Coordinatore GdL Educazione alla Sicurezza Informatica
per (ISC)2 Italy Chapter, ha inviato ai soci di (ISC)2 dei link
interessanti.
EU Kids Online, un'indagine effettuata a partire dal 2009 su incarico della
Commissione Europea in 25 paesi dell'Unione, con l'obiettivo di conoscere
cosa fanno i ragazzi in rete e il livello di competenza nell'utilizzo delle
TIC ha coinvolto 25.000 giovani dai 9 ai 16 anni e i genitori. Il report è
disponibile al link:
http://www.lse.ac.uk/media@lse/research/EUKidsOnline/EU%20Kids%20III/Reports
/PerspectivesReport.pdf
A guide for parents. Education and new media:
http://www.saferinternetday.org/c/document_library/get_file?uuid=15f5f3ac-e6
bb-4760-b6b0-eb4ca46a9829&groupId=10136
The Web We Want:
http://www.saferinternet.org/c/document_library/get_file?uuid=10c06ff7-9263-
4996-a7d3-116340b9fe6f&groupId=10137
suicidano a causa del cyberbullismo:
-
http://www.corriere.it/cronache/14_febbraio_12/cerca-aiuto-online-ma-insulta
no-suicida-14-anni-c48f9e5a-93a8-11e3-84f1-d7c36ce692b4.shtml
Queste notizie non possono non turbarci.
Stefano Ramacciotti, Coordinatore GdL Educazione alla Sicurezza Informatica
per (ISC)2 Italy Chapter, ha inviato ai soci di (ISC)2 dei link
interessanti.
EU Kids Online, un'indagine effettuata a partire dal 2009 su incarico della
Commissione Europea in 25 paesi dell'Unione, con l'obiettivo di conoscere
cosa fanno i ragazzi in rete e il livello di competenza nell'utilizzo delle
TIC ha coinvolto 25.000 giovani dai 9 ai 16 anni e i genitori. Il report è
disponibile al link:
http://www.lse.ac.uk/media@lse/research/EUKidsOnline/EU%20Kids%20III/Reports
/PerspectivesReport.pdf
A guide for parents. Education and new media:
http://www.saferinternetday.org/c/document_library/get_file?uuid=15f5f3ac-e6
bb-4760-b6b0-eb4ca46a9829&groupId=10136
The Web We Want:
http://www.saferinternet.org/c/document_library/get_file?uuid=10c06ff7-9263-
4996-a7d3-116340b9fe6f&groupId=10137
Iscriviti a:
Post (Atom)