Segnalo qualche novità in tema di Codice dell'amministrazione digitale e del Regolamento europeo sulla stessa materia.
Il Consiglio dei ministri ha approvato una bozza di nuovo CAD, ossia le modifiche al Dlgs 82 del 2005:
- http://www.agendadigitale.eu/identita-digitale/nuovo-cad-le-poche-e-confuse-novita-all-orizzonte_1947.htm.
Non sono un estimatore dell'analisi delle bozze, visto che poi sono soggette ad ampi cambiamenti. Ma se qualcuno vuole perderci tempo, faccia pure (se però qualche mio lettore riesce a fare lobby e migliorare il testo, credo lo ringrazieremo in tanti).
Molto più interessante è questo articolo più tecnico su "I primi cinque atti di Esecuzione previsti dal Regolamento eIDAS (UE n. 910/2014)". Si fa il punto di norme fondamentali per chi si occupa della materia:
- https://www.linkedin.com/pulse/eidas-al-decollo-pubblicato-mio-articolo-scritto-con-tumietto.
venerdì 29 gennaio 2016
ENISA Threat Landscape 2015
Luciano Quartarone mi ha segnalato la pubblicazione dell'ENISA Threat Landscape 2015 (ETL 2015):
- https://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisa-threat-landscape/etl2015.
Confesso che trovo un po' troppo numerose queste pubblicazioni.
Però Luciano fa notare che la tassonomia delle minacce (peraltro disponibile su un documento a parte e disponibile allo stesso indirizzo web) è molto interessante.
- https://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisa-threat-landscape/etl2015.
Confesso che trovo un po' troppo numerose queste pubblicazioni.
Però Luciano fa notare che la tassonomia delle minacce (peraltro disponibile su un documento a parte e disponibile allo stesso indirizzo web) è molto interessante.
mercoledì 27 gennaio 2016
OWASP Incident response
Segnalo, da Tweet di @techn0cratic (che a sua volta si riferisce ad un post su LinkedIn
https://www.linkedin.com/pulse/owasp-incident-response-tactical-guidance-tom-brennan), la pubblicazione di OWASP "Top 10 Considerations For Incident Response":
- https://www.owasp.org/index.php/OWASP_Incident_Response_Project.
Nulla di sensazionale, ma la guida è completa e molto sintetica. E già questi sono pregi.
https://www.linkedin.com/pulse/owasp-incident-response-tactical-guidance-tom-brennan), la pubblicazione di OWASP "Top 10 Considerations For Incident Response":
- https://www.owasp.org/index.php/OWASP_Incident_Response_Project.
Nulla di sensazionale, ma la guida è completa e molto sintetica. E già questi sono pregi.
martedì 26 gennaio 2016
Carrai e la Sicurezza Cibernetica Nazionale
Io non ho mai voluto parlare di politica nei miei "luoghi" professionali (blog, newsletter, Twitter), ma questa notizia è veramente troppo diffusa per ignorarla.
Il Presidente del Consiglio Matteo Renzi prevede di nominare tal Marco Carrai come responsabile del "centro nazionale della sicurezza cibernetica". Sembra che Carrai non abbia quasi alcuna competenza in materia. Ecco alcuni articoli (tutti ben polemici; scusate ma è quello che gira in rete):
- http://www.lettera43.it/politica/renzi-la-nomina-di-carrai-ai-servizi-rischia-lo-stop_43675230574.htm;
- https://codiceinsicuro.it/blog/tra-conflitti-di-interesse-e-007-addio-meritocrazia/;
- http://limbeccata.it/la-polemica/10-mesi-di-lavoro-e-0-laurea-carrai-li-non-andrai/.
Io ho già qualche problema perché non riesco a capire cosa sia la "sicurezza cibernetica", visto che la "cibernetica" è la "Disciplina che si occupa dello studio unitario dei processi riguardanti la comunicazione e il controllo nell'animale e nella macchina" (www.treccani.it).
Per la verità, come ho scritto in precedenza, non sopporto neanche il termine "cybersecurity", a prescindere dalla sua etimologia, perché viene usato in ogni contesto senza specificare cosa intende, quali sono i suoi confini e cosa la differenzia dalla "sicurezza informatica".
A parte i miei problemi terminologici, la nomina di Carrai è molto criticata, tanto che è stata scritta una "Lettera aperta al Presidente del Consiglio dei Ministri, Matteo Renzi, sulla "Sicurezza Cibernetica Nazionale"" e tutti gli "esperti del settore" sono stati invitati a sottoscriverla:
- https://www.cybersecuritynazionale.org/.
Cercando di non fare il finto modesto, mi sono sentito in causa e mi sono chiesto se firmarla.
Da una parte è opportuno prestare attenzione ai responsabili con elevate competenze tecniche. Ne ho avuti e ho visto che fungono da collo di bottiglia su tutti i temi di cui sono competenti.
Inoltre, i manager con competenze tecniche riducono tutto alla propria area di competenza (il sistemista IT ignora i problemi delle applicazioni e viceversa, l'esperto in organizzazione ignora i problemi tecnologici e viceversa, i non legali ignorano gli impatti normativi sulle proprie attività, e così via). In una realtà complessa come la sicurezza di Internet (forse è questo che si intende con "sicurezza cibernetica"?) questo può essere un limite.
Osservate, per esempio, i problemi del Garante privacy. Se pure tra il suo personale si trovano dei tecnici molto preparati, alcuni (non tutti...) Provvedimenti contengono sciocchezze tecnologiche inaudite. Segno che da Rodotà in poi i tecnici sono considerati vil razza dannata. E certamente il curriculum di Rodotà non lascia dubbi sulle sue elevate competenze giuridiche.
Dall'altra parte ho pensato che un manager deve essere soprattutto bravo a scegliere e gestire i collaboratori. Questa sarebbe la posizione di Renzi (mi dicono l'abbia esposta in qualche trasmissione televisiva). Però, mi chiedo, se una persona non ha un minimo di competenze, come può scegliere e coordinare correttamente le persone? Ho avuto capi non competenti della materia e ho visto i problemi che hanno causato.
Tra l'altro, ho sempre pensato, e ne ho visto le prove, quanto sia sciocca l'affermazione che un "manager è un bravo manager in qualunque settore lavori". Ritengo sia una baggianata messa in giro dagli stessi manager incompetenti e, purtroppo, presa per buona anche dalle persone competenti.
Qualche manager incompetente può sembrare bravo se, prima di lui, sono stati scelti e coordinati dei bravi tecnici, che possono lavorare bene anche senza i suoi interventi (preferisco non fare esempi...).
Ecco perché alla fine ho deciso di firmare la lettera.
Tra l'altro, spero che Carrai, visto che pare abbia conoscenze nel settore, abbia il buon gusto di rinunciare alla nomina e indicare persone più adatte di lui, con le giuste competenze e incompetenze, al ruolo di responsabile del "centro nazionale della sicurezza cibernetica".
Il Presidente del Consiglio Matteo Renzi prevede di nominare tal Marco Carrai come responsabile del "centro nazionale della sicurezza cibernetica". Sembra che Carrai non abbia quasi alcuna competenza in materia. Ecco alcuni articoli (tutti ben polemici; scusate ma è quello che gira in rete):
- http://www.lettera43.it/politica/renzi-la-nomina-di-carrai-ai-servizi-rischia-lo-stop_43675230574.htm;
- https://codiceinsicuro.it/blog/tra-conflitti-di-interesse-e-007-addio-meritocrazia/;
- http://limbeccata.it/la-polemica/10-mesi-di-lavoro-e-0-laurea-carrai-li-non-andrai/.
Io ho già qualche problema perché non riesco a capire cosa sia la "sicurezza cibernetica", visto che la "cibernetica" è la "Disciplina che si occupa dello studio unitario dei processi riguardanti la comunicazione e il controllo nell'animale e nella macchina" (www.treccani.it).
Per la verità, come ho scritto in precedenza, non sopporto neanche il termine "cybersecurity", a prescindere dalla sua etimologia, perché viene usato in ogni contesto senza specificare cosa intende, quali sono i suoi confini e cosa la differenzia dalla "sicurezza informatica".
A parte i miei problemi terminologici, la nomina di Carrai è molto criticata, tanto che è stata scritta una "Lettera aperta al Presidente del Consiglio dei Ministri, Matteo Renzi, sulla "Sicurezza Cibernetica Nazionale"" e tutti gli "esperti del settore" sono stati invitati a sottoscriverla:
- https://www.cybersecuritynazionale.org/.
Cercando di non fare il finto modesto, mi sono sentito in causa e mi sono chiesto se firmarla.
Da una parte è opportuno prestare attenzione ai responsabili con elevate competenze tecniche. Ne ho avuti e ho visto che fungono da collo di bottiglia su tutti i temi di cui sono competenti.
Inoltre, i manager con competenze tecniche riducono tutto alla propria area di competenza (il sistemista IT ignora i problemi delle applicazioni e viceversa, l'esperto in organizzazione ignora i problemi tecnologici e viceversa, i non legali ignorano gli impatti normativi sulle proprie attività, e così via). In una realtà complessa come la sicurezza di Internet (forse è questo che si intende con "sicurezza cibernetica"?) questo può essere un limite.
Osservate, per esempio, i problemi del Garante privacy. Se pure tra il suo personale si trovano dei tecnici molto preparati, alcuni (non tutti...) Provvedimenti contengono sciocchezze tecnologiche inaudite. Segno che da Rodotà in poi i tecnici sono considerati vil razza dannata. E certamente il curriculum di Rodotà non lascia dubbi sulle sue elevate competenze giuridiche.
Dall'altra parte ho pensato che un manager deve essere soprattutto bravo a scegliere e gestire i collaboratori. Questa sarebbe la posizione di Renzi (mi dicono l'abbia esposta in qualche trasmissione televisiva). Però, mi chiedo, se una persona non ha un minimo di competenze, come può scegliere e coordinare correttamente le persone? Ho avuto capi non competenti della materia e ho visto i problemi che hanno causato.
Tra l'altro, ho sempre pensato, e ne ho visto le prove, quanto sia sciocca l'affermazione che un "manager è un bravo manager in qualunque settore lavori". Ritengo sia una baggianata messa in giro dagli stessi manager incompetenti e, purtroppo, presa per buona anche dalle persone competenti.
Qualche manager incompetente può sembrare bravo se, prima di lui, sono stati scelti e coordinati dei bravi tecnici, che possono lavorare bene anche senza i suoi interventi (preferisco non fare esempi...).
Ecco perché alla fine ho deciso di firmare la lettera.
Tra l'altro, spero che Carrai, visto che pare abbia conoscenze nel settore, abbia il buon gusto di rinunciare alla nomina e indicare persone più adatte di lui, con le giuste competenze e incompetenze, al ruolo di responsabile del "centro nazionale della sicurezza cibernetica".
sabato 23 gennaio 2016
Sicurezza e deviazioni
Bruce Schneier, nel suo Crypto-Gram di gennaio, riporta un articolo dal titolo "IT Security and the Normalization of Deviance":
- https://www.schneier.com/blog/archives/2016/01/it_security_and.html.
Si parla di "normalizzazione della devianza", ossia delle persone che si abituano così tanto ai comportamenti devianti da non considerarli più tali.
Ho già parlato in altre occasioni di questo aspetto della sicurezza, spesso dandone la colpa ai capi (se loro sono i primi a chiedere o operare eccezioni alle regole o ignorano gli avvisi di auditor o altre entità).
L'altra faccia della medaglia dovrebbe essere presa in considerazione: persone che seguono (o chiedono di seguire) regole e procedure senza chiedersene il senso. Alcune volte si tratta di regole necessarie in passato, quando la tecnologia o l'organizzazione erano diverse (pensate a quanti chiedono ancora di firmare a mano dei moduli, quando un'email potrebbe essere sufficiente), o tentativi di risolvere delle situazioni oggi non più verosimili.
Schneier raccomanda ulteriori articoli (alcuni non relativi la sicurezza delle informazioni, ma comunque pertinenti l'argomento). Tra questi segnalo il seguente di John Banja dal titolo "The normalization of deviance in healthcare delivery":
- https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2821100/.
Al paragrafo 4.3 sono fornite alcune indicazioni su come intervenire (ma nessun link è "facilmente" utilizzabile).
- https://www.schneier.com/blog/archives/2016/01/it_security_and.html.
Si parla di "normalizzazione della devianza", ossia delle persone che si abituano così tanto ai comportamenti devianti da non considerarli più tali.
Ho già parlato in altre occasioni di questo aspetto della sicurezza, spesso dandone la colpa ai capi (se loro sono i primi a chiedere o operare eccezioni alle regole o ignorano gli avvisi di auditor o altre entità).
L'altra faccia della medaglia dovrebbe essere presa in considerazione: persone che seguono (o chiedono di seguire) regole e procedure senza chiedersene il senso. Alcune volte si tratta di regole necessarie in passato, quando la tecnologia o l'organizzazione erano diverse (pensate a quanti chiedono ancora di firmare a mano dei moduli, quando un'email potrebbe essere sufficiente), o tentativi di risolvere delle situazioni oggi non più verosimili.
Schneier raccomanda ulteriori articoli (alcuni non relativi la sicurezza delle informazioni, ma comunque pertinenti l'argomento). Tra questi segnalo il seguente di John Banja dal titolo "The normalization of deviance in healthcare delivery":
- https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2821100/.
Al paragrafo 4.3 sono fornite alcune indicazioni su come intervenire (ma nessun link è "facilmente" utilizzabile).
domenica 17 gennaio 2016
Regolamento europeo privacy - Q&A della Commissione europea
Per chi fosse interessato a qualche informazione veloce in merito al quasi futuro Regolamento europeo sulla privacy, segnalo questa pagina (in inglese) della Commissione europea stessa:
- http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm.
- http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm.
Novità SPID
AgID ha comunicato i primi accreditamenti dei primi gestori di identità digitale:
- http://www.agid.gov.it/notizie/2015/12/19/spid-accreditati-i-primi-gestori-identita-digitale.
Da un tweet di @martinapennisi, segnalo questo articolo del Corriere della Sera con qualche elemento in più:
- http://www.corriere.it/tecnologia/economia-digitale/15_dicembre_18/agid-identita-digitale-identity-provider-accreditamento-spid-fe552daa-a5c9-11e5-a238-fd021b6faac8.shtml.
Franco Ferrari di DNV GL mi ha anche segnalato questo articolo dal titolo "Spid, fare in fretta. Ma attenzione a privacy e sicurezza" che propone alcune riflessioni in merito:
- http://www.corrierecomunicazioni.it/pa-digitale/38806_spid-fare-in-fretta-ma-attenzione-a-privacy-e-sicurezza.htm.
- http://www.agid.gov.it/notizie/2015/12/19/spid-accreditati-i-primi-gestori-identita-digitale.
Da un tweet di @martinapennisi, segnalo questo articolo del Corriere della Sera con qualche elemento in più:
- http://www.corriere.it/tecnologia/economia-digitale/15_dicembre_18/agid-identita-digitale-identity-provider-accreditamento-spid-fe552daa-a5c9-11e5-a238-fd021b6faac8.shtml.
Franco Ferrari di DNV GL mi ha anche segnalato questo articolo dal titolo "Spid, fare in fretta. Ma attenzione a privacy e sicurezza" che propone alcune riflessioni in merito:
- http://www.corrierecomunicazioni.it/pa-digitale/38806_spid-fare-in-fretta-ma-attenzione-a-privacy-e-sicurezza.htm.
Normativa firme elettroniche
Luciano Quartone mi ha segnalato una sua presentazione "per illustrare la situazione attuale della normativa italiana in merito alle firme elettroniche e le principali differenze rispetto le novità che verranno con il Regolamento eIDAS".
Visto che l'argomento, per chi non ha seguito con estrema attenzione tutte le puntate, è complesso, mi pare utile segnalarla:
- http://www.lucianoquartarone.it/wp/?p=661.
Importanti saranno le modifiche che dovrebbero essere apportate al Codice dell'amministrazione digitale (CAD, Dlgs. 82 del 2005). A questo proposito, Anorc (Twitter @_ANORC) ha segnalato questo articolo dal titolo "Che resterà del CAD dopo la riforma?":
- http://www.agendadigitale.eu/identita-digitale/che-restera-del-cad-dopo-la-riforma-ecco-tutte-le-modifiche-necessarie_1885.htm.
Sempre da Anorc, segnalo la pubblicazione del D.P.C.M. del 6 novembre 2015, recante la disciplina della firma digitale dei documenti classificati:
- http://anorc.it/notizia/745_Le_nuove_regole_tecniche_per_la_sottoscrizione_digitale_dei_documenti_infor.html.
L'atto lo si trova al seguente link:
- www.gazzettaufficiale.it/eli/id/2015/12/05/15A08534/sg.
Visto che l'argomento, per chi non ha seguito con estrema attenzione tutte le puntate, è complesso, mi pare utile segnalarla:
- http://www.lucianoquartarone.it/wp/?p=661.
Importanti saranno le modifiche che dovrebbero essere apportate al Codice dell'amministrazione digitale (CAD, Dlgs. 82 del 2005). A questo proposito, Anorc (Twitter @_ANORC) ha segnalato questo articolo dal titolo "Che resterà del CAD dopo la riforma?":
- http://www.agendadigitale.eu/identita-digitale/che-restera-del-cad-dopo-la-riforma-ecco-tutte-le-modifiche-necessarie_1885.htm.
Sempre da Anorc, segnalo la pubblicazione del D.P.C.M. del 6 novembre 2015, recante la disciplina della firma digitale dei documenti classificati:
- http://anorc.it/notizia/745_Le_nuove_regole_tecniche_per_la_sottoscrizione_digitale_dei_documenti_infor.html.
L'atto lo si trova al seguente link:
- www.gazzettaufficiale.it/eli/id/2015/12/05/15A08534/sg.
sabato 16 gennaio 2016
ISO/IEC TR 20000-11: relazioni tra ISO/IEC 20000-1 e ITIL
Franco Ferrari di DNV GL mi ha segnalato la pubblicazione della ISO/IEC TR 20000-11:2015 dal titolo "Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: ITIL®":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62151.
Il testo di accompagnamento è molto scarno (6 pagine con anche immagini e tabelle riassuntive) e non dice nulla di nuovo a chi conosce già la ISO/IEC 20000-1 e ITIL (può però far ridere la pretesa di dire che non sono basate l'una sull'altra ma hanno solo qualche elemento in comune).
Il resto del documento è costituito da aride tabelle di correlazione e confronti tra le definizioni usate.
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62151.
Il testo di accompagnamento è molto scarno (6 pagine con anche immagini e tabelle riassuntive) e non dice nulla di nuovo a chi conosce già la ISO/IEC 20000-1 e ITIL (può però far ridere la pretesa di dire che non sono basate l'una sull'altra ma hanno solo qualche elemento in comune).
Il resto del documento è costituito da aride tabelle di correlazione e confronti tra le definizioni usate.
OWASP Top 10 Proactive Controls 2016 (e il Joel Test)
L'OWASP ha pubblicato la OWASP Top 10 Proactive Controls 2016:
- https://www.owasp.org/index.php/OWASP_Proactive_Controls.
Questa notizia mi è stata riferita dalla Newsletter d'information de HSC <newsletter@hsc-news.com>.
L'articolo della newsletter, richiama un punto di cui ho già parlato anche io in passato: per la sicurezza delle applicazioni web, purtroppo il riferimento è la OWASP Top 10, ossia la lista delle 10 vulnerabilità più diffuse delle applicazioni web, che però rappresentano l'inverso del problema:
- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
Ringrazio quindi OWASP per aver presentato la nuova lista.
L'articolo della newsletter, richiama anche la lista di buone pratiche di Joel Spolsky:
- http://www.joelonsoftware.com/articles/fog0000000043.html.
L'ho letta con dolore, pensando a quante volte non ho visto applicati i 12 punti:
- usare un sistema di controllo dei file;
- fare in modo che le build siano prodotte in un solo passaggio;
- fare build almeno ogni giorno;
- usare un sistema di ticketing per tracciare i bug;
- correggere i bug prima di scrivere nuovo codice;
- mantenere un piano di lavoro;
- scrivere le specifiche;
- assicurare ai programmatori un ambiente di lavoro tranquillo;
- fornire ai programmatori gli strumenti migliori;
- avere dei tester;
- in fase di selezione del personale, far scrivere del codice ai programmatori;
- chiedere all'"uomo della strada" di fare dei test di usabilità.
Per ciascun punto è fornita una spiegazione molto utile.
La lista è del 2000 e forse qualche voce potrebbe essere aggiornata. Ciò non toglie che dovrebbe essere studiata e applicata con attenzione.
- https://www.owasp.org/index.php/OWASP_Proactive_Controls.
Questa notizia mi è stata riferita dalla Newsletter d'information de HSC <newsletter@hsc-news.com>.
L'articolo della newsletter, richiama un punto di cui ho già parlato anche io in passato: per la sicurezza delle applicazioni web, purtroppo il riferimento è la OWASP Top 10, ossia la lista delle 10 vulnerabilità più diffuse delle applicazioni web, che però rappresentano l'inverso del problema:
- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
Ringrazio quindi OWASP per aver presentato la nuova lista.
L'articolo della newsletter, richiama anche la lista di buone pratiche di Joel Spolsky:
- http://www.joelonsoftware.com/articles/fog0000000043.html.
L'ho letta con dolore, pensando a quante volte non ho visto applicati i 12 punti:
- usare un sistema di controllo dei file;
- fare in modo che le build siano prodotte in un solo passaggio;
- fare build almeno ogni giorno;
- usare un sistema di ticketing per tracciare i bug;
- correggere i bug prima di scrivere nuovo codice;
- mantenere un piano di lavoro;
- scrivere le specifiche;
- assicurare ai programmatori un ambiente di lavoro tranquillo;
- fornire ai programmatori gli strumenti migliori;
- avere dei tester;
- in fase di selezione del personale, far scrivere del codice ai programmatori;
- chiedere all'"uomo della strada" di fare dei test di usabilità.
Per ciascun punto è fornita una spiegazione molto utile.
La lista è del 2000 e forse qualche voce potrebbe essere aggiornata. Ciò non toglie che dovrebbe essere studiata e applicata con attenzione.
mercoledì 23 dicembre 2015
Top 10 dei rischi legati alle tecnologie sanitarie per il 2016
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.
- 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.
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.
Iscriviti a:
Post (Atom)