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ù.
mercoledì 29 giugno 2011
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#
Iscriviti a:
Post (Atom)