Il 14 luglio il Garante Privacy ha emesso un provvedimento che permette alla società DNP Photomask Europe S.p.A. di conservare alcune immagini videoregistrate per 90 giorni, contrariamente al Provvedimento Generale del 8 aprile 2010 che impone un limite di 24 ore, a meno di eccezioni che possono portare fino al limite massimo di 7 giorni.
- http://www.garanteprivacy.it/garante/doc.jsp?ID=1836335
Cos'è successo? In altre occasioni il Garante ha chiesto di limitare il tempo di conservazione, qui addirittura permette di estenderlo fino a 13 volte il limite massimo ed eccezionale.
Un potenziale cliente (Infineon, tedesco) della società DNP ha richiesto alla DNP di adottare delle misure di sicurezza, tra cui la conservazione per 90 giorni delle immagini, in conformità alle loro procedure, "conformi alla ISO/IEC 17799 e alla ISO/IEC 15408".
Per i pignoli: il Provvedimento dice che la Infineon "opera rispettando i criteri dettati dal protocollo EAL5+ (ISO15408, ISO17799)", non che sono certificati (anche se un prodotto della Infineon è effettivamente certificato EAL5+)
Quindi, al punto 3 del Provvedimento, il Garante (Relatore: Fortunato) elogia gli standard internazionali dicendo alcune cose corrette e osservando che queste norme fissano "stringenti criteri" da prendere per buoni. Il tutto si conclude con: "si ammette la conservazione delle immagini per 90 giorni".
Ecco cosa c'è di sbagliato:
- il Provvedimento è del 14 luglio 2011; ormai da 6 (sei) anni, la ISO/IEC 17799 si chiama ISO/IEC 27002 (peccato veniale, ma allora sentiamoci autorizzati di citare la Legge 675 del 1996)
- le norme citate sono ISO/IEC non ISO (altro peccato veniale)
- la ISO/IEC 27002 (o 17799) non c'entra nulla con il "protocollo EAL5+"
- nessuna delle due norme citate fissa "stringenti criteri"; l'unico "stringente criterio" è che (semplifico) le misure di sicurezza devono essere commisurate al rischio analizzato dall'impresa; non si parla di "videosorveglianza", "90 giorni", "TVCC" o altre cose del genere (ho trovato solo un "suitable intruder detection systems")
- la ISO/IEC 27002 non fornisce "stringenti criteri" per sua natura (è una linea guida, da adattare caso per caso)
Alla luce di tutto ciò, provo a tradurre quello che è successo: la Infineon ha fatto le sue analisi del rischio (secondo un metodo e con risultati non riportati dal Provvedimento) e ha stabilito che il tempo giusto per conservare le immagini per lei e i suoi fornitori è di 90 giorni, lo richiede alla DNP, la quale DNP lo richiede al Garante, che dice "OK". Sintetizzo ancora: il Garante ha detto "se mi dite che avete fatto un'analisi dei rischi (che non vorrò vedere) che vi dice di conservare le immagini per 90 giorni, io approvo".
Non credo fosse quello il suo intendimento. Purtroppo, avendo accettato di trattare un argomento senza conoscerlo e senza averlo studiato, questo è il risultato.
Ma c'è un ulteriore effetto negativo della storia: si dà alle norme ISO/IEC citate un valore inesatto, esattamente come lo si dà alla ISO 9001. Come la ISO 9001 non garantisce l'alta qualità dei prodotti o servizi offerti, così la 27002 e la 15408 non garantiscono l'alta sicurezza dei prodotti o servizi o dell'azienda in assoluto. Non la faccio lunga, ma ricordo che Windows NT fu certificato EAL3, e oggi molti sistemi operativi Windows sono certificati EAL 4+... questo intuitivamente vi fa capire che non basta sapere "certificato", bisogna andare un poco oltre.
E infatti, da tempo, insieme ad altri colleghi, cerco di far capire che queste affermazioni sono false (il Garante invece ha dimostrato di prenderle per buone, soprattutto l'ultima; sarà forse perché tutte quelle sigle e quei numeri l'hanno confuso?):
- io sono certificato ISO -> sono al sicuro
- il mio fornitore è ISO -> è sicuro anche secondo i miei standard, anche se non glieli ho detti
- ricerco un fornitore ISO -> non ho bisogno di dirgli i miei requisiti di sicurezza perché tanto lui è sicuro -> non ho neanche bisogno di capire cosa c'è scritto sul certificato
- compro un prodotto ISO o da un fornitore ISO -> il prodotto è sicuro
- il mio cliente, fornitore o partner è ISO -> tutto ciò che dice è buono e giusto
Mi limito a concludere dicendo che:
- il Garante ha sbagliato
- se ha sbagliato qui, quante altre volte è stato superficiale nei Provvedimenti?
- come è possibile che il Garante non conosca almeno approssimativamente gli standard internazionali sulla sicurezza delle informazioni?
- allora è vero che emette Provvedimenti con misure di sicurezza da realizzare senza una base condivisa dagli specialisti della materia!
- Il Provvedimento Generale sulla videosorveglianza del 8 aprile 2010: http://www.garanteprivacy.it/garante/doc.jsp?ID=1712680#3.4
- il sito ufficiale dei Common Criteria: http://www.commoncriteriaportal.org/
Mi fermo qui. Qualcuno mi dia i riferimenti di un avvocato in caso riceva una querela.
mercoledì 12 ottobre 2011
venerdì 30 settembre 2011
Pagina normativa "informatica"
Ho cambiato la pagina sulla normativa in materia informatica: http://www.cesaregallotti.it/Normativa.html
Ho infatti scelto di non allegare più una copia delle norme, ma di riinviare a siti come www.normattiva.it o quello del Garante Privacy (era impossibile tenere aggiornati i files).
Avrò fatto sicuramente molti errori: se li trovate, vi prego di segnalarmeli.
Ho infatti scelto di non allegare più una copia delle norme, ma di riinviare a siti come www.normattiva.it o quello del Garante Privacy (era impossibile tenere aggiornati i files).
Avrò fatto sicuramente molti errori: se li trovate, vi prego di segnalarmeli.
mercoledì 21 settembre 2011
Vulnerabilità SCADA
La newsletter Sans NewsByte del 20 settembre segnala che "Un ricercatore italiano, Luigi Auriemma, ha pubblicato 13 vulnerabilità di alcuni prodotti SCADA (supervisory control and data acquisition). In marzo, Auriemma aveva già pubblicato altre 34 vulnerabilità."
La notizia su Computerworld:http://www.computerworld.com/s/article/9220099/Researcher_discloses_zero_day_flaws_in_SCADA_systems?taxonomyId=17
Per essere aggiornati in materia, segnalo il ICS-CERT, collegato al "Ministero della Sicurezza Interna" (Department of Homeland Security) degli USA: www.ics-cert.org.
L'ICS-CERT pubblica newsletter mensili e dei Vulnerability Report per gli ICS (o SCADA) che possono interessare i loro utilizzatori.
La notizia su Computerworld:http://www.computerworld.com/s/article/9220099/Researcher_discloses_zero_day_flaws_in_SCADA_systems?taxonomyId=17
Per essere aggiornati in materia, segnalo il ICS-CERT, collegato al "Ministero della Sicurezza Interna" (Department of Homeland Security) degli USA: www.ics-cert.org.
L'ICS-CERT pubblica newsletter mensili e dei Vulnerability Report per gli ICS (o SCADA) che possono interessare i loro utilizzatori.
martedì 20 settembre 2011
Le sanzioni disciplinari nel rapporto di lavoro. Cenni introduttivi
Segnalo questo interessante articolo di Filodiritto sulle sanzioni disciplinari nel rapporto di lavoro.
Come dice il titolo stesso dell'articolo, si tratta di una semplice introduzione. Penso comunque che sia necessaria:http://www.filodiritto.com/index.php?azione=visualizza&iddoc=2429
Come dice il titolo stesso dell'articolo, si tratta di una semplice introduzione. Penso comunque che sia necessaria:http://www.filodiritto.com/index.php?azione=visualizza&iddoc=2429
giovedì 15 settembre 2011
Tor Day
Il 28 giugno, alla Statale di Milano, si è tenuto un incontro con Giovanni Ziccardi, Pierluigi Perri, Andrea Trentini e Jan Reister, tutti dell'Università di Milano, dal titolo "TOR day".
Il TOR è un progetto per l'anonimità on line. Nella sua pagina web (https://www.torproject.org/) è possibile scaricare un browser Firefox con una configurazione specifica e altri software.
Altri miei appunti:
- i siti web per default spesso utilizzano pagine http, anche se sono disponibili quelle https. Il plug-in di Firefox HTTPS Everywhere permette invece di richiedere le pagine https di default
https://www.eff.org/https-everywhere
- per scaricare i video di youtube con TOR o da luoghi dove youtube è censurato: http://pwnyoutube.com o http://deturl.com/
- per creare utenti anonimi, con la possibilità di ricevere files in modo anonimo e per permettere ai mittenti di essere altrettanto anonimi (se usano, ovviamente, TOR): https://privacybox.de/
- via TOR sono poi disponibili diversi "hidden services" (non sempre eticamente accettabili). Per questo, si segnala la pagina http://tor2web.org
Il TOR è un progetto per l'anonimità on line. Nella sua pagina web (https://www.torproject.org/) è possibile scaricare un browser Firefox con una configurazione specifica e altri software.
Altri miei appunti:
- i siti web per default spesso utilizzano pagine http, anche se sono disponibili quelle https. Il plug-in di Firefox HTTPS Everywhere permette invece di richiedere le pagine https di default
https://www.eff.org/https-everywhere
- per scaricare i video di youtube con TOR o da luoghi dove youtube è censurato: http://pwnyoutube.com o http://deturl.com/
- per creare utenti anonimi, con la possibilità di ricevere files in modo anonimo e per permettere ai mittenti di essere altrettanto anonimi (se usano, ovviamente, TOR): https://privacybox.de/
- via TOR sono poi disponibili diversi "hidden services" (non sempre eticamente accettabili). Per questo, si segnala la pagina http://tor2web.org
martedì 13 settembre 2011
Garante: Cloud e smartphones
Il 23 giugno, il Garante ha pubblicato due "schede di documentazione":
- "Cloud computing: indicazioni per l’utilizzo consapevole dei servizi":
http://www.garanteprivacy.it/garante/document?ID=1819933
- "Smartphone e tablet: scenari attuali e prospettive operative":
http://www.garanteprivacy.it/garante/document?ID=1819937
Mi viene da notare che il Garante sta ora espandendo la propria area di azione alla informazione sulla sicurezza informatica, oltre al trattamento dei dati personali.
- "Cloud computing: indicazioni per l’utilizzo consapevole dei servizi":
http://www.garanteprivacy.it/garante/document?ID=1819933
- "Smartphone e tablet: scenari attuali e prospettive operative":
http://www.garanteprivacy.it/garante/document?ID=1819937
Mi viene da notare che il Garante sta ora espandendo la propria area di azione alla informazione sulla sicurezza informatica, oltre al trattamento dei dati personali.
lunedì 5 settembre 2011
BS BS 10008:2008 sulle prove informatiche
Max Cottafavi (Spike Reply) mi segnala che è da tempo pubblicata la BS 10008:2008 dal titolo "Evidential weight and legal admissibility of electronic information. Specification".
Leggendo la presentazione sul sito del BSI Group, mi pare che non sia una anticipazione della ISO/IEC 27037 sulla computer forensics, quanto una norma sulla autenticità dei documenti e delle comunicazioni informatiche. Insomma, qualcosa di molto legata alla firma digitale, per la quale, in Italia, vige il Codice dell'Amministrazione Digitale (Dlgs 82 del 2005) e, quindi, forse questo standard non è utile per le nostre imprese.
Ad ogni modo, posso sempre sbagliarmi e lascio a voi la valutazione (nel caso, provvederò a pubblicare commenti):
http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030191165
Leggendo la presentazione sul sito del BSI Group, mi pare che non sia una anticipazione della ISO/IEC 27037 sulla computer forensics, quanto una norma sulla autenticità dei documenti e delle comunicazioni informatiche. Insomma, qualcosa di molto legata alla firma digitale, per la quale, in Italia, vige il Codice dell'Amministrazione Digitale (Dlgs 82 del 2005) e, quindi, forse questo standard non è utile per le nostre imprese.
Ad ogni modo, posso sempre sbagliarmi e lascio a voi la valutazione (nel caso, provvederò a pubblicare commenti):
http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030191165
ISO/IEC 27035:2011 - Incident management
Il 1 settembre è stata pubblicata la ISO/IEC 27035:2011 dal titolo "Information technology — Security techniques — Information security incident management". Questa norma della famiglia ISO/IEC 270xx sostituisce la ISO/IEC TR 18044:2004.
Oltre alle cose già note e ripetute in mille altri contesti (scrivere politica, registrare gli incidenti, eccetera), sono sviluppati i seguenti argomenti:
- istituzione di un ISIRT (o CERT)
- un'appendice con degli esempi di incidente
- un'appendice con esempi di categorizzazione degli incidenti (in molti, in questi anni, mi hanno chiesto se c'era uno standard con questi esempi; la ISO/IEC TR 18044 non li aveva, ora ci sono)
- esempi di reportistica (già presenti nella ISO/IEC TR 18044)
Ovviamente, non mancano riflessioni su escalation, analisi approfondite dopo aver superato l'emergenza, computer forensics, gestione delle comunicazioni, eccetera.
Il tutto è più orientato al trattamento di attacchi o di gravi incidenti, che alla gestione di eventi meno significativi. Ovviamente, chi seguirà questo standard farà in modo di implementarlo in modo corretto.
Le norme ISO costano (www.iso.org). Per chi vuole risorse autorevoli e gratuite, segnalo la guida del NIST (http://csrc.nist.gov/publications/PubsSPs.html), SP 800-61 "Computer Security Incident Handling Guide" del 2008:
http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf
Grazie a Franco Ferrari del DNV Italia per la segnalazione.
Oltre alle cose già note e ripetute in mille altri contesti (scrivere politica, registrare gli incidenti, eccetera), sono sviluppati i seguenti argomenti:
- istituzione di un ISIRT (o CERT)
- un'appendice con degli esempi di incidente
- un'appendice con esempi di categorizzazione degli incidenti (in molti, in questi anni, mi hanno chiesto se c'era uno standard con questi esempi; la ISO/IEC TR 18044 non li aveva, ora ci sono)
- esempi di reportistica (già presenti nella ISO/IEC TR 18044)
Ovviamente, non mancano riflessioni su escalation, analisi approfondite dopo aver superato l'emergenza, computer forensics, gestione delle comunicazioni, eccetera.
Il tutto è più orientato al trattamento di attacchi o di gravi incidenti, che alla gestione di eventi meno significativi. Ovviamente, chi seguirà questo standard farà in modo di implementarlo in modo corretto.
Le norme ISO costano (www.iso.org). Per chi vuole risorse autorevoli e gratuite, segnalo la guida del NIST (http://csrc.nist.gov/publications/PubsSPs.html), SP 800-61 "Computer Security Incident Handling Guide" del 2008:
http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf
Grazie a Franco Ferrari del DNV Italia per la segnalazione.
ISO 31000: 2009 - Versione italiana
Franco Ferrari del DNV Italia mi segnala che in novembre 2010 è stata pubblicata la versione italiana della ISO 31000:2009 "Risk management — Principles and guidelines".
E' quindi disponibile presso la UNI la UNI ISO 31000:2010 "Gestione del rischio - Principi e linee guida"
E' quindi disponibile presso la UNI la UNI ISO 31000:2010 "Gestione del rischio - Principi e linee guida"
Versione italiana della ISO/IEC 17021:2011
Franco Ferrari mi segnala che a marzo 2011 è stata emessa la traduzione italiana della ISO/IEC 17021:2011 "Conformity assessment — Requirements for bodies providing audit and certification of management systems".
E' quindi disponibile la UNI CEI EN ISO/IEC 17021:2011 "Valutazione della conformità - Requisiti per gli organismi che forniscono audit e certificazione di sistemi di gestione".
Ricordo che questa norma è applicabile ai soli organismi di certificazione, sulla base della quale sono accreditati da orgnismi quali Accredia, UKAS, eccetera.
E' quindi disponibile la UNI CEI EN ISO/IEC 17021:2011 "Valutazione della conformità - Requisiti per gli organismi che forniscono audit e certificazione di sistemi di gestione".
Ricordo che questa norma è applicabile ai soli organismi di certificazione, sulla base della quale sono accreditati da orgnismi quali Accredia, UKAS, eccetera.
venerdì 2 settembre 2011
Regole tecniche documento informatico
Segnalazione ricevuta da Uninfo: DigitPA ha pubblicato la bozza delle regole tecniche documento informatico e gestione documentale, protocollo informatico e sistema conservazione di documenti.
Queste regole dovrebbero sostituire la Circolare CNIPA 11/2004 e AIPA 28/2001 e prendere in carico i requisiti del CAD dopo le modifiche apportate dal Dlgs 235 del 2010.
La bozza è stata pubblicata il 5 agosto e i commenti possono essere inviati entro il 10 settembre. Non commento i tempi.
Può essere comunque utile leggere il materiale proposto:
http://www.digitpa.gov.it/altre-attivit/pubblicata-bozza-regole-tecniche-documento-informatico-protocollo-informatico-conserva
Queste regole dovrebbero sostituire la Circolare CNIPA 11/2004 e AIPA 28/2001 e prendere in carico i requisiti del CAD dopo le modifiche apportate dal Dlgs 235 del 2010.
La bozza è stata pubblicata il 5 agosto e i commenti possono essere inviati entro il 10 settembre. Non commento i tempi.
Può essere comunque utile leggere il materiale proposto:
http://www.digitpa.gov.it/altre-attivit/pubblicata-bozza-regole-tecniche-documento-informatico-protocollo-informatico-conserva
venerdì 26 agosto 2011
I 20 controlli di sicurezza critici
Il SANS ha pubblicato la terza versione del suo elenco dei 20 controlli di sicurezza più importanti.
https://www.sans.org/critical-security-controls/
Il documento in pdf è di 76 pagine. Mi sembra interessante come sono descritte le modalità di implementazione, perché sono distinti i quick wins, attività di monitoraggio, attività di riduzione delle vulnerabilità e controlli avanzati. Il tutto è preceduto da un rationale.
https://www.sans.org/critical-security-controls/
Il documento in pdf è di 76 pagine. Mi sembra interessante come sono descritte le modalità di implementazione, perché sono distinti i quick wins, attività di monitoraggio, attività di riduzione delle vulnerabilità e controlli avanzati. Il tutto è preceduto da un rationale.
Transizione delle certificazioni ISO/IEC 20000-1:2005 a ISO/IEC 20000-1:2011
Dal webinar di APMG "ISO/IEC 20000 - Part 1 Update Explained" del 3 agosto 2011, fornisco risposte a domande che mi sono state poste in questi mesi.
E' bene far notare che le risposte riguardano lo schema di APMG, dovremo vedere se saranno valide anche per le certificazioni gestite da altri organismi (Accredia, UKAS, etc):
- non sono previsti corsi di aggiornamento per Auditor e Lead Auditor (che dovranno comunque studiarsi autonomamanete la nuova norma)- i nuovi certificati dovranno essere basati sulla nuova norma se emessi dopo il 1 giugno 2012
- gli audit di mantenimento, potranno essere condotti sulla ISO/IEC 20000-1:2005 fino al 1 giugno 2013
- l'aggiornamento della ISO/IEC 20000-2 dovrebbe essere pubblicato a inizio 2012
La presentazione del webinar la trovate al link
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4891&sID=4752
E' bene far notare che le risposte riguardano lo schema di APMG, dovremo vedere se saranno valide anche per le certificazioni gestite da altri organismi (Accredia, UKAS, etc):
- non sono previsti corsi di aggiornamento per Auditor e Lead Auditor (che dovranno comunque studiarsi autonomamanete la nuova norma)- i nuovi certificati dovranno essere basati sulla nuova norma se emessi dopo il 1 giugno 2012
- gli audit di mantenimento, potranno essere condotti sulla ISO/IEC 20000-1:2005 fino al 1 giugno 2013
- l'aggiornamento della ISO/IEC 20000-2 dovrebbe essere pubblicato a inizio 2012
La presentazione del webinar la trovate al link
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4891&sID=4752
APMG Ente di Accreditamento per la ISO/IEC 20000-1 (seconda puntata)
Il 27 maggio avevo pubblicato la notizia "APMG Ente di Accreditamento per la ISO/IEC 20000-1":
http://blog.cesaregallotti.it/2011/05/apmg-ente-di-accreditamento-per-la.html
Con il seguente commento: "Sarà interessante capire come saranno gestite le relazioni tra certificati aziendali accreditati APMG e quelli accreditati da altri organismi di certificazione quali Accredia (ex Sincert)".
Tony Coletta, al webinar di APMG "ISO/IEC 20000 - Part 1 Update Explained" del 3 agosto 2011 ha posto questa domanda, soprattutto facendo riferimento alla EC Regulation 765/08 che impone a ciascun stato della UE di avere un unico ente di accreditamento riconosciuto dagli altri stati membri attraverso gli accordi EA MLA (e, pertanto, non ci dovrebbe essere spazio per un ente quale APMG).
APMG ha risposto così (riassumo): "Un ente di accreditamento come UKAS in UK non è coinvolto nelle attività di itSMF e operano il proprio schema di certificazione ISO/IEC 20000 con 3 organismi accreditati, mentre APMG ne ha 50. Altro punto da considerare è che ci sono diversi schemi di certificazione accreditati (con la "a" minuscola) anche al di fuori degli accordi EA MLA, ma comunque riconosciuti dal mercato. E' intenzione di APMG lavorare a stretto contatto con gli organismi di Accreditamento nazionali per garantire l'efficacia dello schema".
Forse ho riassunto male e forse ho tradotto male, ma mi sembra che al momento la situazione sia ancora lacunosa.
Ad ogni modo, potete leggere la presentazione del webinar:
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4891&sID=4752
e le risposte alle domande (tra cui quella di Tony Coletta):
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4892&sID=4752
Alcuni punti sullo schema di certificazione su cui ho ricevuto domande nei mesi scorsi, nel post successivo.
http://blog.cesaregallotti.it/2011/05/apmg-ente-di-accreditamento-per-la.html
Con il seguente commento: "Sarà interessante capire come saranno gestite le relazioni tra certificati aziendali accreditati APMG e quelli accreditati da altri organismi di certificazione quali Accredia (ex Sincert)".
Tony Coletta, al webinar di APMG "ISO/IEC 20000 - Part 1 Update Explained" del 3 agosto 2011 ha posto questa domanda, soprattutto facendo riferimento alla EC Regulation 765/08 che impone a ciascun stato della UE di avere un unico ente di accreditamento riconosciuto dagli altri stati membri attraverso gli accordi EA MLA (e, pertanto, non ci dovrebbe essere spazio per un ente quale APMG).
APMG ha risposto così (riassumo): "Un ente di accreditamento come UKAS in UK non è coinvolto nelle attività di itSMF e operano il proprio schema di certificazione ISO/IEC 20000 con 3 organismi accreditati, mentre APMG ne ha 50. Altro punto da considerare è che ci sono diversi schemi di certificazione accreditati (con la "a" minuscola) anche al di fuori degli accordi EA MLA, ma comunque riconosciuti dal mercato. E' intenzione di APMG lavorare a stretto contatto con gli organismi di Accreditamento nazionali per garantire l'efficacia dello schema".
Forse ho riassunto male e forse ho tradotto male, ma mi sembra che al momento la situazione sia ancora lacunosa.
Ad ogni modo, potete leggere la presentazione del webinar:
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4891&sID=4752
e le risposte alle domande (tra cui quella di Tony Coletta):
http://www.apmg-international.com/nmsruntime/saveasdialog.asp?lID=4892&sID=4752
Alcuni punti sullo schema di certificazione su cui ho ricevuto domande nei mesi scorsi, nel post successivo.
Schema di regolamento su Diritto d'Autore su Internet
Giovanni Francescutti (DNV Italia) segnala l'iniziativa dell'Autorità per le
Garanzie nelle Telecomunicazioni sul Diritto d'Autore. In particolare,
l'AGCOM ha presentato uno "schema di regolamento in materia di tutela del
diritto d'autore sulle reti di comunicazione elettronica".
Riguarda soprattutto il ruolo e le responsabilità degli ISP nel pubblicare
contenuti non rispettosi del Diritto d'Autore e le modalità che dovranno
seguire.
E' possibile leggere il Comunicato Stampa del 6 luglio 2011:
http://www.agcom.it/Default.aspx?message=visualizzadocument&DocID=6663
Lo schema di regolamento in consultazione pubblica per 60 giorni:
http://www.agcom.it/Default.aspx?DocID=6694
<http://www.agcom.it/Default.aspx?DocID=6694>
La delibera 398 del 2011 dell'AGCOM con indicati i diversi contributi
ricevuti per la redazione dello schema di regolamento:
http://www.agcom.it/Default.aspx?DocID=5413
<http://www.agcom.it/Default.aspx?DocID=5413>
Nota: quello che qui è chiamato "schema", altri chiamerebbero "bozza".
Sarà ovviamente interessante vedere come andrà avanti l'iniziativa e i
successivi commenti.
Intanto segnalo già i primi due commenti di Simone Tomirotti che gentilmente
me l'ha segnalato:
-
http://italianjam.blogspot.com/2011/07/lagcom-e-il-diritto-dautore-la-mia.ht
ml
- http://italianjam.blogspot.com/2011/08/la-proposta-dellagcom-e-blanda.html
Garanzie nelle Telecomunicazioni sul Diritto d'Autore. In particolare,
l'AGCOM ha presentato uno "schema di regolamento in materia di tutela del
diritto d'autore sulle reti di comunicazione elettronica".
Riguarda soprattutto il ruolo e le responsabilità degli ISP nel pubblicare
contenuti non rispettosi del Diritto d'Autore e le modalità che dovranno
seguire.
E' possibile leggere il Comunicato Stampa del 6 luglio 2011:
http://www.agcom.it/Default.aspx?message=visualizzadocument&DocID=6663
Lo schema di regolamento in consultazione pubblica per 60 giorni:
http://www.agcom.it/Default.aspx?DocID=6694
<http://www.agcom.it/Default.aspx?DocID=6694>
La delibera 398 del 2011 dell'AGCOM con indicati i diversi contributi
ricevuti per la redazione dello schema di regolamento:
http://www.agcom.it/Default.aspx?DocID=5413
<http://www.agcom.it/Default.aspx?DocID=5413>
Nota: quello che qui è chiamato "schema", altri chiamerebbero "bozza".
Sarà ovviamente interessante vedere come andrà avanti l'iniziativa e i
successivi commenti.
Intanto segnalo già i primi due commenti di Simone Tomirotti che gentilmente
me l'ha segnalato:
-
http://italianjam.blogspot.com/2011/07/lagcom-e-il-diritto-dautore-la-mia.ht
ml
- http://italianjam.blogspot.com/2011/08/la-proposta-dellagcom-e-blanda.html
Minacce e attacchi
In molti mi chiedono dove trovare una lista di attacchi per iniziare a fare un'analisi del rischio.
Da Crypto-Gram del 15 agosto, segnalo questo documento della Canergy Mellon University che può essere un ottimo inizio:
http://www.cert.org/archive/pdf/10tn028.pdf
Per chi volesse andare più in profondità, dai commenti a Crypto-Gram, segnalo il VERIS Framework: https://verisframework.wiki.zoho.com/
Qui l'elenco è molto più dettagliato e forse di difficile utilizzo per un risk assessment generale. La web application messa a disposizione può essere di ulteriore aiuto: https://www2.icsalabs.com/veris/. Per chi volesse leggere un documento vero e proprio, segnalo il "Verizon Data Breach Investigations Report" con riportate anche le statistiche pertinenti (sempre da prendere con cautela).
Da Crypto-Gram del 15 agosto, segnalo questo documento della Canergy Mellon University che può essere un ottimo inizio:
http://www.cert.org/archive/pdf/10tn028.pdf
Per chi volesse andare più in profondità, dai commenti a Crypto-Gram, segnalo il VERIS Framework: https://verisframework.wiki.zoho.com/
Qui l'elenco è molto più dettagliato e forse di difficile utilizzo per un risk assessment generale. La web application messa a disposizione può essere di ulteriore aiuto: https://www2.icsalabs.com/veris/. Per chi volesse leggere un documento vero e proprio, segnalo il "Verizon Data Breach Investigations Report" con riportate anche le statistiche pertinenti (sempre da prendere con cautela).
giovedì 25 agosto 2011
ROSI v2
Il 16 maggio del 2010 avevo segnalato lo studio sul ROSI condotto da AIEA,
CLUSIT, Deloitte, Ernst & Young, KPMG, Oracle, PricewaterhouseCoopers.
Ora ne è uscita la versione 2, liberamente scaricabile da
http://rosi.clusit.it.
Ci sono alcuni spunti interessanti e la lettura è consigliata. Tra l'altro,
avevo già segnalato che lo studio prende correttamente atto
dell'impossibilità di calcolare il ritorno degli investimenti di sicurezza
(dico io: se sono impossibili le analisi del rischio quantitative, sarà
ovviamente impossibile valutare in modo esatto la bontà degli investimenti
di sicurezza) e propone un approccio degno di attenzione.
CLUSIT, Deloitte, Ernst & Young, KPMG, Oracle, PricewaterhouseCoopers.
Ora ne è uscita la versione 2, liberamente scaricabile da
http://rosi.clusit.it.
Ci sono alcuni spunti interessanti e la lettura è consigliata. Tra l'altro,
avevo già segnalato che lo studio prende correttamente atto
dell'impossibilità di calcolare il ritorno degli investimenti di sicurezza
(dico io: se sono impossibili le analisi del rischio quantitative, sarà
ovviamente impossibile valutare in modo esatto la bontà degli investimenti
di sicurezza) e propone un approccio degno di attenzione.
ITIL2011
Il 29 luglio è stata pubblicata la versione 2011 di ITIL. Come già detto,
non si tratta di una versione 4, ma di una versione 3.1.
Faccio un breve riassunto delle novità, affidandomi alla newsletter del 3
agosto di itSMF Italia (i commenti sono miei, ovviamente):
- le nuove pubblicazioni sono acquistabili da itSMF Italia (www.itsmf.it) o
da www.best-management-practice.com; il costo è di non poche 360 sterline
inglesi (410 Euro);
- se già le pubblicazioni del 2007 vi sembravano corpose (un totale di 1.344
pagine), sappiate che le cose non sono migliorate: ora il numero totale di
pagine è di 1.888:
- buona notizia: non sono previsti aggiornamenti (o "bridge") delle
certificazioni ottenute negli anni scorsi su ITILv3; in altre parole, se
avete già un certificato ITILv3 Foundation o Intermediate o Expert, è ancora
valido;
- non è stato ridotto il numero di processi: ora la Service Strategy ne
prevede 5 e al Service Design è stato aggiunto il processo di Design
Coordination (che in effetti mancava... come era facilmente intuibile); gli
altri rimangono dove sono: i redattori di ITIL2011 hanno dimostrato di non
voler buttare via nulla e hanno lasciato dei "processi" che sono
evidentemente delle "attività".
Ad ogni modo, i nuovi esami sono disponibili dal 8 agosto.
Per chi se la sente: buona lettura!
non si tratta di una versione 4, ma di una versione 3.1.
Faccio un breve riassunto delle novità, affidandomi alla newsletter del 3
agosto di itSMF Italia (i commenti sono miei, ovviamente):
- le nuove pubblicazioni sono acquistabili da itSMF Italia (www.itsmf.it) o
da www.best-management-practice.com; il costo è di non poche 360 sterline
inglesi (410 Euro);
- se già le pubblicazioni del 2007 vi sembravano corpose (un totale di 1.344
pagine), sappiate che le cose non sono migliorate: ora il numero totale di
pagine è di 1.888:
- buona notizia: non sono previsti aggiornamenti (o "bridge") delle
certificazioni ottenute negli anni scorsi su ITILv3; in altre parole, se
avete già un certificato ITILv3 Foundation o Intermediate o Expert, è ancora
valido;
- non è stato ridotto il numero di processi: ora la Service Strategy ne
prevede 5 e al Service Design è stato aggiunto il processo di Design
Coordination (che in effetti mancava... come era facilmente intuibile); gli
altri rimangono dove sono: i redattori di ITIL2011 hanno dimostrato di non
voler buttare via nulla e hanno lasciato dei "processi" che sono
evidentemente delle "attività".
Ad ogni modo, i nuovi esami sono disponibili dal 8 agosto.
Per chi se la sente: buona lettura!
Sesso, bugie e ricerche sul cybercrime
Da sempre diffido delle ricerche e dei dati sugli attacchi informatici. E,
conseguentemente, da sempre penso che le analisi di rischio quantitative
siano impossibili da fare.
C'è chi ha raccolto le prove (come segnalato da Cryptogram di luglio):
http://research.microsoft.com/pubs/149886/SexLiesandCybercrimeSurveys.pdf
conseguentemente, da sempre penso che le analisi di rischio quantitative
siano impossibili da fare.
C'è chi ha raccolto le prove (come segnalato da Cryptogram di luglio):
http://research.microsoft.com/pubs/149886/SexLiesandCybercrimeSurveys.pdf
giovedì 28 luglio 2011
Privacy: Legge 106 del 2011 con modifiche al Codice
A maggio era stato emesso il DL 70 del 2011 che (all'articolo 6, comma 2),
tra le altre cose, presentava alcune semplificazioni in materia di privacy.
Ora il DL è stato definitivamente approvato (come mi ha segnalato Franco
Ferrari del DNV) con la Legge 106 del 2011.
Anche con l'aiuto della circolare 19439 di Confindustria (disponibile solo
agli iscritti di Confindustria e altri siti), provo a riassumere i punti
rilevanti:
1. fornita una nuova definizione di "trattamenti effettuati per finalità
amministrativo-contabili", che semplifica gli adempimenti di gestione del
personale; osservo però che molti comportamenti di "buona condotta" del
datore di lavoro (applicazione di misure di sicurezza e non diffusione dei
dati) rimangono attivi.
2. esclusi dall'ambito di applicazione del Codice i trattamenti di dati
effettuati nei rapporti business to business (B2B) per finalità
amministrativo-contabili, con semplificazioni nella gestione dei clienti e
fornitori quando non sono persone fisiche, eliminando la necessità di
informative e raccolte di consenso (peraltro già molto ridotte nel testo
originale del 2003); si potrebbe anche vedere ridotti gli oneri
sull'applicazione delle misure minime e sulle nomine dei responsabili, ma
questo rappresenterebbe una cattiva pratica gestionale, oltre che introdurre
complicazioni quando si deve analizzare gli impatti di ogni misura minima
sui dati personali oggetto del Codice e quelli esclusi
3. esonerate dal consenso le comunicazioni di dati nell'ambito di gruppi
d'impresa, con ovvi benefici per le realtà di gruppo
4. esteso l'ambito di applicazione dell'autocertificazione sostituiva del
DPS; ma, abbiamo visto, in alcuni casi è più "facile" fare il DPS che
seguire le istruzioni per l'autocertificazione, oltre che più produttivo, se
fatto correttamente
5. esclusione dell'obbligo di informativa e consenso per i curricula vitae
trasmessi spontaneamente dall'interessato; con altri ovvi benefici
6. l'estensione del regime di opt-out previsto per le telefonate commerciali
anche al marketing mediante posta cartacea, perché hanno impatto sulle
persone fisiche
Il testo del DL 70 del 2011 consolidato con la Legge 106 del 2011 lo si
trova su www.normattiva.it (cercando il solo DL 70 del 2011).
tra le altre cose, presentava alcune semplificazioni in materia di privacy.
Ora il DL è stato definitivamente approvato (come mi ha segnalato Franco
Ferrari del DNV) con la Legge 106 del 2011.
Anche con l'aiuto della circolare 19439 di Confindustria (disponibile solo
agli iscritti di Confindustria e altri siti), provo a riassumere i punti
rilevanti:
1. fornita una nuova definizione di "trattamenti effettuati per finalità
amministrativo-contabili", che semplifica gli adempimenti di gestione del
personale; osservo però che molti comportamenti di "buona condotta" del
datore di lavoro (applicazione di misure di sicurezza e non diffusione dei
dati) rimangono attivi.
2. esclusi dall'ambito di applicazione del Codice i trattamenti di dati
effettuati nei rapporti business to business (B2B) per finalità
amministrativo-contabili, con semplificazioni nella gestione dei clienti e
fornitori quando non sono persone fisiche, eliminando la necessità di
informative e raccolte di consenso (peraltro già molto ridotte nel testo
originale del 2003); si potrebbe anche vedere ridotti gli oneri
sull'applicazione delle misure minime e sulle nomine dei responsabili, ma
questo rappresenterebbe una cattiva pratica gestionale, oltre che introdurre
complicazioni quando si deve analizzare gli impatti di ogni misura minima
sui dati personali oggetto del Codice e quelli esclusi
3. esonerate dal consenso le comunicazioni di dati nell'ambito di gruppi
d'impresa, con ovvi benefici per le realtà di gruppo
4. esteso l'ambito di applicazione dell'autocertificazione sostituiva del
DPS; ma, abbiamo visto, in alcuni casi è più "facile" fare il DPS che
seguire le istruzioni per l'autocertificazione, oltre che più produttivo, se
fatto correttamente
5. esclusione dell'obbligo di informativa e consenso per i curricula vitae
trasmessi spontaneamente dall'interessato; con altri ovvi benefici
6. l'estensione del regime di opt-out previsto per le telefonate commerciali
anche al marketing mediante posta cartacea, perché hanno impatto sulle
persone fisiche
Il testo del DL 70 del 2011 consolidato con la Legge 106 del 2011 lo si
trova su www.normattiva.it (cercando il solo DL 70 del 2011).
lunedì 25 luglio 2011
ISO 29110: Software Life Cycle Profiles and Guidelines for Very Small Entities
Nel 2011 è stata pubblicata la ISO 29110 sul ciclo di vita del software per le piccole imprese (fino a 25 persone). Si tratta di uno standard diviso in 5 parti.
Per saperne di più:
https://secure.wikimedia.org/wikipedia/en/wiki/ISO_29110:Software_Life_Cycle_Profiles_and_Guidelines_for_Very_Small_Entities_%28VSEs%29
La notizia mi arriva dal gruppo di LinkedIn "ISO/IEC JTC 1/SC7 Software and Systems Engineering".
Alla fine dell'articolo, ci sono i link per procurarsele. Tre delle 5 parti sono gratis:
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.
Per saperne di più:
https://secure.wikimedia.org/wikipedia/en/wiki/ISO_29110:Software_Life_Cycle_Profiles_and_Guidelines_for_Very_Small_Entities_%28VSEs%29
La notizia mi arriva dal gruppo di LinkedIn "ISO/IEC JTC 1/SC7 Software and Systems Engineering".
Alla fine dell'articolo, ci sono i link per procurarsele. Tre delle 5 parti sono gratis:
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.
Firma digitale, questa sconosciuta
Luca De Grazia mi segnala un articolo che lo riguarda in merito alle sue
disavventure nel fare accettare dalla Pubblica Amministrazione dei documenti
firmati digitalmente.
Mi sono ricordato anche che, in forza dell'articolo 16 del DL 185 del 2008)
il 29 novembre tutte le imprese dovranno avere la Posta Elettronica
Certificata per comunicare con la Pubblica Amministrazione.
il 29 novembre tutte le imprese dovranno avere la Posta Elettronica
Certificata per comunicare con la Pubblica Amministrazione.
Luca De Grazia mi ha ricordato che la PEC è strumento diverso dalla
sottoscrizione con firma digitale. Se però oggi siamo a questo punto,
sicuramente ne vedremo delle belle.
sottoscrizione con firma digitale. Se però oggi siamo a questo punto,
sicuramente ne vedremo delle belle.
mercoledì 20 luglio 2011
Sentenza: Accessi abusivi e 231
Dalla newsletter di Filodiritto segnalo questa sentenza della Cassazione
Penale.
http://www.cortedicassazione.it/Notizie/GiurisprudenzaPenale/SezioniSemplici
/SchedaNews.asp?ID=1698
/SchedaNews.asp?ID=1698
La sentenza tratta di diverse cose. Quelle di rilievo per questo blog sono:
- Punto 9.3: "commette il reato di cui all'articolo 615ter Codice Penale non
solo chi si introduca abusivamente nel sistema informatico protetto, ma
anche chi si intrattenga al suo interno [Nota di Cesare: pur essendo un
utente autorizzato del sistema], contro la volontà espressa o tacita di chi
abbia diritto di escluderlo, per finalità diverse da quella per le quali
l'abilitazione era stata concessa."; in altre parole: gli utenti autorizzati
che usano il sistema informatico per raccogliere dati, senza averne il
permesso esplicito o tacito, commette reato perché abusano della propria
posizione
- Punto 11.3: la società capogruppo può essere chiamata a rispondere, ai
sensi del d. lgs. n. 231 del 2001, per il reato commesso nell'ambito
dell'attività di altra società del gruppo, purchè nella sua consumazione
concorra una persona fisica che agisca per conto della holding perseguendo
anche l'interesse di quest'ultima.
- Punto 9.3: "commette il reato di cui all'articolo 615ter Codice Penale non
solo chi si introduca abusivamente nel sistema informatico protetto, ma
anche chi si intrattenga al suo interno [Nota di Cesare: pur essendo un
utente autorizzato del sistema], contro la volontà espressa o tacita di chi
abbia diritto di escluderlo, per finalità diverse da quella per le quali
l'abilitazione era stata concessa."; in altre parole: gli utenti autorizzati
che usano il sistema informatico per raccogliere dati, senza averne il
permesso esplicito o tacito, commette reato perché abusano della propria
posizione
- Punto 11.3: la società capogruppo può essere chiamata a rispondere, ai
sensi del d. lgs. n. 231 del 2001, per il reato commesso nell'ambito
dell'attività di altra società del gruppo, purchè nella sua consumazione
concorra una persona fisica che agisca per conto della holding perseguendo
anche l'interesse di quest'ultima.
L'articolo su Filodiritto:
http://www.filodiritto.com/index.php?azione=archivionews&idnotizia=3258
http://www.filodiritto.com/index.php?azione=archivionews&idnotizia=3258
giovedì 14 luglio 2011
Privacy: dei Titolari e dei Responsabili esterni - Parte 4
NOTA del 2018: questo articolo era di inizio 2016 e contiene errori evidenti. Ha trovato risposte con la pubblicazione del GDPR.
Il 15 giugno, il Garante ha emesso un Provvedimento dal titolo "Titolaritàdel trattamento di dati personali in capo ai soggetti che si avvalgono di agenti per attività promozionali". In questo caso, invita le aziende che danno mandato ad agenti per le attività promozionali a nominare tali agenti "Responsabili del trattamento". Questo pare contraddire alcune riflessioni fatte in post precedenti:
Il 15 giugno, il Garante ha emesso un Provvedimento dal titolo "Titolaritàdel trattamento di dati personali in capo ai soggetti che si avvalgono di agenti per attività promozionali". In questo caso, invita le aziende che danno mandato ad agenti per le attività promozionali a nominare tali agenti "Responsabili del trattamento". Questo pare contraddire alcune riflessioni fatte in post precedenti:
- http://blog.cesaregallotti.it/2011/06/privacy-dei-titolari-e-dei-responsabili.html
- http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili_04.html
- http://blog.cesaregallotti.it/2011/06/privacy-dei-titolari-e-dei-responsabili.html
- http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili_04.html
- http://blog.cesaregallotti.it/2011/06/privacy-dei-titolari-e-dei-responsabili.html
Aggiungo queste riflessioni:
- in questo caso specifico, si tratta di contratti di agenzia e il Garante evidenzia che gli agenti agiscono già nei fatti come responsabili (perché controllati dal cliente, perché agiscono in suo nome, eccetera);
- nel Provvedimento si cita la definizione di Titolare "cui competono, anche unitamente ad altro titolare, le decisioni...", ma furbescamente si omette la parte "anche unitamente ad altro titolare" e ancora una volta si evita di darne un'interpretazione
- il Provvedimento asserisce che il Titolare esercita già nei fatti il "controllo" sugli agenti, ma non cita neanche una modalità con cui questo viene effettuato, laddove ogni dizionario equipara il termine "controllo" con quello di "verifica" e non con quello di "fornire indicazioni"; anche qui, ancora una volta, si evita di darne un esempio (mi ricorda molto le non definite modalità di "verifica" delle attività degli Amministratori di Sistema).
Ecco qui il link al Provvedimento:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1821257
http://www.garanteprivacy.it/garante/doc.jsp?ID=1821257
giovedì 7 luglio 2011
Sulla formazione sulla sicurezza
In molti mi chiedono "quale corso seguire" sulla sicurezza. A questo proposito, copio, traduco con qualche modifica e incollo l'editoriale di Hervé Schauer sulla newsletter della sua società di consulenza HSC (sito web www.hsc.fr).
<< Presso HSC un consulente su due ha fatto un master sulla sicurezza. Con questo, hanno imparato, non sempre benissimo, cose che si imparano facilmente in azienda o con la formazione continua. Sono formati a rispondere bene durante i colloqui, ma non a fare quello che oggi non si insegna più nelle aziende: dai fondamentali dell'informatica alla corretta scrittura in francese, oltre a qualche qualità umana.
20 dopo alcune mie iniziative di promozione di corsi specialistici e in un altro contesto, penso che la moltiplicazione dei corsi sulla sicurezza sia nefasta e inutile. Si basa solo sul profitto. Solo la crittologia giustifica pienamente un insegnamento universitario superiore. La scuola deve insegnare a pianificare, amministrare, sintetizzare, essere disciplinati e imparare a imparare e non tecniche di intrusione o le tecniche di risk assessment. >>
L'avrei scritto in modo diverso, ma condivido appieno.
<< Presso HSC un consulente su due ha fatto un master sulla sicurezza. Con questo, hanno imparato, non sempre benissimo, cose che si imparano facilmente in azienda o con la formazione continua. Sono formati a rispondere bene durante i colloqui, ma non a fare quello che oggi non si insegna più nelle aziende: dai fondamentali dell'informatica alla corretta scrittura in francese, oltre a qualche qualità umana.
20 dopo alcune mie iniziative di promozione di corsi specialistici e in un altro contesto, penso che la moltiplicazione dei corsi sulla sicurezza sia nefasta e inutile. Si basa solo sul profitto. Solo la crittologia giustifica pienamente un insegnamento universitario superiore. La scuola deve insegnare a pianificare, amministrare, sintetizzare, essere disciplinati e imparare a imparare e non tecniche di intrusione o le tecniche di risk assessment. >>
L'avrei scritto in modo diverso, ma condivido appieno.
Cobit 5: il draft
L'ISACA ha pubblicato il draft del Cobit5 e chiede commenti. A inizio 2012
dovrebbe pubblicare la versione finale.
Non sono un esperto di Cobit e quindi mi guardo bene dal commentarlo.
Ritengo però sia necessario conoscerlo perché propone dei modelli molto
interessanti, con carte RACI e un elenco di misure tra cui scegliere.
Ritengo però sia necessario conoscerlo perché propone dei modelli molto
interessanti, con carte RACI e un elenco di misure tra cui scegliere.
Mi pare di notare che in questa edizione non siano più utilizzati i modelli
di maturità come nel passato, preferendo un modello generale descritto una
volta per tutte nel documento di descrizion del framework.
di maturità come nel passato, preferendo un modello generale descritto una
volta per tutte nel documento di descrizion del framework.
Top 25 Most Dangerous Software Errors
Agli americani piace fare classifiche e non sempre significative. Questa del
SANS però è interessante e importante perché allinea gli errori di sviluppo
più comuni e pericolosi e fornisce linee guida per evitarli.
- la pagina di introduzione del SANS:
- il report: http://cwe.mitre.org/top25/
Sicurezza iPhones e Android
Sul gruppo Clusit di LinkedIn, Aldo Ceccarelli segnala questo articolo della
Symantec sulla sicurezza di iPhone e Android:
- l'articolo su Networkworld:
http://www.networkworld.com/news/2011/062811-symantec-mobile-report.html
- il rapporto della Symantec:
http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_se
curity_june2011.pdf
Non si parla di Blackberry, l'unico per il quale il NIST ha prodotto una
check list di sicurezza:
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=252
Segnalo quindi la guida 800-124 del NIST sulla sicurezza di cellulari e PDA:
http://csrc.nist.gov/publications/nistpubs/800-124/SP800-124.pdf
Symantec sulla sicurezza di iPhone e Android:
- l'articolo su Networkworld:
http://www.networkworld.com/news/2011/062811-symantec-mobile-report.html
- il rapporto della Symantec:
http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_se
curity_june2011.pdf
Non si parla di Blackberry, l'unico per il quale il NIST ha prodotto una
check list di sicurezza:
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=252
Segnalo quindi la guida 800-124 del NIST sulla sicurezza di cellulari e PDA:
http://csrc.nist.gov/publications/nistpubs/800-124/SP800-124.pdf
mercoledì 29 giugno 2011
Sulle survey sulla sicurezza
Aldo Ceccarelli, sul gruppo Clusit di LinkedIn, ha postato questo interessante articolo sulle survey sulla sicurezza:
http://www.technologyreview.com/business/37839/?ref=rss
Questo articolo mi ha ricordato un piccolo dibattito che abbiamo avuto qualche tempo fa su non-mi-ricordo-quale survey.
Io dicevo che mi lasciano sempre perplesso e, giustamente, Aldo rifletteva sul fatto che comunque forniscono qualche spunto interessante.
Questo articolo dice proprio che le survey sulla sicurezza forniscono "qualche spunto". Non di più.
http://www.technologyreview.com/business/37839/?ref=rss
Questo articolo mi ha ricordato un piccolo dibattito che abbiamo avuto qualche tempo fa su non-mi-ricordo-quale survey.
Io dicevo che mi lasciano sempre perplesso e, giustamente, Aldo rifletteva sul fatto che comunque forniscono qualche spunto interessante.
Questo articolo dice proprio che le survey sulla sicurezza forniscono "qualche spunto". Non di più.
Novità su ITIL V3.1
Un post di Luigi Buglione su LinkedIn fornisce il link al documento ufficiale sulle novità di ITIL v3.1.
http://www.best-management-practice.com/gempdf/ITIL_UPdate_FAQs_Summer_2011_June11.pdf
Innanzitutto il titolo ufficiale sarà "ITIL 2011" anche se tutti, quasi sicuramente, lo chiameremo ITIL v3.1.
La data di pubblicazione è il 29 luglio 2011, prima in formato cartaceo e poi in formato elettronico.
La novità più grande riguarderà la fase di Strategy. Per le altre fasi, ci saranno "chiarimenti". Il documento non sembra dare indicazioni sui tanti argomenti attualmente confusi.
Ultima cosa interessante è che "chi è già in possesso di certificati ITIL, non avrà la necessità di ri-certificarsi": se capisco bene, le qualifiche ITIL 2007 e ITIL 2011 saranno uguali quindi indistinguibili tra loro.
Il commento di IT Skeptic fornisce ulteriori spunti di riflessione:
http://www.itskeptic.org/itil-v3-2011-new-book-and-four-new-processes
http://www.best-management-practice.com/gempdf/ITIL_UPdate_FAQs_Summer_2011_June11.pdf
Innanzitutto il titolo ufficiale sarà "ITIL 2011" anche se tutti, quasi sicuramente, lo chiameremo ITIL v3.1.
La data di pubblicazione è il 29 luglio 2011, prima in formato cartaceo e poi in formato elettronico.
La novità più grande riguarderà la fase di Strategy. Per le altre fasi, ci saranno "chiarimenti". Il documento non sembra dare indicazioni sui tanti argomenti attualmente confusi.
Ultima cosa interessante è che "chi è già in possesso di certificati ITIL, non avrà la necessità di ri-certificarsi": se capisco bene, le qualifiche ITIL 2007 e ITIL 2011 saranno uguali quindi indistinguibili tra loro.
Il commento di IT Skeptic fornisce ulteriori spunti di riflessione:
http://www.itskeptic.org/itil-v3-2011-new-book-and-four-new-processes
lunedì 20 giugno 2011
NIST SP 800-82 sulla sicurezza dei sistemi informatici industriali
Il NIST ha pubblicato la propria guida per la sicurezza dei sistemi SCADA, DCS e PLC.
Come sempre, la guida inizia con una ottima parte introduttiva che descrive compiutamente i sistemi oggetto del documento e poi via via descrive le minacce, le vulnerabilità e i controlli applicabili.
- La pagina con tutte le SP del NIST: http://csrc.nist.gov/publications/PubsSPs.html
- Il link diretto alla SP 800-82: http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf
Come sempre, la guida inizia con una ottima parte introduttiva che descrive compiutamente i sistemi oggetto del documento e poi via via descrive le minacce, le vulnerabilità e i controlli applicabili.
- La pagina con tutte le SP del NIST: http://csrc.nist.gov/publications/PubsSPs.html
- Il link diretto alla SP 800-82: http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf
sabato 18 giugno 2011
Privacy: dei Titolari e dei Responsabili esterni - Parte 3
NOTA del 2018: questo articolo era di inizio 2016 e contiene errori
evidenti. Ha trovato risposte con la pubblicazione del GDPR.
Seguito del post http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili_04.html
Fabrizio Bottacin mi ha inviato alcuni riferimenti a sentenze del Garante.
Io riassumo (e commento) come segue:
- il 2 giugno 1999 [doc. web n. 39857] il Garante ha stabilito che un fornitore dell'INPS dovesse essere nominato Responsabile esterno (commento di Cesare: non dice però che "ogni fornitore deve essere nominato Responsabile esterno")
- il 29 luglio 1998 [doc. web n. 31023] il Garante stabilisce che una struttura esterna ad un soggetto pubblico può essere nominata Responsabile o detenere la qualità di Titolare (commento di Cesare: si osservi che vigeva la Legge 675/1996)
- il 8 giugno 1999 [doc. web n. 42260] il Garante ha stabilito che le società fornitrici non possono essere nominate "incaricate esterne", ma "Responsabili" (commento Cesare: faccio notare che nulla viene detto sulla possibilità o impossibilità di autonoma titolarità)
Altre sentenze di interesse:
- Garante 7 luglio 1998: doc. web n. 40377
- Garante 24 gennaio 2003: doc. web n. 1067875
- Garante 23 marzo 1998: doc. web n. 40999
- Garante 10 giugno 2003: doc. web n. 1132569
Simone Tomirotti, avendomi segnalato il "Provvedimento banche" (doc. web n. 1813953), segnala la frase: "la posizione di Titolare del trattamento, pur astrattamente riconoscibile anche in capo all'outsourcer, risulta, tuttavia, ascrivibile solo alla banca nei casi in cui la stessa abbia il potere di:
1. assumere decisioni relative alle finalità del trattamento;
2. impartire istruzioni e direttive vincolanti nei confronti delle società di gestione dei sistemi informativi, sostanzialmente corrispondenti alle istruzioni che il titolare del trattamento deve impartire al responsabile;
3. svolgere funzioni di controllo rispetto all'operato delle medesime e degli incaricati delle stesse."
Ho avuto modo di leggere una noticina (quindi da non considerare come definitiva) di AbiLab che traduce così "E' stata confermata la possibilità di qualificare l'outsourcer, sia esso interno od esterno al gruppo bancario, quale autonomo titolare del trattamento qualora i poteri riconosciuti dal Codice della Privacy al titolare del trattamento risultino *in concreto* in capo all'outsourcer e non alla banca."
Ringrazio Fabrizio e Simone per il contributo.
PS: le riflessioni continuano nella "Parte 4":
http://blog.cesaregallotti.it/2011/07/privacy-dei-titolari-e-dei-responsabili.html
Seguito del post http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili_04.html
Fabrizio Bottacin mi ha inviato alcuni riferimenti a sentenze del Garante.
Io riassumo (e commento) come segue:
- il 2 giugno 1999 [doc. web n. 39857] il Garante ha stabilito che un fornitore dell'INPS dovesse essere nominato Responsabile esterno (commento di Cesare: non dice però che "ogni fornitore deve essere nominato Responsabile esterno")
- il 29 luglio 1998 [doc. web n. 31023] il Garante stabilisce che una struttura esterna ad un soggetto pubblico può essere nominata Responsabile o detenere la qualità di Titolare (commento di Cesare: si osservi che vigeva la Legge 675/1996)
- il 8 giugno 1999 [doc. web n. 42260] il Garante ha stabilito che le società fornitrici non possono essere nominate "incaricate esterne", ma "Responsabili" (commento Cesare: faccio notare che nulla viene detto sulla possibilità o impossibilità di autonoma titolarità)
Altre sentenze di interesse:
- Garante 7 luglio 1998: doc. web n. 40377
- Garante 24 gennaio 2003: doc. web n. 1067875
- Garante 23 marzo 1998: doc. web n. 40999
- Garante 10 giugno 2003: doc. web n. 1132569
Simone Tomirotti, avendomi segnalato il "Provvedimento banche" (doc. web n. 1813953), segnala la frase: "la posizione di Titolare del trattamento, pur astrattamente riconoscibile anche in capo all'outsourcer, risulta, tuttavia, ascrivibile solo alla banca nei casi in cui la stessa abbia il potere di:
1. assumere decisioni relative alle finalità del trattamento;
2. impartire istruzioni e direttive vincolanti nei confronti delle società di gestione dei sistemi informativi, sostanzialmente corrispondenti alle istruzioni che il titolare del trattamento deve impartire al responsabile;
3. svolgere funzioni di controllo rispetto all'operato delle medesime e degli incaricati delle stesse."
Ho avuto modo di leggere una noticina (quindi da non considerare come definitiva) di AbiLab che traduce così "E' stata confermata la possibilità di qualificare l'outsourcer, sia esso interno od esterno al gruppo bancario, quale autonomo titolare del trattamento qualora i poteri riconosciuti dal Codice della Privacy al titolare del trattamento risultino *in concreto* in capo all'outsourcer e non alla banca."
Ringrazio Fabrizio e Simone per il contributo.
PS: le riflessioni continuano nella "Parte 4":
http://blog.cesaregallotti.it/2011/07/privacy-dei-titolari-e-dei-responsabili.html
Business Continuity e Incident Management (parte 3)
Sempre sul BCM (il post numero 2 è su http://blog.cesaregallotti.it/2011/05/un-contributo-su-business-continuity-e.html).
Dante Verona mi fa notare quanto segue.
"Ho un modo diverso di argomentare il mio punto di vista, ed è quello che considero più concreto ed efficace ed è in linea con standard BS25999.
Il BS25999-2:2007, al punto 4.1.1.2.c, dice: "The organization shall: establish the maximum tolerable period of disruption for each activity by identifing:....."
E, richiamando la definizione di Maximum Tolerable Period of Disruption presente nello standard stesso, troviamo: "duration after which an organization's viability will be irrevocably threatend if product and service delivery cannot be resumed"
Quindi io escluderei i piccoli incidenti se con piccoli intendiamo quelli che non minacciano la sopravvivenza della organizzazione. E il motivo di ciò per me è molto concreto. Confinare gli scenari BCM è una questione di successo del programma stesso."
Io credo che Dante parli della "parte di BCM per grandi eventi". Per i piccoli incidenti c'è invece il "BCM per piccoli eventi" (dove la gestione degli incidenti è regolamentata da SLA basati anche sul termine di urgenza, proprio per evitare che un "normale incidente" diventi grande). Fanno parte tutti e due del BCM, ma sono affrontati con metodi e tecniche distinte. In fase di analisi si individuano cosa fa parte dell'una e dell'altra e poi vengono affrontati distintamente per garantire il successo del programma (applicando la corretta filosofia del problem solving che prevede di dividere un problema in sotto-problemi più facilmente risolvibili).
Dante Verona mi fa notare quanto segue.
"Ho un modo diverso di argomentare il mio punto di vista, ed è quello che considero più concreto ed efficace ed è in linea con standard BS25999.
Il BS25999-2:2007, al punto 4.1.1.2.c, dice: "The organization shall: establish the maximum tolerable period of disruption for each activity by identifing:....."
E, richiamando la definizione di Maximum Tolerable Period of Disruption presente nello standard stesso, troviamo: "duration after which an organization's viability will be irrevocably threatend if product and service delivery cannot be resumed"
Quindi io escluderei i piccoli incidenti se con piccoli intendiamo quelli che non minacciano la sopravvivenza della organizzazione. E il motivo di ciò per me è molto concreto. Confinare gli scenari BCM è una questione di successo del programma stesso."
Io credo che Dante parli della "parte di BCM per grandi eventi". Per i piccoli incidenti c'è invece il "BCM per piccoli eventi" (dove la gestione degli incidenti è regolamentata da SLA basati anche sul termine di urgenza, proprio per evitare che un "normale incidente" diventi grande). Fanno parte tutti e due del BCM, ma sono affrontati con metodi e tecniche distinte. In fase di analisi si individuano cosa fa parte dell'una e dell'altra e poi vengono affrontati distintamente per garantire il successo del programma (applicando la corretta filosofia del problem solving che prevede di dividere un problema in sotto-problemi più facilmente risolvibili).
venerdì 17 giugno 2011
Privacy: prescrizioni per le banche
Simone Tomirotti mi ha segnalato la pubblicazione delle "Prescrizioni in materia di circolazione delle informazioni in ambito bancario e di tracciamento delle operazioni bancarie - 12 maggio 2011".
http://www.garanteprivacy.it/garante/doc.jsp?ID=1813953
Su questo documento ci sarebbero dei commenti da fare su un discorso che mi sta cuore su "Titolari e Responsabili esterni". Purtroppo neanche questo mese ho avuto la possibilità di studiare come si conviene (grazie al cielo ho dei lavori da fare e nei fine settimana ho fatto il Presidente del Seggio 300 a Milano). Ci riproverò per luglio.
Aggiungo che Simone ha anticipato di poche ore Andrea Praitano che gentilmente mi ha segnalato anche lui questa notizia.
http://www.garanteprivacy.it/garante/doc.jsp?ID=1813953
Su questo documento ci sarebbero dei commenti da fare su un discorso che mi sta cuore su "Titolari e Responsabili esterni". Purtroppo neanche questo mese ho avuto la possibilità di studiare come si conviene (grazie al cielo ho dei lavori da fare e nei fine settimana ho fatto il Presidente del Seggio 300 a Milano). Ci riproverò per luglio.
Aggiungo che Simone ha anticipato di poche ore Andrea Praitano che gentilmente mi ha segnalato anche lui questa notizia.
martedì 14 giugno 2011
Confindustria Digitale
Segnalo questo articolo di Computerworld Italia sulla nuova confederazione
di aziende ICT e ringrazio Aldo Ceccarelli che l'ha pubblicato su LinkedIn:
-
http://www.cwi.it/2011/06/13/confindustria-digitale-un-passo-avanti-ma-il-ri
schio-di-cadere-in-vecchi-errori/
di aziende ICT e ringrazio Aldo Ceccarelli che l'ha pubblicato su LinkedIn:
-
http://www.cwi.it/2011/06/13/confindustria-digitale-un-passo-avanti-ma-il-ri
schio-di-cadere-in-vecchi-errori/
lunedì 13 giugno 2011
Novità sugli standard serie ISO/IEC 27k
Il 15 aprile si è tenuto a Singapore il meeting dell'SC 27 WG 1.
Questi i risultati (per come li ho capiti):
- ISO/IEC 27000 (Vocabolario): sarà prodotto il 3WD (Terzo Working Draft; siamo indietro...)
- ISO/IEC 27001: è in circolazione il 1 CD (Committee Draft, più avanzato del WD);
- ISO/IEC 27002: sarà prodotto il 4 WD (la 27001 avrà ancora l'Annex A, anche se alcuni, tra cui io, volevano lasciare libertà di scelta per il SOA; verranno tolte alcune cose in materia di risk assessment e politiche già presenti sulla 27001)
- ISO/IEC 27005: è stata pubblicata la versione del 2011 che sostitusce quella del 2008 solo per allineare la terminologia alla ISO 31000:2009 (per il resto è rimasta invariata)
- ISO/IEC 27006 (la norma per gli organismi di certificazione):
- ISO/IEC 27007 (linee guida per gli audit): è uscito il Final Draft
- ISO/IEC 27008 (verifica dei controlli di sicurezza): la danno per conclusa
- ISO/IEC 27013 (relazioni tra 27001 e 20000-1): è in circolazione il 1 CD
Non ho ancora letto i draft in circolazione.
Dalla presentazione fatta da Fabio Guasconi per l'Uninfo, segnalo quanto segue:
- Numerosissimi commenti su 27001 e 27002
- si vuole pubblicare la nuova 27006 entro metà 2012
- la 27015 (sui Financial Services) è ferma in attesa di nuovi input
E' stata fatta una proposta per una norma specifica sul Cloud Computing. Voterò contro perché dovrebbe già essere coperta dalle norme sull'outsourcing (se i "servizi cloud" sono offerti dagli esterni) e dalle altre norme più tecniche (se i servizi cloud sono erogati internamente). Uninfo probabilmente voterà a favore.
L'aggiornamento della 27006 è dovuto soprattutto all'allineamento con la ISO/IEC 17021:2011 e quindi gli editor vorrebbero non avere altri argomenti da discutere.
Rimane quindi il grosso problema dei tempi di audit proposti dall'Annex C (Informative) della 27006: attualmente sono esagerati (soprattutto per le PMI). L'allegato è solo informativo e questa è un'altra ragione per cui gli editor non vorrebbero discuterlo; purtroppo Accredia lo considera acriticamente come "normativo" e quindi siamo costretti ad avere audit troppo onerosi per le aziende e anche per gli auditor (che non sanno come giustificare il proprio tempo; per lo meno i molti che conoscono la materia... i tempi sono probabilmente tarati per i pochi che non la conoscono; più ignoranti ma più capaci a far pubblicare le cose).
PS: ringrazio Fabio Guasconi per aver corretto qualche errore di questo post. Quelli rimasti sono colpa mia.
Questi i risultati (per come li ho capiti):
- ISO/IEC 27000 (Vocabolario): sarà prodotto il 3WD (Terzo Working Draft; siamo indietro...)
- ISO/IEC 27001: è in circolazione il 1 CD (Committee Draft, più avanzato del WD);
- ISO/IEC 27002: sarà prodotto il 4 WD (la 27001 avrà ancora l'Annex A, anche se alcuni, tra cui io, volevano lasciare libertà di scelta per il SOA; verranno tolte alcune cose in materia di risk assessment e politiche già presenti sulla 27001)
- ISO/IEC 27005: è stata pubblicata la versione del 2011 che sostitusce quella del 2008 solo per allineare la terminologia alla ISO 31000:2009 (per il resto è rimasta invariata)
- ISO/IEC 27006 (la norma per gli organismi di certificazione):
- ISO/IEC 27007 (linee guida per gli audit): è uscito il Final Draft
- ISO/IEC 27008 (verifica dei controlli di sicurezza): la danno per conclusa
- ISO/IEC 27013 (relazioni tra 27001 e 20000-1): è in circolazione il 1 CD
Non ho ancora letto i draft in circolazione.
Dalla presentazione fatta da Fabio Guasconi per l'Uninfo, segnalo quanto segue:
- Numerosissimi commenti su 27001 e 27002
- si vuole pubblicare la nuova 27006 entro metà 2012
- la 27015 (sui Financial Services) è ferma in attesa di nuovi input
E' stata fatta una proposta per una norma specifica sul Cloud Computing. Voterò contro perché dovrebbe già essere coperta dalle norme sull'outsourcing (se i "servizi cloud" sono offerti dagli esterni) e dalle altre norme più tecniche (se i servizi cloud sono erogati internamente). Uninfo probabilmente voterà a favore.
L'aggiornamento della 27006 è dovuto soprattutto all'allineamento con la ISO/IEC 17021:2011 e quindi gli editor vorrebbero non avere altri argomenti da discutere.
Rimane quindi il grosso problema dei tempi di audit proposti dall'Annex C (Informative) della 27006: attualmente sono esagerati (soprattutto per le PMI). L'allegato è solo informativo e questa è un'altra ragione per cui gli editor non vorrebbero discuterlo; purtroppo Accredia lo considera acriticamente come "normativo" e quindi siamo costretti ad avere audit troppo onerosi per le aziende e anche per gli auditor (che non sanno come giustificare il proprio tempo; per lo meno i molti che conoscono la materia... i tempi sono probabilmente tarati per i pochi che non la conoscono; più ignoranti ma più capaci a far pubblicare le cose).
PS: ringrazio Fabio Guasconi per aver corretto qualche errore di questo post. Quelli rimasti sono colpa mia.
sabato 11 giugno 2011
La natura frattale del ciclo PDCA
Da un Twitter della società di consulenza Lambda CT, segnalo questo articolo in inglese: http://is.gd/iTcILz.
La materia non è nuova, ovviamente. Preferisco alcuni sul Kaizen (tra cui quelli editi da Guerini), ma forse questo articolo può essere d'aiuto ai tanti che non osservano con la dovuta attenzione gli argomenti relativi alla "vecchia" qualità.
Mi viene in mente la frase di un mio cliente che mi disse (con ironia e segnalando la criticità): "nella nostra azienda rilasciamo applicazioni e processi e procedure e moduli solo in versione 1".
Post scriptum: il Twitter successivo di Lambda CT (http://is.gd/W7ogQ4) rimanda a un pdf sulle correlazioni tra sicurezza e ISO/IEC 25504, che è un modello decisamente (troppo) oneroso. Ogni volta mi stupisco di come certe cose così complesse e teoriche abbiano tanto successo: direi che probabilmente si tratta di vittorie delle grandi società di consulenza.
La materia non è nuova, ovviamente. Preferisco alcuni sul Kaizen (tra cui quelli editi da Guerini), ma forse questo articolo può essere d'aiuto ai tanti che non osservano con la dovuta attenzione gli argomenti relativi alla "vecchia" qualità.
Mi viene in mente la frase di un mio cliente che mi disse (con ironia e segnalando la criticità): "nella nostra azienda rilasciamo applicazioni e processi e procedure e moduli solo in versione 1".
Post scriptum: il Twitter successivo di Lambda CT (http://is.gd/W7ogQ4) rimanda a un pdf sulle correlazioni tra sicurezza e ISO/IEC 25504, che è un modello decisamente (troppo) oneroso. Ogni volta mi stupisco di come certe cose così complesse e teoriche abbiano tanto successo: direi che probabilmente si tratta di vittorie delle grandi società di consulenza.
venerdì 10 giugno 2011
Metriche FISMA
Lo statunitense Federal Information Security Management Act (FISMA) richiede alle agenzie governative di rispondere periodicamente a dei questionari sulla sicurezza informatica definiti dal Homeland Security Department.
Per il 2011 è in circolazione un questionario di 11 pagine (pare che però non sia ancora ufficiale) che sta riscontrando il favore degli analisti perché cerca di spingere le agenzie verso il "monitoraggio continuo" (senza però specificare cosa si intenda per "continuo").
Lascio ai lettori più pazienti la possibilità di valutare il questionario e di eventualmente considerare alcune delle metriche proposte come applicabili alla propria organizzazione.
Un articolo piuttosto completo: http://www.govinfosecurity.com/articles.php?art_id=3707
Un articolo più critico: http://www.nextgov.com/nextgov/ng_20110606_5245.php?oref=topstory
Il questionario: http://www.sans.org/critical-security-controls/fisma.pdf
Per il 2011 è in circolazione un questionario di 11 pagine (pare che però non sia ancora ufficiale) che sta riscontrando il favore degli analisti perché cerca di spingere le agenzie verso il "monitoraggio continuo" (senza però specificare cosa si intenda per "continuo").
Lascio ai lettori più pazienti la possibilità di valutare il questionario e di eventualmente considerare alcune delle metriche proposte come applicabili alla propria organizzazione.
Un articolo piuttosto completo: http://www.govinfosecurity.com/articles.php?art_id=3707
Un articolo più critico: http://www.nextgov.com/nextgov/ng_20110606_5245.php?oref=topstory
Il questionario: http://www.sans.org/critical-security-controls/fisma.pdf
Infrastrutture critiche e Dlgs 61/2011
Simone Tomirotti mi informa della pubblicazione del Dlgs 61/2011 dal titolo
"Attuazione della Direttiva 2008/114/CE recante l'individuazione e la
designazione delle infrastrutture critiche europee e la valutazione della
necessita' di migliorarne la protezione".
E' possibile leggere il Dlgs da www.normattiva.it.
E' possibile leggere la Direttiva da http://eur-lex.europa.eu/it/index.htm
Il Dlgs è interessante, anche se riguarda solo il settore energia e il
settore trasporti. In particolare perché tratta compiutamente la sicurezza
delle informazioni, stabilisce che il "funzionario di collegamento in
materia di sicurezza" è anche il responsabile della sicurezza delle
informazioni e, infine, nell'allegato B, illustra i "Requisiti minimi del
piano di sicurezza dell'operatore (PSO)" in modo più convincente di quanto
prescritto dal Codice Privacy.
Simone Tomirotti aggiunge: la Regione Lombardia sembra intenzionata ad affrontare l'argomento Infrastrutture Critiche. E questo è già qualcosa. A giugno del 2010 c'era stato un incontro con alcuni gestori di Infrastrutture Critiche. Poiché in questa prima direttiva la tematica interessa Trasporti ed Energia, all'incontro hanno partecipato società tipo AEM o A2A. A novembre 2011 ci sarà un incontro dal titolo inglese e un po' ambizioso: 1st International Workshop on Regional Critical Infrastructure Protection.
Il sito della protezione civile Regione Lombardia: http://bit.ly/iiDo8T
"Attuazione della Direttiva 2008/114/CE recante l'individuazione e la
designazione delle infrastrutture critiche europee e la valutazione della
necessita' di migliorarne la protezione".
E' possibile leggere il Dlgs da www.normattiva.it.
E' possibile leggere la Direttiva da http://eur-lex.europa.eu/it/index.htm
Il Dlgs è interessante, anche se riguarda solo il settore energia e il
settore trasporti. In particolare perché tratta compiutamente la sicurezza
delle informazioni, stabilisce che il "funzionario di collegamento in
materia di sicurezza" è anche il responsabile della sicurezza delle
informazioni e, infine, nell'allegato B, illustra i "Requisiti minimi del
piano di sicurezza dell'operatore (PSO)" in modo più convincente di quanto
prescritto dal Codice Privacy.
Simone Tomirotti aggiunge: la Regione Lombardia sembra intenzionata ad affrontare l'argomento Infrastrutture Critiche. E questo è già qualcosa. A giugno del 2010 c'era stato un incontro con alcuni gestori di Infrastrutture Critiche. Poiché in questa prima direttiva la tematica interessa Trasporti ed Energia, all'incontro hanno partecipato società tipo AEM o A2A. A novembre 2011 ci sarà un incontro dal titolo inglese e un po' ambizioso: 1st International Workshop on Regional Critical Infrastructure Protection.
Il sito della protezione civile Regione Lombardia: http://bit.ly/iiDo8T
lunedì 6 giugno 2011
Sul downtime di Aruba
Uno dei casi più discussi di recente è il downtime di Aruba, perché tocca gli argomenti "infrastrutture", "continuità operativa" e "contrattualistica".
Segnalo qualche articolo interessante (dalla newsletter del Clusit):
- il commento di Claudio Telmon: http://blog.clusit.it/sicuramente/2011/05/considerazioni-sulla-vicenda-di-aruba.html
- il commento di Armando Leotta: http://blog.clusit.it/sicuramente/2011/04/aruba-downtime-osservazioni.html
- il commento di Andrea Draghetti: http://www.oversecurity.net/2011/04/30/incendio-nella-server-farm-di-aruba-comunicato-stampa/
Segnalo qualche articolo interessante (dalla newsletter del Clusit):
- il commento di Claudio Telmon: http://blog.clusit.it/sicuramente/2011/05/considerazioni-sulla-vicenda-di-aruba.html
- il commento di Armando Leotta: http://blog.clusit.it/sicuramente/2011/04/aruba-downtime-osservazioni.html
- il commento di Andrea Draghetti: http://www.oversecurity.net/2011/04/30/incendio-nella-server-farm-di-aruba-comunicato-stampa/
Report ENISA su resilienza e metriche
A febbraio, ENISA ha pubblicato il documento "Measurement Frameworks and Metrics for Resilient Networks and Services: Technical report" (ho visto la segnalazione sul blog del Clusit).
L'ho trovato interessante per diversi motivi, tra i quali: la presentazione di una selezione di metriche, accompagnate dai loro valori "tipici".
La parte introduttiva è un po' troppo scolastica.
Il link:
http://www.enisa.europa.eu/act/res/other-areas/metrics/reports/metrics-tech-report/at_download/fullReport
L'ho trovato interessante per diversi motivi, tra i quali: la presentazione di una selezione di metriche, accompagnate dai loro valori "tipici".
La parte introduttiva è un po' troppo scolastica.
Il link:
http://www.enisa.europa.eu/act/res/other-areas/metrics/reports/metrics-tech-report/at_download/fullReport
martedì 31 maggio 2011
Internet e politica
A inizio maggio avevo segnalato una presentazione di Atle Skjekkeland sulle nuove modalità di comunicazione:
http://blog.cesaregallotti.it/2011/05/omat-e-gestione-elettronica-di.html
Le campagne elettorali sono molto interessanti perché dimostrano
pubblicamente come alcuni mezzi sono utilizzati. Questo articolo, seppur dal
titolo "di parte" e dal tono ironico, mi sembra equilibrato nell'illustrare
come Pisapia abbia utilizzato Internet efficacemente, al contrario della
Moratti. E ci dà anche altre indicazioni sull'attenzione da porre nell'uso
di questi mezzi:
http://www.02blog.it/post/8170/the-social-letizia-moratti-una-serie-di-sciag
ure-riassunta-con-cura
http://blog.cesaregallotti.it/2011/05/omat-e-gestione-elettronica-di.html
Le campagne elettorali sono molto interessanti perché dimostrano
pubblicamente come alcuni mezzi sono utilizzati. Questo articolo, seppur dal
titolo "di parte" e dal tono ironico, mi sembra equilibrato nell'illustrare
come Pisapia abbia utilizzato Internet efficacemente, al contrario della
Moratti. E ci dà anche altre indicazioni sull'attenzione da porre nell'uso
di questi mezzi:
http://www.02blog.it/post/8170/the-social-letizia-moratti-una-serie-di-sciag
ure-riassunta-con-cura
venerdì 27 maggio 2011
I primi dieci anni di applicazione del Decreto 231
Segnalo questo interessante articolo sul Dlgs 231 del 2011:
http://www.filodiritto.com/index.php?azione=visualizza&iddoc=2320
http://www.filodiritto.com/index.php?azione=visualizza&iddoc=2320
Privacy: pazienti della sanità, telefonia
Daniela Quetti (DFA) ha segnalato diverse novità in materia alla privacy.
1- il Garante ha pubblicato il vademecum intitolato "Dalla parte del paziente. Privacy: le domande più frequenti".
http://www.garanteprivacy.it/garante/doc.jsp?ID=1812194
2- sono stati prorogati i termini per la realizzazione delle misure previste per gli operatori telefonici e riportate nel provvedimento del 24 febbraio 2011, "Modelli di informativa e di richiesta di consenso al trattamento dei dati personali relativi agli abbonati ai servizi di telefonia fissa e mobile"
http://www.garanteprivacy.it/garante/doc.jsp?ID=1811916
3- il Garante ha pubblicato le "Linee guida in tema di trattamento di dati per lo svolgimento di indagini di customer satisfaction in ambito sanitario", utili anche per chi conduce medesime indagini in altri ambiti.
http://www.garanteprivacy.it/garante/doc.jsp?ID=1812910
1- il Garante ha pubblicato il vademecum intitolato "Dalla parte del paziente. Privacy: le domande più frequenti".
http://www.garanteprivacy.it/garante/doc.jsp?ID=1812194
2- sono stati prorogati i termini per la realizzazione delle misure previste per gli operatori telefonici e riportate nel provvedimento del 24 febbraio 2011, "Modelli di informativa e di richiesta di consenso al trattamento dei dati personali relativi agli abbonati ai servizi di telefonia fissa e mobile"
http://www.garanteprivacy.it/garante/doc.jsp?ID=1811916
3- il Garante ha pubblicato le "Linee guida in tema di trattamento di dati per lo svolgimento di indagini di customer satisfaction in ambito sanitario", utili anche per chi conduce medesime indagini in altri ambiti.
http://www.garanteprivacy.it/garante/doc.jsp?ID=1812910
Un contributo su Business Continuity e Incident Management
Maurizio Nastro mi ha inviato un contributo su Business Continuity e Incident Management (http://blog.cesaregallotti.it/2011/04/business-continuity-e-incident.html). Copio integralmente e segnalo in particolare la seconda parte con l'esempio della barca.
Riguardo la differenza tra Business Continuity (BC) e Disaster Recovery (DR), sulla base della mia esperienza, credo che si possa riassumere concettualemente in questi termini.
Il criterio caratterizzante è rappresentato dalla sopravvivenza di un'azienda.
I piani di BC si preoccupano di mantenere, a seguito di un incidente di Business Disruption, la continuità dei servizi critici di Business almeno ad un livello predefinito considerato accettabile.
[Un incidente di Business Disruption è un evento che può intaccare le attività a supporto di servizi critici minando potenzialmente la sopravvivenza aziendale. Ogni organizzazione deve definire la propria classificazione di incidenti; il confine tra ciò che rappresenta un incidente ordinario e uno di Business Disruption è labile, e fortemente dipendente sia dall'organizzazione che dalla realtà in cui opera. A tal riguardo, prendiamo come esempio una organizzazione che opera nel settore dei trasporti, ed un'altra nel campo ICT con la maggior parte dei dipendenti che lavora da remoto via internet. E' evidente che un incidente (in questo caso legato ad un evento naturale) rappresentato da improvviso forte maltempo, che determina il formarsi di ghiaccio con conseguente inagibilità delle strade, assumerà contorni e valenza diversi per le due realtà aziendali.]
La BC è trasversale a tutte le tipologie di settori, potendosi applicare sia alle aziende erogatrici di servizi IT h24, sia, ad esempio, alle aziende manufatturiere che utilizzano laminatoi od altoforni, per le quali l'IT non rappresenta il core business.
I piani di Disaster Recovery si preoccupano di di mantenere, a seguito di un incidente (non necessariamente di Business Disruption), la continuità dei servizi erogati tramite l'infrastruttura IT almeno ad un livello predefinito considerato accettabile.
Qualora tali servizi (erogati tramite l'infrastruttura IT) siano anche servizi critici di Business, i piani di DR faranno parte dei piani di BC. Qualora, questo non avvenga, i piani di DR saranno fuori dai piani di BC. A tal riguardo, c'è però da dire che se l'infrastruttura IT non è a supporto di servizi critici, è presumibile che non vi sia neanche l'adozione di una soluzione di DR.
In altre parole, la BC si colloca ad un livello superiore rispetto al Disaster Recovery, che può essere visto come la parte tecnologica della Business Continuity, laddove l'infrastruttura IT copra un ruolo determinante per la sopravvivenza dell'azienda (in quanto a supporto di servizi critici).
Riguardo invece i piani di BC e i piani di Incident Management (IM) credo che un'analogia possa essere utile.
Se si pensa ad una piccola imbarcazione che improvvisamente presenti una falla che causi infiltrazioni d'acqua, il piano di IM, attuato dall'equipaggio, provvederà alle operazioni necessarie per tamponare la falla; il piano di BC è invece attuato dal personale adibito a scaricare fuoribordo l'acqua che entra durante le operazioni di tamponamento, per evitare che l'imbarcazione affondi.
Il piano di BC non è quindi finalizzato alla risoluzione del problema che ha causato l'incidente, ma a garantire la sopravvivenza dell'organizzazione per il tempo necessario a risolverlo.
Da quanto esposto si comprende come i piani di gestione incidenti e di BC siano diversi, ma, nel contempo, strettamente correlati. I responsabili dei due piani (che in realtà aziendali di piccole dimensioni possono anche essere in carico ad un'unica persona) devono mantenersi in stretto contatto al verificarsi di un incidente di Business Disruption. Se ci si accorge che il tempo trascorso nel tentativo di gestire a buon fine l'incidente, sommato a quello necessario per il ripristino dei servizi critici, rischia di diventare maggiore del massimo tempo tollerabile dall'azienda per la sua sopravvivenza, occorre procedere con l'attivazione dei piani di BC [attivarli subito, contestualemente ai piani di IM, non è detto che sia la soluzione migliore; questo perchè l'incidente potrebbe venire risolto per tempo, con conseguente vanificazione dei piani di BC (e costi conseguenti)].
PS: la puntata successiva è sul post http://blog.cesaregallotti.it/2011/06/business-continuity-e-incident.html
Riguardo la differenza tra Business Continuity (BC) e Disaster Recovery (DR), sulla base della mia esperienza, credo che si possa riassumere concettualemente in questi termini.
Il criterio caratterizzante è rappresentato dalla sopravvivenza di un'azienda.
I piani di BC si preoccupano di mantenere, a seguito di un incidente di Business Disruption, la continuità dei servizi critici di Business almeno ad un livello predefinito considerato accettabile.
[Un incidente di Business Disruption è un evento che può intaccare le attività a supporto di servizi critici minando potenzialmente la sopravvivenza aziendale. Ogni organizzazione deve definire la propria classificazione di incidenti; il confine tra ciò che rappresenta un incidente ordinario e uno di Business Disruption è labile, e fortemente dipendente sia dall'organizzazione che dalla realtà in cui opera. A tal riguardo, prendiamo come esempio una organizzazione che opera nel settore dei trasporti, ed un'altra nel campo ICT con la maggior parte dei dipendenti che lavora da remoto via internet. E' evidente che un incidente (in questo caso legato ad un evento naturale) rappresentato da improvviso forte maltempo, che determina il formarsi di ghiaccio con conseguente inagibilità delle strade, assumerà contorni e valenza diversi per le due realtà aziendali.]
La BC è trasversale a tutte le tipologie di settori, potendosi applicare sia alle aziende erogatrici di servizi IT h24, sia, ad esempio, alle aziende manufatturiere che utilizzano laminatoi od altoforni, per le quali l'IT non rappresenta il core business.
I piani di Disaster Recovery si preoccupano di di mantenere, a seguito di un incidente (non necessariamente di Business Disruption), la continuità dei servizi erogati tramite l'infrastruttura IT almeno ad un livello predefinito considerato accettabile.
Qualora tali servizi (erogati tramite l'infrastruttura IT) siano anche servizi critici di Business, i piani di DR faranno parte dei piani di BC. Qualora, questo non avvenga, i piani di DR saranno fuori dai piani di BC. A tal riguardo, c'è però da dire che se l'infrastruttura IT non è a supporto di servizi critici, è presumibile che non vi sia neanche l'adozione di una soluzione di DR.
In altre parole, la BC si colloca ad un livello superiore rispetto al Disaster Recovery, che può essere visto come la parte tecnologica della Business Continuity, laddove l'infrastruttura IT copra un ruolo determinante per la sopravvivenza dell'azienda (in quanto a supporto di servizi critici).
Riguardo invece i piani di BC e i piani di Incident Management (IM) credo che un'analogia possa essere utile.
Se si pensa ad una piccola imbarcazione che improvvisamente presenti una falla che causi infiltrazioni d'acqua, il piano di IM, attuato dall'equipaggio, provvederà alle operazioni necessarie per tamponare la falla; il piano di BC è invece attuato dal personale adibito a scaricare fuoribordo l'acqua che entra durante le operazioni di tamponamento, per evitare che l'imbarcazione affondi.
Il piano di BC non è quindi finalizzato alla risoluzione del problema che ha causato l'incidente, ma a garantire la sopravvivenza dell'organizzazione per il tempo necessario a risolverlo.
Da quanto esposto si comprende come i piani di gestione incidenti e di BC siano diversi, ma, nel contempo, strettamente correlati. I responsabili dei due piani (che in realtà aziendali di piccole dimensioni possono anche essere in carico ad un'unica persona) devono mantenersi in stretto contatto al verificarsi di un incidente di Business Disruption. Se ci si accorge che il tempo trascorso nel tentativo di gestire a buon fine l'incidente, sommato a quello necessario per il ripristino dei servizi critici, rischia di diventare maggiore del massimo tempo tollerabile dall'azienda per la sua sopravvivenza, occorre procedere con l'attivazione dei piani di BC [attivarli subito, contestualemente ai piani di IM, non è detto che sia la soluzione migliore; questo perchè l'incidente potrebbe venire risolto per tempo, con conseguente vanificazione dei piani di BC (e costi conseguenti)].
PS: la puntata successiva è sul post http://blog.cesaregallotti.it/2011/06/business-continuity-e-incident.html
APMG Ente di Accreditamento per la ISO/IEC 20000-1
Tony Coletta mi ha segnalato come APMG sia ora il gestore delle certificazioni aziendali ISO/IEC 20000-1 su incarico di itSMF.
Maggiori informazioni su:
http://www.apmg-international.com/faq2.asp?category=ISO/IEC%2020000%20FAQs
Sarà interessante capire come saranno gestite le relazioni tra certificati aziendali accreditati APMG e quelli accreditati da altri organismi di certificazione quali Accredia (ex Sincert).
PS: la seconda puntata è al
http://blog.cesaregallotti.it/2011/08/apmg-ente-di-accreditamento-per-la.html
Maggiori informazioni su:
http://www.apmg-international.com/faq2.asp?category=ISO/IEC%2020000%20FAQs
Sarà interessante capire come saranno gestite le relazioni tra certificati aziendali accreditati APMG e quelli accreditati da altri organismi di certificazione quali Accredia (ex Sincert).
PS: la seconda puntata è al
http://blog.cesaregallotti.it/2011/08/apmg-ente-di-accreditamento-per-la.html
Privacy e Decreto Sviluppo
A seguito del post "Privacy: ulteriori semplificazioni" (http://blog.cesaregallotti.it/2011/05/privacy-ulteriori-semplificazioni.html), segnalo una piccola analisi che ho effettuato in materia.
1- i dati dei clienti e fornitori non sono più oggetto della privacy se trattati unicamente per la gestione del rapporto di lavoro. In particolare, non è più necessario mandare loro l'informativa.
2- Attenzione però: questa esclusione sarà annullata laddove quei dati siano oggetto di trattamento per finalità commerciali, pubblicitarie e promozionali.
3- Altra esclusione: la richiesta di consenso preventivo per quanto riguarda dati contenuti nei curricula
4- Il Registro delle opposizioni vale anche per la posta cartacea (in altre parole, prima di fare mailing pubblicitario, bisogna fare uso del Registro delle Opposizioni, di cui ho già scritto in http://blog.cesaregallotti.it/2011/02/dpr-1782010-privacy-e-diritto-di.html)
5- la comunicazione di dati tra societa', enti o associazioni con societa' controllanti, controllate o collegate, nonchè tra consorzi, reti di imprese e raggruppamenti e associazioni temporanei di imprese con i soggetti ad essi aderenti, per le finalita' amministrativo contabili, non è più necessario il consenso. Però il fatto deve essere messo nell'informativa.
1- i dati dei clienti e fornitori non sono più oggetto della privacy se trattati unicamente per la gestione del rapporto di lavoro. In particolare, non è più necessario mandare loro l'informativa.
2- Attenzione però: questa esclusione sarà annullata laddove quei dati siano oggetto di trattamento per finalità commerciali, pubblicitarie e promozionali.
3- Altra esclusione: la richiesta di consenso preventivo per quanto riguarda dati contenuti nei curricula
4- Il Registro delle opposizioni vale anche per la posta cartacea (in altre parole, prima di fare mailing pubblicitario, bisogna fare uso del Registro delle Opposizioni, di cui ho già scritto in http://blog.cesaregallotti.it/2011/02/dpr-1782010-privacy-e-diritto-di.html)
5- la comunicazione di dati tra societa', enti o associazioni con societa' controllanti, controllate o collegate, nonchè tra consorzi, reti di imprese e raggruppamenti e associazioni temporanei di imprese con i soggetti ad essi aderenti, per le finalita' amministrativo contabili, non è più necessario il consenso. Però il fatto deve essere messo nell'informativa.
giovedì 19 maggio 2011
Privacy: ulteriori semplificazioni
Daniela Quetti (della DFA) segnala: la lettura del DECRETO-LEGGE 70 del 13 maggio 2011, in particolare dell'art. 6 comma 2 lettera a) che modifica il Codice Privacy (decreto legislativo 30 giugno 2003, n. 196). Il titolo dell'articolo è "Ulteriori riduzione e semplificazioni degli adempimenti burocratici"
Daniela ci ricorda che siamo ancora in fase di Decreto Legge (pertanto non ancora convertito in Legge), ma di fatto cogente.
Link al testo:
http://www.normattiva.it//dispatcher?task=attoCompleto&service=212&datagu=2011-05-13&redaz=011G0113&parControllo=si&connote=false&aggiorn=si&datavalidita=20110517#
Daniela ci ricorda che siamo ancora in fase di Decreto Legge (pertanto non ancora convertito in Legge), ma di fatto cogente.
Link al testo:
http://www.normattiva.it//dispatcher?task=attoCompleto&service=212&datagu=2011-05-13&redaz=011G0113&parControllo=si&connote=false&aggiorn=si&datavalidita=20110517#
lunedì 9 maggio 2011
Rapporto Melani (Svizzera)
Segnalo l'interessante dodicesimo rapporto semestrale MELANI (Centrale d'annuncio e d'analisi per la sicurezza dell'informazione)della Confederazione Svizzera.
La Svizzera non è l'Italia, ma almeno si tratta di uno studio più vicino a noi rispetto a quelli tipicamente USA.
http://www.melani.admin.ch/dienstleistungen/archiv/01123/index.html?lang=it
(Notizia ricavata dalla newsletter del Clusit).
Inoltre, sempre dalla Svizzera, segnalo il simpatico sito di divulgazione sulla sicurezza informatica Storie di Internet:
http://www.storiediinternet.ch/
La Svizzera non è l'Italia, ma almeno si tratta di uno studio più vicino a noi rispetto a quelli tipicamente USA.
http://www.melani.admin.ch/dienstleistungen/archiv/01123/index.html?lang=it
(Notizia ricavata dalla newsletter del Clusit).
Inoltre, sempre dalla Svizzera, segnalo il simpatico sito di divulgazione sulla sicurezza informatica Storie di Internet:
http://www.storiediinternet.ch/
martedì 3 maggio 2011
Cloud computing e incidenti
Ecco qui un'ulteriore notizia di un incidente sui servizi cloud di Amazon:
http://www.informationweek.com/news/cloud-computing/infrastructure/229402385
In breve: sono stati distrutti diversi dati di clienti.
Commento: il servizio cloud non si discosta troppo da altri servizi erogati da fornitori. Se il contratto con Amazon non prevedeva il backup dei dati, era opportuno pensarci lo stesso.
Notizia segnalata da SANS NewsBites Vol. 13 Num. 34.
http://www.informationweek.com/news/cloud-computing/infrastructure/229402385
In breve: sono stati distrutti diversi dati di clienti.
Commento: il servizio cloud non si discosta troppo da altri servizi erogati da fornitori. Se il contratto con Amazon non prevedeva il backup dei dati, era opportuno pensarci lo stesso.
Notizia segnalata da SANS NewsBites Vol. 13 Num. 34.
OMAT e gestione elettronica di documenti
Il 5 e 6 aprile 2011 si è tenuto a Milano il convegno OMAT (www.omat360.it).
Segnalo che le presentazioni del convegno sono disponibili su
http://milano2011.omat360.it/documentazione/omat.php (forse, per accedervi,
bisogna essere iscritti al convegno).
Io ho trovato interessante soprattutto la presentazione di Atle Skjekkeland
(in inglese) su come oggi sono gestite le informazioni aziendali e lo
saranno. E' stato interessante capire come le diverse generazioni
percepiscono "i dati" e le informazioni: i nuovi lavoratori comunicano via
social network, i loro predecessori via email e così via. Diverse percezioni
e diverse modalità con cui gestire le informazioni a cui forse non siamo
pienamente preparati.
La presentazione, in cui è possibile trovare ulteriori spunti di
riflessione, è disponibile anche su
https://aiimtaskforce.box.net/shared/zdfvxlvpa0.
Segnalo che le presentazioni del convegno sono disponibili su
http://milano2011.omat360.it/documentazione/omat.php (forse, per accedervi,
bisogna essere iscritti al convegno).
Io ho trovato interessante soprattutto la presentazione di Atle Skjekkeland
(in inglese) su come oggi sono gestite le informazioni aziendali e lo
saranno. E' stato interessante capire come le diverse generazioni
percepiscono "i dati" e le informazioni: i nuovi lavoratori comunicano via
social network, i loro predecessori via email e così via. Diverse percezioni
e diverse modalità con cui gestire le informazioni a cui forse non siamo
pienamente preparati.
La presentazione, in cui è possibile trovare ulteriori spunti di
riflessione, è disponibile anche su
https://aiimtaskforce.box.net/shared/zdfvxlvpa0.
lunedì 2 maggio 2011
Privacy Enhancing Technologies
Il 7 aprile, alla Statale di Milano, si è tenuta la lezione aperta dal
titolo "Privacy Enhancing Technologies vs. Antiforensics" di Marco A.
Calamari del Progetto Winston Smith.
La lezione è stata molto interessante anche per l'estesa panoramica sugli
strumenti di anonimizzazione per Internet disponibili.
Per saperne di più, consiglio di visitare il sito:
http://www.winstonsmith.info/pws/index.html
titolo "Privacy Enhancing Technologies vs. Antiforensics" di Marco A.
Calamari del Progetto Winston Smith.
La lezione è stata molto interessante anche per l'estesa panoramica sugli
strumenti di anonimizzazione per Internet disponibili.
Per saperne di più, consiglio di visitare il sito:
http://www.winstonsmith.info/pws/index.html
martedì 19 aprile 2011
Business Continuity e Incident Management
Nella newsletter di marzo, trattando del nuovo CAD, avevo segnalato come disgraziatamente si confonde la Business Continuity con la continuità dei soli sistemi IT e con il Disaster Recovery (termine utilizzato solo per i sistemi IT):
http://blog.cesaregallotti.it/2011/03/nuovo-cad-relazione-convegno-3-marzo.html
Un lettore (anonimo perché non gli ho chiesto se posso pubblicare il suo nome) mi ha fatto giustamente notare che l'approccio secondo cui la Business Continuity si deve occupare anche dei piccoli incidenti di continuità porta al fallimento delle iniziative di BCP (Business Continuity Plan).
Convengo, ma ho fatto qualche riflessione che voglio qui pubblicare:
1- la business continuity è un'attività del business e non dell'IT (questa spero sia una cosa ben chiara a tutti)
2- per fare l'analisi da cui elaborare i BCP, ossia la Business Impact Analysis o BIA, è necessario comprendere i tempi massimi di interruzione che il business può sopportare insieme alla ampiezza della interruzione (in molte realtà, un unico pc rotto per 1 settimana può avere impatti ben diversi di 100 pc per 1 ora). A seconda del business, i tempi massimi possono essere molto ridotti: deve essere la BIA a evidenziare questo parametro.
3- Quando avviene un incidente, a seconda dei tempi previsti di ripristino e dalla sua ampiezza si possono adottare diverse strategie.
4- Solitamente, quando si parla di BCP si intendono i piani da attuare nella peggiore delle ipotesi. L'unica cosa su cui riflettere è che, in realtà, negli altri casi si procede con la "normale" gestione degli incidenti (Incident Management o IM).
5- Io dico che i BCP-estremi (mi permetto di inventare questa definizione) e i piani di IM sono tutti dei BCP e la cosa fondamentale è stabilire quando bisogna adottare gli uni o gli altri (ossia, quando la prima valutazione di un incidente fornisce una previsione di interruzione compresa in un certo intervallo di tempo e una sua ampiezza di un certo tipo, si adottano le procedure A, B o C, che dispongono azioni specifiche tecniche e gestionali).
http://blog.cesaregallotti.it/2011/03/nuovo-cad-relazione-convegno-3-marzo.html
Un lettore (anonimo perché non gli ho chiesto se posso pubblicare il suo nome) mi ha fatto giustamente notare che l'approccio secondo cui la Business Continuity si deve occupare anche dei piccoli incidenti di continuità porta al fallimento delle iniziative di BCP (Business Continuity Plan).
Convengo, ma ho fatto qualche riflessione che voglio qui pubblicare:
1- la business continuity è un'attività del business e non dell'IT (questa spero sia una cosa ben chiara a tutti)
2- per fare l'analisi da cui elaborare i BCP, ossia la Business Impact Analysis o BIA, è necessario comprendere i tempi massimi di interruzione che il business può sopportare insieme alla ampiezza della interruzione (in molte realtà, un unico pc rotto per 1 settimana può avere impatti ben diversi di 100 pc per 1 ora). A seconda del business, i tempi massimi possono essere molto ridotti: deve essere la BIA a evidenziare questo parametro.
3- Quando avviene un incidente, a seconda dei tempi previsti di ripristino e dalla sua ampiezza si possono adottare diverse strategie.
4- Solitamente, quando si parla di BCP si intendono i piani da attuare nella peggiore delle ipotesi. L'unica cosa su cui riflettere è che, in realtà, negli altri casi si procede con la "normale" gestione degli incidenti (Incident Management o IM).
5- Io dico che i BCP-estremi (mi permetto di inventare questa definizione) e i piani di IM sono tutti dei BCP e la cosa fondamentale è stabilire quando bisogna adottare gli uni o gli altri (ossia, quando la prima valutazione di un incidente fornisce una previsione di interruzione compresa in un certo intervallo di tempo e una sua ampiezza di un certo tipo, si adottano le procedure A, B o C, che dispongono azioni specifiche tecniche e gestionali).
6- Il problema delle inziative di BCP è che solitamente riguardano solo i casi peggiori, per i quali è richiesta la collaborazione di persone poco preparate ad un certo tipo di riflessione e poco disposte a farle, visto che i casi sono rari. Ritengo che, in questi casi, è sufficiente trattare con loro solo della BIA e dei casi peggiori semplificando (giustamente, come dice il mio lettore) la teoria in favore della pratica.
Nella mia impostazione sono confortato dalla ISO/IEC 20000 che tratta in un unico capitolo la disponibilità dei sistemi e la continuità dei servizi e dalla ISO/PAS 22399 dal titolo "Guideline for incident management and operational continuity management".
Altri contributi alla discussione sono benvenuti.
PS: la puntata successiva è nel post http://blog.cesaregallotti.it/2011/05/un-contributo-su-business-continuity-e.html
Nella mia impostazione sono confortato dalla ISO/IEC 20000 che tratta in un unico capitolo la disponibilità dei sistemi e la continuità dei servizi e dalla ISO/PAS 22399 dal titolo "Guideline for incident management and operational continuity management".
Altri contributi alla discussione sono benvenuti.
PS: la puntata successiva è nel post http://blog.cesaregallotti.it/2011/05/un-contributo-su-business-continuity-e.html
Privacy: Pubblicazione di dati personali
Il 2 marzo, il Garante ha pubblicato le "Linee guida in materia di trattamento di dati personali contenuti anche in atti e documenti amministrativi, effettuato da soggetti pubblici per finalità di pubblicazione e diffusione sul web".
Inizialmente ho ignorato questo Provvedimento, visto che è specifico per la Pubblica Amministrazione. Lo segnalo perché comunque molti privati pubblicano sui propri siti dati personali, atti e documenti e dovrebbero comunque prendere spunto da quanto previsto per la PA.
Il Provvedimento:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1793203
Inizialmente ho ignorato questo Provvedimento, visto che è specifico per la Pubblica Amministrazione. Lo segnalo perché comunque molti privati pubblicano sui propri siti dati personali, atti e documenti e dovrebbero comunque prendere spunto da quanto previsto per la PA.
Il Provvedimento:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1793203
Value Assessment Tool
Dall'articolo "Value Assessment Tool for ICT Projects at the European Commission" sul Volume 2, 2011 dell'ISACA Journal, segnalo il VAST, strumento messo a punto in seno alla EC per valutare le proposte di progetti ICT.
Evidentemente il tool è tarato per il business specifico della Commissione Europea, ma può essere un ottimo spunto per altre specializzazioni.
http://ec.europa.eu/dgs/informatics/vast/index_en.htm
Evidentemente il tool è tarato per il business specifico della Commissione Europea, ma può essere un ottimo spunto per altre specializzazioni.
http://ec.europa.eu/dgs/informatics/vast/index_en.htm
Abrogazione del SAS 70 e i nuovi SOC Report
Un articolo dell'ISACA Journal Volume 2 del 2011 dal titolo "Understanding the New SOC Reports" segnala l'abrogazione dei report SAS 70 in favore dei nuovi SOC reports.
Infatti, i report SAS 70 erano nati per gli audit sui sistemi contabili e recentemente erano stati utilizzati in modo improprio anche per dimostrare la sicurezza di un IT service provider su standard di controlli di sicurezza non definiti.
L'AICPA ha quindi definito 3 nuove tipologie di report:
- il SOC-1 o SSAE 16, che rimpiazza il SAS 70 propriamente detto e che riguarda i soli sistemi contabili
- il SOC-2 è un report più tecnico, dedicato a uno o più elementi (sicurezza, disponibilità, integrità, riservatezza e privacy), i cui relativi controlli sono descritti nel "Trust Services Principles and Criteria";
- il SOC-3 è una sorta di riassunto del SOC-2 destinato alla pubblicazione; è possibile paragonarlo alla certificazione ISO/IEC 27001 con tanto di marchio da pubblicare sul sito web.
I SOC possono essere di tipo 1 (meno estesi e più legati alla fase di pianificazione dei controlli) o di tipo 2 (con anche la valutazione di come i controlli operano in pratica e la descrizione dei test condotti dall'auditor)
Maggiori (e quasi sicuramente più precisi) dettagli:
- http://www.aicpa.org/InterestAreas/InformationTechnology/Resources/TrustServices/DownloadableDocuments/10957-378%20SOC%20Whitepaper.pdf
I "Trust Services Principles and Criteria" sono disponibili su
http://www.aicpa.org/InterestAreas/InformationTechnology/Resources/TrustServices/DownloadableDocuments/FINAL_Trust_services_PC_Only_0609.pdf
Infatti, i report SAS 70 erano nati per gli audit sui sistemi contabili e recentemente erano stati utilizzati in modo improprio anche per dimostrare la sicurezza di un IT service provider su standard di controlli di sicurezza non definiti.
L'AICPA ha quindi definito 3 nuove tipologie di report:
- il SOC-1 o SSAE 16, che rimpiazza il SAS 70 propriamente detto e che riguarda i soli sistemi contabili
- il SOC-2 è un report più tecnico, dedicato a uno o più elementi (sicurezza, disponibilità, integrità, riservatezza e privacy), i cui relativi controlli sono descritti nel "Trust Services Principles and Criteria";
- il SOC-3 è una sorta di riassunto del SOC-2 destinato alla pubblicazione; è possibile paragonarlo alla certificazione ISO/IEC 27001 con tanto di marchio da pubblicare sul sito web.
I SOC possono essere di tipo 1 (meno estesi e più legati alla fase di pianificazione dei controlli) o di tipo 2 (con anche la valutazione di come i controlli operano in pratica e la descrizione dei test condotti dall'auditor)
Maggiori (e quasi sicuramente più precisi) dettagli:
- http://www.aicpa.org/InterestAreas/InformationTechnology/Resources/TrustServices/DownloadableDocuments/10957-378%20SOC%20Whitepaper.pdf
I "Trust Services Principles and Criteria" sono disponibili su
http://www.aicpa.org/InterestAreas/InformationTechnology/Resources/TrustServices/DownloadableDocuments/FINAL_Trust_services_PC_Only_0609.pdf
lunedì 18 aprile 2011
Sicurezza dei dati in ambito farmaceutico
Il 22 marzo ho assistito al Workshop "Annex 11" organizzato a Milano da CTP System (www.ctpsystem.com), società specializzata in consulenza in ambito farmaceutico.
Per capire meglio di cosa si tratta, riporto il link alla presentazione:
http://www.ctpsystem.com/home/images/PDF/articoloncfmarzo2011_annex11.pdf
In poche parole, si tratta della pubblicazione della nuova versione del
capitolo 4 e dell'Annex 11 delle Good Manufacturing practice (GMP), di
supporto alla Direttiva 2003/94/EC, che entreranno in vigore a giugno 2011 e
che costituiscono lo standard di riferimento per la sicurezza delle
informazioni in ambito farmaceutico.
Le nuove normative hanno introdotto i concetti di risk assessment e risk
management, di ciclo di vita dei sistemi e di sistemi di gestione. E' stato
comunque fatto rilevare che le best practices di settore trattavano già
ampiamente questi temi.
Argomenti, quindi, ben noti a chi segue questo blog. In questo caso, però,
affrontati con l'ottica delle aziende di produzione e non di servizi.
Quindi, un'ottica molto pragmatica da una parte ma anche molto più rigorosa
dei molti esempi a cui siamo abituati.
Le GMP: http://ec.europa.eu/health/documents/eudralex/vol-4/index_en.htm.
Il corrispondente USA, ha sigla 21 CFR 11:
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm ed è
accompagnato dalle linee guida della DFA:
- http://www.fda.gov/RegulatoryInformation/Guidances/ucm125067.htm
- http://www.fda.gov/RegulatoryInformation/Guidances/ucm122046.htm
Molto diffuse in ambito farmaceutico sono le GAMP, pubblicate dalla ISPE:
(http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview
)
Sul Risk Assessment, la bibliografia comprende l'Annex 20 delle GMP, il
capitolo 5 e M3 della GAMP 5, una pubblicazione complementare delle GAMP 5,
la ISO 14971:2009 (in vigore anche per i medical devices), oltre che le ISO
31000, ISO 31010 e ISO Guide 73.
Un'ultima nota: nel calcolo del livello di rischio, alle ben note variabili
di impatto e probabilità (a sua volta funzione di minacce e vulnerabilità),
viene aggiunta la rilevabilità.
Per capire meglio di cosa si tratta, riporto il link alla presentazione:
http://www.ctpsystem.com/home/images/PDF/articoloncfmarzo2011_annex11.pdf
In poche parole, si tratta della pubblicazione della nuova versione del
capitolo 4 e dell'Annex 11 delle Good Manufacturing practice (GMP), di
supporto alla Direttiva 2003/94/EC, che entreranno in vigore a giugno 2011 e
che costituiscono lo standard di riferimento per la sicurezza delle
informazioni in ambito farmaceutico.
Le nuove normative hanno introdotto i concetti di risk assessment e risk
management, di ciclo di vita dei sistemi e di sistemi di gestione. E' stato
comunque fatto rilevare che le best practices di settore trattavano già
ampiamente questi temi.
Argomenti, quindi, ben noti a chi segue questo blog. In questo caso, però,
affrontati con l'ottica delle aziende di produzione e non di servizi.
Quindi, un'ottica molto pragmatica da una parte ma anche molto più rigorosa
dei molti esempi a cui siamo abituati.
Le GMP: http://ec.europa.eu/health/documents/eudralex/vol-4/index_en.htm.
Il corrispondente USA, ha sigla 21 CFR 11:
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm ed è
accompagnato dalle linee guida della DFA:
- http://www.fda.gov/RegulatoryInformation/Guidances/ucm125067.htm
- http://www.fda.gov/RegulatoryInformation/Guidances/ucm122046.htm
Molto diffuse in ambito farmaceutico sono le GAMP, pubblicate dalla ISPE:
(http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview
)
Sul Risk Assessment, la bibliografia comprende l'Annex 20 delle GMP, il
capitolo 5 e M3 della GAMP 5, una pubblicazione complementare delle GAMP 5,
la ISO 14971:2009 (in vigore anche per i medical devices), oltre che le ISO
31000, ISO 31010 e ISO Guide 73.
Un'ultima nota: nel calcolo del livello di rischio, alle ben note variabili
di impatto e probabilità (a sua volta funzione di minacce e vulnerabilità),
viene aggiunta la rilevabilità.
ISO/IEC 20000-1:2011 e traduzione in italiano
Tony Coletta mi annuncia:
"La nuova edizione della ISO/IEC 20000-1 è stata
pubblicata il 12 aprile 2011. Abbiamo pronta la traduzione fatta da un gruppo di volontari itSMF ed il sottoscritto. L'abbiamo sottoposta all'approvazione dell'UNI. Attendiamo fiduciosi"
Lo ringrazio per l'aggiornamento.
"La nuova edizione della ISO/IEC 20000-1 è stata
pubblicata il 12 aprile 2011. Abbiamo pronta la traduzione fatta da un gruppo di volontari itSMF ed il sottoscritto. L'abbiamo sottoposta all'approvazione dell'UNI. Attendiamo fiduciosi"
Lo ringrazio per l'aggiornamento.
venerdì 15 aprile 2011
Italiani, brava gente?
Ieri 14 aprile, alla sessione di studio dell'AIEA a Milano, Tamara Devalle e Tiziana Boffi di Protiviti hanno presentato i risultati di una ricerca sull'organizzazione IT nelle aziende italiane. Il quadro non è certo confortante.
Al termine della presentazione, un partecipante ha detto il solito luogo comune: "molti problemi sono propri di noi italiani".
Ho dovuto intervenire facendo notare che non è vero. Le mie esperienze all'estero o con multi-nazionali e le notizie da siti web di tutto il mondo dimostrano che le difficoltà dell'IT sono comuni.
Il problema del luogo comune "l'IT va male in Italia perché gli italiani non seguono le procedure, non sono educati, eccetera" è che poi diventa una giustificazione per i manager che non sanno convincere e spiegare e inserire una cultura aziendale adeguata, per i consulenti e i vari responsabili che scrivono procedure illeggibili e contorte, per i vertici aziendali che operano cambi organizzativi solo sugli organigrammi e mai sui processi e sui loro riporti che pensano solo a raggiungere gli obiettivi della propria area e mai a capire e risolvere i problemi di interrelazione con le altre aree (e il povero IT che è trasversale se la passa male...).
Concludo pregando tutti di ribellarvi a chiunque dica "siamo noi italiani che siamo fatti così": è una comoda e sbagliata giustificazione. Se vogliamo migliorare (non l'Italia, ma la piccola realtà che ci circonda), non c'è nulla di peggio di nascondersi dietro i luoghi comuni.
La presentazione di Protiviti dovrebbe essere pubblicata su http://www.aiea.it/html/anno_2011.html.
Al termine della presentazione, un partecipante ha detto il solito luogo comune: "molti problemi sono propri di noi italiani".
Ho dovuto intervenire facendo notare che non è vero. Le mie esperienze all'estero o con multi-nazionali e le notizie da siti web di tutto il mondo dimostrano che le difficoltà dell'IT sono comuni.
Il problema del luogo comune "l'IT va male in Italia perché gli italiani non seguono le procedure, non sono educati, eccetera" è che poi diventa una giustificazione per i manager che non sanno convincere e spiegare e inserire una cultura aziendale adeguata, per i consulenti e i vari responsabili che scrivono procedure illeggibili e contorte, per i vertici aziendali che operano cambi organizzativi solo sugli organigrammi e mai sui processi e sui loro riporti che pensano solo a raggiungere gli obiettivi della propria area e mai a capire e risolvere i problemi di interrelazione con le altre aree (e il povero IT che è trasversale se la passa male...).
Concludo pregando tutti di ribellarvi a chiunque dica "siamo noi italiani che siamo fatti così": è una comoda e sbagliata giustificazione. Se vogliamo migliorare (non l'Italia, ma la piccola realtà che ci circonda), non c'è nulla di peggio di nascondersi dietro i luoghi comuni.
La presentazione di Protiviti dovrebbe essere pubblicata su http://www.aiea.it/html/anno_2011.html.
Prodotti per Data Leak Prevention
L'ISACA ha pubblicato un white paper sulla Data Leak Prevention: www.isaca.org/DLP.
Lettura certamente utile, anche se il titolo è fuorviante. Infatti, si occupa di prodotti di Data Leak Prevention (DLP solutions) e solo parzialmente di altri elementi (alcuni li ho riportati in http://blog.cesaregallotti.it/2011/03/proteggersi-dal-leakage.html)
Lettura certamente utile, anche se il titolo è fuorviante. Infatti, si occupa di prodotti di Data Leak Prevention (DLP solutions) e solo parzialmente di altri elementi (alcuni li ho riportati in http://blog.cesaregallotti.it/2011/03/proteggersi-dal-leakage.html)
mercoledì 13 aprile 2011
Atti del Security Summit
Il 14-16 marzo 2011 si è tenuto a Milano il Security Summit. Sono disponibili le presentazioni dei relatori su https://www.securitysummit.it/page/atti_milano_2011
Io ho assistito (e ne raccomando le slides) a:
- La sicurezza dei pagamenti e delle carte di credito (PCI-DSS)
- La computer forensics e le investigazioni digitali tra approcci pratici e rigore scientifico: un'introduzione accademica
- Seminario a cura dell'Information Technology Service Management Forum Italia (itSMF)
- Seminario a cura dell'Information Technology Service Management Forum Italia (itSMF)
Buona lettura!
Io ho assistito (e ne raccomando le slides) a:
- La sicurezza dei pagamenti e delle carte di credito (PCI-DSS)
- La computer forensics e le investigazioni digitali tra approcci pratici e rigore scientifico: un'introduzione accademica
- Seminario a cura dell'Information Technology Service Management Forum Italia (itSMF)
- Seminario a cura dell'Information Technology Service Management Forum Italia (itSMF)
Buona lettura!
mercoledì 6 aprile 2011
ISO 28000 - Security in supply chain
Settimana scorsa, leggendo la newsletter dell'IRCA, ho trovato un articolo sulla ISO 28000:
http://www.irca.org/inform/issue29/TCummins.html?dm_i=4VM,DS56,HZSOT,151FL,1
Volevo quindi leggerlo e poi segnalarlo con il titolo "ISO 28000 - Uno standard dimenticato". Ma giusto nell'ultima settimana ho avuto conferma che sta nascendo interesse in questa norma internazionale sulla sicurezza "fisica". La norma è quindi applicabile a chi opera nella logistica e nel magazzinaggio.
La sua prima versione fu emessa come ISO PAS nel 2005; la seconda e attuale versione è del 2007 come ISO IS.
Di interesse sono le seguenti parti:
- ISO 28000:2007 "Specification for security management systems for the supply chain"; è lo standard "certificabile" e ricorda molto la ISO/IEC 27001:2005;
- ISO 28001:2007 "Security management systems for the supply chain — Best practices for implementing supply chain security, assessments and plans — Requirements and guidance"; riporta anch'esso dei requisiti (malgrado il titolo con l'ossimoro "best practices" - "requirements"), ma l'introduzione non aiuta a comprendere la sua relazione con la 28000; il suo contenuto sembra però più una best practices per il risk assessment richiesto dalla ISO 28000;
- ISO 28004:2007 "Security management systems for the supply chain — Guidelines for the implementation of ISO 28000", riporta le best practices e cita solo la 28000 e non la 28001.
http://www.irca.org/inform/issue29/TCummins.html?dm_i=4VM,DS56,HZSOT,151FL,1
Volevo quindi leggerlo e poi segnalarlo con il titolo "ISO 28000 - Uno standard dimenticato". Ma giusto nell'ultima settimana ho avuto conferma che sta nascendo interesse in questa norma internazionale sulla sicurezza "fisica". La norma è quindi applicabile a chi opera nella logistica e nel magazzinaggio.
La sua prima versione fu emessa come ISO PAS nel 2005; la seconda e attuale versione è del 2007 come ISO IS.
Di interesse sono le seguenti parti:
- ISO 28000:2007 "Specification for security management systems for the supply chain"; è lo standard "certificabile" e ricorda molto la ISO/IEC 27001:2005;
- ISO 28001:2007 "Security management systems for the supply chain — Best practices for implementing supply chain security, assessments and plans — Requirements and guidance"; riporta anch'esso dei requisiti (malgrado il titolo con l'ossimoro "best practices" - "requirements"), ma l'introduzione non aiuta a comprendere la sua relazione con la 28000; il suo contenuto sembra però più una best practices per il risk assessment richiesto dalla ISO 28000;
- ISO 28004:2007 "Security management systems for the supply chain — Guidelines for the implementation of ISO 28000", riporta le best practices e cita solo la 28000 e non la 28001.
lunedì 4 aprile 2011
Privacy: dei Titolari e dei Responsabili esterni - Parte 2
Dopo il mio post con stesso titolo di qualche giorno fa (http://blog.cesaregallotti.it/2011/04/privacy-dei-titolari-e-dei-responsabili.html), Mauro Cicognini
(sempre sul forum Clusit di LinkedIn) concorda con me e mi conferma che non
sono solo a vederla così. Aggiunge che "l'unica complicazione è che
naturalmente tutti i Titolari devono essere riportati nell'informativa".
Io ho continuato nella riflessione come segue.
Nell'ipotesi che si abbiano responsabili e non titolari, anche questi devono
essere riportati sull'informativa. Ma tutti inseriscono solo "le categorie
di soggetti" a cui comunicano i dati, come previsto dal Codice.
Perché il modello regga, bisogna leggere le due parti della disgiuntiva del
punto d del comma 1 dell'articolo 13 come completamente separati. Tradotto:
nell'informativa devo includere "1- i soggetti o le categorie di soggetti ai
quali i dati personali possono essere comunicati; 2- i soggetti o le
categorie di soggetti che possono venirne a conoscenza in qualità di
responsabili o incaricati".
E' una forzatura? Certo. Ma anche nominare degli esterni come "Responsabili"
che poi a loro volta nomineranno dei "Responsabili" è una forzatura. Oppure
nominare degli esterni come "Responsabili" e non fargli mai le verifiche
periodiche è una forzatura (alla banca, per esempio). Oppure scrivere nome e
cognome di alcuni responsabili o co-titolari nell'informativa e non inviarla
ad ogni aggiornamento è una forzatura.
Forzare per forzare, scelgo di forzare utilizzando un modello coerente, in
linea con ogni prassi gestionale di processi e di sicurezza, in linea con
quanto previsto nel resto dell'Europa (dove la Direttiva 95/46/CE è
ovviamente applicata). E scelgo di non aggrapparmi ad un modello fuori da
ogni logica e comunque passibile di contestazione rispetto a quanto si legge
nel Codice.
Ci sarebbe da riflettere mestamente su tanti (troppi) professionisti che
seguono come buoi il primo che dice una fesseria: la custodia delle password
in busta chiusa per migliaia di persone da moltiplicare per decine di
sistemi, il DPS come cosa complessissima che ha richiesto anni di proroghe,
richieste di consenso inutili ancora in circolazione, eccetera.
La smetto qui. Ma se ci sono controdeduzioni da proporre, sarò contento di
pubblicarle (e di rispondere e di pubblicare le risposte e così via; fino a
che nel botta-risposta ci saranno cose intelligenti).
PS: La puntata successiva è su: http://blog.cesaregallotti.it/2011/06/privacy-dei-titolari-e-dei-responsabili.html
(sempre sul forum Clusit di LinkedIn) concorda con me e mi conferma che non
sono solo a vederla così. Aggiunge che "l'unica complicazione è che
naturalmente tutti i Titolari devono essere riportati nell'informativa".
Io ho continuato nella riflessione come segue.
Nell'ipotesi che si abbiano responsabili e non titolari, anche questi devono
essere riportati sull'informativa. Ma tutti inseriscono solo "le categorie
di soggetti" a cui comunicano i dati, come previsto dal Codice.
Perché il modello regga, bisogna leggere le due parti della disgiuntiva del
punto d del comma 1 dell'articolo 13 come completamente separati. Tradotto:
nell'informativa devo includere "1- i soggetti o le categorie di soggetti ai
quali i dati personali possono essere comunicati; 2- i soggetti o le
categorie di soggetti che possono venirne a conoscenza in qualità di
responsabili o incaricati".
E' una forzatura? Certo. Ma anche nominare degli esterni come "Responsabili"
che poi a loro volta nomineranno dei "Responsabili" è una forzatura. Oppure
nominare degli esterni come "Responsabili" e non fargli mai le verifiche
periodiche è una forzatura (alla banca, per esempio). Oppure scrivere nome e
cognome di alcuni responsabili o co-titolari nell'informativa e non inviarla
ad ogni aggiornamento è una forzatura.
Forzare per forzare, scelgo di forzare utilizzando un modello coerente, in
linea con ogni prassi gestionale di processi e di sicurezza, in linea con
quanto previsto nel resto dell'Europa (dove la Direttiva 95/46/CE è
ovviamente applicata). E scelgo di non aggrapparmi ad un modello fuori da
ogni logica e comunque passibile di contestazione rispetto a quanto si legge
nel Codice.
Ci sarebbe da riflettere mestamente su tanti (troppi) professionisti che
seguono come buoi il primo che dice una fesseria: la custodia delle password
in busta chiusa per migliaia di persone da moltiplicare per decine di
sistemi, il DPS come cosa complessissima che ha richiesto anni di proroghe,
richieste di consenso inutili ancora in circolazione, eccetera.
La smetto qui. Ma se ci sono controdeduzioni da proporre, sarò contento di
pubblicarle (e di rispondere e di pubblicare le risposte e così via; fino a
che nel botta-risposta ci saranno cose intelligenti).
PS: La puntata successiva è su: http://blog.cesaregallotti.it/2011/06/privacy-dei-titolari-e-dei-responsabili.html
sabato 2 aprile 2011
Privacy: dei Titolari e dei Responsabili esterni
NOTA del 2018: questo articolo era di inizio 2016 e contiene errori
evidenti. Ha trovato risposte con la pubblicazione del GDPR.
Su LinkedIn, nel gruppo del Clusit, è stata sollevata la questione di un'azienda che fa monitoraggio della rete e configurazione degli apparati ed è stata nominata Responsabile Esterno da un cliente. Inoltre, il cliente ha deciso di "nominare" gli amministratori di sistema del fornitore.
Ho rabbrividito e ho risposto così:
1- Nella "nuova" Legge Privacy (Dlgs 196) il Titolare è stato definito in modo sottilmente diverso dalla "vecchia" 675/96. In particolare, nella nuova definizione, al Titolare "competono, anche unitamente ad altro titolare, le decisioni...". E' stato aggiunto "anche unitamente ad altro titolare". Articolo 1 lettera d della Legge 675/1996 e Articolo 4 lettera f del Dlgs 196/2003.
Io interpreto così: clienti e fornitori possono essere Titolari autonomi, una volta che si sono definite le finalità di ciascuno (nel caso in questione, "monitoraggio e configurazione della rete IT") e il profilo di sicurezza (dal semplice "rispetto della normativa privacy" ad una serie di procedure concordate tra le parti).
Purtroppo sembra che in pochi abbiano capito questo aspetto e si trascinano dietro le interpretazioni pre-2003 e continuano a nominare Responsabili esterni i fornitori, che dovranno anche "subire" verifiche periodiche dal Titolare (Art. 29 comma 5), eccetera.
Qualche domanda sui Responsabili Esterni: io dovrei nominare Responsabile esterno la mia banca? E il mio ISP (Wind)? E il mio gestore del telefono (Telecom)? E le Poste Italiane? Dovrei chiedere loro i nominativi degli AdS? Dovrò fare loro delle verifiche? A sua volta, il Responsabile esterno come può interfacciarsi con i propri fornitori?
Ancora: lo studio legale che ha dato quelle belle interpretazioni è stato nominato Responsabile Esterno? Permetterebbe al Titolare di fare "verifiche periodiche"? Gli ha dato il nominativo dei propri AdS (alla fine anche lo studio legale avrà un server o dei pc)?
E' ovvio che è un modello che non sta in piedi. Rimane solo una possibiltà perché il tutto regga: il fornitore è un Titolare autonomo, che tratterà i dati solo per eseguire il contratto (finalità) e con misure di sicurezza concordate con il cliente (dal "solo" rispetto della normativa a cose più complesse).
Infine: nel Dlgs 196/2003 (ultima versione da consultarsi su www.normattiva.it), non si nomina MAI il "Responsabile esterno".
2- Anche se il fornitore fosse stato nominato Responsabile, il Titolare non deve avere a disposizione i nominativi degli AdS. Questo lo diceva il Provvedimento del 28 novembre del 2008. Poi modificato opportunamente il 25 giugno del 2009. Ora dice "il titolare o il responsabile del trattamento devono conservare i nominativi". E' stato incluso il responsabile (con una bella "o" tra lui e il Titolare), che lo dovrà mantere disponibile in caso di accertamenti.
Ma ancora una volta, sembra che non sia prassi tenersi aggiornati.
Su LinkedIn, nel gruppo del Clusit, è stata sollevata la questione di un'azienda che fa monitoraggio della rete e configurazione degli apparati ed è stata nominata Responsabile Esterno da un cliente. Inoltre, il cliente ha deciso di "nominare" gli amministratori di sistema del fornitore.
Ho rabbrividito e ho risposto così:
1- Nella "nuova" Legge Privacy (Dlgs 196) il Titolare è stato definito in modo sottilmente diverso dalla "vecchia" 675/96. In particolare, nella nuova definizione, al Titolare "competono, anche unitamente ad altro titolare, le decisioni...". E' stato aggiunto "anche unitamente ad altro titolare". Articolo 1 lettera d della Legge 675/1996 e Articolo 4 lettera f del Dlgs 196/2003.
Io interpreto così: clienti e fornitori possono essere Titolari autonomi, una volta che si sono definite le finalità di ciascuno (nel caso in questione, "monitoraggio e configurazione della rete IT") e il profilo di sicurezza (dal semplice "rispetto della normativa privacy" ad una serie di procedure concordate tra le parti).
Purtroppo sembra che in pochi abbiano capito questo aspetto e si trascinano dietro le interpretazioni pre-2003 e continuano a nominare Responsabili esterni i fornitori, che dovranno anche "subire" verifiche periodiche dal Titolare (Art. 29 comma 5), eccetera.
Qualche domanda sui Responsabili Esterni: io dovrei nominare Responsabile esterno la mia banca? E il mio ISP (Wind)? E il mio gestore del telefono (Telecom)? E le Poste Italiane? Dovrei chiedere loro i nominativi degli AdS? Dovrò fare loro delle verifiche? A sua volta, il Responsabile esterno come può interfacciarsi con i propri fornitori?
Ancora: lo studio legale che ha dato quelle belle interpretazioni è stato nominato Responsabile Esterno? Permetterebbe al Titolare di fare "verifiche periodiche"? Gli ha dato il nominativo dei propri AdS (alla fine anche lo studio legale avrà un server o dei pc)?
E' ovvio che è un modello che non sta in piedi. Rimane solo una possibiltà perché il tutto regga: il fornitore è un Titolare autonomo, che tratterà i dati solo per eseguire il contratto (finalità) e con misure di sicurezza concordate con il cliente (dal "solo" rispetto della normativa a cose più complesse).
Infine: nel Dlgs 196/2003 (ultima versione da consultarsi su www.normattiva.it), non si nomina MAI il "Responsabile esterno".
2- Anche se il fornitore fosse stato nominato Responsabile, il Titolare non deve avere a disposizione i nominativi degli AdS. Questo lo diceva il Provvedimento del 28 novembre del 2008. Poi modificato opportunamente il 25 giugno del 2009. Ora dice "il titolare o il responsabile del trattamento devono conservare i nominativi". E' stato incluso il responsabile (con una bella "o" tra lui e il Titolare), che lo dovrà mantere disponibile in caso di accertamenti.
Ma ancora una volta, sembra che non sia prassi tenersi aggiornati.
Iscriviti a:
Post (Atom)