Guida della Commissione europea per il post-Safe harbor

Segnalo questo articolo con le novità in materia di Safe harbour e dal titolo"Safe Harbor Update: The European Commission Issues Guidance on the Schrems Decision":
- http://www.jdsupra.com/legalnews/safe-harbor-update-the-european-61218/.

Questo articolo fa riferimento ad una guida della Commissione europea:
- http://europa.eu/rapid/press-release_MEMO-15-6014_en.htm.

In sintesi: questa guida dice che è necessario usare le clausole contrattuali o le binding corporate rules (BCR).

Nulla è semplice e bisogna cercare un po' per recuperare documentazione utile. Per scrupolo la riporto:
- Clausole contrattuali per trasferimenti tra titolari:
http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1447323316386&uri=CELEX:32004D0915 (da decisione 915 del 2004 della CE);
- Clausole contrattuali tra titolare e responsabile esterno: http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1447323878179&uri=CELEX:32010D0087 (da decisione 87 de 2010 della CE);
- Schema di BCR del Art. 29 Working Party, riportato dai documenti WP 153, WP 154 e WP 155, reperibili al link http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion
-recommendation/index_en.htm.

Questi riferimenti li ho trovati nel documento "Communication from the Commission to the European parliament and the Council on the transfer of personal data from the EU to the United States of America under Directive 95/46/EC following the Judgment by the Court of Justice in Case C-362/14 (Schrems)" del 6 novembre 2015:
- http://ec.europa.eu/justice/data-protection/international-transfers/adequacy/files/eu-us_data_flows_communication_final.pdf.

Regolamento eIDAS e CAD

Il Regolamento europeo cosiddetto eIDAS (n. 910/2014 del Parlamento Europeo e del Consiglio del 23 luglio 2104) impone delle modifiche al nostro Codice per l'amministrazione digitale (CAD, D. Lgs. 82 del 2005).

Alcune considerazioni sono riportate da questo articolo dal titolo "Il senso del regolamento europeo eIDAS per il nuovo Cad: un coordinamento necessario":
- http://www.forumpa.it/pa-digitale/il-regolamento-europeo-910-slash-2014-eidas-e-il-suo-impatto-sulla-legislazione-nazionale-primaria-e-tecnica.

DPCM sul Fascicolo sanitario elettronico

È stato pubblicato sulla Gazzetta ufficiale il Decreto del Presidente del Consiglio dei ministri numero 178 del 29 settembre 2015 e dal titolo "Regolamento in materia di fascicolo sanitario elettronico":
- www.gazzettaufficiale.it/eli/id/2015/11/11/15G00192/sg.

Devo studiarlo. Immagino il Provvedimento sul Fascicolo sanitario elettronico (FSE) del Garante del 2009 (documenti web 1634116 e 1633793) sia abrogato. Ovviamente rimane in vita il Provvedimento sul Dossier sanitario elettronico (DSE) del 2015 (documento web 4084632).

Grazie ad Ernesto Belisario di cui ho letto un tweet con la notizia.

Il boom della sicurezza informatica

Questo articolo del The Economist ("The cost of immaturity: The business of protecting against computer-hacking is booming") è quasi banale: a seguito del crescere degli attacchi informatici, si sta avendo un boom dei servizi di sicurezza informatica:
- http://www.economist.com/news/business/21677639-business-protecting-against-computer-hacking-booming-cost-immaturity.

Il boom fa sì che molti "professionisti" non sono competenti e molti servizi sono di scarsa qualità. Questo anche perché non sono disponibili certificazioni professionali riconosciute.

Mi permetto di fare tre appunti:

• il dilagare dell'incompetenza lo vedo dal 1999 (tra i tecnici e i consulenti), quando ho cominciato a lavorare in questo settore, quando il "boom" era sempre previsto per l'anno dopo;
• evidentemente bisognava aspettare il 2014 per dire, con ragione, che il boom della sicurezza informatica sarebbe stato l'anno successivo (i fanfaroni c'erano anche allora, anche se non usavano i social network per diffondere messaggi profondi di 144 caratteri);
• le certificazioni non sono troppo poche, sono invece troppe, forse giustamente, vista la vastità dell'argomento; chi cerca servizi di qualità fa fatica ad orientarsi (ricordo però il Quaderno Clusit "Certificazioni Professionali in Sicurezza Informatica 2.0", di cui sono co-autore, scaricabile da http://www.clusit.it/download/index.htm).

Avendo commentato sarcasticamente, mi trattengo dal tediare ulteriormente i miei lettori con la solita geremiade sulle competenze già presente in molti miei post precedenti.

Presentazione sulla sicurezza del software

Segnalo questa presentazione di Gary McGraw, un guru della sicurezza del software:
- https://www.cigital.com/blog/annotated-att-cybersecurity-conference-keynote.

Alcuni dei link proposti conducono ad articoli interessanti. Per i più attenti potrebbe valere la pena considerare i libri di Gary McGraw.

Promuove anche il BSIMM, uno studio sulle iniziative per la sicurezza del software:
- https://www.bsimm.com/about/.

Non parlate di "ingegneria" del software

Segnalo questo articolo dal titolo "Programmers: stop calling yourselves engineers":
- http://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/.

In poche parole: i programmatori e gli sviluppatori non sono "ingegneri", visto che non adottano le tecniche di ingegneria e i risultati, con bug, difetti e vulnerabilità, si vedono.

Personalmente ritengo che programmatori e sviluppatori dovrebbero tendere ad essere "ingegneri". Purtroppo, però, quando si chiede loro piani di progetto, documenti di requisiti e verbali di test (con o senza elementi di sicurezza), dimostrano di essere degli "artigiani". Nella peggiore delle ipotesi non hanno neanche idea di cosa gli sia stato chiesto; nella maggior parte dei casi, per contro, questi requisiti sono ben chiari ma applicati poco e male.

Certamente la colpa è gran parte da addebitare alle aziende che li pagano poco, considerano il loro lavoro come "banale", impongono tempi di analisi, sviluppo e verifica brevissimi. Un vero "ingegnere" (per esempio chiamato a progettare e costruire un ponte) rifiuterebbe di adeguarsi a queste condizioni (e non rimarrebbe senza lavoro, al contrario di programmatori e sviluppatori software).

Quindi, forse, per non confondersi e non illudersi, sarebbe effettivamente meglio essere consapevoli dei limiti della "ingegneria" del software nel mondo reale.

