Un riassunto sul GDPR (e il quaderno ANCI)

In tanti (tra cui Franco Ferrari di DNV GL, Pierfrancesco Maistrello e Daniela degli Idraulici della privacy) hanno segnalato questo quaderno dell'ANCI dal titolo "L'attuazione negli Enti Locali del nuovo Regolamento UE n. 679/2016 sulla protezione dei dati personali: Istruzioni tecniche, linee guida, note e modulistica":
http://www.anci.lombardia.it/documenti/7355-regolamento%20ue%20privacy%20ok_def.pdf.

Può essere utile criticarlo, in modo da fare un ripasso di alcuni punti salienti del GDPR. Così potrò essere criticato anche io per quello che scrivo.

Innanzi tutto prima dice che "è definita la nuova categoria di dati personali", che sono i cosiddetti "dati sensibili di cui al precedente Codice Privacy". Poi tutto il quaderno fa riferimento ai "dati sensibili". Il GDPR usa l'espressione "categorie particolari di dati personali ai sensi dell'articolo 9". Anche io uso l'espressione "dati sensibili" perché più pratica, avendo cura, a inizio di documento, di specificare cosa sono e come li designa il GDPR.

I Titolari e i Responsabili dei trattamenti sono visti come persone fisiche (dice che il titolare è il "Sindaco o suo delegato" e i responsabili sono "Dirigenti/Quadri/Responsabili di U.O."), mentre il GDPR lascia intendere che si tratta di strutture organizzative (le "aziende"), mentre le responsabilità personali, tranne il caso di singoli professionisti, sono da gestire con le normali deleghe interne di ciascuna organizzazione e non sono regolamentate dal GDPR. Per la verità non avrebbero dovuto essere regolate neanche dal Codice privacy e questo sarebbe stato più chiaro se non si fosse tradotto "processor" (che anche in altri contesti è sempre visto come organizzazione non singola persona) con "responsabile" e se poi non avessimo insistito per lasciare in vita la traduzione inesatta. Questa interpretazione è stata data anche da dirigenti e funzionari del GDP in diversi incontri pubblici, dicendo che negli anni hanno sempre visto il "responsabile interno" come figura non prevista dal Codice e il "responsabile esterno" come "responsabile e basta" (potevano scriverlo da qualche parte, visto che scrivono già tanto, così avremmo fatto meglio e io non avrei scritto alcune sciocchezze in passato; purtroppo non mi sembrano abbiano intenzione di scriverlo neanche in futuro).

Non sono competente di regolamenti comunali. Quello proposto, a mio parere, manca completamente di regole in merito alle misure di sicurezza da adottare (si limita a parlare di sistema di autorizzazione e di sistema antincendio).

Troppa enfasi è ancora data al consenso come base legale per il trattamento. Oggi sappiamo che le basi legali sono di 6 tipi.

Si sono dimenticati i trattamenti relativi al personale del Comune. Certamente i dati dei cittadini sono importantissimi e devono costituire il punto di maggiore attenzione per i Comuni quando si parla di protezione dei dati personali, però non trovo corretto dimenticarsi completamente dei dati del personale.

Interpreta in modo bizzarro il ruolo degli "incaricati" secondo il Codice privacy, dicendo che sono "sub-responsabili del trattamento". Non posso condividere questa lettura. Mi pare, anzi, che non venga colta la possibilità di designare gli incaricati (ossia autorizzare le persone a trattare i dati personali) in modo adeguato alle esigenze di controllo (reale) e efficienza ma, anzi, promuova il "vecchio" metodo basato su lettera formale firmate e controfirmata.

Ancora più bizzarramente prevede che il Titolare possa delegare un responsabile a nominare il DPO ("alla designazione del Responsabile per la Protezione dei Dati (RPD), se a ciò demandato dal Titolare"). Altra lettura che non posso condividere.

Mi ha fatto notare Pierfrancesco Maistrello che viene suggerita la tenuta di più registri dei trattamenti. Ancora una volta non posso condividere questo approccio.

L'ultima parte del documento (da pagina 43 a pagina 78) è costituita dalla "Guida all'applicazione del Regolamento europeo in materia di protezione dei dati personali" del Garante privacy. Lettura sempre utile.

PS: Francesco Pizzetti e Luca Leone, su LinkedIn hanno commentato dicendo che non bisognerebbe mai usare l'espressione "dati sensibili". Personalmente non vedo ragione oltre la purezza formale. Ho chiesto. Se avrò risposta, la diffonderò.

Libro bianco della cyber security in Italia

NOTA: l'edizione che ho letto, commentato e di cui ho fornito il link è quella del 2015. Me l'ha fatto notare Giancarlo Caroti. Mi scuso per l'errore. Mantengo comunque nel seguito il post originale (inutile nascondere i propri errori).

Franco Ferrari di DNV GL mi ha segnalato questo articolo dal titolo "Cybersecurity, ecco il Libro bianco (ma anche il Libro verde) sulla strategia italiana":
- https://www.corrierecomunicazioni.it/cyber-security/cybersecurity-libro-bianco-anche-libro-verde-sulla-strategia-italiana/.

Certo... l'autore sembra decisamente troppo entusiasta (sembra quasi abbia un debito di riconoscenza con qualcuno degli autori). E si dimentica di dare un link dove reperirlo. Eccolo qui:
- https://www.consorzio-cini.it/index.php/it/labcs-home/libro-bianco.

A me il link non funziona. Quindi l'ho trovato sul sito del Sole 24 Ore:
http://www.ilsole24ore.com/pdf2010/Editrice/ILSOLE24ORE/ILSOLE24ORE/Online/_Oggetti_Correlati/Documenti/Notizie/2015/11/CyberSecurity-Report.pdf.

L'ho letto rapidamente. Sembra ci siano dentro le "solite" (ma non per questo sbagliate o inattuali) idee e più un tono giornalistico che scientifico. Forse chi è più paziente di me se lo leggerà con attenzione e potrà segnalarci i punti più rilevanti (se già non evidenziati dall'articolo segnalato).

Servizio Serc, la forse futura PEC

Franco Ferrari del DNV GL mi ha segnalato questo articolo che presenta il SERC (Servizio elettronico di recapito certificato):
- https://www.agendadigitale.eu/cittadinanza-digitale/servizio-elettronico-recapito-certificato-cose-perche-pensionare-la-pec/.

Forse un giorno questo servizio, previsto dal Regolamento eIDAS, sostituirà la PEC. Per intanto: gli standard tecnici saranno pronti (forse) per febbraio 2019. Ma credo sia giusto informarsi, almeno un po', di cosa si tratta.

ISO 45001 sulla sicurezza dei lavoratori

Segnalo che è stata approvata e sarà tra poco disponibile la ISO 45001 dal titolo "Occupational health and safety management systems -- Requirements with guidance for use":
- https://www.iso.org/standard/63787.html.

Io non mi occupo di questa materia, ma credo sia importante sapere dell'esistenza di questo standard, visto che questa materia si interseca con la sicurezza delle informazioni.

Dati sensibili e cifratura

La notizia me l'ha data per primo Luca De Grazia, ma confesso che non ci avevo capito molto.

L'ho ritrovata su Altalex e quindi ho cercato di capirla meglio:
- http://www.altalex.com/documents/news/2018/01/09/privacy-banca-dati-sensibili.

Una persona si lamenta perché l'accredito sul suo estratto di conto corrente riporta nella causale la motivazione (il numero di Legge, che però riguarda due specifici casi sanitari). A fronte di questo, la Cassazione ha deciso che:
a) la Regione Campania (che ha fatto l'accredito) deve cifrare i dati, in quanto è previsto che i soggetti pubblici debbano cifrare i dati pesonali sanitari dal D. Lgs. 196 del 2003;
b) in forza di questo, anche la banca deve cifrare i dati personali sanitari.

A mio parere era già inappropriato chiedere agli enti pubblici di cifrare i dati personali sanitari, senza rendersi conto degli impatti di tale misura, la sua sostanziale inutilità e prevedendo differenza tra il pubblico e il privato.

Però qui i giudici si sono ritrovati davanti ad un problema, visto che un'altra normativa (un Regio Decreto del 1924!) impone di specificare nei mandati di pagamento la precisa indicazione dell'oggetto di spesa. Ma allora, se è richiesto di cifrarla, come sarebbe riportata nell'estratto conto del destinatario?

Mi rifiuto di studiare l' art. 409 del R.D. n. 827 del 1924, ma credo proprio che un'altra soluzione si renderà necessaria. O forse no?

Articolo su DR per piccole e medie imprese

Tom Keller, autore di questo articolo dal titolo "How to Disaster-Proof Your Business IT", mi ha contattato per presentarmelo:
- https://digital.com/blog/disaster-proof/.

Nulla di eccezionale, ma tutto corretto e, soprattutto, con il tono giusto: tecnico senza tragedie o esaltazioni.

Alla fine dell'articolo ci sono dei link. Quello più interessante è quello verso www.smallbusinesscomputing.com, che a sua volta presenta dei link a soluzioni di mercato.

Attenzione però ad una cosa: noi europei dobbiamo, preferibilmente e per evitare le complicazioni del GDPR, usare server in EU e non tutte le soluzioni proposte garantiscono questo aspetto.

Sviluppo sicuro delle applicazioni: il processo

Segnalo il mio ultimo articolo su ICT Security dal titolo "Sviluppo sicuro delle applicazioni: il processo":
- https://www.ictsecuritymagazine.com/articoli/sviluppo-sicuro-delle-applicazioni-processo/.

Ne approfitto per segnalare che sono a corto di idee. Se qualcuno ha degli argomenti da suggerirmi, lo invito a farlo.

Nuovo Cad (e conservazione) - Riferimenti corretti

In un precedente post avevo segnalato gli aggiornamenti al CAD, senza però fornire i riferimenti normativi esatti:
- http://blog.cesaregallotti.it/2018/01/nuovo-cad-e-conservazione.html.

I riferimenti normativi mi sono stati forniti da Luca De Grazie e Franco Ruggieri, che ringrazio. Il CAD (D.Lgs. 82 del 2005) è stato modificato, con decorrenza 18 gennaio 2018, dal D. Lgs. 217 del 2017.

Il nuovo CAD è disponibile su Normattiva:
- www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=

NB: il link diretto non sembra funzionare; è necessario copiarlo e incollarlo.

Linee guida AgID sullo sviluppo sicuro

Franco Ferrari di DNV GL mi ha segnalato la pubblicazione, da parte di AgID, delle "Linee guida per lo sviluppo del software sicuro":
- http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/cert-pa/linee-guida-sviluppo-sicuro.

Le ho sfogliate rapidamente e mi sembrano un lavoro di "compilazione", ossia di raccolta di varie metodologie, pratiche e linee guida. Si rimane un po' storditi dalla mole di materiale.

A questo si aggiunga che molte indicazioni, sopratuttto quelle di processo, sono quelle classiche da teorici: belle, rigorose e... estremamente onerose.

Se però si ha la pazienza di scorrerle, si trovano molte cose interessanti (a me hanno colpito soprattutto i paragrafi con le tecniche di codifica per i singoli linguaggi). Si aggiunga che non mi pare siano disponibili lavori simili e quindi questo è utilissimo per quanto vogliono studiare lo sviluppo sicuro oltre le Top 10 di OWASP.

Le basi della digital forensics (per la GdF ma non solo)

Segnalo questo articolo di Paolo Dal Checco dal titolo "Le basi della digital forensics nella circolare 1/2018 della Guardia di Finanza":
- https://www.ictsecuritymagazine.com/articoli/le-basi-della-digital-forensics-nella-circolare-12018-della-guardia-finanza/.

