Marco Fabbrini mi ha segnalato il documento "Top 10 Health Technology Hazards for 2016" (bisogna registrarsi):
- https://www.ecri.org/Pages/2016-Hazards.aspx.
Marco segnala soprattutto due rischi legati alla sicurezza IT: errate configurazioni e uso improprio delle porte USB.
Interessante osservare che, malgrado i siti dedicati alla sicurezza IT segnalano i rischi di intrusione informatica e la diffusione di dati personali, questo report non li considera. Infatti qui l'attenzione è posta sulla salute fisica dei pazienti.
Sicurezza delle informazioni, IT service management e qualità da Cesare Gallotti
mercoledì 23 dicembre 2015
Garante Privacy: email ex dipendente deve essere chiusa
Segnalo questo articolo di Filodiritto (con rimando al Provvedimento del Garante):
- http://www.filodiritto.com/news/2015/e-mail-garante-privacy-email-ex-dipendente-deve-essere-chiusa.html.
Sembrerebbe, ad una prima e veloce lettura, che è necessario informare preventivamente il dipendente per poi essere autorizzati ad accedere alla sua email in caso di uscita.
Leggendo il Provvedimento, al punto 2.4 sembra però che la pratica di inoltrare ad altra persona le email indirizzate ad un ex-dipendente sia illegittima in tutti i casi. Osservo che sono in molti ad attuarla, ma evidentemente devono adottare un'altra soluzione (la più semplice consiste nell'avvisare il mittente di inviare nuovamente l'email ad altro dipendente).
- http://www.filodiritto.com/news/2015/e-mail-garante-privacy-email-ex-dipendente-deve-essere-chiusa.html.
Sembrerebbe, ad una prima e veloce lettura, che è necessario informare preventivamente il dipendente per poi essere autorizzati ad accedere alla sua email in caso di uscita.
Leggendo il Provvedimento, al punto 2.4 sembra però che la pratica di inoltrare ad altra persona le email indirizzate ad un ex-dipendente sia illegittima in tutti i casi. Osservo che sono in molti ad attuarla, ma evidentemente devono adottare un'altra soluzione (la più semplice consiste nell'avvisare il mittente di inviare nuovamente l'email ad altro dipendente).
Vulnerabilità firewall Juniper
È stata trovata una backdoor nei firewall Juniper (notizia dal Sans NewsBites). Sono già disponibili degli exploit per sfruttarla. Il primo articolo è più tecnico:
- https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor;
- http://arstechnica.com/security/2015/12/researchers-confirm-backdoor-password-in-juniper-firewall-code/.
Una prima considerazione riguarda i produttori di firewall: evidentemente non fanno un riesame del codice (code review) prima di immettere sul mercato i loro prodotti. Ho letto una notizia secondo la quale CISCO ha intenzione di avviare un programma di code review; questo vuol dire che neanche loro la facevano!
Una seconda considerazione riguarda tutti noi, utilizzatori di questi prodotti. Evidentemente non possiamo rinunciare ai firewall, né possiamo essere sicuri della loro efficacia.
Sembra quindi che abbiano ragione coloro che promuovono l'uso di più firewall diversi in serie per assicurare la "difesa in profondità". Chi critica questo approccio fa notare che più tipi di firewall necessitano un numero maggiore di competenze, rendono meno efficiente la loro gestione e aumentano le vulnerabilità potenziali. Certamente, questi discorsi sono molto interessanti per le aziende medio-grandi, ma non per le piccole, che al massimo hanno una sola persona addetta alla gestione dei sistemi informatici.
- https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor;
- http://arstechnica.com/security/2015/12/researchers-confirm-backdoor-password-in-juniper-firewall-code/.
Una prima considerazione riguarda i produttori di firewall: evidentemente non fanno un riesame del codice (code review) prima di immettere sul mercato i loro prodotti. Ho letto una notizia secondo la quale CISCO ha intenzione di avviare un programma di code review; questo vuol dire che neanche loro la facevano!
Una seconda considerazione riguarda tutti noi, utilizzatori di questi prodotti. Evidentemente non possiamo rinunciare ai firewall, né possiamo essere sicuri della loro efficacia.
Sembra quindi che abbiano ragione coloro che promuovono l'uso di più firewall diversi in serie per assicurare la "difesa in profondità". Chi critica questo approccio fa notare che più tipi di firewall necessitano un numero maggiore di competenze, rendono meno efficiente la loro gestione e aumentano le vulnerabilità potenziali. Certamente, questi discorsi sono molto interessanti per le aziende medio-grandi, ma non per le piccole, che al massimo hanno una sola persona addetta alla gestione dei sistemi informatici.
venerdì 18 dicembre 2015
Regolamento europeo privacy - Aggiornamenti
La notizia è, credo, ben nota: il Regolamento europeo privacy (GDPR) ha fatto altri passi avanti. È stato concordato il testo da parte del "trilogo", ossia Commissione, Consiglio e Parlamento europeo.
Per quanto riguarda il percorso, Biagio Lammoglia, che ringrazio, mi ha scritto che: "i Triloghi (plurale, visto che gli appuntamenti sono stati molteplici) hanno prodotto un testo di accordo definitivo tra l'Istituzione proponente (Commissione Europea) e le Istituzioni legiferanti (Parlamento e Consiglio), accordo che deve essere solo ratificato dal doppio passaggio nelle Camere competenti (Parlamento e Consiglio) in tempi certi (entro la Primavera)".
Biagio aggiunge anche: "Per quanto previsto ancora un doppio passaggio parlamentare (Parlamento e Consiglio), la prassi vuole che l'accordo raggiunto nelle fasi di Trilogo risolva in modo definitivo le controversie e che il testo risultante non possa più essere modificato in modo sostanziale (ad esempio la casistica che determina l'obbligo di adozione del DPO è stata ormai fissata)".
Un articolo in inglese che dettaglia il percorso ancora da fare (grazie a Pierfrancesco Maistrello di Vecomp):
- http://www.insideprivacy.com/international/european-union/political-agreement-on-the-eu-general-data-protection-regulation/.
Traduzione finale: se tutto ciò è vero, l'iter si concluderà non più tardi di fine marzo 2016. In questo modo, considerando il periodo di transizione di 2 anni, le organizzazioni dovranno adeguarsi entro la primavera del 2018.
Segnalo un articolo in italiano, che mi sembra molto equilibrato (da un tuit):
- http://www.webnews.it/2015/12/16/regole-riforma-privacy-europa/.
Un articolo in inglese, che mi sembra però meno equilibrato:
- http://techcrunch.com/2015/12/16/gdpr-agreed.
Un articolo in inglese di Biagio Lammoglia su Europrivacy.info (segnalati da Alessandro Vallega di Oracle):
- http://europrivacy.info/2015/12/16/the-agreement-has-been-reached-gdpr-is-under-christmas-tree/.
Un altro articolo in inglese, segnalatomi sempre da Pierfrancesco Maistrello di Vecomp, di provenienza USA (Pierfrancesco dice "trovo utili queste testimonianze da oltreoceano, perché ci danno l'idea di quale sia il loro focus su questo tema, non sempre coincidente con il nostro"):
- http://blogs.wsj.com/law/2015/12/16/the-eu-data-privacy-agreement-what-we-know-and-dont/.
I due link (grazie a @europrivacy) alle ultime bozze:
- regolamento: http://ow.ly/d/47uW.
- direttiva per il trattamento dei dati trattati a scopo investigativo: http://ow.ly/d/47v0.
Notate che in questo testo ci sono commi e articoli con puntini di sospensione. Evidentemente sono punti cancellati da bozze precedenti. Il tutto, ovviamente, verrà consolidato.
Cosa ne penso?
Per quanto riguarda il percorso, Biagio Lammoglia, che ringrazio, mi ha scritto che: "i Triloghi (plurale, visto che gli appuntamenti sono stati molteplici) hanno prodotto un testo di accordo definitivo tra l'Istituzione proponente (Commissione Europea) e le Istituzioni legiferanti (Parlamento e Consiglio), accordo che deve essere solo ratificato dal doppio passaggio nelle Camere competenti (Parlamento e Consiglio) in tempi certi (entro la Primavera)".
Biagio aggiunge anche: "Per quanto previsto ancora un doppio passaggio parlamentare (Parlamento e Consiglio), la prassi vuole che l'accordo raggiunto nelle fasi di Trilogo risolva in modo definitivo le controversie e che il testo risultante non possa più essere modificato in modo sostanziale (ad esempio la casistica che determina l'obbligo di adozione del DPO è stata ormai fissata)".
Un articolo in inglese che dettaglia il percorso ancora da fare (grazie a Pierfrancesco Maistrello di Vecomp):
- http://www.insideprivacy.com/international/european-union/political-agreement-on-the-eu-general-data-protection-regulation/.
Traduzione finale: se tutto ciò è vero, l'iter si concluderà non più tardi di fine marzo 2016. In questo modo, considerando il periodo di transizione di 2 anni, le organizzazioni dovranno adeguarsi entro la primavera del 2018.
Segnalo un articolo in italiano, che mi sembra molto equilibrato (da un tuit):
- http://www.webnews.it/2015/12/16/regole-riforma-privacy-europa/.
Un articolo in inglese, che mi sembra però meno equilibrato:
- http://techcrunch.com/2015/12/16/gdpr-agreed.
Un articolo in inglese di Biagio Lammoglia su Europrivacy.info (segnalati da Alessandro Vallega di Oracle):
- http://europrivacy.info/2015/12/16/the-agreement-has-been-reached-gdpr-is-under-christmas-tree/.
Un altro articolo in inglese, segnalatomi sempre da Pierfrancesco Maistrello di Vecomp, di provenienza USA (Pierfrancesco dice "trovo utili queste testimonianze da oltreoceano, perché ci danno l'idea di quale sia il loro focus su questo tema, non sempre coincidente con il nostro"):
- http://blogs.wsj.com/law/2015/12/16/the-eu-data-privacy-agreement-what-we-know-and-dont/.
I due link (grazie a @europrivacy) alle ultime bozze:
- regolamento: http://ow.ly/d/47uW.
- direttiva per il trattamento dei dati trattati a scopo investigativo: http://ow.ly/d/47v0.
Notate che in questo testo ci sono commi e articoli con puntini di sospensione. Evidentemente sono punti cancellati da bozze precedenti. Il tutto, ovviamente, verrà consolidato.
Cosa ne penso?
Penso che varrebbe la pena aspettare la pubblicazione del
testo definitivo e qualche interpretazione "ufficiale" (Garante
privacy, WP Art. 29, eccetera) su alcuni requisiti ora un po' vaghi.
Ai miei clienti proporrò di vederci in aprile, a
Regolamento pubblicato e in occasione delle periodiche attività di
aggiornamento e verifica, per fare una prima analisi delle cose da modificare e
predisporre un piano per il 2016-2017.
Ho ancora la speranza che il nostro Garante privacy
cerchi di aiutare le aziende con interpretazioni utili. Finora purtroppo non ha
fatto alcunché, anzi, forse ha aumentato la confusione in merito a questo
Regolamento, alimentando un mercato di pirati. Su questo punto vorrei scrivere
di più, ma evito.
ISO/IEC 27017 - Sicurezza del cloud
È stata pubblicata la ISO/IEC 27017:2015 dal titolo "Code of practice for information security controls based on ISO/IEC 27002 for cloud services":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43757.
Si tratta di un'estensione dei controlli della ISO/IEC 27002 (o dell'Annex A della ISO/IEC 27001). In alcuni casi sono fornite ulteriori indicazioni per i controlli già presenti nella ISO/IEC 27002, in altri casi sono aggiunti nuovi controlli.
Interessante è osservare che tutte le estensioni e i nuovi controlli sono presentati indicando cosa è applicabile al cliente e cosa al fornitore di servizi cloud.
Non mi sembra ci sia nulla di straordinario da segnalare. Questo standard potrà essere utile a coloro che vorranno ottenere un "attestato di allineamento" ad esso. Per studiare come assicurare la sicurezza dei servizi cloud è necessario leggere altri documenti (magari partendo da quelli gratuiti messi a disposizione dalla Cloud security alliance o dal NIST).
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43757.
Si tratta di un'estensione dei controlli della ISO/IEC 27002 (o dell'Annex A della ISO/IEC 27001). In alcuni casi sono fornite ulteriori indicazioni per i controlli già presenti nella ISO/IEC 27002, in altri casi sono aggiunti nuovi controlli.
Interessante è osservare che tutte le estensioni e i nuovi controlli sono presentati indicando cosa è applicabile al cliente e cosa al fornitore di servizi cloud.
Non mi sembra ci sia nulla di straordinario da segnalare. Questo standard potrà essere utile a coloro che vorranno ottenere un "attestato di allineamento" ad esso. Per studiare come assicurare la sicurezza dei servizi cloud è necessario leggere altri documenti (magari partendo da quelli gratuiti messi a disposizione dalla Cloud security alliance o dal NIST).
Vera 4.2 ITA
Ho pubblicato la versione italiana del mio foglio di calcolo per un Very easy risk assessment (VERA) relativo alla sicurezza delle informazioni.
La pagina web è questa:
- http://www.cesaregallotti.it/Pubblicazioni.html.
La pagina web è questa:
- http://www.cesaregallotti.it/Pubblicazioni.html.
Sviluppo sicuro for dummies
Ho ricevuto due belle segnalazioni da WhiteHat Security Europe.
Il primo è "Website Security for Dummies":
http://go.whitehatsec.com/HY002010Lm1WZI60YdB00zP.
Il secondo è "Securing the SDLC for Dummies":
http://go.whitehatsec.com/s0yZ0Yd0WBL00Y016m20P0I.
Mi sembrano librini di base, che dovrebbero essere studiati a memoria da quanti sviluppano.
Il primo è "Website Security for Dummies":
http://go.whitehatsec.com/HY002010Lm1WZI60YdB00zP.
Il secondo è "Securing the SDLC for Dummies":
http://go.whitehatsec.com/s0yZ0Yd0WBL00Y016m20P0I.
Mi sembrano librini di base, che dovrebbero essere studiati a memoria da quanti sviluppano.
martedì 15 dicembre 2015
Auto chiama la polizia dopo incidente: guidatrice arrestata
Si parla tanto di Internet of Things. Credo che questa notizia (tratta da Crypto-gram di dicembre) sia veramente interessante per capirne gli impatti:
- http://www.zdnet.com/article/car-calls-911-after-alleged-hit-and-run-driver-arrested/.
In poche parole: una donna causa un incidente e fugge, l'automobile si accorge che c'è stato un incidente e chiama la polizia. Ovviamente la donna viene arrestata.
Il fatto che l'automobile chiami automaticamente la polizia è una misura di sicurezza nel caso in cui il guidatore sia coinvolto in un incidente e sia impossibilitato a fare la chiamata in autonomia. In questo caso, però, la misura di sicurezza si è dimostrata una misura contraria agli interessi (censurabili) del beneficiario.
- http://www.zdnet.com/article/car-calls-911-after-alleged-hit-and-run-driver-arrested/.
In poche parole: una donna causa un incidente e fugge, l'automobile si accorge che c'è stato un incidente e chiama la polizia. Ovviamente la donna viene arrestata.
Il fatto che l'automobile chiami automaticamente la polizia è una misura di sicurezza nel caso in cui il guidatore sia coinvolto in un incidente e sia impossibilitato a fare la chiamata in autonomia. In questo caso, però, la misura di sicurezza si è dimostrata una misura contraria agli interessi (censurabili) del beneficiario.
Conservazione: pubblicate le linee guida AgID
AgID ha pubblicato le "Linee guida sulla conservazione dei documenti informatici":
- http://www.agid.gov.it/notizie/2015/12/10/conservazione-pubblicate-linee-guida-agid.
Plaudo all'iniziativa di rendere più comprensibili le norme in materia di conservazione e di firma elettronica-digitale.
Nei miei sogni, questo documento dovrebbe essere una guida "for dummies". Se questa è l'intenzione anche di AgID, allora c'è ancora molto da semplificare. In tutti i casi, da qualche parte bisogna pur cominciare e il documento è ancora in fase di sviluppo.
- http://www.agid.gov.it/notizie/2015/12/10/conservazione-pubblicate-linee-guida-agid.
Plaudo all'iniziativa di rendere più comprensibili le norme in materia di conservazione e di firma elettronica-digitale.
Nei miei sogni, questo documento dovrebbe essere una guida "for dummies". Se questa è l'intenzione anche di AgID, allora c'è ancora molto da semplificare. In tutti i casi, da qualche parte bisogna pur cominciare e il documento è ancora in fase di sviluppo.
sabato 12 dicembre 2015
I linguaggi di programmazione più vulnerabili
Chiedo scusa per il titolo del post. Infatti segnalo l'articolo di DarkReading "The Programming Languages That Spawn The Most Software Vulnerabilities" che tratta dei linguaggi di programmazione il cui uso porta ad avere maggiori vulnerabilità:
- http://www.darkreading.com/vulnerabilities---threats/the-programming-languages-that-spawn-the-most-software-vulnerabilities/d/d-id/1323397.
In altre parole, PHP e ASP Web non hanno un numero maggiore di vulnerabilità, ma sono usati peggio degli altri. In realtà, Java e .NET dispongono di funzionalità proprio per ridurre le vulnerabilità, mentre questi no. Viene ovviamente naturale pensare che è sempre più necessario l'uso di analizzatori del codice prima di attivarlo in produzione.
Questo e altri dettagli si trovano nel "State of Software Security Report" di Veracode (che confesso di non aver letto):
- https://info.veracode.co.uk/state-of-software-security-report-volume6-pt2.html.
- http://www.darkreading.com/vulnerabilities---threats/the-programming-languages-that-spawn-the-most-software-vulnerabilities/d/d-id/1323397.
In altre parole, PHP e ASP Web non hanno un numero maggiore di vulnerabilità, ma sono usati peggio degli altri. In realtà, Java e .NET dispongono di funzionalità proprio per ridurre le vulnerabilità, mentre questi no. Viene ovviamente naturale pensare che è sempre più necessario l'uso di analizzatori del codice prima di attivarlo in produzione.
Questo e altri dettagli si trovano nel "State of Software Security Report" di Veracode (che confesso di non aver letto):
- https://info.veracode.co.uk/state-of-software-security-report-volume6-pt2.html.
venerdì 11 dicembre 2015
Novità sul Regolamento europeo privacy
Pierfrancesco Maistrello di Vecomp mi ha inviato degli aggiornamenti sul GDPR (come è indicato da "bravi" la General data protection regulation o, come ho sempre detto io, "futuro Regolamento europeo sulla privacy").
In questi giorni c'è un ulteriore incontro (il trilogo, credo) per fare avanzare la proposta di GDPR. Il testo, non ufficiale e segnalato su Twitter da @EUstaran, oggetto di discussione sarebbe questo:
- http://www.statewatch.org/news/2015/dec/eu-council-dp-reg-prep-trilogue-14902-15.pdf.
Pierfrancesco mi segnala un articolo, forse un poco superato, in cui si cerca di fare chiarezza sulla situazione, anche se presenta un testo diverso dal precedente:
- http://www.istitutoitalianoprivacy.it/it/la-newsletter-del-presidente-iip-2-dicembre-2015/.
In questi giorni c'è un ulteriore incontro (il trilogo, credo) per fare avanzare la proposta di GDPR. Il testo, non ufficiale e segnalato su Twitter da @EUstaran, oggetto di discussione sarebbe questo:
- http://www.statewatch.org/news/2015/dec/eu-council-dp-reg-prep-trilogue-14902-15.pdf.
Pierfrancesco mi segnala un articolo, forse un poco superato, in cui si cerca di fare chiarezza sulla situazione, anche se presenta un testo diverso dal precedente:
- http://www.istitutoitalianoprivacy.it/it/la-newsletter-del-presidente-iip-2-dicembre-2015/.
mercoledì 9 dicembre 2015
Progettare software sicuro
Da un articolo dell'ISACA Journal, volume 4 del 2015, dal titolo "Three Ways to Simplify Auditing Software Security Requirements and Design", segnalo alcuni link.
Il primo è uno studio di IBM dell'ottobre 2008 dal titolo " Minimizing code defects to improve software quality and lower development costs". Questo articolo riporta una delle dichiarazioni più famose della sicurezza ("identificare un difetto del software dopo la consegna costa 30 volte in più che farlo in fase di progettazione") e quindi può essere usata come autorevole fonte. Poi non si capisce bene come sia stato calcolato questo valore, ma se lo ha inventato IBM è sicuramente più veritiero che se lo avessi inventato io:
- ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf.
L'articolo poi tratta di "analisi delle minacce" ("threat modeling") a cui il software potrebbe essere sottoposto. Confesso che non ho mai visto usare questo strumento, però mi piace segnalare quello proposto da Microsoft, visto che è gratuito (l'articolo ne segnala altri, ma non capisco come possano essere utilizzati). Mi piacerebbe ricevere contributi (da chi li ha usati realmente, la pura teoria non mi interessa):
- http://www.microsoft.com/en-ca/download/details.aspx?id=42518.
Il primo è uno studio di IBM dell'ottobre 2008 dal titolo " Minimizing code defects to improve software quality and lower development costs". Questo articolo riporta una delle dichiarazioni più famose della sicurezza ("identificare un difetto del software dopo la consegna costa 30 volte in più che farlo in fase di progettazione") e quindi può essere usata come autorevole fonte. Poi non si capisce bene come sia stato calcolato questo valore, ma se lo ha inventato IBM è sicuramente più veritiero che se lo avessi inventato io:
- ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf.
L'articolo poi tratta di "analisi delle minacce" ("threat modeling") a cui il software potrebbe essere sottoposto. Confesso che non ho mai visto usare questo strumento, però mi piace segnalare quello proposto da Microsoft, visto che è gratuito (l'articolo ne segnala altri, ma non capisco come possano essere utilizzati). Mi piacerebbe ricevere contributi (da chi li ha usati realmente, la pura teoria non mi interessa):
- http://www.microsoft.com/en-ca/download/details.aspx?id=42518.
Perché i progetti IT falliscono
Colgo l'occasione di un interessante articolo dell'ISACA Journal volume 5 del 2015 dal titolo "Auditors and Large Software Projects".
In questo articolo si fa riferimento ad una pubblicazione di Intosai (Issue 26 del 2008) dal titolo "Why IT projects fail". Qui trovo interessante il contributo dell'Oman, che elenca i 21 rischi (intesi un po' come minacce, un po' come vulnerabilità) di project management. Ho trovato interessante leggerli e penso sia un buon riferimento per quando mi chiedono "cosa intendi per rischi di progetto?".
Per chi volesse leggere l'articolo:
- http://www.intosaiitaudit.org/intoit_articles/26_p12top17.pdf.
Le pubblicazioni di Intosai fino al 2010 si trovano qui:
http://www.intosaiitaudit.org/publication_and_resources/1.
In questo articolo si fa riferimento ad una pubblicazione di Intosai (Issue 26 del 2008) dal titolo "Why IT projects fail". Qui trovo interessante il contributo dell'Oman, che elenca i 21 rischi (intesi un po' come minacce, un po' come vulnerabilità) di project management. Ho trovato interessante leggerli e penso sia un buon riferimento per quando mi chiedono "cosa intendi per rischi di progetto?".
Per chi volesse leggere l'articolo:
- http://www.intosaiitaudit.org/intoit_articles/26_p12top17.pdf.
Le pubblicazioni di Intosai fino al 2010 si trovano qui:
http://www.intosaiitaudit.org/publication_and_resources/1.
Linee guida di design per i siti web della PA
Da un tuit di @ilnesi, segnalo che AgID ha presentato le Linee Guida di design (inteso come rappresentazione grafica) per i siti web della pubblica amministrazione.
La notizia di AgID:
- http://www.agid.gov.it/notizie/2015/11/20/online-linee-guida-design-i-siti-web-pa.
Il sito vero e proprio:
- http://design.italia.it/.
Il mio commento è semplice: non si parla di sicurezza.
Forse qualcuno penserà che sono troppo concentrato su questo tema, ma non credo. Innanzi tutto, si parla di "protezione dagli errori" e di "accessibilità" e quindi si poteva parlare anche di sicurezza. Inoltre, la sicurezza deve entrare nella rappresentazione grafica; a me vengono in mente le seguenti caratteristiche: rendere chiare le modalità di registrazione e di accesso, rendere chiaro quando un utente ha acceduto o meno all'area riservata con le proprie credenziali, rendere sempre disponibile un pulsante di disconnessione (e chiarire cosa succede se qualcuno chiude il browser senza usarlo).
Ovviamente si potrebbe cogliere l'occasione per approfondire i temi della sicurezza trattando di funzionalità e meccanismi tecnologici, ma forse questo sarebbe veramente troppo fuori tema.
Invito però i tecnici con le competenze opportune a fornire contributi ad AgID (io l'ho fatto con il testo di questo articoletto). Si tratta di una bella occasione.
La notizia di AgID:
- http://www.agid.gov.it/notizie/2015/11/20/online-linee-guida-design-i-siti-web-pa.
Il sito vero e proprio:
- http://design.italia.it/.
Il mio commento è semplice: non si parla di sicurezza.
Forse qualcuno penserà che sono troppo concentrato su questo tema, ma non credo. Innanzi tutto, si parla di "protezione dagli errori" e di "accessibilità" e quindi si poteva parlare anche di sicurezza. Inoltre, la sicurezza deve entrare nella rappresentazione grafica; a me vengono in mente le seguenti caratteristiche: rendere chiare le modalità di registrazione e di accesso, rendere chiaro quando un utente ha acceduto o meno all'area riservata con le proprie credenziali, rendere sempre disponibile un pulsante di disconnessione (e chiarire cosa succede se qualcuno chiude il browser senza usarlo).
Ovviamente si potrebbe cogliere l'occasione per approfondire i temi della sicurezza trattando di funzionalità e meccanismi tecnologici, ma forse questo sarebbe veramente troppo fuori tema.
Invito però i tecnici con le competenze opportune a fornire contributi ad AgID (io l'ho fatto con il testo di questo articoletto). Si tratta di una bella occasione.
Direttiva europea su sicurezza informatica
Mentre io criticavo alcune iniziative italiane di "strategia sulla cyber security", soprattutto perché "nazionali" quando ormai viviamo in un mondo interconnesso, l'Europa si sta muovendo (grazie a retuit di @Silvia_Mar_).
Si tratta ancora di annunci, ma li fornisco per completezza (il primo è in italiano, gli altri in inglese):
- http://www.techeconomy.it/2015/12/08/ue-ce-laccordo-cybersecurity-paesi-richieste-strategie-nazionali-collaborazione/;
- http://ec.europa.eu/commission/2014-2019/oettinger/blog/first-eu-wide-legisation-cybersecurity-agreed_en;
- http://www.europarl.europa.eu/news/en/news-room/content/20151207IPR06449/html/MEPs-close-deal-with-Council-on-first-ever-EU-rules-on-cybersecurity.
Si tratta ancora di annunci, ma li fornisco per completezza (il primo è in italiano, gli altri in inglese):
- http://www.techeconomy.it/2015/12/08/ue-ce-laccordo-cybersecurity-paesi-richieste-strategie-nazionali-collaborazione/;
- http://ec.europa.eu/commission/2014-2019/oettinger/blog/first-eu-wide-legisation-cybersecurity-agreed_en;
- http://www.europarl.europa.eu/news/en/news-room/content/20151207IPR06449/html/MEPs-close-deal-with-Council-on-first-ever-EU-rules-on-cybersecurity.
martedì 8 dicembre 2015
Nuova versione ISO/IEC 27013 e ISO/IEC 27010
Sono state pubblicate le nuove versioni delle norme in oggetto.
La ISO/IEC 27013 (versione del 2015) ha titolo " Information technology -- Security techniques -- Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1" e riguarda, ovviamente, le relazioni tra due norme molto importanti:
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64138.
Io avevo fornito molti contributi alla versione precedente. Su questa non ci ho lavorato, né l'ho letta. Comunque si tratta di un adattamento della precedente versione alla nuova ISO/IEC 27001, quindi non penso ci siano novità rilevanti.
La ISO/IEC 27010:2015 ha titolo "Information technology -- Security techniques -- Information security management for inter-sector and inter-organizational communications".
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=68427.
Di questa ho letto la versione precedente del 2012 e ho pensato fosse totalmente inutile. Non perderò tempo a leggermi anche questa, a meno che qualcuno non mi suggerisca diversamente.
La ISO/IEC 27013 (versione del 2015) ha titolo " Information technology -- Security techniques -- Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1" e riguarda, ovviamente, le relazioni tra due norme molto importanti:
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64138.
Io avevo fornito molti contributi alla versione precedente. Su questa non ci ho lavorato, né l'ho letta. Comunque si tratta di un adattamento della precedente versione alla nuova ISO/IEC 27001, quindi non penso ci siano novità rilevanti.
La ISO/IEC 27010:2015 ha titolo "Information technology -- Security techniques -- Information security management for inter-sector and inter-organizational communications".
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=68427.
Di questa ho letto la versione precedente del 2012 e ho pensato fosse totalmente inutile. Non perderò tempo a leggermi anche questa, a meno che qualcuno non mi suggerisca diversamente.
Nuova versione della ISO/IEC 20000-10
È stata pubblicata la nuova versione della ISO/IEC 20000-10 (del 2015) dal titolo "Information technology - Service management - Part 10: Concepts and terminology":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=68673
Dispiace vedere che una norma da usare come base sia venduta a 118 Franchi svizzeri.
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=68673
Dispiace vedere che una norma da usare come base sia venduta a 118 Franchi svizzeri.
Correzioni a ISO/IEC 27001 e 27002
Sono stati pubblicati i technical corrigendum della ISO/IEC 27001 e 27002.
Il primo corrigendum, comune a ISO/IEC 27001 e 27002, riguarda l'inventario, la classificazione e trattamento degli "asset". In questi casi, al termine "asset" si è aggiunto il termine "informazioni". Spesso risultava ovvio al lettore che le "informazioni" erano incluse negli "asset", ma evidentemente non a tutti.
Il secondo corrigendum della ISO/IEC 27002 riguarda un riferimento incrociato sbagliato. Al controllo 14.2.8 si fa riferimento al controllo 14.1.9, mentre bisognava fare riferimento al controllo 14.2.9.
È bene discuterli brevemente. Segnalo che in passato
avevo sottovalutato l'importanza del secondo corrigendum della ISO/IEC 27001;
qui cerco di rimediare.
Il primo corrigendum, comune a ISO/IEC 27001 e 27002, riguarda l'inventario, la classificazione e trattamento degli "asset". In questi casi, al termine "asset" si è aggiunto il termine "informazioni". Spesso risultava ovvio al lettore che le "informazioni" erano incluse negli "asset", ma evidentemente non a tutti.
Il secondo corrigendum della ISO/IEC 27001 riguarda la
Dichiarazione di applicabilità. Qui è importante perché ora la DdA non deve più
riportare necessariamente i controlli dell'Annex A, ma "i controlli
necessari" (insieme a giustificazione e stato di attuazione). L'Annex A
deve essere usato solo per indicare e giustificare eventuali esclusioni dei
suoi controlli. Sarà interessante vedere come tutto ciò sarà interpretato nella
pratica.
Il secondo corrigendum della ISO/IEC 27002 riguarda un riferimento incrociato sbagliato. Al controllo 14.2.8 si fa riferimento al controllo 14.1.9, mentre bisognava fare riferimento al controllo 14.2.9.
Iscriviti a:
Post (Atom)