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).
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
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
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
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
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à.
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.
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.
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)
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!
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.
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
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.