Penso sia un ottimo articolo di introduzione (e anche di approfondimento) sulla digital forensics, che prende spunto da una circolare della GdF.

Ritorna la notifica al Garante (nella Legge di Bilancio)

La Legge di Bilancio riporta anche delle indicazioni per la privacy. Faccio riferimento all'articolo 1, commi dal 1020 al 1025 (il comma 1162 fornisce ulteriori fondi al Garante).

La Legge 205 del 2017 si trova su Normattiva:
- www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2017-12-27;205.

Riassumento:
- si ripetono cose già note o comunque prevedibili sul ruolo del Garante (monitoraggio dell'applicazione del GDPR, verifiche, predisposizione di modelli di informativa);
- il Garante dovrà vigilare sulla "presenza di adeguate infrastrutture per l'interoperabilità dei formati con cui i dati sono messi a disposizione dei soggetti interessati, sia ai fini della portabilità dei dati" e quindi spero che capiremo meglio l'estensione del concetto di "portabilità";
- il Garante dovrà "definire linee-guida o buone prassi in materia di trattamento dei dati personali fondato sull'interesse legittimo del titolare"; sicuramente queste saranno utili anche per chi tratta i dati su altri fondamenti legali.

La cosa più inquietante si trova ai commi 2022 e seguenti: "Il titolare, ove effettui un trattamento fondato sull'interesse legittimo che prevede l'uso di nuove tecnologie o di strumenti automatizzati, deve darne tempestiva comunicazione al Garante per la protezione dei dati personali" usando un modello che il Garante metterà a disposizione presumibilmente entro fine febbraio 2018. In caso di silenzio, dopo 15 giorni, il titolare potrà procedere al trattamento, ma il Garante potrà comunque interromperlo (per un massimo di 30 giorni) per chiedere "ulteriori informazioni e integrazioni" o bloccarlo completamente "qualora ritenga che dal trattamento derivi comunque una lesione dei diritti e delle libertà del soggetto interessato"

Perché dico che è inquietante? Perché il GDPR, intenzionalmente, propone l'abrogazione delle "notifiche" al Garante, se non a seguito di PIA (privacy impact assessment) con risultati "negativi". Questo rimette nelle mani del titolare la valutazione della pericolosità dei propri trattamenti, contrariamente a quanto previsto dal Dlgs 196 che richiede, per tutti i trattamenti, la notifica al Garante. Sembrava un passo in avanti, ma il legislatore italiano si è dimostrato ancora una volta troppo paranoico e ha voluto aumentare le normative applicabili e ha voluto reintrodurre un simpatico strumento (la notifica) che speravamo superato.

Da notare un paio di cose:
- la notifica (anche se non si chiama più così) si applica solo ai trattamenti fondati "sull'interesse legittimo", ossia su una delle 6 opzioni su cui fondare un trattamento (legal ground);
- i trattamenti da notificare sono quelli che "prevedono l'uso di nuove tecnologie o di strumenti automatizzati"; ma oggi quasi tutti i trattamenti prevedono l'uso di strumenti automatizzati (notare la "o" disgiuntiva) e quindi la notifica andrà fatta per tutti i trattamenti fondati sull'interesse legittimo del titolare e quindi, per esempio, quelli per protezione aziendale (tutte le attività di videosorveglianza e di log degli strumenti informatici) e per il controllo qualità (quindi tutte le attività di archiviazione pratiche di qualsiasi ufficio, con riportato il nome di chi le ha redatte e approvate).

Sicuramente c'è qualche errore e sarà pubblicata una delle molte "interpretazioni". Però mi pare che l'errore sia grande. A meno che il Garante non voglia crearsi un registro delle imprese italiane.

Grazie a Paolo Calvi e Pietro Calorio degli Idraulici della privacy per la segnalazione.

Paolo Calvi rincara commentando: Così si scardina lo spirito del GDPR, basato sulla responsabilizzazione del titolare, che per trattamenti che rischiano di ledere diritti e libertà effettua una DPIA, e solo nel caso non riesca a mitigare i rischi si rivolge al Garante con la consultazione prevista dall'art.36. Qui invece sembra si voglia tornare al vecchio meccanismo della notificazione o richiesta di autorizzazione.

Nuova privacy per telemarketing

È stata approvata la nuova normativa sulla privcacy in ambito telemarketing. Non ho ancora il numero della norma e pertanto, non avendola ancora letta, evito commenti.

Ivo Trotti di Kantar Italia mi ha segnalato questo articolo da Repubblica:
- http://www.repubblica.it/economia/diritti-e-consumi/diritti-consumatori/2017/12/22/news/telemarketing_e_legge_l_obbligo_di_far_sapere_che_la_telefonata_e_commerciale-184917480/.

Roberto Gallotti (che è anche mio papà) mi ha segnalato questo dal Il Sole 24 Ore:
- http://www.ilsole24ore.com/art/notizie/2018-01-12/privacy-piu-facile-fermare-telefonate-indesiderate-214237.shtml.

Nuovo Cad (e conservazione)

A fine 2017 è stata pubblicato un aggiornamento al Codice per l'amministrazione digitale (CAD), che presenta interessanti novità.

Purtroppo non ho ancora disponibile il numero del Decreto (e non capisco neanche se si tratta di un DL o un DLgs) e su Normattiva non vedo il testo consolidato (l'ultima modifica è del novembre 2016).

Per chi vuole portarsi avanti con il lavoro, Franco Ferrari di DNV GL mi ha segnalato due articoli (un terzo lo segnalo qui, ma è citato da uno dei due).

Il primo ha titolo "Conservazione digitale, cosa cambia con il correttivo Cad":
- https://www.agendadigitale.eu/documenti/conservazione-digitale-cosa-cambia-con-il-correttivo-cad/.

Lo trovo molto interessante perché sintetizza efficacemente il processo di accreditamento dei conservatori e i problemi ad esso connessi.

Tra i problemi avrei aggiunto anche considerazioni sulla "perfettibilità" delle liste di riscontro predisposte da AgID e sull'eccessiva onerosità del processo di verifica. Lungi da me volere un processo che permette ai candidati inadeguati di passare la verifica, ma quello attuale è decisamente eccessivo, dimostrando un eccesso di normazione che diventa, in alcuni casi, inutile.

Gli altri due articoli (titoli "Correttivo CAD, le cinque novità principali" e "Il CAD numero 6 è in Gazzetta Ufficiale, che succede ora") contengono informazioni utili:
- https://www.agendadigitale.eu/cultura-digitale/correttivo-cad-le-cinque-novita-principali/;
- https://www.agendadigitale.eu/cittadinanza-digitale/il-cad-numero-6-e-in-gazzetta-ufficiale-che-succede-ora/.

VERA per privacy

Ho pubblicato sul mio sito il VERA per privacy, ossia un foglio di calcolo (Excel) per la valutazione del rischio relativo alla privacy:
- http://www.cesaregallotti.it/Pubblicazioni.html.

Potrebbe essere usata per dimostrare l'adeguatezza delle misure di sicurezza attuate e per realizzare una PIA. Si basa su VERA (Very easy risk assessment), versione 4.4.

Attenzione che questa versione, in italiano, è in versione alfa. Vi prego di inviarmi suggerimenti per il suo miglioramento.

Rispetto al "normale" VERA 4.4:

• aggiornato un poco il foglio di censimento delle informazioni e dei trattamenti;
• aggiunte, nei criteri di valutazione delle informazioni (o dei trattamenti), considerazioni in merito agli impatti sugli interessati (in precedenza si consideravano solo gli impatti sull'organizzazione);
• tolte le minacce senza impatto sulla privacy; 
• ridotto il numero di controlli di sicurezza (ossia privacy) a 62 (il VERA 27001 + privacy ne aveva circa 140);
• inserite note (molto sintetiche) per l'interpretazione dei controlli;
• corretto qualche refuso.

Nota: ho apportato qualche piccola correzione ai VERA 4.4 già pubblicati. Essendo pigro, non ho cambiato la versione dei file.

Pubblicata la nuova versione della SP 800-160 (Systems Security Engineering)

Il NIST ha pubblicato la nuova versione della SP 800-160 dal titolo "Systems Security Engineering":
- https://csrc.nist.gov/publications/detail/sp/800-160/final.

Confesso di non averla letta (è un malloppo di 160 pagine), ma ne avevo letto le versioni precedenti e non riesco a individuare i cambiamenti in questa (tranne gli errata, riportati in tabella). Sicuramente è un documento importante per chiunque si occupa di sicurezza.

Spectre e Meltdown

La vulnerabilità di inizio 2018 in realtà è doppia e si chiama Spectre e Meltdown.

Per ora il migliore articolo tecnico l'ho trovato sul National Cyber Security Centre (del GCHQ):
- https://www.ncsc.gov.uk/guidance/meltdown-and-spectre-guidance.

Trovo utile ricordare che:
- sono vulnerabili tutti i dispositivi e quindi è necessario aggiornare quelli personali (pc e smartphone), i server, gli apparati di rete (router, firewall, eccetera);
- i server includono gli hypervisor e le guest machine; in altre parole, chi ha i servizi "in IaaS sul cloud" non può ignorare il problema (questo conferma ancora una volta che chi usa servizi cloud deve comunque mantenere forti competenze al proprio interno);
- anche i compilatori vanno aggiornati e, dopo, tutto quanto compilato va ricompilato (questa verifica di sicurezza è fatta raramente, credo, anche perché oggi sono pochi i software compilati; ciò non ostante questo punto andrebbe meglio valutato in futuro).

La questione è esplosa su tutti i media. Passa un po' inosservato il fatto che "non risultano siano stati condotti con successo attacchi che sfruttano queste vulnerabilità". Quindi alcuni suggeriscono di affrontare queste vulnerabilità, ma senza entrare in "panic mode".

Tutelato il dipendente che segnala illeciti

Segnalo questa novità dal sito di Altalex: "Whistleblowing, in vigore le nuove norme: tutelato il dipendente che segnala illeciti":
- http://www.altalex.com/documents/leggi/2017/11/16/whistleblowing.

Copio e incollo: "il dipendente che segnala al responsabile della prevenzione della corruzione dell'ente o all'Autorità nazionale anticorruzione o ancora all'autorità giudiziaria ordinaria o contabile le condotte illecite o di abuso di cui sia venuto a conoscenza in ragione del suo rapporto di lavoro, non può essere - per motivi collegati alla segnalazione - soggetto a sanzioni, demansionato, licenziato, trasferito o sottoposto a altre misure organizzative che abbiano un effetto negativo sulle condizioni di lavoro".

Inoltre: "Le nuove disposizioni valgono anche per chi lavora in imprese che forniscono beni e servizi alla Pa".

VERA 4.4 per ISO/IEC 27001 e privacy

Ho pubblicato VERA 4.4 per ISO/IEC 27001 e privacy. Si trovano sul mio sito:
- http://www.cesaregallotti.it/Pubblicazioni.html.

Ringrazio per i suggerimenti: Nicola Nuti, Roberto Obialero, Antonio Salis.

Ora mi dedicherò al VERA "solo privacy", che sarà una "riduzione" di questo VERA.

Come sempre: vi prego di farmi sapere se trovate errori (temo ce ne siano tanti) o avete suggerimenti. Inoltre: chi vorrà vedere la bozza di VERA "solo privacy", me lo faccia sapere che lo invio appena pronto.

Segnalo che ho cambiato un poco il VERA "solo 27001": Roberto Obialero mi ha suggerito di cambiare alcune descrizioni di minaccia che ho accolto (ma non ho cambiato versione al file, consapevole che non ho seguito la pratica corretta).

Il tracciamento delle email

Per un Natale sempre più sereno, ecco qui un articolo (sempre segnalato dalla newsletter di Bruce Schneier) sul tracciamento delle email:
- https://www.wired.com/story/how-email-open-tracking-quietly-took-over-the-web/.

Mi chiedevo come MailUp faccia a dirmi quante persone hanno aperto la mia newsletter. Ora lo so. Ma so anche che non è solo MailUp che fa uso di questi meccanismi. Anzi: il 40% del traffico email è tracciato. E permette di sapere che le email indirizzate al CEO di Apple sono aperte con un pc Windows.

Amazon Keys

Non sapevo che esistessero chiavi di casa di questo tipo: per facilitare le consegne (e non lasciare il pacco di Amazon fuori casa), Amazon si è inventato le serrature che può aprire autonomamente. Quindi, nel caso più "automatizzato", il trasportatore segnala ad Amazon e al cliente che è fuori dalla porta, arriva un SMS al cliente che può guardare cosa succede con una webcam fornita da Amazon stessa, Amazon apre la porta a distanza, il trasportatore lascia il pacco appena dentro casa e poi chiude la porta.

Tutto ciò mi dà i brividi, per motivi che dovrei ben capire. Però il timore che tutto questo meccanismo possa essere attaccato è uno dei motivi. Parte di esso, ossia la telecamera, lo è già stato:
- https://www.wired.com/story/amazon-key-flaw-let-deliverymen-disable-your-camera/.

Ho seguito dei progetti in ambito IoT e so che parte delle persone che sviluppano queste cose sono professionali e preparate. Ma non tutte. E comunque penso che troppa automazione, oltre a ridurre le nostre capacità di elaborazione mentale, aumenti eccessivamente le possibilità di attacco. Forse è un problema solo mio.

Sicurezza informatica (per i singoli)

Questo mese Bruce Schneier, nella sua newsletter, suggerisce alcune guide per la sicurezza dei dispositivi personali (pc Windows e Mac, Android, iPhone) e la navigazione Internet.

Mi piace diffondere i suoi suggerimenti:
- https://motherboard.vice.com/en_us/article/d3devm/motherboard-guide-to-not-getting-hacked-online-safety-guide;
- https://ssd.eff.org/en;
- https://www.johnscottrailton.com/jsrs-digital-security-low-hanging-fruit/;
- https://www.frontlinedefenders.org/en/resource-publication/digital-security-privacy-human-rights-defenders.

Sono tutti piuttosto lunghi, anche se (ovviamente) non difficili.

Inoltre mi ha scritto John Mason (trovandomi su Google) per segnalarmi questo suo articolo, che è decisamente semplice e quindi un ottimo punto di partenza:
- https://thebestvpn.com/online-privacy-guide/.

Qualche spunto sul DPO

Il (solito) Pierfrancesco Maistrello mi ha segnalato che il Garante ha aggiornato le faq sul DPO ed emanato uno schema tipo di nomina e un modello per comunicare al garante gli estremi del DPO:
- http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/7322110.

La notizia è poi finita sulla newsletter del Garante, ma Pierfrancesco me l'ha fornita con largo anticipo insieme a qualche commento che io riprendo:
- lo schema di nomina del DPO è standard, quindi non lascia spazio a nulla di eccitante, ma è comunque comodo;
- la nomina del DPO per società in-house o partecipate di PA non è obbligatoria, ma fortemente consigliata;
- la posizione del DPO interno (dirigente, o "funzionario di alta professionalità", che sia in contatto con il vertice) non sembra di immediata individuazione in tutte le tipologie di PA;
- certificazioni DPO: utili solo come indicazione di competenze;
- come si nomina: schema tipo, più comunicazioni al garante dei suoi estremi;
- interessante notare che: il DPO nelle FAQ del Garante è sempre una persona fisica;
- può esserci più di un DPO? domanda interessante per le grandi PA, ma la risposa è NO, il DPO è uno, gli altri sono figure di supporto per lui (sia interno che esterno);
- cosa può fare il DPO oltre a quello che prevede la normativa? Difficile dirlo, visto che questo punto è in garantese stretto, che non dice nulla di nuovo, ma conferma che è il titolare a decidere se assegnare altri compiti a figure già ingolfate di attività (ad esempio il responsabile per la prevenzione della corruzione o altri ruoli) o come assegnare compiti in assenza di conflitto di interessi.

In definitiva, le FAQ diradano qualche nebbia, ma non completamente.

Strumento PIA del CNIL

L'autorità francese per la privacy (il CNIL), ha pubblicato uno strumento per realizzare le PIA:
- https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment.

La segnalazione mi arriva da Pierfrancesco Maistrello, che l'ha analizzato molto rapidamente e l'ha trovato facile da usare.

Personalmente rilevo che le misure di sicurezza da considerare non sono incluse nel prodotto (ho analizzato la versione beta, quella disponibile ad oggi). Queste sono comunque presenti nelle linee guida sempre del CNIL (già segnalate a suo tempo):
- https://www.cnil.fr/en/guidelines-dpia.

In definitiva mi sembra uno strumento che aiuta la scrittura del rapporto; una sorta di "indice sofisticato". Non voglio ridurre l'importanza di questo strumento, che rappresenta un punto di vista autorevole e di buona qualità. Anzi, sono contento che questo prodotto sia stato progettato considerando le reali necessità degli utilizzatori, e non le elucubrazioni di qualche "saggio nella torre d'avorio" (come siamo troppo spesso a vedere in troppi documenti o prodotti italiani quando si parla di conformità a normative).

Enisa - Raccomandazioni sulle certificazioni privacy

Paolo Sferlazza di @ mediaservice mi ha segnalato il documento dell'ENISA dal titolo "Recommendations on European Data Protection Certification":
- https://www.enisa.europa.eu/publications/recommendations-on-european-data-protection-certification.

Qualche interpretazione del documento:
1- la certificazione richiamata dal GDPR non è per prodotti, ma per "elaborazioni di dati" (processing of data); la certificazione può includere prodotti, sistemi o servizi, ma nell'ambito di trattamenti effettuati; il mercato potrebbe comunque proporre schemi di certificazione per prodotti;
2- gli enti di Accreditamento potrebbero sviluppare schemi propri, senza l'appoggio dell'autorità garante e che non è necessario l'appoggio del board dei garanti europei (interpretazione che io e altri non condividiamo).

Ad ogni modo, il documento è molto criticabile perché, in definitiva, non presenta correttamente le certificazioni dei sistemi di gestione (lascia intendere che le certificazioni ISO/IEC 27001 riguardano solo la presenza di procedure, non la loro efficacia; ma questo è palesemente falso).

Presentazione sulle certificazioni privacy

Il 30 novembre 2017, ad un convegno organizzato dal Dipartimento di scienze giuridiche dell'Università degli studi di Milano, ho fatto una presentazione sullo stato delle certificazioni privacy. Si trova a questo indirizzo:
- http://www.cesaregallotti.it/Pubblicazioni.html.

Già la sera stessa era vecchia perché era giunta la notizia della pubblicazione della UNI 11697 sulle certificazioni delle competenze in materia di privacy.

ENISA Baseline Security Recommendations for IoT

Alessandro Cosenza di BTicino mi ha segnalato questa pubblicazione di ENISA (l'ente europeo per la sicurezza IT) dal titolo "Baseline Security Recommendations for IoT" a cui ha collaborato:
- https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot.

Personalmente penso si sarebbe potuto fare ancora di più, specificando meglio le misure di sicurezza suggerite. Però mi rendo conto che non è questo l'obiettivo di questo documento.

Devo dire che il documento è molto interessante e c'è molto materiale da studiare.

Modifiche al Codice privacy

E' stata pubblicata in Gazzetta Ufficiale la Legge 167 del 20 novembre 2017:
- www.gazzettaufficiale.it/eli/id/2017/11/27/17G00180/sg.

Qui ci sono alcuni punti interessanti (e criticabili):

- l'articolo 24 stabilisce che ora i dati di traffico telematico vanno conservati per 72 mesi (6 anni), mentre in precedenza la durata era di massimo 2 anni; in tanti dicono che è follia; io non ho ancora capito se in questi anni questi dati sono serviti;

- l'articolo 28 allinea la nomina di responsabile del trattamento a quanto previsto dal GDPR, sicuramente inutilmente (e senza una ragione apparente), visto che tra pochi mesi entrerà in vigore proprio il GDPR e quindi questa modifica non era proprio necessaria;

- sempre l'articolo 28 prevede che il Garante pubblichi "schemi tipo" per stipulare accordi con i responsabili; ad ora mi risulta siano disponibili solo quelli per il trasferimento dei dati extra-UE; mi pare un po' strano questo obbligo di usare "schemi tipo" (la formulazione del requisito non mi pare lasci margini di manovra); Pierfrancesco Maistrello mi segnala che forse questo è per evitare che i contratti stipulati oggi con la PA siano messi in discussione a maggio;

- sempre l'articolo 28 impone restrizioni nel riutilizzo dei dati per finalità di ricerca scientifica o per scopi statistici; ci sono un paio di questioni bizzarre: la richiesta di autorizzazione preventiva al Garante, nonostante il GDPR, volontariamente, non la preveda più, e l'introduzione del silenzio-rigetto (ulteriore aberrazione);

- l'articolo 29 stanzia maggiori fondi al Garante e permette l'aumento di organico (mi viene da pensare che prevedono maggiori introiti grazie alle nuove sanzioni amministrative).

Sembra che questo non sia il provvedimento per allineare la 196 al GDPR. Per quello dovremo aspettare un altro atto.

Criteri per scegliere il DPO

Pierfrancesco Maistrello mi ha segnalato tre begli articoli (in inglese) su come scegliere il DPO.

Il primo ha titolo "What skills should your DPO absolutely have?":
- https://iapp.org/news/a/what-skills-should-your-dpo-absolutely-have/.

Il secondo ha titolo "Outsourcing your DPO: Questions to ask":
- https://iapp.org/news/a/what-to-ask-your-potential-dpo/.

Il terzo ha titolo "How to contract with your outsourced DPO":
- https://iapp.org/news/a/how-to-contract-with-your-outsourced-dpo/.

Aggiungo che sappiamo bene che il DPO non è sempre necessario in tutte le organizzazioni. Però le stesse cose sono applicabili (con pochi cambiamenti) anche ai consulenti privacy e (con maggiori cambiamenti) a tutti gli altri consulenti.

Il caso Uber

Prendo spunto da questi due articoli di DarkReading:
- https://www.darkreading.com/attacks-breaches/ubers-security-slip-ups-what-went-wrong/d/d-id/1330496;
- https://www.darkreading.com/application-security/git-some-security-locking-down-github-hygiene/d/d-id/1330511.

Il primo riassume il caso Uber: a ottobre 2016 dei malintenzionati sono riusciti a raccogliere i dati di 57 milioni di autisti e clienti di Uber; Uber li ha pagati 100mila dollari per cancellare i dati rubati e non divulgare la notizia. La notizia si è però diffusa e Uber è ritenuta colpevole di non aver avvisato gli interessati della violazione ai loro dati personali (misura del GPDR, nuova per alcuni, ma già presente in altre normative).

Il secondo articolo discute le questioni tecniche, altrettanto interessanti. Gli sviluppatori usavano un ambiente GitHub, in cui archiviavano codice e dati, inclusi quelli poi compromessi. Qui i punti dolenti sono vari: gli sviluppatori non avrebbero dovuto avere accesso a quella mole di dati, né salvarli in un ambiente non completamente controllato.

GitHub ha sicuramente messo a disposizione degli sviluppatori una serie di strumenti per assicurare la sicurezza dei dati (controllo di assenza di dati critici, di configurazioni e di credenziali, il controllo accessi solo a utenti "aziendali" e non "pubblici", l'impostazione degli archivi come "privati", la possibilità di verificare le autorizzazioni, la possibilità di attivare la strong authentication), ma probabilmente non erano stati attivati (ci si chiede anche se l'uso di GitHub era stato in qualche modo analizzato dai responsabili della sicurezza di Uber, oppure se era un'iniziativa degli sviluppatori).

GPG 2018 per la business continuity

È stata pubblicata la nuova versione delle Good practice guidelines del BCI:
- https://www.thebci.org/training-qualifications/good-practice-guidelines.html.

Sono il riferimento per quanto riguarda la business continuity e mi sembrano ben fatte.

UNI 11697 per le certificazioni delle competenze privacy

E' stata pubblicata la UNI 11697:2017, che definisce le competenze dei professionisti che si occupano di privacy.

Credo che l'articolo su Linea EDP sia più che esplicativo (anche dove ricorda il far west:
- http://www.lineaedp.it/news/33253/attivita-professionali-non-regolamentate-la-norma-uni/.

Dove comprarla:
- http://store.uni.com/catalogo/index.php/uni-11697-2017.html.

Qualche nota amena:
- grazie a Pietro degli Idraulici della privacy e Franco Ferrari per avermi dato la notizia per primi;
- Monica Perego ha fatto notare che il numero della norma UNI (finisce per 697) è un anagramma del numero del GDPR (679);
- il giorno stesso della pubblicazione avevo tenuto una presentazione in cui avevo detto "chissà quando sarà pubblicato"; accipicchia!

Mio articolo "ISO/IEC 27018: Cloud e Privacy"

Su ICT Security è stato pubblicato il mio articolo dal titolo "ISO/IEC 27018: Cloud e Privacy":
https://www.ictsecuritymagazine.com/articoli/isoiec-27018-cloud-privacy/.

Mio intervento l'11 dicembre a Napoli

Lunedì 11 dicembre terrò un intervento per l'evento "Sicurezza delle informazioni" organizzato da ITAdvice a Napoli, presso il Grand Hotel Parker's.

L'evento sarà la mattina e, oltre al mio, ci saranno interventi di Massimiliano Musto, Silvio Tortora Maione, Biagio Lammoglia, Emanuela Franco.

Su LinkedIn e Twitter posterò, quando sarà disponibile, il link ufficiale all'evento.

Personalmente sono molto contento di partecipare perché avrò l'opportunità di confrontarmi con Biagio su come mettere insieme in modo furbo la 27001 e il GDPR (da notare che saremmo capaci di metterli insieme in modo non furbo!).

Mio intervento il 30 novembre alla Statale di Milano (e iscrizioni Corso di Perfezionamento)

Segnalo questo evento in cui interverrò:
- https://www.linkedin.com/feed/update/urn:li:activity:6336633715602653184.

30 novembre 2017 ore 15-19 Statale di Milano.
"Dalla data protection alla data governance: il GDPR". Previsto intervento prof. Francesco Pizzetti.

Un sacco di gente interessante (chissà io che ci faccio).

Questo evento è collegato al Corso di perfezionamento "Data Protection e Data Governance" promosso dalla Statale di Milano. E' possibile presentare la richiesta di ammissione entro il 12 dicembre:
- http://www.unimi.it/studenti/corsiperf/112084.htm.

Delega al Governo per modificare il Dlgs 196 del 2003

Legge di delegazione europea 2016-2017. L'articolo 13 tratta proprio del D. Lgs. 196 del 2003 (Codice privacy):
http://www.altalex.com/documents/news/2017/11/07/legge-di-delegazione-europea-2016.

In poche parole: il D. Lgs. 196 sarà modificato per abrogare quanto in contrasto con il GDPR e allineare tutto ciò che c'è da allineare. Non darò notizie sulle varie bozze del D. Lgs. 196 modificato perché non credo sia utile agitarsi per delle bozze.

Ringrazio Pietro degli Idraulici della privacy (e Monica Perego per averli creati).

Stato delle norme ISO/IEC 270xx - Novembre 2017

Dal 30 ottobre al 3 novembre 2017 si è tenuto a Berlino il 56mo meeting del ISO/IEC JTC 1 SC 27, ossia del gruppo che si occupa delle norme internazionali della serie ISO/IEC 270xx, dei Common criteria e della privacy.

Questa volta ho partecipato molto poco ai lavori (la delegazione italiana era composta da 4 persone: me, Fabio Guasconi, Stefano Ramacciotti e una rappresentante del Garante privacy). Ciò non ostante, segnalo le cose a mio avviso più interessanti (ringrazio gli altri 3 delegati per aver verificato l'assenza di errori da questo mio resoconto, e per aver fornito alcuni contributi; le opinioni espresse sono unicamente mie).

ISO/IEC 27005 (information security risk management): di questa norma verrà pubblicato a breve un aggiornamento; si tratta in realtà di correzioni necessarie per l'allineamento ad altre norme. Nella sostanza non cambierà nulla. Le discussioni per una nuova versione della norma, con contenuti aggiornati allo stato dell'arte, stanno comunque proseguendo.

ISO/IEC 27006 (requisiti per gli organismi di certificazione): sono stati rilevati possibili errori nella norma e sono pertanto in fase di studio.

ISO/IEC 27552 (Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy management – Requirements and guidelines). A mio parere si tratta di uno schema troppo oneroso, visto che richiede, come prerequisito, la certificazione ISO/IEC 27001. Penso che anche altri stiano maturando lo stesso sospetto, ma questo non è emerso compiutamente durante il meeting (confesso che io stesso sono indeciso perché vedo sì uno standard poco invitante, ma forse uno standard più "leggero" sarebbe da evitare in quanto potrebbe avere conseguenze negative). Vedremo come evolveranno le cose: lo standard è ancora in stato di CD e si prevede la pubblicazione a novembre 2019.

Tra l'altro, mi hanno spiegato che forse la ISO/IEC 27552 non sarebbe lo schema di certificazione privacy previsto dal GDPR: essa è infatti uno standard per sistemi di gestione, mentre il GDPR richiede che gli organismi di certificazione lavorino in conformità alla ISO/IEC 17065, norma relativa alla certificazione di prodotti, processi e servizi e non ai sistemi di gestione. Sono in corso riflessioni in merito, dimostrando così che la faccenda non è banale.

Stanno proseguendo i lavori per altre norme, in particolare:
- ISO/IEC 27102 (Guidelines for cyber insurance);
- ISO/IEC 27002, per una nuova impostazione dei controlli, auspicabilmente più snella (da pubblicare tra qualche anno);
- ISO/IEC 27008 (Guidelines for the assessment of information security controls).

Il gruppo che si sta occupando di Common Criteria (ISO/IEC 15408), ha avviato la revisione delle norme (quindi le nuove versioni saranno pubblicate tra qualche anno). L'obiettivo è quello di pubblicare la versione 4 dei CC nel 2020. Lo standard sarà articolato su un maggior numero di volumi dell'attuale e si preannunciano importanti novità che tengono conto della notevole evoluzione che c'è stata in questi anni.

Sarà a breve pubblicata la ISO/IEC TR 27103, dal titolo "Cybersecurity and ISO and IEC Standards" (si tratta di uno studio che, in parole povere, ricorda che la cybersecurity, così come intesa dal CSF del NIST, è già inclusa nelle ISO/IEC 27001 e ISO/IEC 27002).

Sono stati aperti ulteriori studi in merito alla possibilità di pubblicare ulteriori standard sulla cybersecurity, posto che la prima necessità è quella di concordare in cosa si distingue dalla "sicurezza delle informazioni".

Ulteriore elemento di interesse è l'avvio di uno Study period per discutere dell'utilità (o meno) dello Statement of applicability (o Dichiarazione di applicabilità). Di questo si era discusso molto durante la redazione della ISO/IEC 27001:2013, ma senza, in realtà, che i sostenitori delle diverse posizioni si ascoltassero veramente. Personalmente non sono convinto né della sua utilità né della sua inutilità, ma spero che questo Study period sia l'occasione per capire meglio tutte le posizioni e arrivare più sereni alla redazione della prossima versione della ISO/IEC 27001 (tra qualche anno).

Il prossimo meeting si terrà a Wuhan, in Cina, a metà aprile 2018.

Rischi delle tecnologie sanitarie

Marco Fabbrini, che ringrazio, mi segnala il report "Top 10 Health Technology Hazards for 2018" dell'ECRI Institute:
- https://www.ecri.org/Pages/2018-Hazards.aspx.

Ecco cosa mi scrive Marco: "Alla fine i rischi sulla sicurezza IT sono arrivati in cima alla classifica. In particolare da notare il primo della classifica (Ransomware and Other Cybersecurity Threats), ma anche il nono (Flaws in Medical Device Networking Can Lead to Delayed or Inappropriate Care).

Il nuovo regolamento MED, per fortuna, prende in considerazione in maniera forte gli aspetti legati al software ad alla parte IT, punto molto debole fino ad oggi nella gestione dei dispositivi e sistemi medicali".

VERA 4.4

Ho pubblicato le nuove versioni (in inglese e italiano) di VERA, il mio foglio di calcolo per la valutazione del rischio relativo alla sicurezza delle informazioni. Siamo alla 4.4.

Non grandi cambiamenti, tranne l'aggiunta di una minaccia ("perdita di fornitori").

Ho poi corretto alcuni (troppi!) errori di battitura, sia in italiano sia in inglese. Nessuno me li aveva mai segnalati. Forse nessuno li aveva mai notati?

Per questa versione ringrazio Ivana Catic, Andrea Colato, Vito Losacco, Luciano Quartarone e Giovanni Sadun. Non ho usato tutti i loro suggerimenti, ma sono stati utili e interessanti.

Trovate il file qui:
http://www.cesaregallotti.it/Pubblicazioni.html.

ISO/IEC 27007 per gli audit ISO/IEC 27001

E' stata pubblicata la nuova edizione della ISO/IEC 27007 dal titolo "Guidelines for information security management systems auditing":
- https://www.iso.org/standard/67398.html.

Il documento riporta requisiti aggiuntivi rispetto alla ISO 19011. Le pagine sono tante perché è stata aggiunta un'Appendice con interpretazioni di alcuni requisiti della ISO/IEC 27001, compito svolto già dalla ISO/IEC 27003.

Parere personale: non la trovo utile.

Mio articolo sui requisiti di sicurezza delle applicazioni

Questo, dal titolo " Sviluppo sicuro delle applicazioni: i requisiti" l'ho scritto io:
https://www.ictsecuritymagazine.com/articoli/sviluppo-sicuro-delle-applicazioni-requisiti/.

Linee guida WP 29 sulla DPIA

Premetto che, come spesso succede ultimamente, devo ringraziare Pierfrancesco Maistrello per la segnalazione e lo scambio di idee.

La notizia è che il Art. 29 WP ha pubblicato le sue linee guida sulla DPIA (Data privacy impact assessment). Si trovano alla pagina seguente, con il lungo titolo di "Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is "likely to result in a high risk" for the purposes of Regulation 2016/679, wp248rev.01":
- http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083.

L'Art. 29 WP è paragonabile al "centro studi europeo sulla privacy", è collegato alla Commissione europea e i suoi pareri sono molto importanti.

Meglio ricordare che non tutti i titolari (o responsabili) devono predisporre una DPIA. La linea guida fornisce una tabella molto interessante in cui elenca alcuni trattamenti e se per loro è necessaria o meno una DPIA. E' bene comunque ricordare che è previsto che il Garante pubblichi un elenco più esaustivo di trattamenti per cui predisporre una DPIA.

Per il resto, il documento non specifica "come" fare una DPIA (per quello fornisce dei riferimenti in Annex 1), ma solo alcuni principi generali. Importante comunque l'Annex 2, che propone una lista delle caratteristiche che deve avere la DPIA.

Il messaggio, in sostanza, sembra essere: fatela come volete, purché rispetti i punti dell'Annex 2.

In questi giorni il WP 29 ha pubblicato le bozze di altre linee guida (sul data breach e sulla profilazione). Non le commento perché, appunto, sono in bozza.

Riconoscimento facciale e video porno

Letta da un certo punto di vista, la notizia (da Crypto-Gram di ottobre) è divertente: Pornhub vuole attivare un software per riconoscere gli attori (così gli utenti possono seguire i loro favoriti) e le posizioni:
- https://motherboard.vice.com/en_us/article/a3kmpb/facial-recognition-for-porn-stars-is-a-privacy-nightmare-waiting-to-happen.

Il problema sono gli attori amatoriali: un software del genere potrebbe collegarli alla loro identità reale.

Problema simile (sempre da Crypto-Gram) riguarda le persone che hanno due identità su Facebook. Il caso specifico riguarda chi offre servizi di sesso con un'identità e poi vive il resto della vita con un'altra. Facebook riesce comunque a capirlo e suggerisce ai contatti di un'identità di connettersi anche all'altra:
- https://gizmodo.com/how-facebook-outs-sex-workers-1818861596.

Certo, a molti questo fa sorridere. Ma software che sanno riconoscere le facce e software che sanno collegare cose tra loro scollegate su Internet (ma collegate nella vita reale)... pensiamoci...

Contratti fornitori - una presentazione

Segnalo questa presentazione del Club 27001 dal titolo "Contrôle des prestataires: Erreurs à ne pas commettre" (in francese):
- http://www.club-27001.fr/precedentes-reunions/paris/214-21-septembre-2017-transparents.html

L'ho trovata interessante soprattutto per quanto riguarda le riflessioni sul "diritto di audit". In effetti, spesso troviamo sui contratti una clausola molto generica e semplice. Invece la presentazione ci ricorda di considerare:
- quanti audit prevedere ciascun anno (e possibilità di cambiare la frequenza);
- tempi di preavviso e casi di audit straordinari o a sorpresa;
- garanzie sulla riservatezza delle informazioni raccolte durante l'audit;
- modalità di gestione dei rilievi di audit;
- conseguenze delle non conformità (fino alla rescissione del contratto.

Ho trovato altre cose interessanti nella presentazione e quindi la segnalo.

Il caso dello spesometro

Da un tweet di @a_oliveri segnalo questo breve articolo sul "caso spesometro" che è finito anche sui giornali:
- https://www.avvenire.it/economia/pagine/spesometro-bloccato-il-sito.

Come è noto non riporto solitamente notizie di attacchi. Ma questa mi permette di ricordare che è corretto pensare agli attacchi e agli hacker e alle intrusioni da Internet, ma è necessario pensare anche agli interni o ai fornitori che fanno errori o che installano aggiornamenti dei software. Anzi, forse questi sono i più difficili da controllare ("dagli amici mi guardi Iddio, che ai nemici ci penso io").

Attacco a CCleaner

Un altro attacco che ho trovato interessante è quello a CCleaner:
- https://www.bleepingcomputer.com/news/security/ccleaner-compromised-to-distribute-malware-for-almost-a-month/;
- https://www.bleepingcomputer.com/news/security/avast-publishes-full-list-of-companies-affected-by-ccleaner-second-stage-malware/.

CCleaner è un'utilità che facilita la pulizia di disco, memoria e configurazioni di Windows. Qualcuno si è introdotto nei server di sviluppo e ha inserito del codice dannoso nei sorgenti di CCleaner.

Certamente gli attacchi possono essere più numerosi verso chi sviluppa prodotti di sicurezza (anche se CCleaner non è propriamente un prodotto di sicurezza), ma questo poteva capitare a tanti. Soprattutto in pochi, a differenza del produttore di CCleaner (da poco acquisito da Avast), si sarebbero accorti del problema.

Quindi: prestare attenzione ai prodotti che si installano sui propri pc e sulla propria rete. Soprattutto attenzione, come purtroppo fanno molti sistemisti, a installare prodotti in prova sulla rete aziendale.

L'attacco è stato rilevato grazie alla "recente" installazione del prodotto Morphisec della Cisco. Quindi ho un dubbio di quale sia la causa e quale l'effetto. Ma mi rendo conto che sto esagerando. Forse ;-)

Attacco a Verizon (e ai server sul cloud)

In questi giorni le notizie di attacco sono numerose.

Una su Deloitte: http://money.cnn.com/2017/09/25/technology/deloitte-hack-cybersecurity-guardian/index.html (da tweet di @stevedeft; probabilmente per un server DNS non in completa sicurezza con servizi RDP aperti su Internet);
Una sulla SEC: http://money.cnn.com/2017/09/21/news/sec-edgar-hack/index.html?iid=EL.

La più interessante, a mio parere, è quello di Verizon (dal Sans NewsBites): http://www.zdnet.com/article/another-verizon-leak-exposed-confidential-data-on-internal-systems/.

Infatti l'attacco a Verizon è avvenuto su server sul cloud AWS. Uno studio più ampio (accennato su
https://www.cyberscoop.com/verizon-wireless-s3-bucket-public-access-kromtech/) dimostra che sono tantissimi i server S3 non correttamente configurati.

Qui ripeto quanto già detto in altre occasioni e con altre parole: il cloud non è il bene né il male; purtroppo molti comprano server in cloud senza capire di cosa si tratta; pensano di risparmiare, fino a pensare di non avere più bisogno di sistemisti capaci di fare il loro lavoro (ho visto casi del genere). Invece un server in cloud va configurato e mantenuto come gli altri, senza poter risparmiare chissà quali cifre.

Il caso Equifax

Il primo a darmi notizia del caso Equifax è stato Sandro Sanna:
- http://money.cnn.com/2017/09/08/technology/equifax-hack-qa/.

Questo è un articolo più approfondito di Bloomberg (grazie a un tweet di @carolafrediani):
- https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros.

Equifax è un'azienda che raccoglie dati da varie compagnie (carte di credito, banche, eccetera) e fornisce valutazioni sulla situazione economica delle persone. Immagino sia ad una centrale del rischio.

Da quello che ho capito, gli attaccanti hanno sfruttato una vulnerabilità nota e pericolosa di Apache e sono riusciti ad accedere al sistema informatico di Equifax, ossia ai dati di 143 milioni di cittadini USA (pare ci siano anche dati di cittadini UK e chissà di chi altro).

Il caso è ovviamente esploso anche perché hanno scoperto che il responsabile della sicurezza informatica era una persona senza competenze tecnologiche (grazie ad Alberto Viganò per questa segnalazione):
- http://www.marketwatch.com/story/equifax-ceo-hired-a-music-major-as-the-companys-chief-security-officer-2017-09-15.

Alberto ha subito pensato ai nostri futuri DPO, spesso con competenze incerte.

Il caso, secondo me, è molto semplice, anche se la semplicità è nascosta dal polverone mediatico. Bisogna aggiornare dei server, ma nessuno lo fa perché bisogna interrompere il servizio per qualche tempo, richiede tempo, è noioso, ci sono cose più interessanti da fare. Il responsabile della sicurezza (anche se con competenze inadeguate), magari ha segnalato il problema, ha chiesto soldi per segmentare meglio la rete, ha telefonato ogni giorno ai sistemisti perché facessero gli aggiornamenti, ha chiesto ogni giorno ai "capi" di autorizzare l'interruzione del servizio per un'oretta. Ma tutti avevano cose più interessanti da fare e la manutenzione della "macchina IT" aveva priorità bassissima.

Anche noi, nel nostro piccolo, non abbiamo voglia di portare l'automobile a fare il tagliando o la revisione periodica e neanche il cambio gomme stagionale. Però lo facciamo perché sappiamo che è importante per la nostra sicurezza e perché le forze dell'ordine potrebbero bloccarci la macchina.

Semplicemente, i "capi" delle aziende non sono consapevoli di questo. Non si rendono conto che i sistemi informatici sono oggetti potentissimi ma anche delicatissimi e che richiedono manutenzione.

Semplice. L'avevo già detto, ma lo sappiamo tutti (basta parlare per qualche minuto di IT con qualunque manager italiano o straniero). E quindi la notizia dov'è? Solo nei numeri elevati di questo ennesimo caso.

Nuove specifiche NIST per le password

Considerazioni sulle nuove specifiche NIST per le password le avevo già scritte in questo blog.

Sullo stesso argomento ho scritto un articolo per ICT Security Magazine un poco più lungo del post originario. L'articolo ha titolo "Nuove specifiche NIST per le password":
https://www.ictsecuritymagazine.com/articoli/nuove-specifiche-nist-le-password/.

Il Garante privacy e i requisiti del DPO

La newsletter del Garante (e Franco Ferrari del DNV GL, che ringrazio) mi segnalano questo articolo dal titolo "Regolamento privacy, come scegliere il responsabile della protezione dei dati":
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/6826945#1.

Mi pare divertente leggere che "Non sono richieste attestazioni formali sul possesso delle conoscenze o l'iscrizione ad appositi albi professionali". Lo dicevo da tempo.

Trovo che la corsa alle certificazioni non sempre sia giustificata. Vorrei si promuovessero dei corsi seri e dei momenti di approfondimento, anche senza certificazioni e senza spargimenti di terrore per l'entrata in vigore del GDPR.

Nota: un momento di approfondimento è quello che abbiamo organizzato come DFA il 27 settembre
(http://www.perfezionisti.it/open-day/dfa-open-day-2017/). I posti (gratuiti) sono esauriti e l'associazione è senza cassa; quindi posso anche fare questa pubblicità!

Accesso del datore di lavoro a email e IM - Sentenza Barbulescu

Interessante caso della Corte di giustizia europea che verrà ricordato, penso, come "Sentenza Barbulescu".

Vediamo se ho capito bene (in caso contrario, scrivetemi):
- Barbulescu lavora per un'azienda, che gli chiede di aprire un account all'instant messaging di Yahoo per comunicare con i clienti;
- Barbulescu usa lo stesso account per scambiare messaggi con la fidanzata e il fratello;
- l'azienda se ne accorge, si legge e stampa 45 pagine (!) di messaggi di Barbulescu e lo licenzia;
- Barbulescu fa ricorso fino alla Corte di giustizia europea;
- la Corte di giustizia europea, a dicembre 2016, dà ragione all'azienda;
- la Grand chamber of human rights, a settembre 2017, dà invece ragione a Barbulescu (comminando però una multa molto bassa).

A me interessa capire cosa ha fatto l'azienda per dimostrare la propria ragione. Ossia le misure ritenute "corrette" dai giudici. Quindi, dalla sentenza della Corte di giustizia europea, ricavo quanto segue:
- l'azienda, nel regolamento interno, aveva ben specificato che era vietato l'uso dei pc aziendali per scopi personali;
- Barbulescu aveva asserito di aver usato il proprio account Yahoo solo per scopi di lavoro (non solo mentendo, ma dichiarando quindi che Yahoo non riguardava dati personali e poi, illogicamente, da qualche punto di vista, lamentandosi dell'invasione della propria privacy);
- comunque l'azienda, licenziandolo, non ha menzionato nelle motivazioni il contenuto dei messaggi, ma solo al fatto che fossero "non di lavoro";
- l'azienda aveva "limitato" l'indagine al solo account di Yahoo (non al pc o altro) e in un tempo limitato (pochi giorni e solo in orario di lavoro) e quindi in modo "limitato e proporzionato".

La Grand chamber, per contro, mi pare abbia notato che il regolamento interno non specificava le modalità di controllo delle comunicazioni Internet (ossia di come l'azienda intendesse verificare email, IM, eccetera).

Ricordo che, fino ad un certo punto, non sono favorevole al controllo dei lavoratori. Ma è importante capire come si può agire in caso di abuso.

La sentenza della Grand chamber (grazie a Pierfrancesco Maistrello):
- http://www.dirittoegiustizia.it/allegati/PP_INTERN_CEDU_milizia_s_4.pdf.

Un articolo segnalato da Pierfrancesco Maistrello:
- https://strasbourgobservers.com/2016/12/20/resuscitating-workplace-privacy-a-brief-account-of-the-grand-chamber-hearing-in-barbulescu-v-romania/.

Un articolo di Altalex:
- http://www.altalex.com/documents/news/2017/09/06/datore-controllo-mail-lavoratore.

La notizia l'ho avuta inizialmente da ictBusiness.it, ma l'articolo non mi era chiaro (infatti il solito Pierfrancesco Maistrello mi ha dovuto correggere):
- http://www.ictbusiness.it/cont/news/email-dei-lavoratori-controllate-l-europa-dice-si-con-limiti/40030/1.html.

La sentenza di dicembre (il primo link segnalato da Qwant che permette di scaricarla):
- http://www.federalismi.it/nv14/articolo-documento.cfm?Artid=31234.

Infine una domanda: ora quale sentenza dovrà essere seguita? Quella della Corte di giustizia o quella della Grand chamber?

Rasperry Pi e la insecurity by default

Bruce Schneier ha segnalato una guida per mettere in sicurezza i computer Rasperry Pi, ossia i dispositivi più diffusi per sviluppare gli oggetti dell'Internet of things.

Il post di Bruce Schneier:
https://www.schneier.com/blog/archives/2017/09/securing_a_rasp.html.

L'articolo "Take These Steps to Secure Your Raspberry Pi Against Attackers":
https://makezine.com/2017/09/07/secure-your-raspberry-pi-against-attackers/.

Il punto, come dice Bruce Schneier, non è tanto studiare come mettere in sicurezza un Rasperry Pi, quanto notare la difficoltà per farlo. Purtroppo la difficoltà a metterli in sicurezza è comune a tutti i computer. Forse il Windows, pur con tutti i suoi problemi, è tra i più semplici e questo dà l'idea del problema. Continuiamo infatti a produrre, comprare e usare prodotti difficili da mettere in sicurezza.

La security-by-design (e quindi la privacy-by-design) è quindi un'utopia. L'insecurity-by-design è invece quello che c'è. Rendiamocene conto e cerchiamo di conviverci.

Articolo su eIDAS

Fabrizio Cirilli (PDCA S.r.l.) mi ha segnalato un articolo dal titolo "Regolamento eIDAS (EU 910/2014) e direttive italiane in materia di digitalizzazione", che ha scritto con Riccardo Bianconi (ispettore Accredia). Si trova sulla rivista KnowIT (bisogna registrarsi per scaricarla):
- https://www.knowit.clioedu.it/rivista.

Personalmente, sarei stato più esplicito in alcune considerazioni (nell'articolo si accenna allo sforzo necessario per vedere tutti gli HSM e alle eccessive ridondanze delle check list AgID). In particolare avrei indicato anche alcune questioni relative al controllo dei fornitori, a mio parere non corrette, come già detto in altre occasioni (http://blog.cesaregallotti.it/2015/10/per-agid-linformatica-e-ferma-agli-anni.html).

Però penso che questo articolo sia un buon riferimento per ragionare in merito all'applicazione del Regolamento eIDAS in Italia.

Software, controllo dei lavoratori e Ispettorato del Lavoro

Segnalo questo articolo di Filodiritto dal titolo "Controllo dei lavoratori - Ispettorato Nazionale del Lavoro: alcuni software di gestione dell'attività dei Call Center configurano un controllo a distanza dei lavoratori":
- https://www.filodiritto.com/news/2017/controllo-dei-lavoratori-ispettorato-nazionale-del-lavoro-alcuni-software-di-gestione-dellattivita-dei-call-center.html.

Ho trovato molto interessante la terza pagina, dove sono riassunte le due tipologie di software che possono comportare il controllo dei lavoratori e le quanto è necessario fare.

Pubblicata ISO/IEC 29151

Fabio Guasconi di Bl4ckSwan mi ha informato che è stata pubblicata la ISO/IEC 29151 dal titolo "Code of practice for personally identifiable information protection":
https://www.iso.org/standard/62726.html.

E' applicabile ai soli titolari dei trattamenti (e non mi sembra una buona idea).

Si tratta di un'estensione dei controlli della ISO/IEC 27002. Per alcuni dei controlli già previsti dalla ISO/IEC 27002 sono indicate ulteriori indicazioni per l'attuazione. In Annex A sono poi riportati controlli aggiuntivi rispetto a quelli già presenti nella ISO/IEC 27002.

Questo documento potrebbe essere usato dalle organizzazioni già certificate ISO/IEC 27001 per estendere la propria Dichiarazione di applicabilità (o Statement of applicability). Questo poi potrebbe portare a certificazioni ISO/IEC 27001 basate "sui controlli riportati dalle ISO/IEC 27001 e ISO/IEC 29151" (non sono previste certificazioni ISO/IEC 29151).

Ora è anche in corso di discussione la ISO/IEC 27552, che dovrà estendere (non ridurre!) la ISO/IEC 27001 in modo che sia dedicata alla protezione dei dati personali. C'è da dire che i lavori su questa norma sono in stato ancora di "Working draft" e pertanto uscirà tra non meno di due anni.

ISO 18295 sui Costumer contact centre

Franco Ferrari di DNV GL mi ha segnalato la pubblicazione, a luglio 2017, della norma ISO 18295 dal titolo "Customer contact centres". Essa è divisa in due parti: la prima ("Requirements for customer contact centres") presenta i requisiti proprio di customer contact centre (CCC), mentre la seconda ("Requirements for clients using the services of customer contact centres") presenta i requisiti che dovrebbero attuare i clienti, interni o esterni, dei CCC.

Si tratta di norme certificabili. Non si tratta di norme di "sistemi di gestione", ma "di servizio", e pertanto non sono impostate come la ISO 9001:2015 o la ISO/IEC 27001:2013.

Prima di questa norma era disponibile la norma europea EN 15838 (dal titolo "Customer Contact Centres: Requirements for service provision"), ora abrogata. In Italia la EN 15838 andava integrata con la UNI 11200 (dal titolo "Servizi di relazione con il cliente, con il consumatore e con il cittadino, effettuati attraverso centri di contatto: Requisiti operativi per l'applicazione della UNI EN 15838:2010") e ora vedremo se questa norma nazionale avrà ancora ragione di esistere.

La UNI 11200 è comunque interessante perché riporta delle metriche più precise rispetto a quelle generiche delle norme europee e internazionali. In molti casi riporta anche dei valori di riferimento (o SLA).

Tecnicamente, le norme precedenti riguardavano solo l'erogazione dei servizi. Ora la parte 2 della ISO 18295 introduce requisiti anche per i clienti dei contact centre.

Segnalo quindi la presentazione di queste norme fatta dall'ISO: https://www.iso.org/news/ref2191.html.

27 settembre: DFA Open Day - GDPR e investigazioni aziendali

Io sono Consigliere di DFA e sono molto orgoglioso di presentarvi l'Open day 2017 dedicato a GDPR e investigazioni aziendali:
- http://www.perfezionisti.it/open-day/dfa-open-day-2017/.

Ci si può iscrivere gratuitamente, ma al momento in cui io sto scrivendo questo annuncio l'evento risulta "tutto esaurito". Magari si libereranno dei posti nei prossimi giorni:
- https://www.eventbrite.it/e/biglietti-dfa-open-day-2017-36684332827.

Ritirata la ISO/IEC 27015

Franco Ferrari di DNV GL mi ha segnalato che è stata ritirata la ISO/IEC 27015 dal titolo "Information security management guidelines for financial services":
https://www.iso.org/standard/43755.html.

Infatti sembra che i fornitori di servizi finanziari (soprattutto le banche) preferiscono appoggiarsi ad altri standard interni o di altra provenienza. Per esempio, mi risulta che la BCE (Banca centrale europea) si appoggia sul NIST Cybersecurity framework, di origine USA.

Questo lo trovo molto bizzarro: piuttosto che appoggiare uno standard internazionale, con procedure di approvazione aperte, alcune istituzioni preferiscono appoggiarsi a standard elaborati da strutture che sfuggono completamente al loro controllo. Contenti loro...

Il flop della regolamentazione dei cookies

Fabrizio Monteleone di DNV GL mi ha segnalato uno studio dal titolo "Uncovering the Flop of the EU Cookie Law". L'ho trovato su questo sito:
https://scirate.com/arxiv/1705.08884.

Riassumo l'abstract. La Direttiva ePrivacy richiede che i siti web chiedano consenso esplicito agli utenti prima di usare i "tracking cookies". Gli autori hanno quindi analizzato più di 35.000 siti web e hanno scoperto che il 65% di questi siti installa i tracking cookies prima che l'utente possa accettarli esplicitamente. Gli autori sono convinti che le agenzie di controllo non facciano controlli, ma anche delle difficoltà di attuazione delle misure tecniche richieste.

Del NIST e della lunghezza e complessità delle password

Il NIST ha pubblicato la SP 800-63B, una nuova versione della "Digital Identity Guidelines: Authentication and Lifecycle Management":
http://csrc.nist.gov/publications/PubsSPs.html.

In realtà vedo che ha pubblicato anche, nella stessa data, la SP 800-63C e la SP 800-63-3. Confesso che mi sono perso in questi documenti e non li ho letti. Però segnalo quanto richiamato dal SANS Newsbites (https://www.sans.org/newsletters/newsbites/xix/62#200), in particolare facendo riferimento al punto 5.1.1 del SP 800-63B, "Memorized secrets", e all'Appendix A: "il nuovo documento suggerisce di usare password lunghe, facili da ricordare e da cambiare solo quando si pensa siano state compromesse". Un autore della precedente guida del NIST dice che "rimpiange" la vecchia impostazione che richiedeva di usare password complesse (con lettere maiuscole, minuscole, numeri e caratteri speciali) e da cambiare almeno ogni 3 mesi.

Si ritiene preferibile lasciare liberi gli utenti di scegliere le proprie password, purché di almeno 8 caratteri e non presenti in una blacklist di password troppo facili (per esempio password già diffuse a seguito di altri attacchi, parole del dizionario, caratteri sequenziali o ripetuti, come 1234 e aaaa, parole derivate dal nome del servizio, dal nome dell'utente, dalla sua user-id o altri elementi). Infatti le password sono più spesso individuate attraverso attacchi di social engineering e non di forza bruta.

Per quanto riguarda la lunghezza, il NIST fa notare che questa non ha impatto sugli attacchi offline, visto che questi sono rivolti ai valori hash, indipendenti dall'input. Per gli attacchi online, bisogna invece prevedere altre misure di sicurezza, come il blocco dopo alcuni tentativi errati, valutando però la possibilità che un malintenzionato possa provare deliberatamente password errate per bloccare l'utente. E' comunque raccomandata una lunghezza minima di 8 caratteri.

Per quanto riguarda la complessità, il NIST segnala che spesso gli utenti riescono ad aggirare la richiesta con scelte banali, per esempio usando al posto di "password" la stringa "Password1". In altri casi, la complessità porta gli utenti a scrivere le proprie password, annullando (o peggiorando) la misura.

Personalmente ho qualche perplessità e devo ancora pensare ai pro e ai contro di queste proposte. Per esempio, il cambio periodico della password è necessario negli ambienti in cui gli utenti si scambiano le password (anche se proibito o sconsigliato) o le usano su strumenti non personali o aziendali (e quindi ricavabili dalla cache dello strumento).

In Italia, comunque, sono ancora vigenti le misure minime del Codice della privacy che impone una lunghezza minima di 8 caratteri, un minimo di complessità e il cambio ogni 3 o 6 mesi. Vedremo dopo le modifiche che saranno apportate al Codice e ai Provvedimenti (e Linee guida) del Garante privacy.

Nota: un articolo simile l'ho proposto a https://www.ictsecuritymagazine.com/ (finora non risulta pubblicato).

Certificazioni ISO/IEC 27018

Accredia ha pubblicato un regolamento per le "certificazioni" ISO/IEC 27018 (grazie a Franco Ferrari di DNV GL per la notizia):
http://www.accredia.it/extsearch_documentazione.jsp?area=55&ID_LINK=331&page=118&IDCTX=5549&id_context=5549.

Purtroppo ci sono stati casi in passato (e nel presente) di certificazioni rispetto a questa linea guida, con anche marchi di accreditamento. Sappiamo bene che le linee guida non sono certificabili.

Accredia ha messo un punto fermo e questo è un bene. Però non concordo con l'impostazione. Infatti la ISO/IEC 27018 fa parte di quelle norme di "estensione" dei controlli ISO/IEC 27002 e non dovrebbe essere trattata a parte. Ci dovremo quindi aspettare regole per la 27017, 27011, 27019, 27799 e la futura ISO/IEC 29151 (quella sulla privacy)?

Il fatto che continua a sfuggire è che la ISO/IEC 27006 permette di scrivere su un certificato ISO/IEC 27001 che il SOA include i controlli della ISO/IEC 27018 o di altre norme di "estensione" della ISO/IEC 27002. Anzi, si potrebbero citare anche controlli diversi, come quelli del NIST Cybersecurity framework. E quindi questa circolare riguarda solo un caso particolare e non aiuta ad impostare il lavoro in modo coerente e utile per il futuro. Un'altra occasione persa, ahinoi.

Libro "Privacy & audit"

Mi piace consigliare il libro "Privacy & audit" di Fulvia Emegian, Monica Perego:
http://shop.wki.it/Ipsoa/Libri/Privacy_Audit_s559485.aspx (link della casa editrice).

Ovviamente ho trovato qua e là qualche piccola imprecisione (!), ma l'ho trovato ben fatto: ben raccontato e con molti esempi (veramente tanti, con anche tracce di audit svolti). E poi mi trovo d'accordo con l'approccio proposto sia per gli adempimenti privacy sia per l'esecuzione degli audit.

Ho conosciuto Fulvia e Monica e ci siamo scambiati i libri. Meno male che non è stata quella situazione imbarazzante per cui qualcuno ti regala il suo libro e a te non piace!

Monica è formatrice presso corsi per DPO, che ho sempre sconsigliato (e ci sono altre cose che chi mi conosce potrebbe trovare interessanti). Però sia Fulvia sia Monica sono molto preparate, brave e entusiaste e il libro è fatto bene.

Conclusione: sono ben contento di fare questa pubblicità estiva (d'altra parte non ci guadagno niente).

Il Garante si diverte

Segnalo, grazie a Giulia Zanchettin, che il Garante ha pubblicato "Estate in privacy", ossia consigli per tutti da seguire durante l'estate (e non solo):
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/3240343.

Mi sembrano regole banali, ma ben presentate.

Confesso che stavo ignorando completamente la notizia (semplicemente perché i miei lettori sono principalmente professionisti della sicurezza), ma è vero che un ripasso delle regole di base non guasta mai (sono purtroppo tanti i professionisti della sicurezza che scrivono tweet quando atterrano a Hong Kong, Parigi, Londra, New York eccetera, non preoccupandosi di potenziali ladri interessati a sapere quando non sono a casa).

Inoltre il titolo di Giulia ("Il Garante si diverte") era troppo bello per essere ignorato.

Report sicurezza di Lloyds of London

Segnalo (grazie a Stefano Ramacciotti) il "Emerging Risk Report on Cyber Insurance" (sottotitolo "Counting the cost: Cyber exposure decoded") della Lloyds of London:
- https://www.lloyds.com/news-and-insight/risk-insight/library/technology/countingthecost.

Mi affido al commento del SANS: "il rapporto, in definitiva, suggerisce di trattare gli attacchi IT come disastri naturali, non come crimini "tradizionali".

Inoltre il report presenta due esempi: per il primo (fornitore di servizi cloud) con l'assicurazione si recuperano il 15% dei danni, mentre per il secondo (interruzione di un server critico) si recuperano il 7% dei danni. Tradotto: è sempre e comunque necessario attuare le "solite" misure di sicurezza preventiva.

Opinione del WP Art. 29 sulla privacy dei lavoratori

Ho notato la notizia in molti posti, ma non l'avevo ben considerata. Fino a quando ho letto questo articolo di Interlex:
- http://www.interlex.it/privacyesicurezza/ricchiuto43.html.

Ricordo che le opinioni del WP Art. 29 sono importanti, in quanto (mi scuso per l'imprecisione) espressione dei Garanti europei.

Inoltre avevo intravisto il punto "caldo" di questa opinione: è ritenuto non corretta la consultazione dei profili dei candidati sui social network da parte del potenziale datore di lavoro. Confesso che la cosa mi lascia perplesso: a mio parere, se una persona mette in pubblico i fatti suoi, legittima, di fatto, chiunque altro a giudicarlo. Comunque, sempre a mio parere, i potenziali datori di lavoro verificheranno sempre il profilo social di un candidato, ma non lo pubblicizzeranno.

Altri aspetti legati ai social network, che mi paiono invece molto pertinenti, sono: i capi non dovrebbero chiedere ai collaboratori la connessione (o la "amicizia"), i capi non dovrebbero obbligare i lavoratori a usare solo profili aziendali.

Inoltre, come già segnalato dall'articolo di Interlex, questa opinione non riguarda solo i dipendenti. E mi sembra corretto siano protetti tutti i lavoratori, a prescindere dal tipo di collaborazione subordinata che hanno.

Infine ho chiesto lumi a Pierfrancesco Maistrello, perché ricordavo un'altra recente "opinione" in merito alla privacy e ai lavoratori. E infatti mi ha confermato che nel 2015 era stata pubblicata dal "Comitato dei ministri" una raccomandazione:
- http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/4224268.

Inoltre Pierfrancesco mi fa notare che questa del WP Art. 29 è una "opinion" e non una "linea guida". Forse perché (opinione anche questa!) vuole aiutare i processi di adeguamento legislativo al GDPR dei singoli Stati.

Certificazioni privacy per aziende

Proseguo quanto già scritto in un precedente post:
(blog.cesaregallotti.it/2017/05/certificazioni-privacy-per-aziende-e-bs.html.

Infatti Pierfrancesco Maistrello, Franco Ferrari e Paolo Sferlazza mi hanno segnalato questo comunicato del Garante e Accredia:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6621723.

Riassunto (mio): lasciate perdere le certificazioni di persone e organizzazioni fino a quando non ve lo diciamo noi (poi... Accredia ha già accreditato un organismo di certificazione senza l'avallo del Garante, ma evito di fare il pignolo).

ISO/IEC 27004:2016 sulle misurazioni

E' stata pubblicata a dicembre 2016 la nuova versione della ISO/IEC 27004 dal titolo "Information security management -- Monitoring, measurement, analysis and evaluation":
https://www.iso.org/standard/64120.html.

Sono stupito di non aver rilevato la notizia all'epoca. Infatti tengo molto a questa versione della ISO/IEC 27004, a cui ha contribuito molto Fabio Guasconi e anche io ho partecipato.

Questa versione è molto meno teorica della precedente e presenta ben 35 esempi di misurazioni per la sicurezza (c'è il mio zampino...). Non tutti questi indicatori mi convincono (per esempio quello che richiede di misurare il numero di riesami di Direzione), mentre altri sono più indicatori di avanzamento (per esempio percentuale degli audit interni rispetto a quelli programmati). Infine rimangono gli indicatori "veri" (per esempio disponibilità dei sistemi, tempi di intervento sugli incidenti), che sono pochi, come ho sempre sostenuto.

Ricordo infatti che il problema della sicurezza delle informazioni è che ha come obiettivo il "non verificarsi di eventi" e quindi non è possibile raccogliere molti dati utili per misurare.

Fornitori di servizi per le aziende con i piedi per terra

Mio articolo dal titolo "Fornitori di servizi per le aziende con i piedi per terra":
- https://www.ictsecuritymagazine.com/articoli/fornitori-piedi-terra/.

Lavori sul Codice privacy (e integrazione con il GDPR)

Monica Perego mi segnala questo emendamento ad un DDL in discussione al Parlamento:
http://www.senato.it/japp/bgt/showdoc/frame.jsp?tipodoc=Emendc&leg=17&id=1029112&idoggetto=1035671.

Questo il commento di Monica: "questa è la legge delega che non abroga il codice ma dice che va integrato con il Regolamento". Monica non lo dice, ma lo sottintende: avevano torto quelli che davano per abrogato il D. Lgs. 196 dopo l'entrata in vigore del GDPR (e purtroppo alcuni lo dicevano con troppa indisponenza).

Allagamento blocca i server del Tribunale di Napoli

Sandro Sanna mi segnala la seguente notizia, dal titolo "In tilt i sistemi informatici del Tribunale di Napoli, si torna alla carta":
http://www.ilmattino.it/napoli/cronaca/napoli_palazzo_giustizia_server_carta_tribunale-2550463.html.

Il suo commento: " c'è chi mette sempre nel risk assessment probabilità bassa è poi invece...".

Nuova versione della UNI 10459

Mi segnala Franco Ferrari di DNV GL che è stata pubblicata la UNI 10459:2017, aggiornamento della versione del 2015, dal titolo "Attività professionali non regolamentate - Professionista della security - Requisiti di conoscenza, abilità e competenza":
http://store.uni.com/magento-1.4.0.1/index.php/uni-10459-2017.html.

Franco mi segnala un articolo su Punto Sicuro, però non accessibile senza credenziali. Riporto però questa frase: "Questa nuova edizione della norma presenta dei miglioramenti, soprattutto di tipo formale, che mirano a rendere la norma sempre più leggibile ed aderente a una realtà in costante evoluzione, come la realtà degli scenari di rischio e delle strategie di attacco e difesa".

Ho chiesto lumi a Fabio Guasconi di Bl4ckSwan, che ha partecipato ai lavori. Mi ha detto che ha lavorato soprattutto "per evitare che ci fossero ambiguità tra il Security manager (che è in sostanza un CSO, con responsabilità di più alto livello in materia di sicurezza delle informazioni) e l'Information security manager".

Per questa figura ha anche uniformato la terminologia usata per riferirsi alla sicurezza delle informazioni con quella della ISO/IEC 27001 e richiamato i profili specifici della UNI 11621-4 con cui interfacciarsi, rimosso dove possibile le responsabilità e le competenze di dettaglio del Security manager sull'information security, lasciandogli quelle di più alto livello.

ISO/IEC 29134 - Privacy impact assessment

E' stata pubblicata la ISO/IEC 29134:2017 dal titolo "Information technology -- Security techniques -- Guidelines for privacy impact assessment":
https://www.iso.org/standard/62289.html.

Ne ho già parlato in precedenza. Da notare che è, in sostanza, il recepimento ISO delle linee guida del CNIL sulla PIA (gratuite!):
www.cnil.fr/english/news-and-events/news/article/privacy-impact-assessments-the-cnil-publishes-its-pia-manual/.

Su questa norma ho qualche perplessità teorica (confusione su "fonti di rischio" e "minacce") e pratica (gli esempi non sono illuminanti). Però non ci ho minimamente lavorato, malgrado ne avessi la possibilità, e quindi non ho approfondito i perché di queste scelte.

Lavoro e dati giudiziari dei dipendenti

Il Garante privacy, con la sua ultima newsletter, ribadisce che le organizzazioni non possono trattare i dati giudiziari dei dipendenti (e neanche dei candidati) se non richiesto dalla legge o autorizzato dal Garante stesso.

La newsletter:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558875.

Il Provvedimento specifico:
http://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/6558837.

In effetti, c'è la cattiva abitudine, in troppe imprese, di chiedere il casellario giudiziario. Questo non solo perché contrario alla normativa in vigore, ma perché i comportamenti passati di una persona non possono dare indicazioni su quelli futuri. In caso contrario, dovremmo pensare che le persone non potranno mai migliorare e neanche noi stessi; e quindi a che servirebbe studiare?

Forse sono fuori tema. Ma ci torno subito. Infatti è sbagliato pensare che il personale selezionato in quanto senza reati passati sia migliore di quello che è già stato oggetto di indagine. Sappiamo che una persona delinque spesso "in crescendo" e quindi un incensurato potrebbe già essere avviato per quella strada. Una persona che ha già scontato una pena, forse, riesce a riconoscere ed evitare di percorrere una certa strada, rinforzata anche dalla stabilità del posto di lavoro.

Inoltre non dobbiamo progettare controlli di sicurezza pensando che le persone interne siano tutte oneste (sindrome di Fort Apache). Questo è un errore: le persone possono compiere errori e possono anche peggiorare (non solo migliorare) e quindi i controlli di sicurezza devono essere progettati adeguatamente.

Email ammissibile come prova

Segnalo questo articolo di Altalex dal titolo "Email ammissibile come prova anche senza la firma elettronica qualificata":
- http://www.altalex.com/documents/news/2017/01/23/email-ammissibile-come-prova-anche-senza-la-firma-elettronica-qualificata.

Il titolo dice già tutto.

Raccomandazioni per i fornitori di cloud

Francesca Lazzaroni di Spike Reply mi ha segnalato una pubblicazione del German Federal Office for Information Security (anch'esso designato con BSI) sul cloud:
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/SecurityRecommendationsCloudComputingProviders.html.

Si tratta di una pubblicazione del 2011, ma mi sembra utile perché per ogni argomento è proposta una tabella di sintesi delle misure di sicurezza da prevedere per i servizi cloud (e non solo, per la verità). Queste tabelle potrebbero essere utili anche per chi si occupa di contratti con fornitori cloud.

In passato avevo già segnalato altre pubblicazioni:
- di AIEA, In italiano: http://www.aiea.it/attivita/gruppi-di-ricerca/it-audit-cloud;
- di ENISA: https://www.enisa.europa.eu/media/press-releases/enisa2019s-security-guide-and-online-tool-for-smes-when-going-cloud.

Perché avere lo spezzatino dei documenti?

Dalla newsletter di ANSSAIF segnalo questo articolo dal titolo "Asset Protection. Perché alle aziende piace lo 'spezzatino' di norme ai testi unici?":
https://www.key4biz.it/assetprotection-perche-alle-aziende-piace-lo-spezzatino-norme-ai-testi-unici/191349/.

In sintesi, l'autore lamenta che troppe organizzazioni pubblicano documenti distinti per codice etico, regolamento per la privacy e guida alla sicurezza, nonostante siano elementi assolutamente integrabili.

Inventario degli asset: l'incompreso

Mio articolo dal titolo "Inventario degli asset: l'incompreso":
- https://www.ictsecuritymagazine.com/articoli/inventario-degli-asset-lincompreso/.

Mi hanno proposto di scrivere articoli per ICT Security Magazine. Di materia ne avrei e spero quindi di scriverne altri nel futuro.

Piano Triennale per l'IT nella PA

Da un tweet di @diritto2punto0 segnalo la pubblicazione del "Piano Triennale 2017-2019 per l'informatica nella Pubblica Amministrazione":
https://pianotriennale-ict.italia.it/.

Confesso che non l'ho letto. Il poco che ho visto dimostra un piano decisamente ambizioso, ma alcuni mi dicono irrealizzabile nei tempi prospettati e considerando che si sta parlando di PA.

Su Nova 24 (grazie a Roberto Gallotti) ho letto un articolo di presentazione del piano. Sul web ne è disponibile solo una scansione su Twitter, probabilmente non legale (ma finché c'è, si può leggere):
https://twitter.com/gabferrieri/status/873839729661399040/photo/1.

Aggiornamento "Piano nazionale per la protezione cibernetica e la sicurezza informatica"

Segnalo da un tweet di @cgiustozzi il "Piano nazionale per la protezione cibernetica e la sicurezza informatica":
http://www.sicurezzanazionale.gov.it/sisr.nsf/archivio-notizie/pubblicato-il-nuovo-piano-nazionale-cyber.html.

Sensibilizzazione 03 - La telefonata

Fabio Biancotto di Air Dolomiti mi ha segnalato questo video, indirizzato a chi fornisce assistenza (e non dovrabbe fornirne troppa):
https://www.youtube.com/watch?v=lc7scxvKQOo.

British Airways ferma per un giorno

Avevo letto inizialmente la notizia sul Corriere della Sera su un articolo dal titolo "Gb: guasto al sistema informatico, voli British tutti a terra, caos a Londra":
http://www.corriere.it/esteri/17_maggio_27/gb-guasto-sistema-informatico-voli-british-tutti-terra-caos-londra-24359854-42d4-11e7-bf8f-efa16b87b247.shtml.

Il problema sembra fosse dovuto ad un tecnico che per sbaglio ha staccato la corrente:
http://www.corriere.it/cronache/17_giugno_02/voli-cancellati-british-airways-causare-caos-errore-umano-un-tecnico-ha-spento-interruttore-06e0857c-476e-11e7-b4db-9e2de60af523.shtml.

Le stesse notizie in inglese, dai link forniti dal SANS Newsbyte:
Reuters: http://www.reuters.com/article/us-britain-airports-heathrow-idUSKBN18P01O;
BBC: http://www.bbc.com/news/uk-40069865.

I sindacati accusano BA di aver esternalizzato tutto l'IT presso un fornitore in India, perdendo così competenze. BA nega.

Di certo sappiamo che molti problemi delle aziende hanno come causa la gestione orientata alla Borsa (breve periodo) e non all'impresa (lungo periodo) e manager che stanno più attenti agli obiettivi personali (avidità economica) che a quelli dell'impresa (sostenibilità).

E io penso che veramente i manager di oggi non si rendano conto di cosa vuol dire "digitalizzazione". In termini di rischi, di costi e di necessità di manutenzione. Tutti a voler sistemi informatici più belli e più nuovi (cominciando dai pc, tablet, smartphone personali) e nessuno a chiedersi cosa bisogna fare tra qualche anno. E così ci sono aziende che hanno ancora Windows XP e altre che non vogliono investire in una prova di disaster recovery. Giusto pochi giorni fa, una persona mi diceva che ha dovuto combattere lungamente con gli altri manager per evitare che anche la sicurezza fosse esternalizzata e che venisse invece considerata come elemento strategico per il governo dell'impresa.

Oggi mi sembra che un manager non possa più ignorare la gestione dei sistemi IT.

Nuovi trend e norme ISO/UNI

Segnalo questa presentazione dal titolo " Uninfo - nuovi trend e norme ISO/UNI - Blockchain, IoT, Big Data, Industry 4.0 e certificazioni Privacy":
https://www.slideshare.net/bl4ckswan/uninfo-nuovi-trend-e-norme-isouni-blockchain-iot-big-data-industry-40-e-certificazioni-privacy.

Per chi vuole avere un quadro degli standard che si stanno preparando su alcuni temi molto innovativi. Segnalo solo che la gran parte degli standard citati non prevedono la possibilità di certificazione della conformità.

Accesso abusivo ai sistemi IT anche con autorizzazione

L'articolo ha titolo " Le Sezioni unite confermano: è abusivo l'accesso a sistemi informatici per ragioni diverse da quelle per le quali l'agente dispone di autorizzazione":
http://www.penalecontemporaneo.it/d/5428-le-sezioni-unite-confermano-e-abusivo-laccesso-a-sistemi-informatici-per-ragioni-diverse-da-quelle.

Provo a riassumere: è stato chiesto alla Corte di cassazione se è da considerare reato l'accesso ad un sistema informatico da parte di qualcuno che ha sì le autorizzazioni a farlo, ma non ne avrebbe motivo. La risposta è sì.

Il quesito riguarda specificatamente pubblici ufficiali o incaricati di un pubblico servizio, ma credo sia importante anche per le aziende private e altre organizzazioni.

Infatti è vero che i sistemi IT dovrebbero essere configurati secondo i principi del privilegio minimo e del "need to know", ma è spesso necessario fare delle semplificazioni per evitare il sovraccarico di lavoro degli amministratori di sistema.

Legge contro il cyberbullismo

E' stata approvata la legge contro il cyberbullismo.

Su Altalex si trova una breve analisi del contenuto di legge:
http://www.altalex.com/documents/news/2016/09/21/bullismo-e-cyberbullismo.

Sul Corriere della Sera si trova la storia di questa legge, la cui proposta ha subito molte critiche prima di essere modificata e approvata nella versione attuale:
http://www.corriere.it/tecnologia/cyber-cultura/cards/lotta-cyberbullismo-arriva-l-ok-camera-cosa-prevede-legge/contro-bullismo-cyberbullismo-l-ok-camera_principale.shtml.

Sul sito della Camera dei Deputati, si trova un'analisi più istituzionale del provvedimento:
http://www.camera.it/leg17/522?tema=prevenzione__e_repressione_del_bullismo_e_del_cyberbullismo.

App medicali e nuovo Regolamento UE sui dispositivi medici

Ho trovato interessante questo breve intervento su "App medicali e nuovo Regolamento UE sui dispositivi medici":
https://www.filodiritto.com/articoli/2017/05/app-medicali-e-nuovo-regolamento-ue-sui-dispositivi-medici.html

Mi pare tratti uno degli argomenti di sicurezza informatica più importanti in questo periodo. Infatti i dispositivi medici sono dei casi particolari (e critici) di IoT, che sappiamo essere molto vulnerabile.

Segnalo che anche la "vecchia Direttiva UE sui dispositivi medici" tratta, seppur meno esplicitamente, di app medicali e pertanto andrebbe applicata già da tempo.