Segnalo questo interessante articolo sul Dlgs 231 del 2011:
http://www.filodiritto.com/index.php?azione=visualizza&iddoc=2320
venerdì 27 maggio 2011
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.
Iscriviti a:
Post (Atom)