L'articolo segnala la "Guide to the software engineering body of knowledge (SWEBOK Guide)" dell'IEEE, che sembra interessante (è necessario fornire la propria email all'IEEE, ma si tratta di un ente serio e non credo la usi per fare spamming):
- http://www.computer.org/web/swebok/index.

KeeFarce

KeeFarce è uno strumento per recuperare le password gestite da KeePass. KeePass, a sua volta, è uno strumento per memorizzare le tante password in modo sicuro.

KeeFarce, quindi, rende meno sicuro KeePass. Però alla condizione che il pc su cui è installato KeePass sia compromesso e l'utente legittimo lo abbia sbloccato. Rimane un prodotto di sicurezza da adottare (molte sue alternative, comunque da considerare, possono ritenersi allo stesso livello di sicurezza e insicurezza), purché si sia consapevoli dei suoi limiti.

Per saperne di più:
- http://arstechnica.com/security/2015/11/hacking-tool-swipes-encrypted-credentials-from-password-manager/.

Grazie a Pasquale Stirparo che annunciato la notizia.

Per la cronaca: io preferisco scrivere le password su un file testo e cifrarlo; ma io non sono amministratore di una rete complessa di sistemi informatici.

Stato delle norme ISO/IEC 270xx

Dal 26 al 30 ottobre si è svolto il 51o meeting del ISO/IEC JTC1 SC27, ossia l'incontro semestrale dei delegati delle diverse nazioni per scrivere le norme della serie ISO/IEC 270xx e non solo.

Questa volta la delegazione italiana era composta da tre persone (sempre poche): io, il presidente Fabio Guasconi e una persona dedicata alle norme correlate alla privacy.

Ecco lo stato delle norme della serie ISO/IEC 270xx, curate dal WG1 (ringrazio Fabio per aver fatto la sintesi):

• 27000 (vocabolario): dovrebbe uscire a breve una nuova edizione;
• 27001: noi italiani abbiamo individuato un errore da correggere (in sintesi e senza essere troppo accurato: è usato "criteri di rischio" per indicare la metodologia di valutazione del rischio, mentre la definizione e la ISO 31000 usano "criteri di rischio" solo per indicare i "criteri di ponderazione del rischio"; sembra una sciocchezza formale, ma credo sia nostro compito fare bene il lavoro ed evitare di introdurre elementi che potrebbero creare confusione);
• 27003 (guida alla 27001): il testo è stato migliorato e passa in DIS; se tutto va bene dovrebbe essere approvato ad aprile e pubblicato per fine 2016;
• 27004 (misurazioni e monitoraggio): testo riorganizzato ma non cambiato; passa in DIS;
• 27005 (gestione del rischio): rimane in bozza e rischia la cancellazione per superamento dei tempi massimi consentiti per il progetto; il comitato è molto litigioso;
• 27007 (linee guida per l'audit al sistema di gestione): rimane in bozza;
• 27008 (valutazione dei controlli di sicurezza): rimane in bozza;
• 27009 (certificazioni per settori particolari): va in bozza finale con alcuni voti negativi; personalmente credo sia una norma che potrebbe creare confusione perché promuove l'uso di linee guida insieme ad uno standard di requisiti (la ISO/IEC 27001);
• 27011 (controlli per le TLC): va in bozza finale;
• 27019 (controlli per il settore energia): rimane in bozza;
• 27021 (competenze): rimane in bozza ma cambia la struttura allineandosi a e-CF.

Altri lavori sono stati proposti (sulle assicurazioni, sulla resilienza, sulla sanità, sul settore avio). Ogni tanto penso si stia esagerando con questi standard, ma cerco di non contrastare chi ha voglia di lavorarci.

Per quanto riguarda gli standard correlati alla privacy:

• 29134 (per realizzare un privacy impact assessment, PIA): proseguono i lavori;
• 29151 (linee guida per la protezione dei dati personali): proseguono i lavori;
• 20889 (tecniche di de-identificazione): prima bozza.

Sono anche stati proposti lavori su informativa e consenso on-line, autenticazione, app per smartphone, smart city, correlazione tra privacy e ISO/IEC 27001.

Prossimo appuntamento ad aprile.

Riportare bug

Questo articolo ha titolo "If You Find a Software Bug, Don't Try to Report It to These Companies":
- http://blogs.wsj.com/digits/2015/11/05/if-you-find-a-software-bug-dont-try-to-report-it-to-these-companies/.

In breve: ci sono delle grandi società che non mettono a disposizione del pubblico un indirizzo a cui segnalare difetti o vulnerabilità individuati, altre (Microsoft, Amazon) lo fanno.

Ovviamente un canale di comunicazione per ricevere segnalazioni è fondamentale per poter migliorare i prodotti e servizi. Alcuni pensano che questo rappresenterebbe una dichiarazione di disfatta (come se non si sappia che i software sono sempre pieni di bug e vulerabilità), altri semplicemente non ci pensano.

CIS Critical Security Controls

Stefano Ramacciotti mi ha segnalato questo documento dal titolo "The CIS Critical: Security Controls for Effective Cyber Defense":
- http://www.cisecurity.org/critical-controls.cfm.

Si tratta di una "solita" lista di controlli di sicurezza, con l'aggravante dell'uso "cyber". Però è ben fatta (sicuramente meglio della ISO/IEC 27002, con maggiori dettagli e più coerenza) e vale la pena leggerla. Il CIS mette anche a disposizione un Excel (xlsx) per condurre valutazioni su questi controlli.

Per scaricare il documento, purtroppo, è necessario fornire il proprio indirizzo email.

Lo stesso documento è stato ripreso dall'ETSI (www.etsi.org) come norma ETSI TR 103 305. Questa si può scaricare senza fornire i propri riferimenti, ma (visti i tempi di recepimento) potrebbe non essere aggiornata. Inoltre, in questo secondo caso, l'Excel non è disponibile.

Lo stesso documento è anche proposto dal SANS, che rimanda al sito del CIS:
- https://www.sans.org/critical-security-controls/.

In questo caso ho notato che il SANS mette anche a disposizione una "Solution Directory" che mi sembra essere (ancora) vuota. Trovo l'idea ottima e spero venga attuata quanto prima.

Nuovo Statuto dei lavoratori - Riflessioni

Valerio Vertua (Presidente di DFA) mi ha segnalato un interessante articolo di Andrea Stanchi sul controllo a distanza previsto dal nuovo articolo 4 dello Statuto dei lavoratori (ne ho parlato in http://blog.cesaregallotti.it/2015/10/privacy-statuto-dei-lavoratori.html):
- http://www.quotidianogiuridico.it/documents/2015/10/22/gps-il-controllo-per-la-cassazione-si-puo-fare-se-il-lavoratore-e-inadempiente.

Purtroppo l'articolo è ad accesso controllato. Io ho trovato queste slides, che sono ovviamente meno esaustive, ma comunque interessanti:
- http://www.pietroichino.it/?p=37560.

Stanchi parte da una sentenza in particolare (su una verifica dei movimenti di un lavoratore tramite GPS installato sulla macchina usata per gli spostamenti lavorativi) per alcune considerazioni.

In particolare: tramite gli strumenti posso eseguire i controlli sull'impiego corretto dello strumento rispetto alla sua specifica finalità (abuso ed uso illecito).

Inoltre suggerisce le finalità del trattamento dei dati personali raccolti dagli strumenti di lavoro: verifica della conformità del risultato della prestazione, verifica della qualità della prestazione, accertamento delle difformità, provvedimenti disciplinari e denunce penali.

Rapporto semestrale MELANI

È pubblicato il 21o rapporto semestrale della "Centrale d'annuncio e d'analisi per la sicurezza dell'informazione MELANI" della Confederazione Svizzera:
- https://www.melani.admin.ch/melani/it/home/dokumentation/bollettino-d-informazione/MELANI-21-rapporto-semestrale.html.

Si trova anche in inglese.

In questo numero il tema principale è la sicurezza dei siti Web. Ma non c'è solo questo: analisi degli ultimi attacchi e approfondimenti su altri temi come i dispositivi medici.

Io sono un fan dei rapporti MELANI e ne consiglio sempre la lettura.

AgID cerca personale

AgID cerca personale (scadenza per le candidature il 6 novembre):
- http://www.agid.gov.it/agid/avvisi

La segnalo perché noto un profilo decisamente tecnico delle figure cercate. Mi pare, dai documenti che ho criticato nel tempo, siano anche necessari delle competenze più gestionali (non dirigenziali, ma con competenze per capire gli impatti di alcune misure anche da un punto di vista organizzativo, nelle aziende private che oggi operano nel mercato).

Critico spesso i lavori di AgID, ma credo che molti degli errori siano originati da due cause (ricordo che non so assolutamente nulla dell'organizzazione di AgID): a) il personale con competenze più gestionali è poco numeroso; b) il personale con esperienza reale e capacità (e tempo) di confronto con le aziende private coinvolte è poco numeroso.

Diffamazione via web: sentenza sugli accertamenti

Segnalo, da Altalex, questo articolo dal titolo "Reato di diffamazione mezzo web: l'accertamento è possibile grazie alla tecnica ed alla logica":
- http://www.altalex.com/documents/news/2015/08/25/diffamazione-rilievo-indirizzo-ip.

La Cassazione ha bocciato il ricorso della difesa, che riteneva inadeguate le prove di accusa di diffamazione perché:
- erano stampe delle pagine web in cui l'accusato aveva inserito dei post a nome della moglie con cui era in corso la separazione;
- nessun accertamento era stato fatto direttamente sul pc dell'accusato, ma solo facendo riferimento all'indirizzo IP dal quale erano stati inviati i post;
- l'indirizzo IP usato per inviare i post provenivano da un router (della casa della madre dell'accusato) che però poteva essere stato compromesso da altri.

Non ho letto completamente la sentenza, ma la Corte ha ritenuto completamente accettabile la condanna in quanto gli elementi raccolti sono incontestabili tecnicament, ma anche per un chiaro percorso di carattere logico-deduttivo.

La sentenza l'ho trovata qui:
- http://renatodisa.com/2015/08/12/corte-di-cassazione-sezione-v-sentenza-6-agosto-2015-n-34406-laccertamento-della-responsabilita-per-il-reato-di-diffamazione-commesso-a-mezzo-web-puo-desumersi-dallindividuazion/.

Startup

Si parla molto di startup. Avevo già letto un articolo che diceva che le startup non rappresentano il meccanismo di crescita di un Paese.

Segnalo quindi questo articolo, più recente, che riassume bene la questione:
- http://www.agendadigitale.eu/startup/tante-chiacchiere-sull-innovazione-e-dimentichiamo-cio-che-serve-davvero_1758.htm.

Intrusione nell'email del direttore della CIA

La notizia è pubblica: degli hacker sono entrati nell'email (quella su America On Line, AOL) del direttore della CIA e ne hanno diffuso i contenuti su Wikileaks.

Io vi segnalo questo articolo dal titolo "teen who hacked CIA director's email tells how he did it":
- http://www.wired.com/2015/10/hacker-who-broke-into-cia-director-john-brennan-email-tells-how-he-did-it/.

In estrema sintesi: scoprono che John Brennan ha un cellulare Verizon; chiamano Verizon spacciandosi per colleghi e ottengono delle informazioni; chiamano AOL e, con le medesime informazioni, si fanno dare una nuova password per accedere all'email di Brennan.

Qualche veloce, e semplice, considerazione:
- il direttore della CIA teneva quindi email critiche su AOL?
- spero che questo caso porti ad un innalzamento di sicurezza del meccanismo "reset password" dei fornitori di email.

Un dubbio. Forse a tutto il personale della CIA era stato vietato di usare servizi pubblici per archiviare o scambiare documenti critici. Ovviamente questa regole non si è applicata ai vertici dell'organizzazione... Chissà perché.

VERA 4.1

Il mio foglio di calcolo per un Very easy risk assessment (VERA) relativo
alla sicurezza delle informazioni, ora è alla versione 4.1:
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2015-VERA-4.1.xlsx.

Reperibile anche sulla mia pagina web:
- http://www.cesaregallotti.it/Pubblicazioni.html.

Ringrazio Francesca Lazzaroni di Spike Reply per i contributi.

Mia presentazione ISO/IEC 27001

Introduzione alla ISO/IEC 27001: una mia presentazione per l'Ordine
Ingegneri Pavia (pdf, 1,4MB):
- http://www.cesaregallotti.it/Pdf/Pubblicazioni/2015-Intro-ISMS.pdf

Potete anche trovarla sulla pagina web:
- http://www.cesaregallotti.it/Pubblicazioni.html.

Security scanner

Un articolo di Pete Herzog sui vulnerability scanner
http://darkmatters.norsecorp.com/2015/10/19/the-awesome-truth-about-vulnerability-scanners/.

Il sottotitolo è: "uno strumento altamente tecnologico utilizzato male e
incompreso". In effetti, tratta di funzionalità che non sapevo oggi fossero
incluse in questo strumento. Pete Herzog mi dà (non direttamente) del
vecchio... Oggi questi strumenti non sono più quelli degli inizi.

Un solo difetto dell'articolo: viene citato, quasi per caso, un solo
strumento (Nessus). Avrei preferito qualche esempio in più.

Cloud Forensics Capability Maturity Model

CSA ha pubblicato il "Cloud Forensics Capability Maturity Model":
- https://cloudsecurityalliance.org/download/cloud-forensics-capability-model.

Mi dicono che è "un buon lavoro", anche se migliorabile.

Ne raccomando la lettura perché molte indicazioni sono applicabili ad ogni
tipo di fornitore.

Privacy: Statuto dei lavoratori - Modificato articolo 4

Come molte volte preannunciato, è stato modificato l'articolo 4 della Legge 300 del 1970.

Segnalo questo articolo, dove si trovano il link al D. Lgs. 151 del 2015 (articolo 23) che modifica l'articolo 4, il link al commento del Garante privacy (polemico e non certo risolutivo):

- http://www.webnews.it/2015/09/24/controllo-distanza-lavoro/.

Tra l'altro, il Garante non ricorda (e poteva farlo!) le sue "Linee-guida per il trattamento di dati dei dipendenti privati", che rimangono applicabili:

- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/1364099.

Segnalo anche la comunicazione del Ministero del lavoro del 18 giugno 2015:

- http://www.lavoro.gov.it/Notizie/Pages/2015_06_18-Controlli-a-distanza.aspx.

Segnalo anche questo articolo di Gabriele Faggioli in merito:

- www.clusit.it/docs/faggioli_app_controllo.pdf.

Io ho letto e ho qualche dubbio. Provo a riassumere cosa dice il provvedimento e scrivo qualche commento tratto dalla lettura degli articoli sopra riportati (ricordo però che non sono un legale e la colpa di inesattezze è mia).

Il comma 1 dice, in sostanza, che è possibile utilizzare strumenti di controllo purché si abbiano le opportune autorizzazioni. Gli strumenti di controllo possono essere installati solo per esigenze organizzative e produttive, per la sicurezza del lavoro e per la tutela del patrimonio aziendale. Deduco che le "esigenze produttive" non includano il controllo delle prestazioni del singolo lavoratore, ma solo quelle "generali". Ad ogni modo, l'unica vera novità riguarda l'aggiunta della finalità di "tutela del patrimonio aziendale".

Il comma 2 dice che le autorizzazioni non sono necessarie quando la raccolta dati (e quindi il potenziale controllo) avviene tramite gli "attrezzi di lavoro" (detti "strumenti utilizzati dal lavoratore per rendere la prestazione lavorativa") e gli strumenti di registrazione degli accessi e delle presenze. Da notare:

• gli strumenti di controllo accessi sono principalmente quelli fisici, relativi alle presenze; Faggioli include anche gli strumenti di controllo degli accessi ai sistemi informatici;
• tra gli attrezzi di lavoro sono da includere sicuramente pc, tablet e cellulari; secondo me, sono anche da aggiungere i sistemi informatici nel loro complesso; in altre parole, il "gestionale aziendale" (tipo SAP, per intenderci, che raccoglie log su chi ha modificato un documento o un record) e l'e-mail sono anch'essi attrezzi di lavoro;
• la raccolta dati tramite gli "attrezzi di lavoro" prevista da questo comma non comprende gli "attrezzi di lavoro modificati"; in altre parole, se ad un pc o smartphone si aggiungono software di monitoraggio o di localizzazione, questi richiedono autorizzazione.

Il comma 3 ricorda che è comunque applicabile la normativa privacy e quindi i lavoratori devono essere adeguatamente informati in merito agli strumenti di controllo (anche quelli inclusi nel comma 2). 

Un mio dubbio: se un lavoratore dovesse richiedere il blocco del trattamento, su quale base è possibile continuare il controllo? Forse perché c'è qualche disposizione contrattuale in merito?

Gabriele Faggioli ricorda inoltre delle sentenze della Cassazione dicendo (se riassumo correttamente): se il controllo dei log e delle registrazioni non avviene in modo continuativo (quindi "preventivo", come se fossero delle telecamere), ma solo quando ve ne è la necessità, per esempio a seguito di segnalazione di illecito (quindi "reattivo"), allora questo è permesso (purché questo aspetto sia incluso nell'informativa).

Le sentenze della Cassazione citate da Faggioli con le mie conclusioni:

• la 4746 del 2002, che validava la prova sull'uso illecito del cellulare aziendale da parte di un lavoratore; oggi questa sentenza rimarrebbe valida in quanto la verifica è stata effettuata ad hoc su una persona precisa (quindi non con strumenti specifici di monitoraggio dell'uso dei cellulari) e solo analizzando gli accessi non autorizzati allo strumento aziendale;
• la 15892 del 2007, che invalidava delle prove raccolte filtrando con strumenti specifici tutti gli accessi del personale; oggi forse queste prove sarebbero state ritenute valide, purché il personale sia stato adeguatamente informato;
• la 4375 del 2010, che invalidava delle prove raccolte attraverso strumenti di analisi del traffico Internet; anche oggi queste prove non sarebbero state ritenute valide in quanto gli strumenti usati erano ulteriori a quelli "di base" e non autorizzati (segnalo che da un punto di vista sicurezza sarebbe stato meglio bloccare direttamente i siti web, non raccogliere dati);
• la 2722 del 2012, che validava delle prove raccolte grazie a meccanismi "di base" dei sistemi informatici (nel caso particolare, l'archiviazione delle e-mail); anche oggi queste prove sarebbero ritenute valide.

Spero di ricevere ulteriori contributi, soprattutto per rispondere alle mie domande.

PS: Questo post consolida (e corregge) altri post già pubblicati, ora cancellati.

Privacy: Safe Harbour non è più valido - 2

Segnalo questo articolo di Gabriele Faggioli in merito:
- www.clusit.it/docs/faggioli_ue_inval_safe_harbor.pdf.

Sembrerebbe che la soluzione sia quella di usare le "clausole contrattuali standard".

Privacy: Safe Harbour non è più valido

Con sentenza del 6 ottobre, la Corte di giustizia dell'UE ha dichiarato nulli gli accordi di Safe Harbour.

La sentenza la trovate nella pagina web con il commento del nostro Garante:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4308245.

Per chi non avesse seguito la questione in passato, gli accordi Safe Harbour, in breve, prevedevano quanto segue: se un'azienda USA dichiarava la propria adesione a questi accordi, automaticamente era consentito il trasferimento di dati personali dalla UE a questa azienda. Molte di queste aziende sono data centre in cui imprese europee archiviano i propri dati (la lista delle aziende Safe Harbour è liberamente accessibile: https://safeharbor.export.gov/list.aspx).

Questi accordi non sono più ritenuti validi perché non impediscono, per esempio e come dimostrato dal caso Snoweden, la sorveglianza da parte di entità quali NSA.

Ora cosa succede? Faccio riferimento ad un articolo segnalatomi da Daniela Quetti di Lispa:
- http://uk.businessinsider.com/european-court-of-justice-safe-harbor-ruling-2015-10.

Ora le organizzazioni europee dovranno seguire le indicazioni delle autorità garanti nazionali. A quanto mi risulta non abbiamo ancora un Provvedimento del nostro Garante privacy.

Comunque già ora ci sono delle regole, previste dal nostro Codice privacy (D.lgs 196/2003) che richiedono, tra l'altro, il consenso esplicito da parte degli interessati.

In alternativa, si possono applicare le "clausole tipo" previste dall'autorizzazione del Garante del 2010
(http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/1728496).

Mi sto chiedendo quanto tempo avranno le nostre aziende per adeguarsi. Però mi pare di capire che sarebbe meglio aspettare ulteriori decisioni.

Segnalo altri articoli di cui ho trovato riferimento su Twitter:
- http://www.reuters.com/article/2015/10/07/us-eu-ireland-privacy-idUSKCN0S00NT20151007;
- http://www.lastampa.it/2015/10/06/tecnologia/la-sentenza-shock-della-corte-ue-sulla-privacy-spiegata-in-punti-bpu45K0Ha8FRNOYvnbZ5TO/pagina.html.

Pubblicata la ISO/IEC 27006:2015

Il 30 settembre è stata pubblicata la nuova versione della ISO/IEC 27006 dal titolo "Requirements for bodies providing audit and certification of information security management systems":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62313.

Si applica solo agli organismi di certificazione.

Non sono pienamente soddisfatto del risultato raggiunto perché:
- la versione del SOA (o Dichiarazione di applicabilità) deve comunque essere presente nei "documenti di certificazione"; in questo caso la dicitura è più vaga, ma l'idea di riportare la versione del SOA sul certificato, ahinoi, è rimasta;
- le giornate uomo minime previste non sono diminuite; qualcuno ha visto margini per essere "creativi" nel calcolo delle giornate uomo, ma la base di partenza è comunque inspiegabilmente elevata.

Rapporti di sicurezza informatica

In questo periodo ho ricevuto notizia di diversi rapporti di sicurezza informatica.

Il primo è "Annual Incident reports 2014" di ENISA, l'agenzia europea per la sicurezza informatica, relativo ai sistemi di telecomunicazione:
- https://www.enisa.europa.eu/activities/Resilience-and-CIIP/Incidents-reporting/annual-reports/annual-incident-reports-2014.

La segnalazione è arrivata da Claudio Telmon, attraverso il gruppo Clusit di LinkedIn. Il suo commento: Ci sono molti dati interessanti, ma uno mi ha colpito particolarmente, da pag. 15 del Report: le gravi interruzioni dovute ad azioni malevole (9%, quasi un decimo) hanno superato quelle dovute ad eventi naturali (5%); e mentre il secondo valore è in calo, il primo è in crescita. Per completezza, la causa principale (66%) sono "system failures". Non che si possano trarre delle conclusioni statistiche "certe" anche per altri contesti, ma noto però che nei piani di BC/DR continuo a vedere tanta attenzione agli eventi naturali, e poca a quelli malevoli.

Il secondo è "The Internet Organised Crime Threat Assessment (IOCTA) 2015" a cura di Europol:
- https://www.europol.europa.eu/content/internet-organised-crime-threat-assessment-iocta-2015.

La segnalazione è arrivata da Mattia Epifani, via mailing list di www.perfezionisti.it. Ad avviso di Mattia, dopo una prima veloce lettura, i fatti salienti sono:

• valutazione della situazione nelle tre aree ritenute di maggiore interesse da Europol (Cyber Attacks, Online Child Exploitation e Payment Fraud);
• analisi dei malware che hanno avuto maggiore effetto nell'ultimo anno;
• grande spazio ai ransomware ma attenzione anche sui RAT; è strano vedere che Dark Comet (che è oramai vecchiotto) e le sue varianti siano ritenute ancora un High Risk (pagina 27);
• preoccupazione per lo sviluppo delle criptomonete e delle darknet per le attività illegali.

Il terzo è l'aggiornamento del rapporto Clusit 2015:
- http://clusit.it/rapportoclusit/

Io avevo già la versione di marzo 2015 e non ho notato cambiamenti. Ad ogni modo, chi non dovesse averlo ancora letto, dovrebbe farlo.

Infine, Vito Losacco mi ha segnalato il Report McAfee Labs sulle minacce" dell'Agosto 2015:

• http://www.mcafee.com/it/mcafee-labs.aspx?view=legacy (versione italiana);
• http://www.mcafee.com/it/resources/reports/rp-quarterly-threats-aug-2015.pdf (link diretto alla versione italiana);
• https://blogs.mcafee.com/mcafee-labs/malware-trend-continues-relentless-climb/ (versione inglese).

In realtà questo report propone delle riflessioni su alcuni temi e alcuni casi di interesse.

iOS Security paper

La Apple ha pubblicato recentemente un documento dl titolo " iOS Security: iOS 9.0 or later":
- http://www.apple.com/iphone/business/it/security.html.

Gli appassionati di tecnologia lo troveranno interessante.

Io però sono interessato ad un'altra cosa: la cura con cui la Apple ha preparato questo documento. Certamente si tratta di marketing. Ma non è solo questo: è una presentazione dei meccanismi di sicurezza di un sistema hardware e software.

È vero che la Apple dispone di personale preparato e dedicato a questo tema, ma certamente il loro esempio dovrebbe essere considerato dalle aziende produttrici e clienti di hardware e software.

Ringrazio Mattia Epifani per la segnalazione e i link.

Il computer a scuola non aiuta ad imparare il digitale

Questo argomento è lievemente fuori tema rispetto ai soliti qui trattati:
- http://www.techeconomy.it/2015/09/15/ocse-computer-scuola-non-aiuta-ad-imparare-digitale/.

In sintesi: non è detto che gli alunni con maggiore accesso ai sistemi informatici siano più bravi ad utilizzarli. La conclusione: è necessario non solo mettere a disposizione gli strumenti informatici e il tempo per utilizzarli, ma anche "un rilevante livello di preparazione degli insegnanti" su come gestire questo tempo in modo efficace.

Penso che sia il caso di riflettere su questi aspetti perché forse la questione non si ferma alle scuole: nelle aziende il personale, di qualunque età, usa i sistemi informatici in modo continuativo, ma non per questo ne capisce tutte le potenzialità, i limiti e, ovviamente, i rischi.

Articolo su eIDAS

Come noto da precedenti post, eIDAS, il Regolamento europeo relativo ai servizi fiduciari, è un argomento che trovo interessante e degno di attenzione.

Ricordo qui i miei post precedenti:
- http://blog.cesaregallotti.it/2014/12/regolamento-ue-910-del-2014-e-cad_11.html;
- http://blog.cesaregallotti.it/2015/03/spid-identita-digitale.html;
- http://blog.cesaregallotti.it/2015/03/novita-legali-spid-precisazione.html.

A questo punto segnalo un articolo di Andrea Caccia e Daniele Dumietto che, secondo me, rende più chiara la situazione:
- http://www.ildocumentodigitale.com/regolamento-europeo-eidas/.

Assicurazione si rifiuta di pagare dopo un attacco

Sono sempre stato perplesso in merito alle assicurazioni relative agli attacchi informatici.

Questo caso, conseguente all'attacco a BitPay, sembra confermare la mia prudenza:
- http://www.networkworld.com/article/2984989/security/cyber-insurance-rejects-claim-after-bitpay-lost-1-8-million-in-phishing-attack.html.

Faccio la sintesi del caso. BitPay è una società che gestisce Bitcoin. Un hacker invia una mail al CFO di BitPay con un link fraudolento a Google. Il CFO usa il link, si connette alla propria e-mail su Google e, ovviamente, l'hacker da quel momento dispone delle credenziali dell'e-mail del CFO. Quindi, con le credenziali del CFO, invia una mail al CEO chiedendogli di inviare dei bitcoin ad un certo conto. Il CEO esegue e, ancora ovviamente, l'hacker si vedere recapitare i bitcoin sul proprio conto.

L'assicurazione si è rifiutata di pagare BitPay perché l'attacco non è avvenuto sui sistemi di gestione dei bitcoin, oggetto dell'assicurazione, ma sul sistema di e-mail.

Per AgID l'informatica è ferma agli anni Novanta

Per AgID l'informatica è ferma agli anni Novanta, forse. Forse agli Ottanta.

Mi spiego. La Circolare AgID 65 del 2014 riguarda l'accreditamento per le attività di conservazione dei documenti informatici e non distingue tra i 3 elementi fondamentali di un servizio IT: attività burocratiche e amministrative, sviluppo e manutenzione dell'applicazione, conduzione dei sistemi informatici.

La circolare stabilisce: "Il conservatore può affidare ad altro conservatore accreditato le attività a supporto del processo di conservazione limitatamente a quelle che riguardano le infrastrutture per la memorizzazione, trasmissione ed elaborazione dei dati".

In altre parole, se un'azienda conosce il processo e mantiene l'applicazione non può usare i servizi di amministrazione dei sistemi (e il CED) di un esterno, a meno che questo non sia accreditato a sua volta come conservatore. Quindi, questo professionista esterno deve essere bravo a gestire il CED, ad amministrare i sistemi, a sviluppare un'applicazione complessa, a gestire un processo di conservazione sostitutiva.

Oggi, però, le aziende sono spesso specializzate in un solo di questi compiti (chi conosce le aziende specializzate nello sviluppo sa bene che, spesso, una delle prime cose da fare per migliorarne la sicurezza è proprio quella di far gestire i sistemi ad altri).

Pensate che io sia paranoico? Pensate che in realtà quelli di AgID non la pensino così?

Purtroppo questa mia accusa nasce da casi reali.

Ulteriore considerazione: la medesima disposizione non si applica allo sviluppatore del software. Sebbene l'applicazione sia fondamentale, chi la mantiene non deve essere necessariamente accreditato, a differenza di chi gestisce i sistemi. Come negli anni Ottanta-Novanta, quando le vulnerabilità applicative erano poco considerate.

La circolare di AgID, quindi, doveva essere scritta decisamente meglio, tenendo conto di un concetto che oggi si applica a quasi tutti i settori: la catena di fornitura.

Nota finale: non penso che i conservatori accreditati ad oggi siano deboli in uno dei settori indicati. Ma le aziende di questo tipo sono necessariamente molto poche.

Uscita la nuova ISO 9001:2015

Il 23 settembre è infine uscita la ISO 9001:2015 (anche se la data riportata dalla norma è il 15 settembre), di cui ho già parlato in altri post.

La pagina dell'ISO:
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=62085.

La pagina UNI per la versione italiana (già disponibile):
- http://store.uni.com/magento-1.4.0.1/index.php/uni-en-iso-9001-2015.html.

Complimenti al BSI e al BSI Italia per la celerità con cui hanno inviato la notizia.

Per quanto riguarda i tempi di transizione: il 15 settembre 2018 tutti i certificati ISO 9001:2008 non saranno più validi e quindi le organizzazioni dovranno adeguarsi entro quella data. Gli Organismi di certificazione dovranno rendere disponibili regolamenti con maggiori dettagli.

Segnalo (grazie a Franco Ferrari di DNV GL) anche la seguente pagina di Accredia con molti chiarimenti:
- http://www.accredia.it/news_detail.jsp?ID_NEWS=1962&areaNews=95&GTemplate=default.jsp.

Nella pagina Accredia trovate anche dei documenti, in inglese, di chiarimento elaborati dal gruppo ISO (ISO/TC 176/SC 2) responsabile dello sviluppo della ISO 9001. Gli stessi documenti si trovano anche nella ISO TC/176/SC2 Home Page (che però è meno chiara della pagina Accredia):
- http://isotc.iso.org/livelink/livelink/open/tc176SC2public.

Ci tengo a sottolineare che questi documenti riportano pochi chiarimenti su come effettuare l'analisi del rischio richiesta dalla ISO 9001. Pertanto non esiste una "via giusta". Vedere anche un altro post:
http://blog.cesaregallotti.it/2015/09/iso-9001-e-risk-thinking.html.

Nota: aggiorno con questo il post, ora cancellato, del 24 settembre.

EN 319403 per i servizi fiduciari

È stata pubblicata la EN 319 403, dal titolo " Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers":
- http://uninfo.it/index.php/news/focus/item/pubblicata-la-norma-en-319403-nasce-l-accreditamento-per-la-conformita-dei-servizi-fiduciari

È applicabile ai fornitori di servizi che vorranno ottenere dall'AgID lo status di servizio qualificato. Tra questi servizi vi sono quelli relativi a:
- firme elettroniche, sigilli elettronici o validazioni temporali elettroniche, servizi elettronici di recapito certificato e certificati relativi a tali servizi;
- certificati di autenticazione di siti web;
- conservazione di firme, sigilli o certificati elettronici relativi a tali servizi.

Grazie ad Andrea Caccia per la segnalazione.

Valutatori e competenze

Prendo lo spunto da questo post di Paolo Perego:
- https://codiceinsicuro.it/blog/premetto-io-non-sono-uno-sviluppatore/.

Riassunto: chi fa i vulnerability assessment delle applicazioni dovrebbe avere un po' di esperienza di programmazione; in caso contrario le raccomandazioni per il miglioramento non possono essere pienamente adeguate.

Estendo e penso a auditor, assessor e alcuni consulenti (detti "advisor"), che spesso non hanno mai scritto una riga di procedura da condividere con tutte le parti interessate. Ho notato che sono spesso prodighi di "buoni consigli", senza però alcuna idea della loro fattibilità nel contesto di riferimento.

Piccolo aneddoto: recentemente ho seguito un audit. L'auditor si è proclamato ex programmatore. Ha fornito suggerimenti su tutto, con molto entusiasmo, ma senza chiedersi se fossero realmente applicabili e utili per l'azienda in cui si trovava (tra le tante: ha suggerito di usare diagrammi causa-effetto per individuare le cause di OGNI non conformità, ha chiesto di vedere un'analisi del rischio di ogni processo, ha suggerito di adottare ITIL per la gestione dei sistemi e della rete, malgrado le persone coinvolte fossero 8).

Per un solo settore non ha dato consigli: lo sviluppo delle applicazioni (eppure qualche idea sarebbe stata utile).

Perché? Perché incompetente in materia o perché capiva che, per quel contesto, era stato fatto il massimo? Forse la seconda.

Caso Volkswagen

Il caso è molto marginale per gli argomenti di questo blog:
- http://www.pressreader.com/italy/corriere-della-sera/20150923/281685433644490/TextView.

Però due riflessioni le faccio:
- se questi hanno fatto dei test tarocchi su un'automobile, perché stupirci quando gli sviluppatori di software meno critici fanno lo stesso?
- smettiamo di parlare male dell'Italia e degli italiani quando emergono queste cose: non è un problema di cultura nazionale, è un problema di cultura imprenditoriale. Tradotto: smettiamo di dire "qui è difficile applicare certe procedure perché siamo italiani" e cominciamo a dire "qui è difficile applicare certe procedure perché alla Direzione non interessa". Chissà che avere ben chiara la causa del problema renda meno difficile risolverlo.

Accordo USA-UE per i dati personali

Franco Ferrari mi ha segnalato il recente Umbrella agreement, accordo USA-UE per la protezione dei dati personali scambiati con la finalità di prevenzione, rilevazione, indagine e gestione dei procedimenti legali di reati, incluso il terrorismo:
- http://europa.eu/rapid/press-release_MEMO-15-5612_en.htm.

Da quanto capisco:
- per essere adottato in Europa deve essere ancora approvato dalla Commissione;
- l'accordo non introduce elementi peggiorativi della situazione attuale; forse la migliora.

Riflessione sulle sanzioni privacy

Pierfrancesco Maistrello di Vecomp, mi ha reso partecipe di qualche sua riflessione.

Anche lui ha notato la scarsa comprensione dei requisiti normativi vigenti presso alcune PA.

Relativamente ad un sistema biometrico, per far comprendere il problema ad un suo committente, ha pensato di utilizzare il vecchio e consumato asso nella manica del conto della serva: Violazione del 162, comma2-ter, cioè 30mila-180mila Euro.

E il data breach, nei conti della serva? Considerando anche le ipotesi aggravate dell'art.164-bis, l'ammontare è attorno ai 50-60mila Euro. Con le migliori delle attenuanti non si scende sotto i 12mila Euro.

Pierfrancesco mi chiede: chi compra o commissiona soluzioni biometriche o grafo-metriche questo lo ha capito?

Rispondo: probabilmente no, perché sperano sempre nello stellone o nell'inefficienza della giustizia italiana (a individuare i reati e sanzionarli).

ISO 9001 e "risk thinking"

Con la nuova ISO 9001, si richiede di identificare e "affrontare" i rischi, senza però fornire ulteriori dettagli.

Ho avuto l'occasione di raccogliere alcune indicazioni da Nicola Gigante, rappresentante italiano presso il ISO/TC176/SC2/WG24 (ossia il gruppo che ha elaborato la ISO 9001:2015), basate sulle indicazioni fornite da ISO e maturate nel corso della scrittura della norma stessa.

Si premette che la norma non richiede esplicitamente di documentare i rischi e le opportunità individuate; in altre parole, non è richiesto che le organizzazioni predispongano un'analisi dei rischi, ma che lo sviluppo, mantenimento e valutazione del sistema di gestione sia orientato da un approccio che metta la valutazione dei rischi al primo posto.

La norma non impone alcun approccio strutturato per affrontare rischi e opportunità: saranno le organizzazioni a decidere, con il rischio (!) che vi possa essere una generale banalizzazione del requisito.

Tuttavia va considerato che, come spesso accade a causa della natura "sistemica" della norma, anche in questo caso esiste una "circolarità": in altri termini, stabilire, da parte dell'organizzazione, con quale livello di approfondimento debba essere affrontata la gestione del rischio è essa stessa una operazione "risk-based", come tale soggetta a giustificazione e a valutazione di efficacia. Questo dovrebbe essere il primo effetto di un corretto orientamento al rischio.

In generale, organizzazioni semplici, di piccole dimensioni, con tecnologie consolidate e caratterizzate da un contesto stabile, non avranno effettivamente bisogno di strumenti sofisticati per mettere in pratica il "risk-based thinking". In tali realtà potrebbe essere sufficiente "lavorare" sugli atteggiamenti mentali di ciascuno, affinché ogni decisione - a livello strategico, tattico, e operativo - sia determinata da una sia pure intuitiva valutazione della concatenazione dei possibili eventi.

Nelle organizzazioni più grandi e complesse, invece, l'approccio al rischio dovrà verosimilmente essere di tipo più strutturato e potrebbe comportare la messa in atto di metodi, infrastrutture e competenze mirate. In caso contrario, cioè in presenza di un approccio riduttivo al tema del rischio, l'auditor chiederà ragione di ciò all'organizzazione, che dovrà fornire spiegazioni convincenti (cioè oggettivamente sostenibili).

In ogni caso l'efficacia dell'approccio dovrà essere dimostrata dall'organizzazione (vedere per esempio, al riguardo, il p.to 9.3.2 e, relativo al riesame di Direzione) e all'auditor spetterà valutare l'adeguatezza delle dimostrazioni (anche se rappresentate solo da argomentazioni).

E' evidente che questo "gioco" è possibile se vi sono competenze adeguate da entrambe le parti (organizzazione e auditor).

Mio (di Cesare Gallotti) parere personale: forse qualche indicazione in più sarebbe stata utile. Ora correremo il rischio (!) di vedere auditor imporre valutazioni del rischio molto dettagliate, altri accontentarsi di un'analisi SWOT generale e poi chissà che altro, con il risultato che le aziende, ancora una volta, non capiranno le motivazioni della ISO 9001, non ne coglieranno i benefici e, anzi, la rifiuteranno ancora di più.

Infine: ringrazio Nicola per avermi consentito la pubblicazione.

PA e adempimenti

Fabrizio Bottacin, dopo aver letto il mio post in merito al Provvedimento del Garante privacy sul data breach (http://blog.cesaregallotti.it/2015/08/privacy-comunicazione-compromissioni.html), mi ha comunicato alcune sue considerazioni che riassumo nel seguito.

Condivido con Fabrizio la necessità di rifletterci.

Il Provvedimento è un po' monco rispetto al D.Lgs. 82 del 2005 (Codice per l'Amministrazione Digitale). Questo riporta delle misure non applicabili solo dalla PA, ma anche da altri soggetti.

I gestori dei servizi pubblici, quindi PA o altri soggetti, devono adempiere ai dettami in materia di continuità Operativa (art. 50bis), sicurezza dei dati (art. 51), fruibilità del dato (art. 58), organizzazione dei servizi in rete (art. 63).

Ci sarebbero due riflessioni da fare, quindi:
- molti (come sappiamo) non sanno nemmeno che sono tenuti a questi adempimenti;
- il Provvedimento del Garante poteva essere esteso ai "gestori di servizi pubblici" e non solo alle PA.

Scadenze sul protocollo IT per la PA

Segnalo questo articolo (grazie a Giovanni Francescutti e Franco Ferrari di DNV GL) dal titolo "Gestione dei documenti informatici nella PA: scatta tra un mese (11 ottobre 2015) una scadenza cruciale":
- http://www.agendadigitale.eu/egov/gestione-dei-documenti-informatici-nella-pa-scatta-tra-un-mese-una-scadenza-cruciale_1660.htm

I toni sono molto giornalistici, ma il contenuto è interessante.

Corso di sicurezza IT del MIT

Il corso "Computer Systems Security" del 2014 MIT:
- http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-858-computer-systems-security-fall-2014/

Direi che bisognerebbe darci un'occhiata.

Gli esperti credono alle bugie

La mia traduzione del titolo della notizia è scorretta. Quello giusto sarebbe: "Quelli che si auto-proclamano esperti, hanno più probabilità di credere ad asserzioni false":
- http://www.washingtonpost.com/news/speaking-of-science/wp/2015/07/20/self-proclaimed-experts-more-likely-to-fall-for-made-up-facts-study-finds/

In sostanza: se elenchi ad un fan del rock indie dei gruppi inesistenti, ti rispondono che li conoscono o ne hanno sentito parlare; se chiedi a degli esperti di finanza se conoscono alcuni termini, più si sentono esperti, più è elevata la probabilità che conoscono anche quelli inesistenti (anche se dici loro che si tratta di un esperimento e alcuni termini sono inventati!).

L'articolo si conclude dicendo che, una volta ci si reputa un esperto, si smette di imparare e questo ci porta a non essere più esperti e a fare figuracce.

Mi è venuto in mente che, quando avete a che fare con dei consulenti (che si proclamano esperti), potreste chiedere loro di cose inesistenti e vedere l'effetto che fa (questo quando non sono già abbastanza esaltati di loro stessi e non dicono sciocchezze senza alcun invito...).

I manager parlano di sicurezza, ma poi...

La notizia è sempre la stessa, ma mi piace ribadirla perché un po' di polemica non guasta:
- http://www.csoonline.com/article/2978020/security-leadership/do-boards-of-directors-actually-care-about-cybersecurity.html.

In sostanza:
- una ricerca di CSO dice che il 60% dei responsabili della sicurezza delle informazioni fanno almeno una presentazione annuale ai manager;
- il 42 dei manager pensa che la sicurezza delle informazioni non sia un problema della Direzione.

Ognuno tragga le proprie conclusioni.

Check list

A luglio, con perfetto tempismo, ben tre clienti mi hanno chiesto cosa ne pensassi dell'uso di check list per gli audit. La mia risposta è stata: "non le ritengo utili, anzi, le ritengo dannose". Non sono un genio e a questa conclusione sono arrivato dopo aver usato delle check list e averne visto i difetti.

Come auditor di certificazione, la mia check list dovrebbe essere la norma di riferimento. Ovviamente, negli anni, ho creato degli appunti relativi ai requisiti più sintetici e ad alcuni settori merceologici; però non costituiscono assolutamente una check list.

Come auditor interno, i requisiti da verificare sono le procedure e regole interne, e quindi svolgo l'audit con quelle, non con un'altra cosa (le check list). Infatti: perché dovrei avere un documento di riferimento (la check list) diverso da quello che hanno le persone da intervistare (le politiche e le procedure)? Se ho difficoltà ad orientarmi tra regole e procedure, perché dovrei pretendere che non ne abbiano gli intervistati? Se ci sono regole scritte solo sulla mia check list e non nelle regole e procedure consegnate al personale, come posso pretendere che le seguano? Perché, quando necessario, invece di aggiornare un solo documento bisogna aggiornarne due? Come faccio a capire se una procedura è scorretta, incompleta o poco chiara se non la leggo insieme alla persona intervistata e mentre mi illustra come applica i requisiti stabiliti?

Anche qui non sono completamente impreparato: sul piano di audit riporto le procedure applicabili ad ogni intervista e prima di ogni intervista rileggo le procedure e mi segno i punti più importanti da verificare.

Certamente le check list compilate possono dimostrare che l'audit è stato fatto completamente. Ma anche un rapporto di audit, con riportate le procedure analizzate e le prove raccolte, lo può fare.

Privacy: comunicazione compromissioni nella PA

Il 2 luglio 2015 il Garante ha pubblicato il Provvedimento dal titolo "Misure di sicurezza e modalità di scambio dei dati personali tra amministrazioni pubbliche" (doc web 4129029):
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4129029.

In sintesi, il Garante richiede alle pubbliche amministrazioni di "comunicare al Garante, entro 48 ore dalla conoscenza del fatto, tutte le violazioni dei dati o gli incidenti informatici che possano avere un impatto significativo sui dati personali contenuti nelle proprie banche dati".

Insomma, si tratta di un'estensione della misura cosiddetta "data breach", finora prevista solo per i fornitori di servizi di telecomunicazione.

Spid - Un articolo

In precedenza avevo annunciato novità sullo Spid, Sistema pubblico di identità digitale. Franco Ferrari di DNV GL mi ha segnalato questo articolo, che mi pare chiarisca bene cos'è lo Spid e cosa succederà nel prossimo futuro:
- http://www.wired.it/attualita/2015/07/29/guida-spid-sistema-identita-digitale/.

Sicurezza applicazioni e apps

Un'altra puntata sulla sicurezza delle applicazioni informatiche.

Stefano Ramacciotti mi ha segnalato questo link con il commento "l'articolo dice un po' le solite cose, ma i link di approfondimento possono essere utili":
- https://www.checkmarx.com/2015/07/01/9-secure-coding-practices-you-cant-ignore/.

Vista l'ignoranza in materia, penso che anche l'articolo sia interessante (noto che alcuni link sono datati, ma incredibilmente attuali).

Dal NTT Security Blog, ho avuto invece notizia della pubblicazione (del 2014!) "OWASP Mobile Security Project - Top Ten Mobile Risks":
- https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks.

Altri standard: ISO/IEC 27033-1 e 27034-2

Segnalo la pubblicazione di altre due norme internazionali:

• ISO/IEC 27033-1:2015: "Information technology -- Security techniques -- Network security -- Part 1: Overview and concepts" (http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63461);
• ISO/IEC 27034-2:2015: "Information technology -- Security techniques -- Application security -- Part 2: Organization normative framework" (http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63461).

Sicuramente è stato interessante per gli autori scriverle. Per capire la sicurezza delle reti e delle applicazioni IT, raccomando però la lettura di altri manuali più pragmatici, pratici ed economici.

ISO/IEC 29190 - Privacy capability assessment model

È stata pubblicata la ISO/IEC 29190:2015 dal titolo "Privacy capability assessment model":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=45269.

L'intenzione è quella di presentare un metodo per valutare i processi relativi alla privacy, in linea con quanto già proposto dalla ISO/IEC 15504.

L'ho letta rapidamente e l'ho trovata: inutile (non aggiunge molto rispetto a quanto già presente nella ISO/IEC 15504 e nel Cobit) e pasticciata (dove aggiunge, si trova solo confusione).

Ora, però, i venditori di "assessment" hanno un'altra cosa da proporre.

Windows 10

È ora disponibile gratuitamente Windows 10 per chi ha Windows 7 e Windows 8. Probabilmente lo installerò, ma devo prima verificare se questo Windows 10 è anche "Pro" (come il mio Windows 8).

In molti mi hanno assicurato che è migliore di Windows 8, in termini di prestazioni e facilità d'uso.

Però ci sono almeno due problemi da approfondire.

Il primo riguarda la privacy: Microsoft ha capito che deve agire come Google, Facebook e Amazon, raccogliendo il maggior numero di dati possibili sui propri utenti e poterli usare (o rivenderli a chi li vuole usare) per finalità di marketing e pubblicità. Non riesco né ad esserne sorpreso né indignato,  visto che il mercato dell'informatica è ormai questo e tutti, chi più chi meno, ci siamo adeguati. Per adeguarsi un po' di meno, o si passa a Linux o si configura con attenzione il proprio sistema operativo Windows 10, come suggerito da questi articoli (ricevuti dalla newsletter SANS News Bytes):
- http://www.slate.com/articles/technology/bitwise/2015/08/windows_10_privacy_problems_here_s_how_bad_they_are_and_how_to_plug_them.single.html;
 - http://www.wired.com/2015/08/windows-10-security-settings-need-know/.

Altro aspetto riguarda la gestione delle wi-fi e il meccanismo Wi-Fi Sense: Windows 10 permette di condividere le password di accesso alle wi-fi a cui ci si è collegati con tutti i propri contatti Sype e Outlook. Cioè: io invito un mio amico a casa, gli do la password wi-fi e automaticamente tutti i suoi amici ce l'hanno. Non ho capito se è comunicata anche agli amici degli amici:
- http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/;
- http://www.zdnet.com/article/no-windows-10s-wi-fi-sense-feature-is-not-a-security-risk/.

Come fare, quindi, se, al contrario degli articoli citati, si pensa che questo sia un rischio? Modificare l'SSID della propria wi-fi aggiungendo "_optout":
- http://money.cnn.com/2015/07/30/technology/windows10-wifi-sense/

Problema: con i router ADSL Alice Telecom non è possibile modificare l'SSID (l'assistenza tecnica mi ha chiesto 9 Euro per dirmi come fare). Non mi sembra molto corretto, visto che si tratta di sicurezza...

Hacking e automobili

La notizia è nota da tempo: è possibile accedere via wi-fi al sistema di controllo di certe vetture e comandarle a distanza:
- http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ (in inglese);
- http://www.itespresso.it/fca-richiama-14-milioni-di-auto-hackerate-110191.html (in italiano, per quanto brutto).

La cosa incredibile, come già è stato dimostrato con gli aerei, è che l'attacco inizia con la compromissione del sistema di intrattenimento, da quale poi accedere al sistema di controllo. Questo la dice lunga sulla competenza di chi ha progettato questi sistemi (o dei loro responsabili che hanno imposto sistemi più economici): da sempre sappiamo che, per sicurezza, i sistemi più critici devono essere completamente isolati da quelli meno critici.

E, ancora una volta, si vede come gli sviluppatori (di qualunque livello) di sistemi informatici siano completamente disinteressati alla sicurezza, inclusi quelli che lavorano in ambienti da sempre attentissimi a questo aspetto.

Non avrei soluzioni da proporre. Forse nelle scuole e nelle università dovrebbero integrare meglio questo aspetto nelle materie (ma recentemente ho sentito presentazioni agghiaccianti da parte di "esperti di sicurezza" che tengono corsi in qualche università; dimostrando così che la selezione dei docenti per questa materia è ancora carente); forse dovremmo noi "esperti" trovare altre strade per promuovere la sicurezza (temo che i convegni con sole presentazioni commerciali o di tecniche "base" non siano sufficienti); forse Governo e Autorità varie potrebbero trovare ulteriori strade (ma ancora una volta si vede come in questi ambienti siano molto presenti degli "esperti" incompetenti).

Scusate lo sfogo.

Colgo l'occasione per riportare una cosa che mi ha scritto Andrea Rui: "Un tempo ero più disfattista, e pensavo che fosse un problema tutto italiano: vedendo ciò che è accaduto negli ultimi anni agli americani ed ai giapponesi mi sono reso conto che il problema è uniformemente distribuito, e che alcuni sono soltanto più bravi a far credere di essere migliori degli altri".

Negli USA vogliono proporre una normativa per la sicurezza informatica delle automobili. Ottima iniziativa, ma forse non sufficiente (anche perché riguarda solo le automobili):
- http://www.wired.com/2015/07/senate-bill-seeks-standards-cars-defenses-hackers/.

PS: segnalo anche questo articolo del The Economist:
- http://www.economist.com/news/science-and-technology/21657766-nascent-internet-things-security-last-thing-peoples.

Nel finale ricorda il tempo, lungo, passato prima che la sicurezza ferroviaria e delle automobili fosse presa seriamente.

Qualche commento sulla futura ISO 9001:2015

IRCA ha pubblicato un documento dal titolo "ISO 9001:2015: understanding the international standard". Purtroppo è disponibile solo agli iscritti.

Il documento riepiloga i cambiamenti maggiori rispetto all'edizione del 2008: l'adozione dell'Annex SL e, quindi, un maggiore allineamento con gli altri standard relativi ai sistemi di gestione; il maggiore coinvolgimento della Direzione, anche se solo attraverso il cambiamento del termine "impegno" con "leadership"; la necessità di analizzare non solo l'organizzazione ma anche il contesto in cui opera; l'introduzione di tecniche di valutazione del rischio e la promozione di un "pensiero basato sul rischio"; l'integrazione dei requisiti per i fornitori con quelli per gli outsourcer; l'uso di "informazioni documentate" al posto di "documenti" e "registrazioni".

Trovo molto interessante la parte relativa alle cose NON richieste a chi adotta il nuovo standard;

• non è necessario rimuovere il "referente della Direzione per il sistema qualità"; la norma non lo più richiede esplicitamente, ma non lo vieta neanche; si osservi che oggi è molto più chiaro il fatto che la responsabilità del sistema di gestione per la qualità è della Direzione, ma è anche vero che alcune attività di coordinamento e supervisione dovranno essere assegnate a qualcuno (segnalo che in passato mi divertivo molto ad osservare alcuni auditor perplessi perché in alcune aziende in cui ero consulente il "responsabile qualità" era il Direttore Generale o l'Amministratore Delegato; purtroppo non potrò più godere di questo discutibile divertimento);
• non è necessario buttare via tutti i manuali e le procedure già fatti: se li avete fatti bene, vuol dire che sono utili e vanno mantenuti; osservate che i processi e le attività devono comunque essere stabili e, quindi, un minimo di documentazione è raccomandata; forse vedremo meno documenti inutilmente lunghi per essere "a prova di auditor" e questo sarà un beneficio per tutti;
• rinumerare i documenti esistenti per allineamento con la nuova struttura della norma: io ho sempre pensato che fosse un errore numerare e ordinare i documenti come i capitoli della norma perché su certe cose è l'azienda che deve guidare, non la norma; comunque nessuno vi vieta di rinumerarli;
• riordinare i documenti per allinearli al nuovo standard: ancora una volta ho sempre pensato fosse molto stupido avere il manuale qualità numerato secondo la norma (ma, in Italia, Accredia l'aveva raccomandato...) perché un manuale scritto così spesso era di difficile lettura per il personale medio di un'azienda (e infatti non era usato come "manuale", ma come "presentazione" neanche tanto chiara, come ricordo bene dalle mie precedenti esperienze di lavoratore dipendente);
• modificare i documenti esistenti per adottare la nuova terminologia: non ho mai condiviso l'idea che chi adotta la ISO 9001 debba anche adottarne la terminologia (e, per esempio, usare "non conformità" e non "difettosità" o "azioni correttive e preventive" e non "azioni di miglioramento"), ma non la ritengo infondata; bisogna però evitare di modificare termini chiari ("procedure", "istruzioni", "registrazioni") con termini oggettivamente poco chiari ("informazioni documentate").

ISO/IEC TS 30104 su sicurezza fisica

Nel 2012 avevo annunciato l'avvio dei lavori della norma ISO/IEC TS 30104 dal titolo "Physical security attacks, mitigation techniques and security requirements":
- http://blog.cesaregallotti.it/2012/05/andamento-delle-norme-della-famiglia.html.

Questo standard è stato pubblicato a maggio 2015 (grazie a Franco Ferrari di DNV GL per l'informazione).

Speravo si trattasse di un documento relativo alla sicurezza fisica in generale (controllo accessi fisici, sorveglianza, anti-intrusione, eccetera), invece riguarda solo la sicurezza fisica dei dispositivi crittografici (HSM, smart card, eccetera).

ISO/TS 22317 e BIA

Franco Ferrari di DNV GL mi ha segnalato la prossima pubblicazione della ISO/TS 22317 dal titolo "Business continuity management systems -- Guidelines for business impact analysis (BIA)":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50054.

Rimango dell'idea che la SP 800-34 del NIST, dal titolo "Contingency Planning Guide for Federal Information Systems", è più chiara e utile (propone anche un modello da usare per la BIA):
- http://csrc.nist.gov/publications/PubsSPs.html#800-34.

Tripadvisor non risponde della veridicità delle recensioni

Sono sempre molto prudente quando leggo le recensioni di Tripadvisor e di siti simili. E ora ho confermata questa mia attitudine:
- http://www.altalex.com/documents/news/2015/07/22/tripadvisor-recensioni-tar-roma-9355-del-2015.

L'AGCOM aveva inizialmente individuato la diffusione di informazioni ingannevoli nelle recensioni su Tripadvisor e quindi scritto "Tripadvisor, infatti, pur dichiarando di non controllare i fatti contenuti nelle recensioni ed essendo a conoscenza che sul predetto sito vengono pubblicate false recensioni, sia di valenza positiva che negativa, da parte di utenti che non hanno effettivamente fruito dei servizi offerti dalle strutture presenti nel database...".

Poi il TAR del Lazio ha annullato la multa di AGCOM, basandosi sicuramente su aspetti legislativi corretti, ma a mio parere l'annosa questione della veridicità delle recensioni sui siti web rimane aperta.

Per chi volesse leggere la sentenza, l'ho trovata qui:
- http://www.eius.it/giurisprudenza/2015/196.asp.

ISO/IEC 27023 - Confronto versioni 27001 e 27002

La ISO ha pubblicato la ISO/IEC 27023:
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61005

Questa norma, dal prezzo di 118 Franchi svizzeri, riporta le tabelle di correlazione tra le versioni del 2005 e 2013 delle ISO/IEC 27001 e 27002.

Confesso che non ne ho seguito i lavori, visto che era già stato pubblicato un documento ufficiale a inizio 2014, tra l'altro liberamente scaricabile:
- http://www.jtc1sc27.din.de/cmd?level=tpl-bereich&languageid=en&cmsareaid=wg1sd3.

Per questo motivo non capisco perché sia stata pubblicata ora questa versione a pagamento, ben due anni dopo la pubblicazione delle nuove ISO/IEC 27001 e 27002.

Privacy e apps

Ivo Trotti di TNS Italia mi ha segnalato questo articolo:
- http://blog.wired.it/dirittifuturo/2013/04/15/privacy-e-app-le-regole-europee.html.

Il documento segnalato, dell'Article 29 Data protection working party, ha titolo "WP 202 - Opinion 02/2013 on apps on smart devices" ed è del febbraio 2013. L'argomento, ovviamente, è: come progettare le app (e i sistemi e processi ad esse correlati) per dispositivi mobili in modo da rispettare la privacy degli utilizzatori.

La notizia è un po' vecchiotta, ma in questo periodo mi sono trovato spesso a discutere con dei clienti in merito a questo aspetto e pertanto mi sembra opportuna.

Per completare, segnalo un mio post di dicembre 2013 con ulteriori link:
- http://blog.cesaregallotti.it/2013/12/studi-sicurezza-apps.html.

ISO/IEC TS 38501:2015 su Governance of IT

Tony Coletta, che ringrazio, mi ha permesso di leggere la norma ISO/IEC TS 38501:2015 dal titolo "Information technology - Governance of IT - Implementation guide".

Si tratta di 19 pagine. Se togliamo la parte introduttiva e la bibliografia, si riducono a 10.

Io segnalo che, prendendo spunto dal nuovo "testo unico" per norme dedicate ai sistemi di gestione (l'attuale ISO/IEC 27001, l'imminente nuova versione della ISO 9001), elenca i fattori che compongono il contesto dell'organizzazione, dividendoli in interni (strategie generali, propensione al rischio, prestazioni, cambiamenti strategici previsti e in corso, relazione tra i processi di "business" e IT, risultati degli audit cultura dell'organizzazione, impegno della Direzione, maturità, livelli di competenza, modello di erogazione dei servii informatici, rapporti con le organizzazioni partner) ed esterni (norme, leggi e regolamenti, tecnologia disponibile e come questa può ridefinire i modelli di organizzazione e la partecipazione delle persone, rischi e opportunità poste dalle nuove generazioni, mercato in cui opera l'organizzazione e concorrenza, aspettative dei clienti e dei consumatori, requisiti delle parti interessate).

Tony, a sua volta, mi ha segnalato l'appendice A, che riporta uno schema molto sintetico (una pagina) di assessment, evidentemente ispirato dalle norme SPICE, in 5 livelli: sconosciuto, non applicato, applicato parzialmente, applicato quasi completamente, applicato completamente.

Regolamenti SPID

Franco Ferrari di DNV GL mi ha segnalato la pubblicazione dei regolamenti AgID per i gestori dell'identità digitale (SPID). Una pagina web per capire di cosa si tratta e trovare i regolamenti è la seguente:
- http://www.agid.gov.it/notizie/2015/07/28/spid-al-il-sistema-laccesso-semplice-sicuro-ai-servizi-line-pa.

Copio la descrizione di SPID fornita da AgID: SPID è la nuova "infrastruttura paese" di login che permette a cittadini e imprese di accedere con un'unica identità digitale, in maniera semplice e sicura, ai ervizi on line della pubblica amministrazione e dei privati che aderiranno.

Il Regolamento tecnico richiede le certificazioni ISO 9001 e ISO/IEC 27001. Ad una prima lettura, le richieste mi sembrano fatte in modo corretto. Finalmente!

Ci sono altre bizzarrie, giusto per non sbagliare, tipo la necessità di prevedere, in certe occasioni, verifiche da parte di due organismi di certificazione.

Privacy: Linee guida in materia di Dossier sanitario

Pierfrancesco Maistrello mi ha segnalato le nuove "Linee guida in materia di Dossier sanitario" (4 giugno 2015) emanate dal Garante privacy:
- http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/4084632.

Una domanda che ci siamo fatti tutti e due riguarda i rapporti tra queste nuove linee guida e le "Linee guida in tema di Fascicolo sanitario elettronico (Fse) e di dossier sanitario" del 16 luglio 2009:
- http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/1634116.

Dovremmo leggerci con attenzione ambedue i provvedimenti e capire quali punti sono stati aggiornati.

Altra riflessione riguarda il termine "Linee guida": visto che poi sono usate come "normative", ci chiediamo perché non le titoli come "prescrizioni".

La guerra sulla crittografia

Segnalo questo lungo articolo (in inglese) su un argomento di attualità:
- http://www.dailydot.com/politics/encryption-crypto-war-james-comey-fbi-privacy/

In poche parole: l'FBI richiede ai produttori di software che fanno uso di meccanismi crittografici di mettere a disposizione delle forze dell'ordine una backdoor.

Ovviamente non è una buona idea (perché la backdoor potrebbe essere individuata anche dai "cattivi", perché ogni porta aperta è una vulnerabilità in più, perché nelle forze dell'ordine ogni tanto si trova una mela marcia, eccetera).

Questo articolo, quindi, ripercorre la vicenda attuale e il passato, citando Zimmerman, Clipper chip e altro.

Multitasking e produttività

Da Twitter (@A1SiteSolutions), segnalo questo articolo su come il multitasking uccida la produttività:
- https://blog.todoist.com/2014/05/13/how-multitasking-slows-your-brain-and-kills-your-productivity/

Trovo interessanti le premesse, ma non tutte le conclusioni (avere due schermi non mi sembra una buona idea; bloccare l'e-mail o i siti social non credo sia efficace: bisognerebbe proprio spegnerli). Ognuno può trovare il metodo che ritiene più opportuno (la pagina segnalata riporta dei link), ma credo sia opportuno essere consapevoli dei problemi del multitasking.

Hacking Team (Post scriptum)

Avevo scritto che la vicenda Hacking Team non è molto interessante per la sicurezza delle informazioni:
- http://blog.cesaregallotti.it/2015/07/hacking-team.html

Non ritratto la convinzione, ma segnalo alcune cose interessanti che ho visto su Twitter:
- @DanielaQuetti segnala un'utilità della vicenda: "Per fortuna c'è hacking team l'estate era diventata noiosa tra caldo e Grecia...;-)";
- un articolo di Francesco Paolo Micozzi sulla valenza giuridica dei software spia (il pezzo ha titolo "Il caso Hacking Team e il rinnovato interesse per i captatori informatici" e si trova qui: http://www.huffingtonpost.it/francesco-paolo-micozzi/caso-hacking-team-captatori-informatici_b_7775152.html);
- Firefox blocca l'avvio automatico di Flash per evitare che le sue vulnerabilità vengano sfruttate (http://twib.in/l/5LkqoMgMG9G);
- @SwiftOnSecurity ricorda i prodotti da installare per evitare gli attacchi: Microsoft EMET; MalwareBytes Anti-Exploit; HitmanPro.Alert (lo sta valutando).

Slide DFA Open Day 2015

Segnalo che sono disponibili le presentazioni del DFA Open Day del 2 luglio 2015:
- http://www.perfezionisti.it/proposte-formative/dfa-open-day-2015/

Alcuni argomenti: i PIN dei cellulari, VoIP Forensics, investigazione di immagini digitali, profilazione online, applicazioni mobile di dating, diritto all'oblio, NodeXL, applicazioni mobile nell'ambito sanitario, standard europeo per lo scambio di digital evidence, Forensic Acquisition of Website.

Buona lettura!

Pubblicata la ISO/IEC 27042

Segnalo che è stata pubblicata la ISO/IEC 27042 dal titolo "Guidelines for analysis and interpretation of digital evidence". In precedenza avevo dato notizie inesatte sul suo stato di approvazione e me ne scuso. In questo caso, ho visto la notizia della pubblicazione dalla newsletter del BSI.

Le norme ISO/IEC dedicate alla digital forensics sono quindi:
- ISO/IEC 27035 (molto parzialmente) - Information security incident management;
- ISO/IEC 27037 - Guidelines for identification, collection, acquisition, and preservation of digital evidence;
- ISO/IEC 27041 - Guidance on assuring suitability and adequacy of incident investigative method;
- ISO/IEC 27042 - Guidelines for analysis and interpretation of digital evidence;
- ISO/IEC 27043 - Incident investigation principles and processes.

Industriale: standard e linee guida per la sicurezza IT

Dalla newsletter di HSC segnalo questa pubblicazione del Clusif dal titolo "Cybersécurité des systèmes industriels: par où commencer? Panorama des référentiels et synthèse des bonnes pratiques":
- http://www.clusif.fr/fr/production/ouvrages/pdf/CLUSIF-2014-SCADA-Panorama-des-referentiels.pdf.

Il documento è in francese (e usa troppo il termine "cybersécurité" al posto di "sicurezza informatica"). Il lavoro è notevole: hanno analizzato più di 50 documenti dedicati alla sicurezza informatica in ambito industriale e li hanno categorizzati (in settori industriali, in base al livello di specializzazione, in base al livello tecnico o gestionale, in documenti base o di approfondimento).

Nel documento sopra segnalato sono rappresentati i 21 documenti ritenuti più rappresentativi. In un altro documento sono invece analizzati tutti uno per uno:
- http://www.clusif.fr/fr/production/ouvrages/pdf/CLUSIF-2014-SCADA-Annexes-Fiches-de-lecture.pdf.

"Merci" ai colleghi francesi.

Privacy impact assessment

Del Privacy impact assessment (PIA) si parla sempre più diffusamente.

La vigente Direttiva 95/46 richiede di "ridurre al minimo, mediante l'adozione di idonee e preventive misure di sicurezza, i rischi..." (secondo il testo del nostro Dlgs 196/2003). Il nostro sistema normativo prevedeva inoltre di redigere un Documento programmatico per la sicurezza con un'analisi del rischio relativo alla privacy.

Oggi le bozze di Regolamento Europeo in materia di privacy citano esplicitamente il Privacy impact assessment e alcuni lo stanno già prendendo in considerazione più seriamente dell'analisi del rischio prevista dal famigerato DPS (chissà perché).

Non conosco l'origine del termine, ma una breve ricerca su Google mi ha portato a leggere quelli della Homeland security USA. Essi, anche degli anni 2005-2006 sembrano delle informative estese:
- http://www.dhs.gov/privacy-impact-assessments

In Europa, per quello che è di mia conoscenza, si parla dei PIA dal 2009, quando la Commissione Europea ha emesso "Commission recommendation of 12 May 2009 on the implementation of privacy and data protection principles in applications supported by radio- frequency identification (notified under document number C(2009) 3200) - (2009/387/EC)" in cui si chiede agli operatori di applicazioni RFID di predisporre una "sintesi delle valutazioni degli impatti su privacy e dati " e di descrivere i "rischi verosimili relativi alla privacy, se esistenti, e all'uso di tag nelle applicazioni RFID e le misure che gli individuo possono prendere per mitigare quei rischi":
- https://ec.europa.eu/digital-agenda/en/news/commission-recommendation-12-may-2009-implementation-privacy-and-data-protection-principles

A quel punto, il Art. 29 WP (gruppo collegato alla Commissione Europea) ha emanato delle raccomandazioni per realizzare i PIA, complicando le cose, chiedendo un risk assessment e proponendo una sorta di linea guida abbastanza incompleta ma con una direzione precisa: identificare dei rischi (è proposta una lista di 15 minacce), valutarne gli impatti e la verosimiglianza, assegnare loro un livello (alto, medio, basso), descrivere i controlli di sicurezza, correlarli ai rischi (minacce) e specificare se il rischio risultante è accettable. La documentazione, del 12 gennaio 2011, si trova tra i documenti del WP 29; particolarmente importante è il " Annex: Privacy and Data Protection Impact Assessment Framework for RFID Applications":
- http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/index_en.htm

La situazione è ancora accettabile. Poi la Commissione Europea è passata alle smart grid e nel 2014 ha promosso un modello per realizzare i PIA. Un malloppo di 74 pagine, che promuove una distinzione tra "eventi temuti" e "minacce" (lo studioso che è in me rabbrividisce) e una loro valutazione basata su parametri quali: facilità di identificazione degli interessati, impatti sugli interessati, facilità di riuscità di un attacco, capacità delle minacce di sfruttare le vulnerabilità. Questo per fornire un livello di rischio su 4 livelli, descrivere i controlli e stabilire se sono sufficienti. I documenti (incluso il DPIA template) si trovano qui:
- http://ec.europa.eu/energy/en/topics/markets-and-consumers/smart-grids-and-meters

Le cose peggiorano ancora. Il CNIL (Garante privacy francese), a luglio 2015, ha proposto le proprie linee guida, ovviamente basate sul modello più complicato (quello per le smart grid), introducendo altri concetti un po' a caso come "sorgenti di rischio", anticipando l'analisi dei controlli rispetto all'analisi dei rischi e non fornendo indicazioni utili per correllare rischi e controlli. Sono in francese e in inglese:
- http://www.cnil.fr/linstitution/actualite/article/article/etude-dimpacts-sur-la-vie-privee-suivez-la-methode-de-la-cnil/;
- http://www.cnil.fr/english/news-and-events/news/article/privacy-impact-assessments-the-cnil-publishes-its-pia-manual/.

Ultimo attore: il ISO/IEC JTC1 SC27 WG5 che sta redigendo la ISO/IEC 29134, ora in stato di Committee Draft (cioè, nella migliore delle ipotesi, richiede altre 2 riletture tecniche e uscirà a fine 2016). Questa proposta ha un grande pregio: torna a chiedere un'analisi del rischio basata su due parametri (verosimiglianza e impatto).

Procedo con le conclusioni. Sono convinto della necessità delle analisi del rischio, ma quando vedo un eccesso di complicazione rabbrividisco perché capisco che la teoria (o la furbizia) sta prendendo il sopravvento sulla pratica. Spero che in questo campo non prendano troppo piede le interpretazioni "sbagliate" (come, per esempio, sono state quelle sulla custodia delle password e sul DPS iper-complicato, per citare quelle più ovvie).

Ringrazio Alessandro Cosenza di BTicino, che mi ha fornito molti dei riferimenti sopra citati.

Hacking Team

Può un blog o una newsletter o un twittatore che si occupano di sicurezza informatica non parlare di Hacking Team? Quindi lo faccio brevemente.

Segnalo un articolo in italiano e sintetico:
- http://www.massimomelica.net/hacking-team-spy-che-storia-di-cacca/

Quindi riassumo:
- un'azienda italiana vende armi (informatiche) a Governi anche non democratici;
- un'azienda di sicurezza informatica è stata vittima di un riuscito attacco informatico;
- sono disponibili su Internet dei nuovi exploit (ossia programmi che automatizzano alcuni attacchi informatici).

C'è qualche novità degna di discussione in blog, newsletter o tweet? Mi pare di no.

Certamente si può parlare di etica ("non si lavora con governi non democratici!"), di sociologia ("come è possibile che degli italiani brava gente lavorino per dei governi non democratici?"), di situazioni comico-avventurose ("lo spione è stato spiato con le sue stesse armi, ah ah ah") o della diffusione incredibile di tecniche di attacco informatico (per questo ho già segnalato la presentazione di Ramacciotti e Paganini). Ma sono tutti argomenti o non pertinenti o troppo ribaditi per dedicarci altro tempo.

Qualche lezione, comunque, è emersa. Per esempio che alcuni exploit di Hacking Team si applicavano a smartphone sbloccati (a seguito di jailbreak) e quindi è sconsigliato fare il jailbreak (per iPhone) e il rooting (per Android) del proprio smartphone. Ma anche questa è cosa nota è stra-nota.

E anch'io ho scritto troppo su questa storia. A meno che qualcuno non voglia segnalarmi degli articoli un po' più interessanti di quelli che ho già visto.

FDIS ISO 9001:2015

È disponibile la FDIS della futura ISO 9001. Ringrazio Franco Ferrari di DNV GL per avermelo segnalato. Ci saranno quindi le votazioni e ne è prevista la pubblicazione finale per il 22 novembre.

Le novità rispetto alla ISO 9001:2008 sono tante. E ne segnalo solo alcune.

La prima è relativa alla "valutazione del rischio", che sostituisce le azioni preventive. Il testo non è di facilissima comprensione (anche se chi ha già lavorato sulla ISO/IEC 27001:2013 lo conosce bene). Richiederà qualche aggiustamento al sistema di gestione per la qualità e all'approccio al sistema stesso. Come per gli "indicatori" introdotti dalla ISO 9001:2000, ci vorrà un po' di tempo perché organizzazioni, consulenti e auditor trattino queste novità correttamente. Nel frattempo, spero che nessuno faccia danni introducendo troppo fuffaware.

Altre novità riguardano la terminologia: "persone" al posto di "risorse umane", "informazioni documentate" al posto di "procedure documentate" e "registrazioni" e così via.

In alcuni casi, queste novità danno luogo a difficoltà di lettura. Per esempio, bisogna stare attenti a distinguere tra il mantenimento di informazioni documentate (ossia avere procedure documentate) e la conservazione di informazioni documentate (ossia avere registrazioni).

In molti si stupiranno della riduzione di procedure e registrazioni. In realtà bisogna prestare attenzione a non esagerare ed eliminare tutti i documenti. Forse però questa novità imporrà di vedere le procedure qualità come vere procedure o istruzioni e non come carta da fare per la certificazione. D'altra parte, sono numerosi i casi in cui le "vere" istruzioni non coincidono con le procedure presentate agli auditor. D'ora in avanti, sarà sempre più evidente la differenza tra la "carta per gli auditor" e i "documenti necessari".

Altra eliminazione importante è il manuale qualità, che negli ultimi anni era diventato sempre più un esempio di "carta da auditor" che non diceva nulla, frutto di un'errata interpretazione della norma.

Ulteriore eliminazione è il responsabile della qualità, in realtà già assente dalle ultime versioni, che richiedevano la presenza di un membro dell'Alta Direzione come referente per la qualità (mentre spesso il Responsabile per la qualità, nella migliore delle ipotesi, era un quadro o un primo livello). La responsabilità del sistema di gestione per la qualità è la Direzione, punto e basta.

Non ho accennato a molte cose. La norma è impostata in modo molto diverso da prima e un breve articolo non può esaurire l'elenco delle novità. Usciranno libri, si faranno corsi e presentazioni, si scriveranno articoli. Ancora una volta: tutti da leggere o seguire con attenzione, anche per evitare di incappare in interpretazioni fantasiose.

Storia dell'insicurezza su Internet

Una serie di tre interessanti articoli del Washington Post sulla storia dell'insicurezza di Internet:
- http://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/;
- http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/;
- http://www.washingtonpost.com/sf/business/2015/06/22/net-of-insecurity-part-3/.

Certo: è giornalismo, quindi l'attenzione è più sulle storie (la nascita di Internet, il protocollo BGP e il gruppo L0pht), ma il tutto è accurato e interessante.

A chi piacciono gli schemi, segnalo anche questo elenco di "date importanti":
- http://www.washingtonpost.com/graphics/national/security-of-the-internet/history/.

Prego di notare la ragione di fondo dell'insicurezza di Internet: volevano fare le cose in fretta e che funzionassero e la sicurezza era vista come un ostacolo; alla peggio, si sarebbero fatte le correzioni necessarie in un secondo tempo. Ancora oggi, purtroppo, questo è l'approccio.

Lombardia Informatica e privacy

Marco Fabbrini mi ha segnalato questo articolo:
- http://www.ilfattoquotidiano.it/2015/06/22/sanita-lombardia-appalti-milionari-poca-sicurezza-il-lato-oscuro-della-privacy-digitale/1782904/

In poche parole, un rapporto riservato di audit è uscito dalla società Lombardia Informatica; questo rapporto riguarda il sub-fornitore Santer e riporta 56 non conformità anche piuttosto gravi.

Ci ho messo un po' a inoltrare questa notizia per almeno due motivi. Il primo è un conflitto di interessi che non intendo spiegare; il secondo è che l'articolo è evidentemente scandalistico e volevo capire meglio quanto prenderlo per buono. Osservate, per dirne una, che la Regione paga a Santer 600 mila Euro al mese per il servizio, che comunque deve avere dei costi elevati a causa dei volumi del lavoro, mentre l'articolo li fa risultare dedicati alla sicurezza; inoltre la diffusione di un rapporto del genere mi fa pensare a manovre di potere che poco hanno a che fare con la sicurezza delle informazioni. Chiunque ha le (poche) competenze per interpretare gli estratti del rapporto capisce che non tutti i rilievi sono necessariamente gravi (per esempio, nessuna delle mancanze è in realtà prescritta dalle misure minime dell'allegato B del Codice privacy, ma così viene fatto credere).

Che dire poi la nota finale sul fatto che l'audit è stato fatto pagare a Santer Reply? Ottima per il "uomo della strada", ma ridicola per chi mastica la materia e sa perché il rischio si "condivide" con i fornitori, non si "trasferisce" ai fornitori.

L'effetto, quindi, è quello di vedere un bambino che urla come un ossesso per un taglietto al dito. La situazione, seppure non così drammatica, rimane inquietante e spero ritorni sotto controllo (essendo io stesso lombardo), perché un taglietto trascurato può avere conseguenze molto gravi.

User experience Vs. Design

Grazie a Marco Fabbrini per avermi segnalato questa meravigliosa foto sulle sfide tra user experience e design:
- https://twitter.com/arjunsethi/status/613473156469145600