Da Interlex (http://www.mcreporter.info/)
Importante sentenza della Corte d'Appello di Torino: il gestore di un blog non può essere equiparato al direttore responsabile di un giornale e quindi non esiste il reato di "omesso controllo". Resta la responsabilità per diffamazione.
http://www.mcreporter.info/giurisprudenza/to100423.pdf
Sicurezza delle informazioni, IT service management e qualità da Cesare Gallotti
martedì 21 dicembre 2010
Libro bianco: Le Prove, i Controlli, le Valutazioni e le Certificazioni per i prodotti, i servizi, le aziende ed i professionisti
Segnalo, da comunicazione ricevuta dal CEPAS, la pubblicazione del Libro bianco: "Le Prove, i Controlli, le Valutazioni e le Certificazioni per i prodotti, i servizi, le aziende ed i professionisti" a cura di Confindustria Servizi Innovativi e Tecnologici.
Il libro è il risultato di un'ampia indagine su diverse tipologie di certificazione, tra cui quella dei dispositivi medici (e del relativo software!), dei Sistemi di Gestione per la Qualità, di Sistemi di Gestione per la Sicurezza delle Informazioni e del personale.
Ho trovato decisamente interessante e brutalmente sincera la parte sulla 9001, mentre ho trovato diverse inesattezze nell'ambito della 27001 (ma ricordo che qualcuno mi aveva coinvolto e avevo riportato delle considerazioni... mi avrà ignorato...) e della certificazione del personale. Ho poi intercettato un riferimento alla vecchia 626 e mi sono accorto che per capire la data di pubblicazione bisogna andare fino all'ultima pagina in cui si legge un generico 2010.
Il lavoro, quindi, presenta disomogeneità tra i vari capitoli e alcune imprecisioni ci impongono di leggerlo con prudenza. Ciò non toglie che può presentare un valido punto di riferimento per capire meglio alcuni ambiti e alcuni campi di applicazione.
Il link: http://www.cepas.it/news.asp
Il libro è il risultato di un'ampia indagine su diverse tipologie di certificazione, tra cui quella dei dispositivi medici (e del relativo software!), dei Sistemi di Gestione per la Qualità, di Sistemi di Gestione per la Sicurezza delle Informazioni e del personale.
Ho trovato decisamente interessante e brutalmente sincera la parte sulla 9001, mentre ho trovato diverse inesattezze nell'ambito della 27001 (ma ricordo che qualcuno mi aveva coinvolto e avevo riportato delle considerazioni... mi avrà ignorato...) e della certificazione del personale. Ho poi intercettato un riferimento alla vecchia 626 e mi sono accorto che per capire la data di pubblicazione bisogna andare fino all'ultima pagina in cui si legge un generico 2010.
Il lavoro, quindi, presenta disomogeneità tra i vari capitoli e alcune imprecisioni ci impongono di leggerlo con prudenza. Ciò non toglie che può presentare un valido punto di riferimento per capire meglio alcuni ambiti e alcuni campi di applicazione.
Il link: http://www.cepas.it/news.asp
Commenti su Decreto Legislativo 198 del 2010 sull'installazione di reti IT
Andrea Rui mi ha riportato un paio di commenti sul Dlgs 198 che condivido.
Avendomi scritto privatamente (a cosa serve il blog?), sono "costretto" a riportare le cose anche un poco filtrate da mie idee.
1- Dopo tanto parlare dell'eliminazione degli albi professionali, ci si inventa il nuovo albo o registro per gli installatori. A cui saranno iscritti i soliti noti alla faccia delle liberalizzazioni.
2- Se l'azienda sarà nell'albo, poi si corre il rischio che gli operatori sul campo non saranno sempre opportunamente preparati, come troppo spesso succede.
3- Perché invece non richiedere certificazioni personali? Anche se il mercato delle certificazioni personali potrebbe deteriorarsi, almeno rimarrebbe valida la responsabilità personale di chi svolge i lavori.
domenica 19 dicembre 2010
ISO/IEC TR 20000-4:2010
E' stata pubblicata la quarta parte (non certificabile!) della 20000 dal titolo "Information technology — Service management — Part 4: Process reference model".
In poche parole, si tratta di una riscrittura della attuale 20000-1 (prima edizione) e del draft della seconda edizione seguendo il modello della ISO/IEC 15504-1.
Che dire? Si tratta di un esercizio di stile, forse interessante ma che non approfondirò. A questo aggiungo che non sono riuscito a capire il perché di questa operazione ora, a poco tempo dalla riemissione della norma. Infine, non sono riuscito a capire a quale draft della seconda edizione faccia riferimento.
In poche parole, si tratta di una riscrittura della attuale 20000-1 (prima edizione) e del draft della seconda edizione seguendo il modello della ISO/IEC 15504-1.
Che dire? Si tratta di un esercizio di stile, forse interessante ma che non approfondirò. A questo aggiungo che non sono riuscito a capire il perché di questa operazione ora, a poco tempo dalla riemissione della norma. Infine, non sono riuscito a capire a quale draft della seconda edizione faccia riferimento.
WD3 ISO/IEC 27002
La 27002 è invece al terzo draft.
Le cose non sono molto cambiate per i capitoli dal 5 al 9. Segnalo che è stato introdotto un controllo sui progetti e uno sull'inserimento di nuovo personale.
C'è invece molta manovra sui capitoli successivi. Quelli attuali presentano infatti molte ridondanze, disomogeneità di tecnicità (si va dai molto generici ai molto specifici) e non sempre sono al posto giusto (perché il mobile computing e il teleworking sono nel capitolo dedicato al "controllo accessi" e non alle "operations"?).
Una lettura del testo mi ha però fatto capire che ogni controllo del capitolo 10 non deve essere visto solo come collegato all'IT, ma anche a tutte le tipologie di "informazioni". Ho quindi chiesto di esplicitarlo meglio.
La situazione è al momento talmente "fluida" che non mi sembra il caso di fare ulteriori commenti.
Le cose non sono molto cambiate per i capitoli dal 5 al 9. Segnalo che è stato introdotto un controllo sui progetti e uno sull'inserimento di nuovo personale.
C'è invece molta manovra sui capitoli successivi. Quelli attuali presentano infatti molte ridondanze, disomogeneità di tecnicità (si va dai molto generici ai molto specifici) e non sempre sono al posto giusto (perché il mobile computing e il teleworking sono nel capitolo dedicato al "controllo accessi" e non alle "operations"?).
Una lettura del testo mi ha però fatto capire che ogni controllo del capitolo 10 non deve essere visto solo come collegato all'IT, ma anche a tutte le tipologie di "informazioni". Ho quindi chiesto di esplicitarlo meglio.
La situazione è al momento talmente "fluida" che non mi sembra il caso di fare ulteriori commenti.
WD4 ISO/IEC 27001
Siamo al quarto draft della 27001.
L'aspetto da notare è che ora è impostata secondo il modello "JTCG 8 Common Structure and Identical Text for management system standards". La 27001 sarà la prima norma ad adottare questo modello e le altre (9001, 14001, 20000) dovrebbero seguire.
La norma, di per se stessa, non cambia molto soprattutto per quanti ne hanno dato delle interpretazioni corrette da un punto di vista formale e sostanziale. Ne riparleremo le prossime volte, quando si sarà più stabilizzata.
In realtà, il nuovo modello introduce almeno tre aspetti che al momento mi lasciano perplesso. Non mi sono ancora imbattutto in disquisizioni in merito sulla rete per capirli fino in fondo, ma lascio qui un piccolo elenco:
1- viene introdotta la necessità di pianificare il sistema di gestione tenendo in conto, seppure in modo sfumato ma esplicito, i rischi di impresa; se questa non è una novità per la 27001, certamente lo è per altre norme; il problema è che li chiama "issues" e questo potrà creare qualche confusione in chi si occuppa di "risks"
2- non ci sono più "procedure documentate" e "registrazioni", ma "documented information"; questo genera dei giri di parole non sempre semplici da assimilare
3- la richiesta di procedure documentate e registrazioni (quindi, di informazioni documentate) obbligatorie si è di molto ridotta, lasciando ulteriore margine all'utilizzatore; questo potrebbe creare qualche difficoltà per gli auditor che potrebbero trovarsi con sempre meno punti di appoggio per "capire" cosa auditare
Ripeto: non ho ancora valutato fino in fondo questi aspetti e mi riserverò di farlo dopo il prossimo draft.
L'aspetto da notare è che ora è impostata secondo il modello "JTCG 8 Common Structure and Identical Text for management system standards". La 27001 sarà la prima norma ad adottare questo modello e le altre (9001, 14001, 20000) dovrebbero seguire.
La norma, di per se stessa, non cambia molto soprattutto per quanti ne hanno dato delle interpretazioni corrette da un punto di vista formale e sostanziale. Ne riparleremo le prossime volte, quando si sarà più stabilizzata.
In realtà, il nuovo modello introduce almeno tre aspetti che al momento mi lasciano perplesso. Non mi sono ancora imbattutto in disquisizioni in merito sulla rete per capirli fino in fondo, ma lascio qui un piccolo elenco:
1- viene introdotta la necessità di pianificare il sistema di gestione tenendo in conto, seppure in modo sfumato ma esplicito, i rischi di impresa; se questa non è una novità per la 27001, certamente lo è per altre norme; il problema è che li chiama "issues" e questo potrà creare qualche confusione in chi si occuppa di "risks"
2- non ci sono più "procedure documentate" e "registrazioni", ma "documented information"; questo genera dei giri di parole non sempre semplici da assimilare
3- la richiesta di procedure documentate e registrazioni (quindi, di informazioni documentate) obbligatorie si è di molto ridotta, lasciando ulteriore margine all'utilizzatore; questo potrebbe creare qualche difficoltà per gli auditor che potrebbero trovarsi con sempre meno punti di appoggio per "capire" cosa auditare
Ripeto: non ho ancora valutato fino in fondo questi aspetti e mi riserverò di farlo dopo il prossimo draft.
sabato 18 dicembre 2010
FDIS ISO/IEC 20000-1
La ISO/IEC 20000-1 è ora allo stadio di FDIS. Questo non vuol dire che sarà approvata, ma a questo punto è molto probabile che nel 2011 sarà emessa la nuova versione della norma.
La nuova versione è molto meglio scritta della precedente, anche se si notano ancora alcune inesattezze e imprecisioni deprecabili quando si tratta di uno standard internazionale. Sembra quasi che troppi standardizzatori improvvisati siano all'opera.
A parte ciò, i requisiti, in definitiva, sono molto simili agli attuali (ho fatto una verifica veloce) e soprattutto la parte di "New or changed services" ha ora un senso. Inoltre, molti requisiti sono simili all'attuale ISO 9001 di modo che anni di sviluppo non sono andati dimenticati ;-)
Mi ha molto interessato il lavoro fatto sul miglioramento continuo, ora esplicitamente non collegato alle sole azioni correttive e preventive.
Rimane infine un dubbio: perché continuare a chiamare "Known errors" gli incidenti di cui è nota la causa, quando nella realtà (e in modo a mio parere più significativo) si usa questo termine per gli incidenti di cui è noto uno o più workarounds?
La nuova versione è molto meglio scritta della precedente, anche se si notano ancora alcune inesattezze e imprecisioni deprecabili quando si tratta di uno standard internazionale. Sembra quasi che troppi standardizzatori improvvisati siano all'opera.
A parte ciò, i requisiti, in definitiva, sono molto simili agli attuali (ho fatto una verifica veloce) e soprattutto la parte di "New or changed services" ha ora un senso. Inoltre, molti requisiti sono simili all'attuale ISO 9001 di modo che anni di sviluppo non sono andati dimenticati ;-)
Mi ha molto interessato il lavoro fatto sul miglioramento continuo, ora esplicitamente non collegato alle sole azioni correttive e preventive.
Rimane infine un dubbio: perché continuare a chiamare "Known errors" gli incidenti di cui è nota la causa, quando nella realtà (e in modo a mio parere più significativo) si usa questo termine per gli incidenti di cui è noto uno o più workarounds?
Utente "sconosciuto" su HP MSA2000 G3
Dal SANS Newsbyte, giro la notizia "sulle macchine HP StorageWorks MSA G3 P2000, è presente un utente non rilevabile attraverso i normali strumenti gestionali e con password standard"
La HP ha già pubblicato le specifiche per risolvere il problema.
http://isc.sans.edu/diary.html?storyid=10090
http://www.securityweek.com/backdoor-vulnerability-discovered-hp-msa2000-storage-systems
Come Stuxnet, anche questo caso sottolinea come i concetti base della sicurezza IT siano sconosciuti ai più.
La HP ha già pubblicato le specifiche per risolvere il problema.
http://isc.sans.edu/diary.html?storyid=10090
http://www.securityweek.com/backdoor-vulnerability-discovered-hp-msa2000-storage-systems
Come Stuxnet, anche questo caso sottolinea come i concetti base della sicurezza IT siano sconosciuti ai più.
Wikileaks
Credo che la faccenda Wikileaks sia stata sufficientemente coperta da diversi media e commentatori. Quindi non ritengo di doverne discutere molto.
Si potrebbero anche fare delle riflessioni su "come si diffondono le notizie", vere o false che siano. Ma su questo, credo che Quarto Potere di Orson Welles e l'ultimo libro di Eco siano sufficientemente illuminanti.
Rimane il problema della sicurezza. Visto che nessun uomo è un'isola, è necessario dare un certo livello di fiducia a amici, clienti, collaboratori e fornitori. In altre parole, è necessario dare loro un tot di informazioni.
Sono dei rischi che corriamo, a fronte di innegabili benefici (umani, sociali, economici, professionali).
Possiamo (e dobbiamo!) realizzare tutte le misure tecniche o organizzative che vogliamo (dal SANS Newsbyte, la reazione dei militari USA http://www.wired.com/dangerroom/2010/12/military-bans-disks-threatens-courts-martials-to-stop-new-leaks/), possiamo monitorare il personale (qualcuno, in barba allo Statuto dei Lavoratori ha anche proposto la macchina della verità!), possiamo limitare il più possibile l'accesso di ciascuno alle informazioni, ma avversari, delusi e ricattabili ci saranno sempre.
In conclusione: cogliere il segnale è un bene, ma ricordarsi sempre che la sicurezza al 100% non è raggiungibile e che la parola chiave è "bilanciamento" (tra i rischi, le esigenze efficienza e il budget).
Rimane la massima applicabile a tanti contesti: "se non vuoi che non sia pubblicato, non scriverlo, non dirlo, non fotografarlo".
A fronte di una serie di commenti inutili, ridondanti o addirittura sciocchi, mi permetto di suggerirne uno buono di Andrea Monti, dove viene anche ricordato il caso del dossier Mitrokin: http://www.ictlex.net/?p=1211
PS: qualche tempo fa, mi è capitato di vedere una mail di risposta ad un creditore. Il debitore accampava delle belle scuse per ritardare il pagamento o, addirittura, per non farlo. Peccato che si fosse dimenticato di cancellare dalla mail tutta la propria corrispondenza interna, da cui si capiva chiaramente che le scuse erano costruite ad arte.
Questo per dire: il caso Wikileaks è solo un segnale pubblico di cose che accadono quotidianamente e non diffuse.
PS2: mi è tornato in mente un progetto in cui il cliente, per necessità di riservatezza, non mi voleva dare accesso ad una serie di documenti. Gli ho fatto notare che senza documenti non avrei potuto fare nulla.
Questo per dire: anche la paranoia non porta da nessuna parte
PS3: Hervé Schauer, nella sua newsletter, premette un editoriale molto più corto di questo (e senza Post scriptum...) segnalando solo che la vicenda ci ricorda due vulnerabilità da tenere in conto: 1) le chiavi USB permettono di trasmettere più informazioni della rete IT; 2) le persone nate nell'era dell'informatica distinguono sempre meno tra vita professionale e vita privata.
Si potrebbero anche fare delle riflessioni su "come si diffondono le notizie", vere o false che siano. Ma su questo, credo che Quarto Potere di Orson Welles e l'ultimo libro di Eco siano sufficientemente illuminanti.
Rimane il problema della sicurezza. Visto che nessun uomo è un'isola, è necessario dare un certo livello di fiducia a amici, clienti, collaboratori e fornitori. In altre parole, è necessario dare loro un tot di informazioni.
Sono dei rischi che corriamo, a fronte di innegabili benefici (umani, sociali, economici, professionali).
Possiamo (e dobbiamo!) realizzare tutte le misure tecniche o organizzative che vogliamo (dal SANS Newsbyte, la reazione dei militari USA http://www.wired.com/dangerroom/2010/12/military-bans-disks-threatens-courts-martials-to-stop-new-leaks/), possiamo monitorare il personale (qualcuno, in barba allo Statuto dei Lavoratori ha anche proposto la macchina della verità!), possiamo limitare il più possibile l'accesso di ciascuno alle informazioni, ma avversari, delusi e ricattabili ci saranno sempre.
In conclusione: cogliere il segnale è un bene, ma ricordarsi sempre che la sicurezza al 100% non è raggiungibile e che la parola chiave è "bilanciamento" (tra i rischi, le esigenze efficienza e il budget).
Rimane la massima applicabile a tanti contesti: "se non vuoi che non sia pubblicato, non scriverlo, non dirlo, non fotografarlo".
A fronte di una serie di commenti inutili, ridondanti o addirittura sciocchi, mi permetto di suggerirne uno buono di Andrea Monti, dove viene anche ricordato il caso del dossier Mitrokin: http://www.ictlex.net/?p=1211
PS: qualche tempo fa, mi è capitato di vedere una mail di risposta ad un creditore. Il debitore accampava delle belle scuse per ritardare il pagamento o, addirittura, per non farlo. Peccato che si fosse dimenticato di cancellare dalla mail tutta la propria corrispondenza interna, da cui si capiva chiaramente che le scuse erano costruite ad arte.
Questo per dire: il caso Wikileaks è solo un segnale pubblico di cose che accadono quotidianamente e non diffuse.
PS2: mi è tornato in mente un progetto in cui il cliente, per necessità di riservatezza, non mi voleva dare accesso ad una serie di documenti. Gli ho fatto notare che senza documenti non avrei potuto fare nulla.
Questo per dire: anche la paranoia non porta da nessuna parte
PS3: Hervé Schauer, nella sua newsletter, premette un editoriale molto più corto di questo (e senza Post scriptum...) segnalando solo che la vicenda ci ricorda due vulnerabilità da tenere in conto: 1) le chiavi USB permettono di trasmettere più informazioni della rete IT; 2) le persone nate nell'era dell'informatica distinguono sempre meno tra vita professionale e vita privata.
Velocità di trasmissione
Andrea Rui (Tecnoindex S.p.A.) mi ha segnalato questa divertente notizia:
per inviare un messaggio nella zona di Durban (Sudafrica) è più veloce il
piccione dell'Adsl.
http://www.tgcom.mediaset.it/mondo/articoli/articolo459872.shtml
per inviare un messaggio nella zona di Durban (Sudafrica) è più veloce il
piccione dell'Adsl.
http://www.tgcom.mediaset.it/mondo/articoli/articolo459872.shtml
giovedì 16 dicembre 2010
Club di Cyberspazio e Diritto
E' stato attivato il forum di discussione "Club di Ciberspazio e Diritto", come mi è stato segnalato da Giovanni Ziccardi.
Al momento ci sono 5 segnalazioni molto interessanti per chi vuole capire di più la materia.https://groups.google.com/group/ciberspazioediritto/topics?hl=it
Ho trovato particolarmente interessante il riferimento ad un articolo in cui sono stati analizzati (e criticati) più di 400 casi nei quali sentenze statunitensi hanno citato Wikipedia.
http://www.yjolt.org/files/peoples-12-YJOLT-1.pdf
Al momento ci sono 5 segnalazioni molto interessanti per chi vuole capire di più la materia.https://groups.google.com/group/ciberspazioediritto/topics?hl=it
Ho trovato particolarmente interessante il riferimento ad un articolo in cui sono stati analizzati (e criticati) più di 400 casi nei quali sentenze statunitensi hanno citato Wikipedia.
http://www.yjolt.org/files/peoples-12-YJOLT-1.pdf
martedì 14 dicembre 2010
Privacy: modificato il Codice per i funzionari pubblici
Dalla newsletter della DFA (www.perfezionisti.it) giro la notizia della modifica al Dlgs 196/2003 relativa agli "addetti ad una funzione pubblica".
In particolare sono stati modificati l'articolo 1 e 19.
La versione consolidata del Dlgs si trova suhttp://www.garanteprivacy.it/garante/doc.jsp?ID=1311248
In particolare sono stati modificati l'articolo 1 e 19.
La versione consolidata del Dlgs si trova suhttp://www.garanteprivacy.it/garante/doc.jsp?ID=1311248
Abolizione Decreto Pisanu sulle wi-fi libere
Dalla newsletter della DFA (perfezionisti.it) riprendo la notizia dell'approvazione del Pacchetto Sicurezza da parte del Consiglio dei Ministri, che prevede il non rinnovo del Decreto Pisanu.
Il Decreto Pisanu, lo ricordo, imponeva diverse limitazioni alle connessioni su Internet, imponendo la rintracciabilità dell'utente. In modo molto semplicistico, si può quindi dire che ora i bar potranno offrire la connessione wi-fi gratuita.
L'articolo di riferimento: http://www.zeusnews.com/index.php3?ar=stampa&cod=13408
Luca De Grazia, nel suo blog, esprime un parere non allineato con quello più diffuso (tanto per intenderci: quasi tutti vogliono "la wi-fi libera") e per questo vale la pena di analizzarlo: http://lucadegrazia.postilla.it/2010/11/18/sprint-finale-per-il-wi-fi-libero-in-italia/
Io continuo a pensare che stiamo dibattendo senza dati: è servito a qualcosa il Decreto Pisanu o no? Finora, ancora nessuno mi ha risposto e quindi non mi pronuncio. Egoisticamente, lo ammetto, accetterò la comodità di potermi connettere alle wi-fi libere con gioia.
Aggiornamento del marzo 2011: http://blog.cesaregallotti.it/2011/03/abolizione-decreto-pisanu-sulle-wi-fi.html
Il Decreto Pisanu, lo ricordo, imponeva diverse limitazioni alle connessioni su Internet, imponendo la rintracciabilità dell'utente. In modo molto semplicistico, si può quindi dire che ora i bar potranno offrire la connessione wi-fi gratuita.
L'articolo di riferimento: http://www.zeusnews.com/index.php3?ar=stampa&cod=13408
Luca De Grazia, nel suo blog, esprime un parere non allineato con quello più diffuso (tanto per intenderci: quasi tutti vogliono "la wi-fi libera") e per questo vale la pena di analizzarlo: http://lucadegrazia.postilla.it/2010/11/18/sprint-finale-per-il-wi-fi-libero-in-italia/
Io continuo a pensare che stiamo dibattendo senza dati: è servito a qualcosa il Decreto Pisanu o no? Finora, ancora nessuno mi ha risposto e quindi non mi pronuncio. Egoisticamente, lo ammetto, accetterò la comodità di potermi connettere alle wi-fi libere con gioia.
Aggiornamento del marzo 2011: http://blog.cesaregallotti.it/2011/03/abolizione-decreto-pisanu-sulle-wi-fi.html
sabato 11 dicembre 2010
Fascicolo Sanitario Elettronico
Segnalo l'interessante pagina sul Fascicolo Sanitario Elettronico (http://fse.clusit.it), da cui è possibile scaricare una breve analisi della normativa vigente e delle best practices applicabili. Sono inoltre disponibili le modalità per richiedere ulteriore materiale al gruppo di lavoro.
Decreto Legislativo 198 del 2010 sull'installazione di reti IT
Dal blog di Luca De Grazia (http://lucadegrazia.postilla.it/2010/11/29/installare-da-soli-un-router-o-una-chiavetta-umts-sara-illegale/) ho trovato la notizia che il 15 dicembre entrerà in vigore il Dlgs 198 del 2010 che manderà in pensione tra un anno la Legge 109 del 1990 e il DM 314 del 1992.
Il Dlgs: http://www.normattiva.it/dispatcher?service=213&fromurn=yes&datagu=2010-11-30&annoatto=2010&numeroatto=198&task=ricercaatti&elementiperpagina=50&redaz=010G0219&newsearch=1&classeprv=1&paginadamostrare=1&tmstp=1292571461591
La lettura del dispositivo non chiarisce le idee, così come non le chiarivano i precedenti. Ad una lettura "intransigente", sembrerebbe che tutte le reti (anche interne di una casa, ufficio o azienda)debbano essere installate, collaudate e manutenute solo ed esclusivamente da aziende inserite in un apposito registro.
Rimane il punto f) del comma 2 dell'articolo 2 che prevede che vengano stabilite delle semplificazioni (chissà...).
Un'interpretazione più condivisa, però, prevede che il Dlgs si rivolga ai soli installatori e agli operatori di TLC, regolandone l'accesso al mercato. A questo va però aggiunto il fatto che il rappresentante legale di un'azienda potrebbe incorrere in qualche sanzione relativa alla sicurezza dei lavoratori (Articolo 80 del Dlgs 81 del 2008) perché, se non dovesse chiamare un installatore qualificato, non potrebbe dimostrare che "le installazioni e gli impianti elettrici ed elettronici sono stati progettati, realizzati e costruiti a regola d'arte". Questo anche se si tratta di tirare un solo cavo di TLC sotto il pavimento flottante.
Concordo con Luca De Grazia dicendo che il Dlgs è scritto male e può essere fonte di confusione.
Ogni contributo in merito sarà gradito.
Il Dlgs: http://www.normattiva.it/dispatcher?service=213&fromurn=yes&datagu=2010-11-30&annoatto=2010&numeroatto=198&task=ricercaatti&elementiperpagina=50&redaz=010G0219&newsearch=1&classeprv=1&paginadamostrare=1&tmstp=1292571461591
La lettura del dispositivo non chiarisce le idee, così come non le chiarivano i precedenti. Ad una lettura "intransigente", sembrerebbe che tutte le reti (anche interne di una casa, ufficio o azienda)debbano essere installate, collaudate e manutenute solo ed esclusivamente da aziende inserite in un apposito registro.
Rimane il punto f) del comma 2 dell'articolo 2 che prevede che vengano stabilite delle semplificazioni (chissà...).
Un'interpretazione più condivisa, però, prevede che il Dlgs si rivolga ai soli installatori e agli operatori di TLC, regolandone l'accesso al mercato. A questo va però aggiunto il fatto che il rappresentante legale di un'azienda potrebbe incorrere in qualche sanzione relativa alla sicurezza dei lavoratori (Articolo 80 del Dlgs 81 del 2008) perché, se non dovesse chiamare un installatore qualificato, non potrebbe dimostrare che "le installazioni e gli impianti elettrici ed elettronici sono stati progettati, realizzati e costruiti a regola d'arte". Questo anche se si tratta di tirare un solo cavo di TLC sotto il pavimento flottante.
Concordo con Luca De Grazia dicendo che il Dlgs è scritto male e può essere fonte di confusione.
Ogni contributo in merito sarà gradito.
venerdì 10 dicembre 2010
BS 8878:2010 "Web accessibility. Code of practice"
Il BSI annuncia la pubblicazione della BS 8878 "Web accessibility. Code of practice".
Questo ci fa ricordare della necessità di pensare ad un tema apparentemente marginale: un sito "accessibile" non è solo necessario a chi è portatore di handicap, ma è anche più facilmente fruibile dai cosiddetti normodotati (alla fine degli anni '90, una delle richieste di accessibilità riguardava gli scivoli strada-marciapiede che ora si rilevano utili per tutti).
La pubblicazione dello standard inglese ricorda sì questi aspetti, ma costa 100 sterline (120 Euro) per 90 pagine. Per chi volesse approfondire la materia gratuitamente, un punto di accesso è la pagina della DigitPA (http://www.digitpa.gov.it/content/accessibilit%C3%A0) da cui accedere anche ad interessanti risorse on line.
Il CNIPA gestiva il sito http://www.pubbliaccesso.gov.it con una buona Biblioteca (link ad altre risorse), ha pubblicato nel lontano 2005 il quaderno 4 sull'accessibilità (http://www.cnipa.gov.it/site/it-IT/La_Documentazione/Pubblicazioni/Quaderni_dell'accessibilit%c3%a0/).
Un altro importante riferimento sono le "Linee guida per l'accessibilità ai contenuti del Web" del W3C, ora alla versione 2.0:http://www.w3.org/Translations/WCAG20-it/
Questo ci fa ricordare della necessità di pensare ad un tema apparentemente marginale: un sito "accessibile" non è solo necessario a chi è portatore di handicap, ma è anche più facilmente fruibile dai cosiddetti normodotati (alla fine degli anni '90, una delle richieste di accessibilità riguardava gli scivoli strada-marciapiede che ora si rilevano utili per tutti).
La pubblicazione dello standard inglese ricorda sì questi aspetti, ma costa 100 sterline (120 Euro) per 90 pagine. Per chi volesse approfondire la materia gratuitamente, un punto di accesso è la pagina della DigitPA (http://www.digitpa.gov.it/content/accessibilit%C3%A0) da cui accedere anche ad interessanti risorse on line.
Il CNIPA gestiva il sito http://www.pubbliaccesso.gov.it con una buona Biblioteca (link ad altre risorse), ha pubblicato nel lontano 2005 il quaderno 4 sull'accessibilità (http://www.cnipa.gov.it/site/it-IT/La_Documentazione/Pubblicazioni/Quaderni_dell'accessibilit%c3%a0/).
Un altro importante riferimento sono le "Linee guida per l'accessibilità ai contenuti del Web" del W3C, ora alla versione 2.0:http://www.w3.org/Translations/WCAG20-it/
Lasciatemi il mio PC!
Sulla newsetter della società Ready Informatica (temo si tratti di spam...), si trova un articolo dal titolo "Lasciatemi il mio PC!". In poche parole, l'articolo si pone la domanda "Come far fronte alla marea di dispositivi personali e non tradizionali sul lavoro?" e risponde proponendo la soluzione di Citrix.
Al di là dell'aspetto commerciale che non intendo approfondire anche perché non l'ho studiato né nello specifico, né in rapporto ad eventuali concorrenti, è opportuno riflettere sulla pertinenza della domanda: oggi si vedono innumerevoli dipendenti che usano smartphones e tablet personali (per non parlare del pc di casa) anche per accedere alla rete aziendale. Per non parlare poi dei fornitori che si collegano alla stessa rete con dei pc incontrollati.
Le risposte "semplici" sono facili: non permettere questo genere di comportamenti, non permettere l'accesso alla rete aziendale dall'esterno, dare l'accesso ai fornitori solo attraverso computer aziendali. Ma è vero che il mondo è ormai cambiato e sta cambiando sempre più e noi dobbiamo prenderne atto e cambiare le scelte di trattamento di questi rischi.
L'articolo:http://www.ready.it/lasciatemi_il_mio_pc.html
Al di là dell'aspetto commerciale che non intendo approfondire anche perché non l'ho studiato né nello specifico, né in rapporto ad eventuali concorrenti, è opportuno riflettere sulla pertinenza della domanda: oggi si vedono innumerevoli dipendenti che usano smartphones e tablet personali (per non parlare del pc di casa) anche per accedere alla rete aziendale. Per non parlare poi dei fornitori che si collegano alla stessa rete con dei pc incontrollati.
Le risposte "semplici" sono facili: non permettere questo genere di comportamenti, non permettere l'accesso alla rete aziendale dall'esterno, dare l'accesso ai fornitori solo attraverso computer aziendali. Ma è vero che il mondo è ormai cambiato e sta cambiando sempre più e noi dobbiamo prenderne atto e cambiare le scelte di trattamento di questi rischi.
L'articolo:http://www.ready.it/lasciatemi_il_mio_pc.html
"At your service", magazine di itSMF
Su ITSM News di novembre si trova la notizia sulla prima uscita del magazine dell'itSMF "At your Service", dedicato all'IT Service Management e a ITIL.
Particolarmente significativo è l'articolo di IT Skeptic, utile per capire come è evoluto ITIL nel passato e come probabilmente evolverà.
Purtroppo, il sito ufficiale dell'itSMF non dà grande risalto al magazine, né dà informazioni sulle prossime uscite (quando saranno e come esserne aggiornati).
http://www.itsmfi.org/content/new-itsmf-international-magazine-your-service-launched
Particolarmente significativo è l'articolo di IT Skeptic, utile per capire come è evoluto ITIL nel passato e come probabilmente evolverà.
Purtroppo, il sito ufficiale dell'itSMF non dà grande risalto al magazine, né dà informazioni sulle prossime uscite (quando saranno e come esserne aggiornati).
http://www.itsmfi.org/content/new-itsmf-international-magazine-your-service-launched
mercoledì 1 dicembre 2010
Val IT 2.0 in italiano
L'AIEA ha pubblicato la traduzione in italiano di Val IT 2.0 ed è scaricabile dall'area download di www.aiea.it.
Il framework estende i concetti di quello che in ITIL è il processo di Service Portfolio. E' un'ottima lettura.
Per i più pigri, spaventati dalle 128 pagine, suggerisco di leggere almeno fino a pagina 19, dove si trovano due perle:
1- "I programmi sono selezionati sulla base non solo della desiderabilità ma anche sulla capacità dell'organizzazione di portarli a termine".
2- "La presenza di metodologie in azienda è meno importante del loro effettivo utilizzo da parte dei business managers".
A pagina 20 si trova la figura 9, con illustrati i domini del Val IT e i corrispondenti processi. Il primo processo "Istituire una leadership informata e responsabilizzata" potrebbe dare materia di riflessione.
Il framework estende i concetti di quello che in ITIL è il processo di Service Portfolio. E' un'ottima lettura.
Per i più pigri, spaventati dalle 128 pagine, suggerisco di leggere almeno fino a pagina 19, dove si trovano due perle:
1- "I programmi sono selezionati sulla base non solo della desiderabilità ma anche sulla capacità dell'organizzazione di portarli a termine".
2- "La presenza di metodologie in azienda è meno importante del loro effettivo utilizzo da parte dei business managers".
A pagina 20 si trova la figura 9, con illustrati i domini del Val IT e i corrispondenti processi. Il primo processo "Istituire una leadership informata e responsabilizzata" potrebbe dare materia di riflessione.
venerdì 26 novembre 2010
FDIS ISO/IEC 27031
La ISO/IEC 27031 "Guidelines for information and communication technology
readiness for business continuity" è ora allo stadio di final draft.
Si tratta di linee guida (quindi non "certificabili") che riprendono i
concetti espressi dalla BS 25777 sulla relazione tra IT e Business
Continuity.
Alcune cose interessanti:
- viene detto che bisogna segnalare quando i sistemi IT non possono
soddisfare i requisiti di business in materia di tempi e metodi di
ripristino, in modo da valutare se accettare la situazione attuale o
intraprendere opportune azioni; troppo spesso si vede come il business
stabilisca invece i propri obiettivi sulla base delle prestazioni dell'IT e
come non siano evidenziati eventuali disallineamenti affinché siano
consapevolmente accettati
- sono ben descritte le varie tipologie di test praticabili
- vi sono utili esempi di misurazioni quantitative (ve ne sono anche sulle
misurazioni qualitative che non mi convincono)
Punto debole è l'eccessiva considerazione degli RTO a scapito di altri
requisiti come gli RPO e altri controlli di sicurezza, oltre all'assenza del
parametro relativo alle prestazioni (spesso ridotte rispetto a quelle normali)
previste in caso di emergenza.
Alessandro Cerasoli (NIS - Network Integration and Solutions), durante le discussioni in seno all'Uninfo, ha fatto anche notare la mancanza del concetto di MTPoD (Maximum Tolerable Period of Distruption), ossia il limite massimo degli RTOs.
Aggiornamento del 23 marzo 2011:
http://blog.cesaregallotti.it/2011/03/isoiec-27031-e-bs-25777.html
readiness for business continuity" è ora allo stadio di final draft.
Si tratta di linee guida (quindi non "certificabili") che riprendono i
concetti espressi dalla BS 25777 sulla relazione tra IT e Business
Continuity.
Alcune cose interessanti:
- viene detto che bisogna segnalare quando i sistemi IT non possono
soddisfare i requisiti di business in materia di tempi e metodi di
ripristino, in modo da valutare se accettare la situazione attuale o
intraprendere opportune azioni; troppo spesso si vede come il business
stabilisca invece i propri obiettivi sulla base delle prestazioni dell'IT e
come non siano evidenziati eventuali disallineamenti affinché siano
consapevolmente accettati
- sono ben descritte le varie tipologie di test praticabili
- vi sono utili esempi di misurazioni quantitative (ve ne sono anche sulle
misurazioni qualitative che non mi convincono)
Punto debole è l'eccessiva considerazione degli RTO a scapito di altri
requisiti come gli RPO e altri controlli di sicurezza, oltre all'assenza del
parametro relativo alle prestazioni (spesso ridotte rispetto a quelle normali)
previste in caso di emergenza.
Alessandro Cerasoli (NIS - Network Integration and Solutions), durante le discussioni in seno all'Uninfo, ha fatto anche notare la mancanza del concetto di MTPoD (Maximum Tolerable Period of Distruption), ossia il limite massimo degli RTOs.
Aggiornamento del 23 marzo 2011:
http://blog.cesaregallotti.it/2011/03/isoiec-27031-e-bs-25777.html
giovedì 18 novembre 2010
Corso di Perfezionamento forensics a Milano
Sono state avviate le iscrizioni per il Corso di Perfezionamento in
"Computer forensics e investigazioni digitali" dell'Università di Milano.
Il corso è costituito da cinque giornate formative, al giovedì, dal 27
gennaio al 24 febbraio 2011.
Per info: http://forensics.typepad.com/ e infogiuremi@gmail.com
Mi permetto di segnalare l'evento perché io ho partecipato come studente
alla seconda edizione e l'ho trovata molto interessante.
Purtroppo penso che questa segnalazione vi arrivi in ritardo (il termine per
le iscrizioni è il 9.12).
Ad ogni modo, il 20 gennaio ci sarà la "Lezione zero" aperta, anche se
consiglio di informarsi presso l'associazione Digital Forensics Alumni
info@perfezionisti.it.
"Computer forensics e investigazioni digitali" dell'Università di Milano.
Il corso è costituito da cinque giornate formative, al giovedì, dal 27
gennaio al 24 febbraio 2011.
Per info: http://forensics.typepad.com/ e infogiuremi@gmail.com
Mi permetto di segnalare l'evento perché io ho partecipato come studente
alla seconda edizione e l'ho trovata molto interessante.
Purtroppo penso che questa segnalazione vi arrivi in ritardo (il termine per
le iscrizioni è il 9.12).
Ad ogni modo, il 20 gennaio ci sarà la "Lezione zero" aperta, anche se
consiglio di informarsi presso l'associazione Digital Forensics Alumni
info@perfezionisti.it.
lunedì 15 novembre 2010
Prossimi interventi di Cesare Gallotti
Il 18 novembre, intervengo al convegno "Stanco di fare l'equilibrista -
Lasciatevi condurre sul cammino sicuro verso una corretta IT Governance"
organizzato da ECS (http://www.ecs-group.com/it/default.aspx) all'Hotel
Boscolo Exedra di Roma (ore 10.45 - 17.00)
Il mio intervento avrà il titolo "IT Governance: scelte e soluzioni".
Il 30 novembre interverrò ai GS Days di Parigi (http://www.club-27001.fr/)
su "Appréciation conjointe ISO 27001 et ISO 20000-1"
Lasciatevi condurre sul cammino sicuro verso una corretta IT Governance"
organizzato da ECS (http://www.ecs-group.com/it/default.aspx) all'Hotel
Boscolo Exedra di Roma (ore 10.45 - 17.00)
Il mio intervento avrà il titolo "IT Governance: scelte e soluzioni".
Il 30 novembre interverrò ai GS Days di Parigi (http://www.club-27001.fr/)
su "Appréciation conjointe ISO 27001 et ISO 20000-1"
Stuxnet
In questi giorni si parla molto del work Stuxnet, che attacca le PLC, ossia
gli strumenti di controllo elettronici degli impianti.
L'articolo più approfondito è quello di Bruce Schneier:
http://www.schneier.com/blog/archives/2010/10/stuxnet.html
Accanto alle sue riflessioni, ne aggiungo due mie:
- viste le sue modalità di propagazione, è opportuno ricordare la misura che
prevede di isolare certi sistemi critici dal resto della rete
- sembra che sfrutti le password di admin di alcune PLC della Siemens e che
queste non possano essere modificate, contrariamente a tutte le regole di
buona sicurezza (i signori della Siemens sono in nutrita compagnia di altri
prodotti, utilizzati in contesti assai critici, che possono girare solo con
l'utenza di admin e non consentono agli Amministratori di Sistema di
accedere con altre utenze)
gli strumenti di controllo elettronici degli impianti.
L'articolo più approfondito è quello di Bruce Schneier:
http://www.schneier.com/blog/archives/2010/10/stuxnet.html
Accanto alle sue riflessioni, ne aggiungo due mie:
- viste le sue modalità di propagazione, è opportuno ricordare la misura che
prevede di isolare certi sistemi critici dal resto della rete
- sembra che sfrutti le password di admin di alcune PLC della Siemens e che
queste non possano essere modificate, contrariamente a tutte le regole di
buona sicurezza (i signori della Siemens sono in nutrita compagnia di altri
prodotti, utilizzati in contesti assai critici, che possono girare solo con
l'utenza di admin e non consentono agli Amministratori di Sistema di
accedere con altre utenze)
Verifica sull'operato degli Amministratori di Sistema (Rev1)
Con Vito Losacco di Engineering, abbiamo elaborato una proposta di check
list per la verifica dell'operato degli AdS secondo quanto richiesto dal
Provvedimento del Garante.
Ogni proposta di miglioramento sarà la benvenuta.
http://www.cesaregallotti.it/art_pres/20100920-Checklist-AdS.pdf
list per la verifica dell'operato degli AdS secondo quanto richiesto dal
Provvedimento del Garante.
Ogni proposta di miglioramento sarà la benvenuta.
http://www.cesaregallotti.it/art_pres/20100920-Checklist-AdS.pdf
Sicurezza delle applicazioni (REV. 1)
[Ripubblico l'articolo già uscito in novembre sulla sicurezza a livello
applicativo, grazie anche ai suggerimenti di Fabrizio Monteleone del DNV
Italia]
Quasi sempre è difficile trovare correttamente documentati i requisiti di
sicurezza delle applicazioni. Anche senza voler imporre un modello
waterfall, i troppi esempi di incidenti collegabili allo sviluppo non ben
controllato suggeriscono di documentarli in maniera coerente. Ho riscontrato
spesso la scarsità di idee su "quali requisiti considerare".
Alcuni standard (come la ISO/IEC 15408 "Common Criteria") presentano
metodologie e specifiche molto dettagliate. La ISO/IEC 15408 è una norma
divisa in 3 parti per un totale di circa 650 pagine. Sicuramente, in molte
situazioni è troppo onerosa.
La metodologia OWASP (http://www.owasp.org/) è invece orientata alle applicazioni e
ai servizi web. E' comunque consigliabile la sua lettura anche a chi si
occupa di altre tipologie di applicazioni.
Si propone qui di seguito un ulteriore ma breve elenco di requisiti da
consierare, basati sui punti dell'allegato A della ISO/IEC 27001:
- i requisiti legali applicabili
- le necessità di capacity a livello tecnologico: potenza, spazio disco e
banda di rete dedotte dal numero di utenti previsti e dalla mole di dati che
saranno coinvolti dalla loro operatività)
- le necessità di disponibilità dell'applicazione, anche in modo da disporre
delle risorse necessarie al momento del go live
- i meccanismi crittografici (inclusa la loro configurazione) da prevedere
per la connessione degli utenti e degli amministratori di sistema
- le connessioni con altre applicazioni in modo da prevedere gli opportuni
meccanismi di comunicazione sicura
- i meccanismi di identificazione e autenticazione per utenti e
amministratori (userid e password? con quali regole di complessità,
scadenza, modalità di modifica da parte degli utenti, ripristino, eccetera?)
- i meccanismi di autorizzazione per gli accessi ai dati (controllo accessi,
gestione dei ruoli e profili utente)
- i meccanismi di log (login, logout, azioni degli utenti)
- le modalità di validazione degli input (controllo dei campi di input),
degli output (messa a disposizione delle opportune query) e della loro
corretta elaborazione (con quadrature o report periodici)
- il processo di gestione del patching
- gli impatti sui sistemi di backup e sul Business Continuity Management
(impatti sui sistemi del sito di Disaster Recovery e sulle procedure di
gestione degli incidenti) in modo da aggiornarli opportunamente
- gli impatti sul service desk, in modo da aggiornare gli operatori e i loro
strumenti
- gli impatti sulla configurazione dei firewall
- gli impatti sui sistemi di monitoraggio e discovery, anche per
riconfigurarli opportunamente
- il ruolo dei fornitori, in modo da controllarli in modo adeguato
Accanto a questi requisiti più tecnici, è opportuno riflettere sulle
modalità di controllo dello sviluppo. Tra queste:
- "normali" procedure di project management: modalità di comunicazione tra
le parti interessate, pianificazione, attribuzione responsabilità per i
diversi deliverable, tempistiche per lo sviluppo e per il testing, verifiche
e riesami periodici, ...
- regole di codifica sicura (basate sulle best practices esistenti)
- regole per il debugging
- modalità di separazione delle funzioni tra i soggetti che analizzano,
progettano, codificano, testano, portano in esercizio...
applicativo, grazie anche ai suggerimenti di Fabrizio Monteleone del DNV
Italia]
Quasi sempre è difficile trovare correttamente documentati i requisiti di
sicurezza delle applicazioni. Anche senza voler imporre un modello
waterfall, i troppi esempi di incidenti collegabili allo sviluppo non ben
controllato suggeriscono di documentarli in maniera coerente. Ho riscontrato
spesso la scarsità di idee su "quali requisiti considerare".
Alcuni standard (come la ISO/IEC 15408 "Common Criteria") presentano
metodologie e specifiche molto dettagliate. La ISO/IEC 15408 è una norma
divisa in 3 parti per un totale di circa 650 pagine. Sicuramente, in molte
situazioni è troppo onerosa.
La metodologia OWASP (http://www.owasp.org/) è invece orientata alle applicazioni e
ai servizi web. E' comunque consigliabile la sua lettura anche a chi si
occupa di altre tipologie di applicazioni.
Si propone qui di seguito un ulteriore ma breve elenco di requisiti da
consierare, basati sui punti dell'allegato A della ISO/IEC 27001:
- i requisiti legali applicabili
- le necessità di capacity a livello tecnologico: potenza, spazio disco e
banda di rete dedotte dal numero di utenti previsti e dalla mole di dati che
saranno coinvolti dalla loro operatività)
- le necessità di disponibilità dell'applicazione, anche in modo da disporre
delle risorse necessarie al momento del go live
- i meccanismi crittografici (inclusa la loro configurazione) da prevedere
per la connessione degli utenti e degli amministratori di sistema
- le connessioni con altre applicazioni in modo da prevedere gli opportuni
meccanismi di comunicazione sicura
- i meccanismi di identificazione e autenticazione per utenti e
amministratori (userid e password? con quali regole di complessità,
scadenza, modalità di modifica da parte degli utenti, ripristino, eccetera?)
- i meccanismi di autorizzazione per gli accessi ai dati (controllo accessi,
gestione dei ruoli e profili utente)
- i meccanismi di log (login, logout, azioni degli utenti)
- le modalità di validazione degli input (controllo dei campi di input),
degli output (messa a disposizione delle opportune query) e della loro
corretta elaborazione (con quadrature o report periodici)
- il processo di gestione del patching
- gli impatti sui sistemi di backup e sul Business Continuity Management
(impatti sui sistemi del sito di Disaster Recovery e sulle procedure di
gestione degli incidenti) in modo da aggiornarli opportunamente
- gli impatti sul service desk, in modo da aggiornare gli operatori e i loro
strumenti
- gli impatti sulla configurazione dei firewall
- gli impatti sui sistemi di monitoraggio e discovery, anche per
riconfigurarli opportunamente
- il ruolo dei fornitori, in modo da controllarli in modo adeguato
Accanto a questi requisiti più tecnici, è opportuno riflettere sulle
modalità di controllo dello sviluppo. Tra queste:
- "normali" procedure di project management: modalità di comunicazione tra
le parti interessate, pianificazione, attribuzione responsabilità per i
diversi deliverable, tempistiche per lo sviluppo e per il testing, verifiche
e riesami periodici, ...
- regole di codifica sicura (basate sulle best practices esistenti)
- regole per il debugging
- modalità di separazione delle funzioni tra i soggetti che analizzano,
progettano, codificano, testano, portano in esercizio...
Cloud computing
Franco Ferrari (DNV Italia) segnala le pubblicazioni del Cloud Security
Alliance, scaricabili da http://www.cloudsecurityalliance.org/Research.html.
Il punto di partenza è la versione 2.1 del "Security Guidance for Critical
Areas of Focus in Cloud Computing".
Inoltre, ricorda la pubblicazione dell'ENISA "Cloud Computing - Benefits,
risks and recommendations for information security" scaricabile da
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-as
sessment
Alliance, scaricabili da http://www.cloudsecurityalliance.org/Research.html.
Il punto di partenza è la versione 2.1 del "Security Guidance for Critical
Areas of Focus in Cloud Computing".
Inoltre, ricorda la pubblicazione dell'ENISA "Cloud Computing - Benefits,
risks and recommendations for information security" scaricabile da
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-risk-as
sessment
I benefici dell'IT Auditing
Simone Tomirotti mi segnala questo articolo sui 5 benefici dell'IT Auditing.
http://www.freebie-articles.com/Art/67813/368/The-Top-Five-Benefits-of-IT-Au
diting.html
Simone commenta: "Non sono riuscito a capire chi sia questo fantomatico
"John Welsh" e non credo dica nulla di nuovo. Però, l'articolo è chiaro e ci permette di ricordare i nostri obiettivi.
In sintesi, i 5 maggiori benefici del lavoro degli IT Auditor sono:
1. Ridurre il rischio
2. Rafforzare i controlli (e migliorare la sicurezza)
3. Conformarsi alla normativa
4. Facilitare la comunicazione tra il business e l'IT
5. Migliorare l'IT Governance
Con un po' di spirito polemico ci si potrebbe chiedere: questi 5 benefici
interessano veramente le aziende?"
Io ho risposto dicendo che, durante gli audit, il pensiero dominante
dell'azienda è "speriamo che non ci rompano troppo le scatole". Quindi,
difficilmente avrà spazio per pensare ad altri benefini.
Simone quindi: "Vero; altre volte si prende l'audit come un esame ed alla
fine ci si aspetta - a prescindere da tutto - un bel voto. Si pensa: "con le
nostre forze/risorse abbiamo fatto tutto il possibile, dovete darci un voto
alto!". Dimenticando quali sono i veri obiettivi di un audit.
Spesso, sia nel tuo caso che nel mio, la colpa sta nel mezzo: chi è oggetto
dell'ispezione non ne sa gli obiettivi e chi fa l'auditor non ha tempo
(voglia?) di spiegarli."
Concludo dicendo che il mestiere dell'auditor può essere frustrante, ma va
fatto bene e ogni tanto dà buone soddisfazioni.
Altri commenti sono benvenuti.
http://www.freebie-articles.com/Art/67813/368/The-Top-Five-Benefits-of-IT-Au
diting.html
Simone commenta: "Non sono riuscito a capire chi sia questo fantomatico
"John Welsh" e non credo dica nulla di nuovo. Però, l'articolo è chiaro e ci permette di ricordare i nostri obiettivi.
In sintesi, i 5 maggiori benefici del lavoro degli IT Auditor sono:
1. Ridurre il rischio
2. Rafforzare i controlli (e migliorare la sicurezza)
3. Conformarsi alla normativa
4. Facilitare la comunicazione tra il business e l'IT
5. Migliorare l'IT Governance
Con un po' di spirito polemico ci si potrebbe chiedere: questi 5 benefici
interessano veramente le aziende?"
Io ho risposto dicendo che, durante gli audit, il pensiero dominante
dell'azienda è "speriamo che non ci rompano troppo le scatole". Quindi,
difficilmente avrà spazio per pensare ad altri benefini.
Simone quindi: "Vero; altre volte si prende l'audit come un esame ed alla
fine ci si aspetta - a prescindere da tutto - un bel voto. Si pensa: "con le
nostre forze/risorse abbiamo fatto tutto il possibile, dovete darci un voto
alto!". Dimenticando quali sono i veri obiettivi di un audit.
Spesso, sia nel tuo caso che nel mio, la colpa sta nel mezzo: chi è oggetto
dell'ispezione non ne sa gli obiettivi e chi fa l'auditor non ha tempo
(voglia?) di spiegarli."
Concludo dicendo che il mestiere dell'auditor può essere frustrante, ma va
fatto bene e ogni tanto dà buone soddisfazioni.
Altri commenti sono benvenuti.
giovedì 11 novembre 2010
Vulnerabilità delle applicazioni di ebanking per smart phones
Dal SANS NewsBites Vol. 12 Num. 89: "Alcuni ricercatori hanno trovato bachi
di sicurezza in 6 applicazioni di ebanking (sulle 7 analizzate) per Android
e iPhone; in particolare, hanno scoperto che i dati di accesso sono
conservati in chiaro".
http://www.wired.com/threatlevel/2010/11/bank-apps-for-phones/
http://www.informationweek.com/news/security/vulnerabilities/showArticle.jht
ml?articleID=228200291&cid=RSSfeed_IWK_News
Come sempre, si tratta di mancanza di una decorosa pianificazione dei
requisiti di sicurezza a livello applicativo. Possiamo pubblicare tutti gli
standard e le best practices che vogliamo, ma non serviranno a nulla, se il
90% dei project manager vedono la documentazione come "inutile sovraccarico
di lavoro".
di sicurezza in 6 applicazioni di ebanking (sulle 7 analizzate) per Android
e iPhone; in particolare, hanno scoperto che i dati di accesso sono
conservati in chiaro".
http://www.wired.com/threatlevel/2010/11/bank-apps-for-phones/
http://www.informationweek.com/news/security/vulnerabilities/showArticle.jht
ml?articleID=228200291&cid=RSSfeed_IWK_News
Come sempre, si tratta di mancanza di una decorosa pianificazione dei
requisiti di sicurezza a livello applicativo. Possiamo pubblicare tutti gli
standard e le best practices che vogliamo, ma non serviranno a nulla, se il
90% dei project manager vedono la documentazione come "inutile sovraccarico
di lavoro".
martedì 9 novembre 2010
Business Continuity - Norma AS-NZS-5050
Massimo Cottafavi (Spike Reply), dopo l'articolo del mese scorso sul BCM,
segnala il fatto che la norma AS-NZS-5050 è composta da più parti e che al
link http://www.calamityprevention.com/links/ sono liberamente scaricabili i
draft.
Anche il sito http://www.calamityprevention.com/, nel suo complesso, è
interessante.
segnala il fatto che la norma AS-NZS-5050 è composta da più parti e che al
link http://www.calamityprevention.com/links/ sono liberamente scaricabili i
draft.
Anche il sito http://www.calamityprevention.com/, nel suo complesso, è
interessante.
Quali manager per quale progetto?
Circola ancora la voce che "un buon manager può fare il buon manager in
qualunque realtà". Ho visto diversi manager all'opera e ho imparato che non
è vero, ma spesso incontro perplessità di fronte al mio convincimento.
Un manager, per quanto bravo, ha le proprie inclinazioni e le proprie
competenze, non applicabili ad ogni realtà. Perché ogni realtà si basa su
una cultura interna e agisce in un mercato con le sue precise particolarità,
non sempre assimilabili a quello di provenienza del manager (mi ricordo
sempre di alcuni dirigenti, provenienti dalla vendita di software, che
chiedevano quante licenze aveva venduto la business unit "consulenza").
In questo articolo, Gianfilippo Cuneo racconta le stesse cose, ma con note
tecniche preziose
http://www.fbritaly.it/articolo.php?aId=0000000043&n=Quali+manager+per+quale
+progetto%3F
Ringrazio Gianni Signa di Itnet per la segnalazione.
qualunque realtà". Ho visto diversi manager all'opera e ho imparato che non
è vero, ma spesso incontro perplessità di fronte al mio convincimento.
Un manager, per quanto bravo, ha le proprie inclinazioni e le proprie
competenze, non applicabili ad ogni realtà. Perché ogni realtà si basa su
una cultura interna e agisce in un mercato con le sue precise particolarità,
non sempre assimilabili a quello di provenienza del manager (mi ricordo
sempre di alcuni dirigenti, provenienti dalla vendita di software, che
chiedevano quante licenze aveva venduto la business unit "consulenza").
In questo articolo, Gianfilippo Cuneo racconta le stesse cose, ma con note
tecniche preziose
http://www.fbritaly.it/articolo.php?aId=0000000043&n=Quali+manager+per+quale
+progetto%3F
Ringrazio Gianni Signa di Itnet per la segnalazione.
Business Model for Information Security (BMIS)
Dalla newsletter dell'ISACA, segnalo la recente pubblicazione del "Business Model for Information Security (BMIS)". E' scaricabile gratuitamente da http://www.isaca.org/bmis.
Lo confesso: quando leggo un articolo sulla sicurezza e trovo la parola
"olistico" (o un suo derivato, o "a 360 gradi"), parto prevenuto. Sarà
perché sento gli stessi concetti da più di 10 anni, magari con altre parole,
e non mi trovo a mio agio con modelli sempre più complicati, apparentemente
"nuovi" che dicono sempre la stessa cosa: "la sicurezza non è solo
tecnologia, non è solo reazione agli incidenti, non è solo materia tattica o
operativa, richiede l'appoggio di tutta l'azienda e in particolare della
Direzione, deve fondarsi sulla cultura aziendale, eccetera". L'esperienza
conferma che questi concetti non sono però recepiti da tutti.
Questo BMIS non fa eccezione alla regola: usa diffusamente il termine
"olistico", presenta un modello abbastanza complicato, ricorda molti
principi noti da tempo come se fossero "nuovi". E' comunque scritto bene,
con buoni esempi e quindi forse utile a chi ha ancora dei dubbi sulla
materia.
Aggiungo un'ulteriore nota amena: spero che a breve questi documenti vengano
anche diffusi in formato epub e non solo in pdf, visto che gli e-reader si
stanno sempre più diffondendo e rendono la lettura agevole senza dover
stampare (però il pdf è difficilmente convertibile in epub).
Lo confesso: quando leggo un articolo sulla sicurezza e trovo la parola
"olistico" (o un suo derivato, o "a 360 gradi"), parto prevenuto. Sarà
perché sento gli stessi concetti da più di 10 anni, magari con altre parole,
e non mi trovo a mio agio con modelli sempre più complicati, apparentemente
"nuovi" che dicono sempre la stessa cosa: "la sicurezza non è solo
tecnologia, non è solo reazione agli incidenti, non è solo materia tattica o
operativa, richiede l'appoggio di tutta l'azienda e in particolare della
Direzione, deve fondarsi sulla cultura aziendale, eccetera". L'esperienza
conferma che questi concetti non sono però recepiti da tutti.
Questo BMIS non fa eccezione alla regola: usa diffusamente il termine
"olistico", presenta un modello abbastanza complicato, ricorda molti
principi noti da tempo come se fossero "nuovi". E' comunque scritto bene,
con buoni esempi e quindi forse utile a chi ha ancora dei dubbi sulla
materia.
Aggiungo un'ulteriore nota amena: spero che a breve questi documenti vengano
anche diffusi in formato epub e non solo in pdf, visto che gli e-reader si
stanno sempre più diffondendo e rendono la lettura agevole senza dover
stampare (però il pdf è difficilmente convertibile in epub).
venerdì 5 novembre 2010
Sicurezza: Il trasferimento dei rischi
La Newsletter del Clusit del 31 ottobre 2010 segnala un articolo di Riccardo
Salici sui rischi trasferibili al mercato assicurativo.
L'articolo presenta una premessa generale di 2 pagine, in cui sono
riepilogate le caratteristiche del mercato assicurativo collegato ai rischi
informatici. E' interessante rilevare come sia suggerita, come attività di
risk assessment, una "valutazione tecnico-assicurativa proveniente da un
settore che di eventi imponderabili se ne intende, al contrario di altri".
Certo mi fa riflettere come in tutti questi anni non abbia mai assistito a
presentazioni da parte delle assicurazioni per illustrare, anche brevemente,
i metodi utilizzati. Salici giustifica la cosa scrivendo: "In genere gli
assicuratori tengono riservati i loro calcoli e le stime dei rischi
residuali nei confronti dei clienti per evitare di passare per i "giona"
della situazione". Io rimango con il dubbio (sempre pronto ad essere
contraddetto) che questi attori non abbiano strumenti sufficientemente
maturi da essere esposti ed, eventualmente, criticati. Rimane il fatto che,
sicuramente, una valutazione tecnico-assicurativa svolta da persone con una
sensibilità diversa rispetto a consulenti, personale interno o tecnici
informatici, possa portare elementi utili alla valutazione del rischio e
alle conseguenti scelte di trattamento.
Al termine del documento, sono riportati i "Rischi tipicamente trasferiti al
mercato assicurativo". Qui l'elenco può confondere chi è attaccato alla
terminologia ISO/IEC 27000 perché confonde rischi, danni e minacce.
L'annuncio del Clusit termina con la seguente frase: "Inoltre, Riccardo ci
sta mettendo a disposizione una vasta panoramica di sinistri realmente
avvenuti e trattati dalle Assicurazioni. Non mancheremo di condividere
queste informazioni (ovviamente anonimizzate) con la nostra community".
In attesa di questo materiale, ci si può leggere l'articolo liberamente
disponibile su www.clusit.it/docs/rscalici_10-10-26.pdf.
PS: il 9 febbraio ho pubblicato la seconda parte di questo argomento: http://blog.cesaregallotti.it/2011/02/sicurezza-il-trasferimento-dei-rischi.html
Salici sui rischi trasferibili al mercato assicurativo.
L'articolo presenta una premessa generale di 2 pagine, in cui sono
riepilogate le caratteristiche del mercato assicurativo collegato ai rischi
informatici. E' interessante rilevare come sia suggerita, come attività di
risk assessment, una "valutazione tecnico-assicurativa proveniente da un
settore che di eventi imponderabili se ne intende, al contrario di altri".
Certo mi fa riflettere come in tutti questi anni non abbia mai assistito a
presentazioni da parte delle assicurazioni per illustrare, anche brevemente,
i metodi utilizzati. Salici giustifica la cosa scrivendo: "In genere gli
assicuratori tengono riservati i loro calcoli e le stime dei rischi
residuali nei confronti dei clienti per evitare di passare per i "giona"
della situazione". Io rimango con il dubbio (sempre pronto ad essere
contraddetto) che questi attori non abbiano strumenti sufficientemente
maturi da essere esposti ed, eventualmente, criticati. Rimane il fatto che,
sicuramente, una valutazione tecnico-assicurativa svolta da persone con una
sensibilità diversa rispetto a consulenti, personale interno o tecnici
informatici, possa portare elementi utili alla valutazione del rischio e
alle conseguenti scelte di trattamento.
Al termine del documento, sono riportati i "Rischi tipicamente trasferiti al
mercato assicurativo". Qui l'elenco può confondere chi è attaccato alla
terminologia ISO/IEC 27000 perché confonde rischi, danni e minacce.
L'annuncio del Clusit termina con la seguente frase: "Inoltre, Riccardo ci
sta mettendo a disposizione una vasta panoramica di sinistri realmente
avvenuti e trattati dalle Assicurazioni. Non mancheremo di condividere
queste informazioni (ovviamente anonimizzate) con la nostra community".
In attesa di questo materiale, ci si può leggere l'articolo liberamente
disponibile su www.clusit.it/docs/rscalici_10-10-26.pdf.
PS: il 9 febbraio ho pubblicato la seconda parte di questo argomento: http://blog.cesaregallotti.it/2011/02/sicurezza-il-trasferimento-dei-rischi.html
Risk Assessment: Mehari 2010
Dalla Newsletter del Clusit si apprende che è stata pubblicata la versione
2010 della metodologia Mehari. La precedente era del 2007.
Mehari è una metodologia "classica" di risk assessment e segue completamente
i passi previsti dalla teoria, espressa ufficialmente anche dalla ISO/IEC
27005.
La sua implementazione può risultare eccessivamente onerosa per motivi che
ho già espresso altrove.
D'altro canto, la metodologia è intesa come "operativa" e presenta delle
scelte ben precise e degli esempi rispetto al modello necessariamente
astratto delle norme ISO. Sono ben definite le vulnerabilità e cosa si
intende con questo termine, è proposto un elenco di circa 800 minacce di
dettaglio da affiancare alle 40 "generali", i controlli di sicurezza della
ISO/IEC 27002 sono rinominati "servizi di sicurezza" e riclassificati fino
ad arrivare al numero di circa 350 (la 27002 ne propone 133, variamente
aggregati), a loro volta ulteriormente dettagliati nelle tabelle di analisi
e ben spiegati in uno specifico documento.
Accanto a tutto ciò, è messo a disposizione un foglio di calcolo di
supporto.
La lettura è dunque interessante e istruttiva. Oltre ad essere gratuita.
Tutta la documentazione è disponibile in francese ed inglese su
https://www.clusif.asso.fr/fr/production/ouvrages/type.asp?id=METHODES.
L'introduzione alla metodologia, in italiano, è disponibile su
https://www.clusif.asso.fr/fr/production/ouvrages/pdf/MEHARI-2010-Introduzio
ne-Italiano.pdf
2010 della metodologia Mehari. La precedente era del 2007.
Mehari è una metodologia "classica" di risk assessment e segue completamente
i passi previsti dalla teoria, espressa ufficialmente anche dalla ISO/IEC
27005.
La sua implementazione può risultare eccessivamente onerosa per motivi che
ho già espresso altrove.
D'altro canto, la metodologia è intesa come "operativa" e presenta delle
scelte ben precise e degli esempi rispetto al modello necessariamente
astratto delle norme ISO. Sono ben definite le vulnerabilità e cosa si
intende con questo termine, è proposto un elenco di circa 800 minacce di
dettaglio da affiancare alle 40 "generali", i controlli di sicurezza della
ISO/IEC 27002 sono rinominati "servizi di sicurezza" e riclassificati fino
ad arrivare al numero di circa 350 (la 27002 ne propone 133, variamente
aggregati), a loro volta ulteriormente dettagliati nelle tabelle di analisi
e ben spiegati in uno specifico documento.
Accanto a tutto ciò, è messo a disposizione un foglio di calcolo di
supporto.
La lettura è dunque interessante e istruttiva. Oltre ad essere gratuita.
Tutta la documentazione è disponibile in francese ed inglese su
https://www.clusif.asso.fr/fr/production/ouvrages/type.asp?id=METHODES.
L'introduzione alla metodologia, in italiano, è disponibile su
https://www.clusif.asso.fr/fr/production/ouvrages/pdf/MEHARI-2010-Introduzio
ne-Italiano.pdf
sabato 16 ottobre 2010
Novità standard famiglia ISO/IEC 27000
Da Fabio Guasconi, Presidente Commissione SC27 di Uninfo.
Lunedì 11 novembre si è concluso il meeting del SC27 (comitato internazionale incaricato della revisione delle norme della famiglia ISO/IEC 27000) a Berlino.
In anteprima ed in estrema sintesi, i punti salienti emersi nel meeting:
Lunedì 11 novembre si è concluso il meeting del SC27 (comitato internazionale incaricato della revisione delle norme della famiglia ISO/IEC 27000) a Berlino.
In anteprima ed in estrema sintesi, i punti salienti emersi nel meeting:
- i commenti a 27001 e 27002 sono stati così numerosi che nessuno dei due gruppi è riuscito a visionarli tutti. Nel primo caso si è proceduto per priorità e nel secondo per ordine
- l'annex A della 27001 rimane al suo posto nonostante i continui tentativi di spostarlo
- la 27001 adotterà il nuovo formato del JTC per i sistemi di gestione (che poi diventerà comune a tutte gli standard ISO sui sistemi di gestione)
- ci sarà una nuova norma sul Cloud Computing
- avrà inizio la revisione della ISO/IEC 27006 (quella applicabile agli Organismi di Certificazione)
- la 27007 (sull'auditing degli ISMS) avanza a FCD
- la neo uscita IEC 62443 (SCADA) verrà revisionata per essere allineata con la 27001
- la revisione della 27005 (Linee guida per il risk assessment) per allinearne i termini alla 31000 è allo stato di FDIS (final draft, quasi la versione finale tranne errori editoriali)
- la 27016 sugli elementi economici della gestione della sicurezza è partita
Standardizzazione: Business Continuity
Dalla newsletter del Disaster Recovery Institute, segnalo l'articolo "The shifting sands of business continuity management".http://www.continuitycentral.com/feature0812.html
Questo articolo confronta le norme
- BS 25999 e NFPA 1600 (basate sul solo "ripristino del business"),
- SPC.1-2009 (che richiede anche di prevenire gli incidenti e di mitigarne gli effetti)
- la nuova AS/NZS 5050:2010 (basata sul risk management).
Sembra ci sia molto dibattito in materia.
Per leggerle:
- SPC.1-2009 (free): http://www.asisonline.org/guidelines/ASIS_SPC.1-2009_Item_No._1842.pdf
- NFPA (free): http://www.nfpa.org/assets/files//PDF/NFPA16002010.pdf
- BS 25999-2 (a pagamento): http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030169700&t=r
- AS/NZS 5050:2010 (a pagamento): http://www.standards.co.nz/web-shop/?action=viewSearchProduct&pid=5050%3A2010%28AS%7CNZ%29&mod=catalog
- AS/NZS 5050:2010 DRAFT (free): http://www.calamityprevention.com/links/AS-NZS-5050-Part-1-Specification.pdf
Questo articolo confronta le norme
- BS 25999 e NFPA 1600 (basate sul solo "ripristino del business"),
- SPC.1-2009 (che richiede anche di prevenire gli incidenti e di mitigarne gli effetti)
- la nuova AS/NZS 5050:2010 (basata sul risk management).
Sembra ci sia molto dibattito in materia.
Per leggerle:
- SPC.1-2009 (free): http://www.asisonline.org/guidelines/ASIS_SPC.1-2009_Item_No._1842.pdf
- NFPA (free): http://www.nfpa.org/assets/files//PDF/NFPA16002010.pdf
- BS 25999-2 (a pagamento): http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030169700&t=r
- AS/NZS 5050:2010 (a pagamento): http://www.standards.co.nz/web-shop/?action=viewSearchProduct&pid=5050%3A2010%28AS%7CNZ%29&mod=catalog
- AS/NZS 5050:2010 DRAFT (free): http://www.calamityprevention.com/links/AS-NZS-5050-Part-1-Specification.pdf
An Excel Based Risk Assessment Methodology
Ho trovato interessante questa metodologia basata su Excel. In alcuni punti, più complicata del necessario, in altri troppo semplicistica (io terrei conto delle vulnerabilità e i parametri di riservatezza e integrità sembrano sottovalutati). La soluzione è comunque interessante.http://www.17799.com/modules.php?name=Papers&pa=showpage&pid=6
Attacchi IT e perdite economiche
Da SANS NewsBites Vol. 12 Num 76: la Corte Suprema dello Stato del Maine ha stabilito che l'azienda Hannaford Bros (la cui banca-dati con i numeri di carte di credito dei clienti è stata violata) non deve riconoscere alcunché ai clienti che non hanno subito alcun danno diretto (cioè, perdite economiche a causa di uso fraudolento del numero della propria carta).
Ovviamente, tali clienti hanno subito danni indiretti, visto che hanno dovuto impiegare un po' del loro tempo per chiedere la sostituzione della propria carta. Ma questi non dovranno essere riconosciuti.http://www.computerworld.com/s/article/9187340/Maine_court_limits_damage_claims_in_data_breach_cases?source=rss_news
La sentenza mi lascia perplesso. Inoltre, deduco che uno dei messaggi più utilizzati per vendere sicurezza ("negli USA eventuali attacchi possono costare molti soldi") non potrà più essere utilizzati.
Ovviamente, tali clienti hanno subito danni indiretti, visto che hanno dovuto impiegare un po' del loro tempo per chiedere la sostituzione della propria carta. Ma questi non dovranno essere riconosciuti.http://www.computerworld.com/s/article/9187340/Maine_court_limits_damage_claims_in_data_breach_cases?source=rss_news
La sentenza mi lascia perplesso. Inoltre, deduco che uno dei messaggi più utilizzati per vendere sicurezza ("negli USA eventuali attacchi possono costare molti soldi") non potrà più essere utilizzati.
Tecnologia Microsoft: EMET
Sul forum di discussione del Clusit su LinkedIn è stata data la notizia che il 14 settembre la Microsoft ha pubblicato un tool di hardening dei sistemi denominato EMET.
L'articolo in italiano: http://sicurezza.html.it/articoli/leggi/3475/aumentiamo-la-sicurezza-dei-programmi-windows-con-emet-20/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+HTML.it+-+Articoli
La pagina della Microsoft: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c6f0a6ee-05ac-4eb6-acd0-362559fd2f04
L'articolo in italiano: http://sicurezza.html.it/articoli/leggi/3475/aumentiamo-la-sicurezza-dei-programmi-windows-con-emet-20/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+HTML.it+-+Articoli
La pagina della Microsoft: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c6f0a6ee-05ac-4eb6-acd0-362559fd2f04
Novità legali - Modifica Codice della Proprietà Industriale
Il 30 luglio, il Consiglio dei Ministri ha approvato il Dlgs di modifica del Codice della Proprietà Industriale. Per ora non è stato ancora pubblicato in Gazzetta Ufficiale, ma può essere utile comprenderne le novità con questo articolo:http://www.filodiritto.com/index.php?azione=visualizza&iddoc=1955
Novità legali - Articolo sulla PEC
Da Filodiritto, segnalo l'articolo "Fine del telefax nell’èra della PEC?", dove è ribadita l'importanza della PEC anche per il miglioramento dell'efficienza della Pubblica Amministrazione.http://www.filodiritto.com/index.php?azione=visualizza&iddoc=1964
Intanto, aziende private continuano a chiedermi di inviare moduli firmati e scannerizzati via mail. Chi dice che il privato è sempre più avanti della PA?
Intanto, aziende private continuano a chiedermi di inviare moduli firmati e scannerizzati via mail. Chi dice che il privato è sempre più avanti della PA?
Privacy - Sentenza Garante sulle indagini su un dipendente
In materia di Privacy, il 10 Giugno il Garante ha vietato ad una società di utilizzare i file pornografici memorizzati sul pc di un proprio dipendente per avallare la decisione di licenziamento. Ancora una volta, perché l'informativa non è risultata ben scritta.http://www.filodiritto.com/index.php?azione=visualizza&iddoc=1962&newsfrom=2634
Gestione progetti - Articolo "Ridurre le perdite di tempo"
Su Computer World è stato pubblicato un interessante articolo dal titolo "Progetti di CRM, qualche suggerimento per ridurre le perdite di tempo". Non è applicabile ai soli progetti CRM e quindi molto interessante.
http://www.cwi.it/knowledge-center/2010/07/01/progetti-di-crm-qualche-suggerimento-per-ridurre-le-perdite-di-tempo/
http://www.cwi.it/knowledge-center/2010/07/01/progetti-di-crm-qualche-suggerimento-per-ridurre-le-perdite-di-tempo/
Sicurezza delle applicazioni
Quasi sempre è difficile trovare correttamente documentati i requisiti di sicurezza delle applicazioni. Lungi il voler imporre il modello waterfall, ma troppe volte in fase di analisi non si sa "quali requisiti considerare". E' quindi improbabile che siano documentati in maniera coerente.
Alcuni standard (come la ISO/IEC 15408 "Common Criteria") presentano metodologie e specifiche molto dettagliate. La ISO/IEC 15408 è una norma divisa in 3 parti per un totale di circa 650 pagine. Sicuramente, in molte situazioni è troppo onerosa.
La metodologia OWASP (www.owasp.org) è invece orientata alle applicazioni e ai servizi web. E' comunque consigliabile la sua lettura anche a chi si occupa di altre tipologie di applicazioni.
Io mi sono permesso di elaborare un ulteriore elenco di requisiti da consierare, basati sui punti dell'allegato A della ISO/IEC 27001:
Ovviamente l'elenco è migliorabile, ma da qualche parte bisogna iniziare (se avete idee...).
Alcuni standard (come la ISO/IEC 15408 "Common Criteria") presentano metodologie e specifiche molto dettagliate. La ISO/IEC 15408 è una norma divisa in 3 parti per un totale di circa 650 pagine. Sicuramente, in molte situazioni è troppo onerosa.
La metodologia OWASP (www.owasp.org) è invece orientata alle applicazioni e ai servizi web. E' comunque consigliabile la sua lettura anche a chi si occupa di altre tipologie di applicazioni.
Io mi sono permesso di elaborare un ulteriore elenco di requisiti da consierare, basati sui punti dell'allegato A della ISO/IEC 27001:
- i requisiti legali applicabili
- considerazioni sulla capacity (quanti utenti utilizzeranno l'applicazioni? quanto spazio disco sarà utilizzato? ...)
- considerazioni sulla disponibilità
- quali meccanismi crittografici per la connessione degli utenti e degli amministratori e come configurarli
- quali meccanismi di sicurezza per la connessione dell'applicazione con altre applicazioni
- quali meccanismi di identificazione e autenticazione per utenti e amministratori (userid e password? con quali regole di complessità, scadenza, modalità di modifica da parte degli utenti, ripristino, eccetera?)
- quali meccanismi di autorizzazione per gli accessi ai dati (controllo accessi, gestione dei ruoli e profili utente)
- quali meccanismi di log (login, logout, azioni degli utenti)
- come validare gli input e gli output e avere la garanzia che i dati siano elaborati correttamente (anche in considerazione delle potenziali vulnerabilità)
- come gestire il patching
- gli impatti sui sistemi di backup e sul Business Continuity Management (impatti sui sistemi del sito di Disaster Recovery e sulle procedure di gestione degli incidenti)
- gli impatti sul service desk (è necessario aggiornare gli operatori?)
- gli impatti sulla configurazione dei firewall
- gli impatti sui sistemi di monitoraggio e discovery (per esempio, se è necessario riconfigurarli)
- il ruolo dei fornitori
Ovviamente l'elenco è migliorabile, ma da qualche parte bisogna iniziare (se avete idee...).
Prossimi interventi di Cesare Gallotti
Il 5 ottobre ho tenuto un'intervista per Salotto Tecnologico su "Sicurezza delle informazioni, privacy e organizzazione: che deve fare una PMI per ottenere risultati concreti?". Sono quasi 50 minuti...http://www.salottotecnologico.it/video.cfm?idVideo=19&id=2
Il 30 novembre interverrò ai GS Days di Parigi (http://www.club-27001.fr/) su "Appréciation conjointe ISO 27001 et ISO 20000-1"
Il 30 novembre interverrò ai GS Days di Parigi (http://www.club-27001.fr/) su "Appréciation conjointe ISO 27001 et ISO 20000-1"
Iscriviti a:
Post (Atom)