Stefano Ramacciotti mi ha segnalato questo interessante report sulla qualità
del codice:
- http://softwareintegrity.coverity.com/register-for-scan-report-2013.html
Lo trovo interessante perché presenta un elenco dei tipi di difetti
riscontrati nelle analisi effettuate su sorgenti C/C++ e Java. In C/C++ il
più alto numero di errori rientra nei tipi "Resource leaks", "Null pointer
dereferences" e "Control flow issues", mentre in Java gli errori più comuni
riguardano "Null pointer dereferences", "Dodgy code" e "FindBugs:
Performance".
Quello che mi chiedo è: quanti sviluppatori Java usano strumenti di analisi
come FindBugs (http://findbugs.sourceforge.net/)? Quanti sviluppatori usano
altri strumenti?
Ho paura della risposta...
mercoledì 16 luglio 2014
Le assicurazioni relative agli incidenti IT sono un pasticcio
Articolo segnalato da Crypto-Gram dal titolo " The $10 Million Deductible:
Why the cyberinsurance industry is a mess":
-
http://www.slate.com/articles/technology/future_tense/2014/06/target_breach_
cyberinsurance_is_a_mess.html
Continuo quindi la mia piccola campagna di sensibilizzazione: se neanche le
assicurazioni sanno quantificare i rischi, perché ostinarsi a voler
realizzare valutazioni del rischio quantitative? Per non parlare di quelle
semi-quantitative (un ossimoro)?
Why the cyberinsurance industry is a mess":
-
http://www.slate.com/articles/technology/future_tense/2014/06/target_breach_
cyberinsurance_is_a_mess.html
Continuo quindi la mia piccola campagna di sensibilizzazione: se neanche le
assicurazioni sanno quantificare i rischi, perché ostinarsi a voler
realizzare valutazioni del rischio quantitative? Per non parlare di quelle
semi-quantitative (un ossimoro)?
Attacco a Code Spaces
Il 17 giugno è stato attaccato il servizio Code Spaces, che è rimasto
indisponibile per molti giorni (oggi, 16 giugno, il servizio è ancora
indisponibile). Code Spaces offre un servizio cloud di configuration
management per i codici sorgenti e si basa sull'infrastruttura (sempre
cloud) di Amazon.
Pare che un attaccante abbia iniziato con un DDoS e abbia anche sfruttato
delle credenziali di accesso alla rete interna di Code Spaces ottenute con
del phishing. Obiettivo: chiedere un riscatto per sospendere l'attacco.
Gli analisti hanno subito cominciato a dibattere sul fatto che l'accesso ai
pannelli di amministrazione del servizio Code Spaces poteva essere prevenuto
se si fosse basato su un'autenticazione a multi-fattori (o con
one-time-password; insomma, come quando bisogna usare una password
temporanea che viene inviata via SMS o e-mail).
Non solo questo, però, va considerato. Ma anche: la mancanza di un business
continuity plan, l'errore di un utente che ha risposto ad un'email
fraudolenta e non se ne è accorto neanche in un secondo momento (o forse non
ha avvisato nessuno), il fatto che questo utente (mia deduzione) abbia usato
una password con molti privilegi per un sito che può essere oggetto di
phishing. Tutte cose, tra l'altro, non applicabili al solo cloud.
La notizia l'ho ricevuta dal SANS NewsBites che a sua volta segnala questa
pagina web:
-
http://searchsecurity.techtarget.com/news/2240224102/Multifactor-authenticat
ion-key-to-cloud-security-success
indisponibile per molti giorni (oggi, 16 giugno, il servizio è ancora
indisponibile). Code Spaces offre un servizio cloud di configuration
management per i codici sorgenti e si basa sull'infrastruttura (sempre
cloud) di Amazon.
Pare che un attaccante abbia iniziato con un DDoS e abbia anche sfruttato
delle credenziali di accesso alla rete interna di Code Spaces ottenute con
del phishing. Obiettivo: chiedere un riscatto per sospendere l'attacco.
Gli analisti hanno subito cominciato a dibattere sul fatto che l'accesso ai
pannelli di amministrazione del servizio Code Spaces poteva essere prevenuto
se si fosse basato su un'autenticazione a multi-fattori (o con
one-time-password; insomma, come quando bisogna usare una password
temporanea che viene inviata via SMS o e-mail).
Non solo questo, però, va considerato. Ma anche: la mancanza di un business
continuity plan, l'errore di un utente che ha risposto ad un'email
fraudolenta e non se ne è accorto neanche in un secondo momento (o forse non
ha avvisato nessuno), il fatto che questo utente (mia deduzione) abbia usato
una password con molti privilegi per un sito che può essere oggetto di
phishing. Tutte cose, tra l'altro, non applicabili al solo cloud.
La notizia l'ho ricevuta dal SANS NewsBites che a sua volta segnala questa
pagina web:
-
http://searchsecurity.techtarget.com/news/2240224102/Multifactor-authenticat
ion-key-to-cloud-security-success
Pianificare data center
Interessante questo articolo di ZeroUno:
-
http://www.zerounoweb.it/osservatori/data-center-management/pianificare-il-d
ata-center-un-metodo-per-evitare-errori.html
Alcuni dei 9 errori di pianificazione di un data center sono:
1- sottovalutazione dei costi operativi (da aggiungere a quelli di
realizzazione iniziale);
2- stima imprecisa dei costi di realizzazione;
3- sovradimensionamento;
4- pianificazione prematura dello spazio;
5- non pensare ai possibili ampliamenti futuri;
6- progetti troppo complicati.
Viene da pensare che questi errori, con le dovute specificità, siano comuni
a tanti progetti, non necessariamente di data center.
-
http://www.zerounoweb.it/osservatori/data-center-management/pianificare-il-d
ata-center-un-metodo-per-evitare-errori.html
Alcuni dei 9 errori di pianificazione di un data center sono:
1- sottovalutazione dei costi operativi (da aggiungere a quelli di
realizzazione iniziale);
2- stima imprecisa dei costi di realizzazione;
3- sovradimensionamento;
4- pianificazione prematura dello spazio;
5- non pensare ai possibili ampliamenti futuri;
6- progetti troppo complicati.
Viene da pensare che questi errori, con le dovute specificità, siano comuni
a tanti progetti, non necessariamente di data center.
Tribunale di Napoli ed efficacia probatoria dei log
Un'azienda ha provato che un suo dipendente accedeva abusivamente alle
caselle di e-mail dei colleghi. Il dipendente è ricorso è ha vinto.
La storia è interessante perché, una volta tanto, il ricorso non è stato
vinto a causa di informative inesistenti o scritte male o per regole di
sicurezza informatica carenti, ma perché non è stata provata l'efficacia
probatoria dei log.
Infatti è stato nominato un CTU (Consulente tecnico d'ufficio) che "ha
constatato come sia stato possibile recuperare solo una copia dei log senza
possibilità di verifica della conservazione sui sistemi di origine. I
sistemi aziendali prevedono, infatti, un sistema di sovrascrittura dei file
di log originari che sono andati così distrutti e l'implementazione di copia
dei file di log" e pertanto "i sopra citati dati non siano attendibili né
affidabili. L'azienda non ha adottato adeguate misure per attestare e
precostituirsi l'immodificabilità e attendibilità dei file di log". " Nel
momento in cui è stata effettuata la copia dei log che ricollegano al pc del
ricorrente l'indirizzo Ip utilizzato – il contenuto del file non è stato
sottoposto a nessun controllo di integrità al fine di sancire l'identità
assoluta con il dato nel suo contenuto originale, così come prodotto dal
sistema. Secondo il CTU, in assenza di tali garanzie, il dato dei file di
log è alterabile. I log sono stati infatti esportati su file di testo,
consultabili e alterabili con un normale strumento di edizione".
Si legge quindi che: "Osserva il CTU che, pur potendosi prospettare in
astratto varie modalità di conservazione dei dati che avrebbero
inconfutabilmente determinato la loro immodificabilità e attendibilità, le
stesse non sono state adottate dal datore di lavoro; il sistema avrebbe
dovuto produrre log firmati digitalmente e marcati temporalmente.
L'articolo di Altalex:
-
http://www.altalex.com/index.php?idu=264948&cmd5=021c46ab76df2fd7050bbc8c56e
d7fe1&idnot=67750
Di esso non condivido assolutamente le conclusioni (che gli adempimenti
privacy erano formalistici e non sostanziali, la necessità di adottare
sistemi di audit esterni certificati, la necessità di formazione per le
aziende (che ci stanno a fare gli avvocati e i consulenti?). Condivido
invece il richiamo al Provvedimento del Garante privacy del 1 marzo 2007.
caselle di e-mail dei colleghi. Il dipendente è ricorso è ha vinto.
La storia è interessante perché, una volta tanto, il ricorso non è stato
vinto a causa di informative inesistenti o scritte male o per regole di
sicurezza informatica carenti, ma perché non è stata provata l'efficacia
probatoria dei log.
Infatti è stato nominato un CTU (Consulente tecnico d'ufficio) che "ha
constatato come sia stato possibile recuperare solo una copia dei log senza
possibilità di verifica della conservazione sui sistemi di origine. I
sistemi aziendali prevedono, infatti, un sistema di sovrascrittura dei file
di log originari che sono andati così distrutti e l'implementazione di copia
dei file di log" e pertanto "i sopra citati dati non siano attendibili né
affidabili. L'azienda non ha adottato adeguate misure per attestare e
precostituirsi l'immodificabilità e attendibilità dei file di log". " Nel
momento in cui è stata effettuata la copia dei log che ricollegano al pc del
ricorrente l'indirizzo Ip utilizzato – il contenuto del file non è stato
sottoposto a nessun controllo di integrità al fine di sancire l'identità
assoluta con il dato nel suo contenuto originale, così come prodotto dal
sistema. Secondo il CTU, in assenza di tali garanzie, il dato dei file di
log è alterabile. I log sono stati infatti esportati su file di testo,
consultabili e alterabili con un normale strumento di edizione".
Si legge quindi che: "Osserva il CTU che, pur potendosi prospettare in
astratto varie modalità di conservazione dei dati che avrebbero
inconfutabilmente determinato la loro immodificabilità e attendibilità, le
stesse non sono state adottate dal datore di lavoro; il sistema avrebbe
dovuto produrre log firmati digitalmente e marcati temporalmente.
L'articolo di Altalex:
-
http://www.altalex.com/index.php?idu=264948&cmd5=021c46ab76df2fd7050bbc8c56e
d7fe1&idnot=67750
Di esso non condivido assolutamente le conclusioni (che gli adempimenti
privacy erano formalistici e non sostanziali, la necessità di adottare
sistemi di audit esterni certificati, la necessità di formazione per le
aziende (che ci stanno a fare gli avvocati e i consulenti?). Condivido
invece il richiamo al Provvedimento del Garante privacy del 1 marzo 2007.
Eliminare da ITIL il processo di Configuration management
In questo articolo, segnalato dal gruppo ITIL & ISO20000 Service Management
+ ITSM di LinkedIn, è proposta l'eliminazione del processo di configuration
management da ITIL:
-
https://community.servicenow.com/community/learn/blog/2014/06/27/dear-itil-p
lease-kill-off-the-configuration-management-process
Il punto chiave è che troppe persone cercano di avere un database
omnicomprensivo e accuratissimo degli asset collegati all'informatica.
Solitamente, chi non adotta ITIL ma cerca di lavorare bene ha più "database"
(degli asset personali come pc e cellulari, dei sorgenti se sviluppano, dei
sistemi collegati alla rete, degli impianti, eccetera) e, quando possibile,
con automatismi che permettono di identificare le variazioni da un momento
all'altro.
Non credo, quindi, che il processo di configuration management vada
eliminato. Piuttosto va riconosciuto e promosso nel modo più corretto e più
funzionali alle reali esigenze di chi offre servizi e delle diverse funzioni
coinvolte (ciascuna con le sue diverse esigenze).
Da questo argomento ne viene fuori un altro: spesso, chi applica ITIL o
altri standard parla di "processo" unico, quando invece lo stesso processo
deve essere istanziato in più parti. Per esempio, il change management di un
mainframe non può essere lo stesso del change management di un sistema
Windows (per non parlare poi del fatto che il loro responsabile deve essere
diverso). Così il configuration management degli asset personali deve essere
gestito con strumenti e da persone diverse del configuration management
della rete o dei server.
+ ITSM di LinkedIn, è proposta l'eliminazione del processo di configuration
management da ITIL:
-
https://community.servicenow.com/community/learn/blog/2014/06/27/dear-itil-p
lease-kill-off-the-configuration-management-process
Il punto chiave è che troppe persone cercano di avere un database
omnicomprensivo e accuratissimo degli asset collegati all'informatica.
Solitamente, chi non adotta ITIL ma cerca di lavorare bene ha più "database"
(degli asset personali come pc e cellulari, dei sorgenti se sviluppano, dei
sistemi collegati alla rete, degli impianti, eccetera) e, quando possibile,
con automatismi che permettono di identificare le variazioni da un momento
all'altro.
Non credo, quindi, che il processo di configuration management vada
eliminato. Piuttosto va riconosciuto e promosso nel modo più corretto e più
funzionali alle reali esigenze di chi offre servizi e delle diverse funzioni
coinvolte (ciascuna con le sue diverse esigenze).
Da questo argomento ne viene fuori un altro: spesso, chi applica ITIL o
altri standard parla di "processo" unico, quando invece lo stesso processo
deve essere istanziato in più parti. Per esempio, il change management di un
mainframe non può essere lo stesso del change management di un sistema
Windows (per non parlare poi del fatto che il loro responsabile deve essere
diverso). Così il configuration management degli asset personali deve essere
gestito con strumenti e da persone diverse del configuration management
della rete o dei server.
lunedì 7 luglio 2014
Blackphone
Ormai in molti ne parlano: il cellulare a prova di privacy. Il blackphone si
basa su Android e utilizza un insieme di apps per la sicurezza, per navigare
senza essere tracciati, eccetera:
-
http://arstechnica.com/security/2014/06/exclusive-a-review-of-the-blackphone
-the-android-for-the-paranoid/
Al momento li hanno esauriti (cosa "solo" 630 Euro):
- https://store.blackphone.ch/
Tutto molto interessante, se solo non avete già dato tutti i vostri dati a
Google o Apple o Microsoft. Difficile...
basa su Android e utilizza un insieme di apps per la sicurezza, per navigare
senza essere tracciati, eccetera:
-
http://arstechnica.com/security/2014/06/exclusive-a-review-of-the-blackphone
-the-android-for-the-paranoid/
Al momento li hanno esauriti (cosa "solo" 630 Euro):
- https://store.blackphone.ch/
Tutto molto interessante, se solo non avete già dato tutti i vostri dati a
Google o Apple o Microsoft. Difficile...
lunedì 30 giugno 2014
Cloud Service Level Agreement Standardisation Guidelines
La Commissione Europea ha pubblicato le "Cloud Service Level Agreement
Standardisation Guidelines" (ringrazio Giacomo Orlando della segnalazione):
- http://europa.eu/rapid/press-release_IP-14-743_en.htm
-
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-st
andardisation-guidelines
Il documento è interessante. Ma continuo a pensare che ci siano troppe linee
guida per la gestione dei fornitori cloud, mentre per i fornitori di servizi
informatici non cloud non c'è quasi nulla, sebbene loro gestione lasci
spesso a desiderare. Tra l'altro, nel documento non ho trovato alcun
requisito non applicabile a fornitori di servizi IT non cloud.
Quindi mi piacerebbe vedere almeno una linea guida una sulla gestione in
generale dei fornitori dei servizi IT (per cui prevedere anche qualche
requisito in più di quelli che ci sono nel documento).
Standardisation Guidelines" (ringrazio Giacomo Orlando della segnalazione):
- http://europa.eu/rapid/press-release_IP-14-743_en.htm
-
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-st
andardisation-guidelines
Il documento è interessante. Ma continuo a pensare che ci siano troppe linee
guida per la gestione dei fornitori cloud, mentre per i fornitori di servizi
informatici non cloud non c'è quasi nulla, sebbene loro gestione lasci
spesso a desiderare. Tra l'altro, nel documento non ho trovato alcun
requisito non applicabile a fornitori di servizi IT non cloud.
Quindi mi piacerebbe vedere almeno una linea guida una sulla gestione in
generale dei fornitori dei servizi IT (per cui prevedere anche qualche
requisito in più di quelli che ci sono nel documento).
sabato 28 giugno 2014
Registro dei certificati ITIL
E' attivo il registro delle persone certificate ITIL (da notizia del gruppo
EXIN Certified Professionals di LinkedIn:
-
http://www.itil-officialsite.com/candidate-register/candidate-register.aspx
EXIN Certified Professionals di LinkedIn:
-
http://www.itil-officialsite.com/candidate-register/candidate-register.aspx
Wind e Exchange
In giugno due notizie di interruzione di servizi si sono imposte. La prima è
il "blackout di Wind": l'operatore di telecomunicazioni ha avuto un problema
di "configurazione dei router" che ha bloccato la connettività dei suoi
utenti per diverse ore:
-
http://www.tomshw.it/cont/news/blackout-wind-sotto-la-lente-dell-agcom/57277
/1.html
- http://www.forexinfo.it/Wind-Infostrada-le-cause-del
L'altro caso riguarda il blocco di Office 365: il servizio cloud di
Micorosoft è rimasto fermo per 9 ore per un "problema hardware":
-
http://www.ictbusiness.it/cont/news/exchange-online-attivo-dopo-nove-ore-di-
blocco/32712/1.html
Le due notizie mi sembrano in qualche collegate, anche se non saprei dire
esattamente come: forse perché piccoli errori hanno messo in difficoltà
tantissime persone, forse perché si dimostra quanto siamo dipendenti da
servizi con SLA non perfettamente garantiti, forse perché le mitiche grandi
imprese fanno anche loro degli errori.
il "blackout di Wind": l'operatore di telecomunicazioni ha avuto un problema
di "configurazione dei router" che ha bloccato la connettività dei suoi
utenti per diverse ore:
-
http://www.tomshw.it/cont/news/blackout-wind-sotto-la-lente-dell-agcom/57277
/1.html
- http://www.forexinfo.it/Wind-Infostrada-le-cause-del
L'altro caso riguarda il blocco di Office 365: il servizio cloud di
Micorosoft è rimasto fermo per 9 ore per un "problema hardware":
-
http://www.ictbusiness.it/cont/news/exchange-online-attivo-dopo-nove-ore-di-
blocco/32712/1.html
Le due notizie mi sembrano in qualche collegate, anche se non saprei dire
esattamente come: forse perché piccoli errori hanno messo in difficoltà
tantissime persone, forse perché si dimostra quanto siamo dipendenti da
servizi con SLA non perfettamente garantiti, forse perché le mitiche grandi
imprese fanno anche loro degli errori.
UNI CEI ISO/IEC 27002:2014
Finalmente è uscita la versione italiana della ISO/IEC 27002:2013 ed ha
codice UNI CEI ISO/IEC 27002:2014. Purtroppo gli anni sono diversi e quindi
si dovrà citare la "ISO/IEC 27002:2013" o la "UNI CEI ISO/IEC 27002:2014".
Altri metodi denotano scarsa conoscenza della materia.
La ISO/IEC 27002 è una lettura consigliata per quanti vogliono occuparsi di
sistemi di gestione per la sicurezza delle informazioni, anche se ci sono
punti in cui è troppo generica o ripetitiva.
Faccio i complimenti a Fabio Guasconi, che ha coordinato il non semplice
lavoro di traduzione delle 86 pagine della norma.
La norma è acquistabile sul sito dell'UNI: http://store.uni.com (la versione
italiana della UNI CEI ISO/IEC 27002:2014 costa 98 Euro, mentre la versione
inglese costa 75 Euro; infine la ISO/IEC 27002:2013 costa 153 Euro; non
capisco che differenza ci possa essere tra queste ultime due).
Bisogna fare attenzione al metodo scelto da UNI per proteggere il diritto
d'autore: si può aprire il file solo sul proprio computer e quindi va
necessariamente stampato subito, per evitare che un crash ce lo faccia
perdere per sempre.
codice UNI CEI ISO/IEC 27002:2014. Purtroppo gli anni sono diversi e quindi
si dovrà citare la "ISO/IEC 27002:2013" o la "UNI CEI ISO/IEC 27002:2014".
Altri metodi denotano scarsa conoscenza della materia.
La ISO/IEC 27002 è una lettura consigliata per quanti vogliono occuparsi di
sistemi di gestione per la sicurezza delle informazioni, anche se ci sono
punti in cui è troppo generica o ripetitiva.
Faccio i complimenti a Fabio Guasconi, che ha coordinato il non semplice
lavoro di traduzione delle 86 pagine della norma.
La norma è acquistabile sul sito dell'UNI: http://store.uni.com (la versione
italiana della UNI CEI ISO/IEC 27002:2014 costa 98 Euro, mentre la versione
inglese costa 75 Euro; infine la ISO/IEC 27002:2013 costa 153 Euro; non
capisco che differenza ci possa essere tra queste ultime due).
Bisogna fare attenzione al metodo scelto da UNI per proteggere il diritto
d'autore: si può aprire il file solo sul proprio computer e quindi va
necessariamente stampato subito, per evitare che un crash ce lo faccia
perdere per sempre.
lunedì 23 giugno 2014
Garante e biometria
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).
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).
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!
Iscriviti a:
Post (Atom)