domenica 18 febbraio 2024

Sul cambio delle password - 02

Dopo il post in cui riportavo lo scambio di idee tra me e Stefano Ramacciotti sul cambio periodico o meno delle password (https://blog.cesaregallotti.it/2024/02/sul-cambio-delle-password.html), mi ha scritto Pietro, che desidera essere anonimo e che ringrazio (si definisce addirittura mio fan).

Riassumo quanto da lui scritto.

<< 

Per me, il nuovo approccio che prevede di non cambiare più periodicamente la password è stato veramente una liberazione, più che altro per sensibilizzare quegli amministratori di sistema che impongono ancora il cambio molto, troppo spesso.

E' sempre stato evidente, e mi meraviglia che ci si sia arrivati in decenni, che gli utenti non potranno o vorranno mai memorizzare le loro credenziali, se le cambiano di continuo in maniera sostanziale, con le conseguenze che tutti sappiamo: non vengono più memorizzate ma trascritte o vengono cambiate solo di una virgola. Questo permetteva solo, a certi amministratori di sistema, di giustificarsi dicendo che facevano fatto il loro dovere sorvolando sull'efficacia o meno del controllo. Era talmente entrato nella cultura che non potevi non obbligare il cambio password, saresti stato uno scellerato. Ricordo sempre con un sorriso un utente che mi chiese come mai non lo obbligavo a cambiare la password, perché dove era prima era abituato così, e mi pregò di applicare questa policy altrimenti lui non si sarebbe mai ricordato di farlo e ciò lo metteva a disagio per la sicurezza del suo accesso. Ovviamente mi capitò tempo dopo di scoprire che la sua password era del tipo "Qualcosa11" dove il numero finale era circa il numero dei mesi dall'assunzione.

Sono d'accordo che magari, piuttosto che non cambiarla proprio mai, il cambio ogni anno o due possa essere salutare.

Io mi sono inventato un metodo rafforzativo, che potremmo chiamare l'auto-salting. Si decide una prima parte di password molto robusta e strong, diciamo di 8 caratteri almeno. Quello diventa il salt: non cambia mai. E una parte successiva, più semplice ma certo non troppo, insomma non proprio "mamma" per intenderci, che possa esser cambiata periodicamente. La semplicità di questa seconda parte permette all'utente di non dover barare e quindi di non cambiarne solo una virgola ma di poterla cambiare del tutto e con una certa frequenza.

A questo, aggiungo sempre questo mio suggerimento che credo piacerà: l'uso del dialetto. E' un modo simpatico, e soprattutto facilmente memorizzabile, di usare una lingua che (per lo più) non è in nessun dizionario di bruta forza dell'attaccante, il che lo rende quasi equivalente a una sequenza random di caratteri (poi è chiaro che l'uso di più parole e l'aggiunta di un qualche numeretto o carattere speciale etc possano aiutare a rafforzare ulteriormente). E tra l'altro è un modo piacevole di tenere calde le nostre origini. Io nel mio studio tengo apposta un libro discorsivo nel mio dialetto, che consulto a questo scopo.

Serve comunque buonsenso: un mio cliente di Bologna, di fronte a tale consiglio, ha risposto "Qui a Bologna al 99% userebbero la stessa password" e non la riporto. E' ovvio che funziona sempre e solo cercando un minimo di originalità.

>>

Ringrazio Pietro perché, da un'esperienza diversa da quella mia e di Stefano, alla fine, concordiamo.

giovedì 15 febbraio 2024

Pubblicata la ISO/IEC 27001:2022 in italiano

Pubblicata (e disponibile dal 20 febbraio) la UNI CEI EN ISO/IEC 27001:2024 "Sicurezza delle informazioni, cybersecurity e protezione della privacy - Sistemi di gestione per la sicurezza delle informazioni - Requisiti": https://store.uni.com/uni-cei-en-iso-iec-27001-2024.

Il testo è lo stesso della ISO/IEC 27001:2022, che è anche lo stesso della EN ISO/IEC 27001:2023. Cambiano solo gli anni di recepimento, in modo da confondere un po' gli utilizzatori (scherzo).

Io continuerò a far riferimento alla ISO/IEC 27001:2022 perché è il titolo più corto.

Ringrazio Fabio Guasconi di Bl4ckSwan per avermelo segnalato.

lunedì 12 febbraio 2024

Gli uomini possono fare tutto (feb. 2024)

Il mese scorso non avevo scritto questa rubrica. Me ne scuso.

Questo mese pensavo inizialmente di scrivere in poche righe che avevo rinunciato a quasi tutto l'incontro annuale degli Idraulici della Privacy (meno male che era a Milano!) per accompagnare i bambini alle loro varie attività.

Invece mi è successo questo. Inizio le attività annuali presso un cliente e organizzo le interviste. Il referente del cliente mi segnala che la responsabile di un'area conosciuta l'anno scorso è in uscita perché "è tornata dalla maternità e tutte le donne quando tornano dalla maternità hanno pretese". Io non reagisco. Sicuramente avrei dovuto dire che non è opportuno generalizzare.

Su tutto il resto sentivo che c'era qualcosa che non andava, ma cosa? Avrei dovuto dire che non si tratta di pretese, ma di giusti diritti? Ma io non sapevo niente delle richieste della persona.

Allora ho pensato che una donna va in maternità e solitamente si assenta per un anno o un anno e mezzo. Poi torna e non sempre ha tantissima voglia di tornare in ufficio, con la strada da fare, i colleghi non sempre splendidi, i margini di libertà minori. Tanti di noi, in effetti, l'hanno sperimentato dopo la pandemia. Forse voleva fare smart working, non previsto dall'azienda. E quindi, in effetti, la richiesta non era così scontata.

Forse l'azienda, per l'anno o più di assenza, ha incaricato un'altra persona. Poi torna la titolare e cosa fare con la sostituta? In una piccola o media impresa c'è poco da fare: o la degradi o cerchi di suddividere le responsabilità. Come fai, sbagli.

Insomma, la situazione era sgradevole, ma io non sapevo perché. E forse l'unico motivo è che io sono un maschio che quindi non sono mai stato costretto ad affrontare una situazione così.

Manuale VERA

Ho scritto una prima bozza di manuale del VERA, il mio foglio Excel per valutare il rischio.

Chi volesse correggere le bozze (e indicare mancanze, imprecisioni, cose incomprensibili, eccetera), mi scriva privatamente.

Sono anni che mi chiedono un manuale e io non ho mai voluto scriverlo per pigrizia. Vito Losacco, amico e collega e concorrente, è stato l'ultimo a chiedermelo e questa volta non sono riuscito a dire di no. Spero solo di non aver peggiorato la situazione.

Garante privacy e conservazione email e metadati

Il Garante della privacy ha pubblicato il Provvedimento - Documento di indirizzo “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati”: https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9978728.

Esso si affianca alle antiche, ma sempre applicabili, "Linee guida del Garante per posta elettronica e Internet" del 2007.

Ringrazio Glauco Rampogna (Idraulico della privacy e molto altro) per avermi inviato la segnalazione precisa.

Se ho capito bene, il riassunto finale è: email e metadati (quindi anche i log) vanno conservati al più per 7 giorni dal datore di lavoro.

Nel caso in cui il datore di lavoro usi servizi email in cloud (Microsoft 365, Google e simili) e questi non permettono di configurare i parametri come prescritto, è necessario accordarsi con i sindacati o l'Ispettorato nazionale del lavoro, secondo quanto prescritto dall'articolo 4 della Legge 300 del 1970 (Statuto dei lavoratori). In alternativa, bisogna dedurre che, fino a quando il fornitore non metta a disposizione configurazioni allineate o in mancanza di accordo con i sindacati, bisognerebbe sospendere l'uso dell'email (opzione ovviamente non percorribile in tempi brevi).

Questo, penso, sia necessario anche quando il servizio email non è propriamente in cloud, ma comunque gestito da un fornitore esterno. C'è poi il problema (come ricorda Christian Bernieri, altro Idraulico della privacy) delle email di Gruppo, gestite da una Casa madre estera.

Christian Bernieri ha scritto un lungo articolo in merito qui: https://bernieri.blogspot.com/2024/02/chi-vusa-puse-la-vaca-le-sua.html.

Rimangono sempre in vigore gli obblighi di informativa verso i lavoratori e, se necessario, di valutazione d'impatto (DPIA).

Sto ragionando sul fatto che spesso è necessario mantenere i log per controllare se viene data risposta alle email (questo anche nella Pubblica amministrazione). Io posso pensare che per le caselle "d'ufficio", non si debbano applicare i 7 giorni.

domenica 11 febbraio 2024

EN 17740:2023 sui profili professionali privacy

A ottobre 2023 è stata pubblicata la EN 17740:2023 "Requirements for professional profiles related to personal data processing and protection": https://store.uni.com/en-17740-2023.

Essa è la traduzione della  UNI 11697:2017 "Attività professionali non regolamentate - Profili professionali relativi al trattamento e alla protezione dei dati personali - Requisiti di conoscenza, abilità e competenza".

A me sembrano norme un po' troppo corpose (ossia, le caratteristiche di DPO, privacy manager, specialista privacy e auditor privacy mi sembrano troppo numerose e forse eccessive). Però forse mi sbaglio io.

sabato 10 febbraio 2024

Atlante dell'Infanzia (a rischio) - Tempi Digitali

Segnalo il XIV Atlante dell'Infanzia (a rischio) - Tempi Digitali di Save the children: https://www.savethechildren.it/cosa-facciamo/pubblicazioni/14-atlante-dell-infanzia-a-rischio-tempi-digitali.

Notoriamente, in questo periodo mi sto occupando, anche perché coinvolto personalmente, del rapporto tra digitale e minori. Questa pubblicazione è forse troppo ricca (ammetto di averla solo sfogliata), ma riporta tante cose interessanti.

Nota divertente: è stato suggerito a me e ad altri genitori da un signore che avevamo involontariamente circondato al bar dopo aver condotto i bambini a scuola. Ci aveva sentito parlare del rapporto con il digitale, ovviamente.

lunedì 5 febbraio 2024

Sul cambio delle password

Qualche tempo fa, nel 2019, avevo segnalato che NIST e Microsoft non ritenevano più necessario il cambio periodico delle password perché siano sicure: https://blog.cesaregallotti.it/2019/04/microsoft-e-il-cambio-delle-password.html.

Avevo espresso qualche perplessità sul fatto che la giustificazione non considerava che, in ambiente lavorativo, alcuni si scambiano le password e il cambio periodico permette di tornare a una situazione più sicura. In generale, però, la mia esperienza mi ha fatto cogliere favorevolmente questo approccio.

Ne ho discusso con Stefano Ramacciotti che invece sostiene l'opportunità di cambiare periodicamente le password. Almeno una volta all'anno.

Stefano dice che il NIST non cita le ricerche su cui ha fondato questo approccio. Anzi, mi segnala questo articolo che segnala questa carenza e approfondisce perché è opportuno cambiare le password almeno una volta all'anno (quelle per uso personale) o più spesso (in ambito lavorativo): https://www.linkedin.com/pulse/why-passwords-must-periodically-changed-roger-grimes/.

Stefano mi dice che "il considerando 49 della recente NIS 2, che dovrà essere recepita entro il 18.10.2024, riporta il cambio delle password come misura di cyber hygiene", o anche che la PCI DSS V 4.0 del 2022 prevede il cambio ogni 90 gg".

Conviene poi sul fatto che oggi, con le tecniche di salting, i tempi per compromettere le password sono abbastanza lunghi, ma non abbastanza da non richiedere un cambio periodico delle password ("un attaccante che avesse fatto il dump del SAM delle password di Windows o di /etc/shadow su Linux avrebbe prima o poi acquisito la password").

Sui tempi di compromissione delle password, poi, mi segnala un altro articolo, che contesta le tabelle che spesso si vedono in giro (quelle che dicono che password di meno di 8 caratteri si possono compromettere in pochi minuti, quelle di 8-10 caratteri in ore, eccetera): https://billatnapier.medium.com/those-tables-password-cracking-times-that-scare-you-are-mostly-wrong-7d03bf4aec6.

In questo secondo articolo, l'autore sembra contraddire la posizione di Stefano e non promuove il cambio della password. Però lo stesso Stefano precisa che "l'articolo prende solo in esame attacchi a forza bruta e nulla dice in merito ad altri tipi di attacchi; inoltre questi metodi sono in uso sui sistemi operativi di nuova generazione ma sono ancora utilizzati vecchi sistemi operativi e non tutti i servizi web usano librerie di gestione password aggiornate (sono tantissimi i siti che non memorizzano in modo appropriato le password e, per gli attaccanti, è facile prendere elenchi di password anche in chiaro o con una protezione ROT-13 equivalente)".

Stefano contesta anche la giustificazione fornita dal NIST (ossia che gli utenti, se richiesti di cambiare frequentemente le password, le scelgono deboli) perché questo non dovrebbe impedire di promuovere buone pratiche come il cambio periodico.

La cosa mi ha fatto riflettere e ci rifletterò.

Chiudo dando l'ultima parola a Stefano, che ringrazio per il confronto sempre costruttivo: "Dato che il prossimo 2 maggio cade il Password Day (sempre il primo giovedì di maggio di ogni anno dal 2013), perché non usarlo per cambiare tutte le nostre password almeno una volta all'anno (anche se a naso direi meglio due volte)?".

sabato 3 febbraio 2024

Primo Cybersecurity Certification Scheme europeo (basato sui Common Criteria)

L'Unione Europea, secondo quanto previsto dal Cybersecurity Act nel 2019, ha adottato il primo schema di certificazione sulla cybersecurity: https://www.enisa.europa.eu/news/an-eu-prime-eu-adopts-first-cybersecurity-certification-scheme. Ringrazio Riccardo Lora per averlo segnalato agli Idraulici della privacy.

Questo schema è basato sui Common Criteria, quindi è più orientato ai prodotti.

Non ho ancora capito come funzionerà lo schema, visto che è previsto che ogni Paese indichi un NCCA (organismo di accreditamento) che a sua volta controllerà i CAB (organismi di certificazione). Visto che le certificazioni secondo i Common Criteria erano gestite in modo diverso dalle certificazioni sui sistemi di gestione, non ho elementi per sapere come funzionerà questo schema in Italia (rimando al sito dell'unico organismo di certificazione italiano, https://www.ocsi.gov.it/index.html). Aggiungo che i Common Criteria non sono molti usati in Italia, vista la loro complessità e i costi per ottenere la certificazione (e infatti sul sito dell'OCSI i prodotti italiani certificati sono pochi sui circa 60; ce ne sono diversi non italiani).

Segnalo poi che l'UE sta lavorando ad altri schemi, uno per i servizi cloud (molto più interessante, credo, per l'Italia) e sulla sicurezza del 5G (non mi è chiaro però a cosa si riferisce, posso dedurre ai prodotti che hanno connettività 5G, ma non ne sono sicuro). Credo che questi siano molto importanti per l'Italia, visto che riguarderanno un mercato significativo.

Sono anche stati presi i primi passi per schemi sull'intelligenza artificiale, sui servizi eIDAS e sui servizi di sicurezza gestita. Visti i tempi tenuti finora, rimango in paziente attesa.

Chiara Ponti mi ha gentilmente segnalato questo articolo: https://formiche.net/2024/02/ue-certificazione-cyber-mele/. Non conoscendo bene lo schema approvato, visto lo scarso successo dei Common Criteria per costi e complessità, visto il tempo passato dal 2019 al 2024 per uno schema che tutto sommato era già pronto, non sono convinto che "molto presto senza un ‘bollino di cybersicurezza’ i produttori rischieranno di essere di fatto tagliati fuori”. Ho sbagliato altre volte, potrei sbagliare anche questa.

Confesso la mia ignoranza su questi schemi, ma penso che sia una materia da tenere sotto controllo e ringrazio finora chiunque vorrà contribuire, anche con segnalazioni su corsi di formazione, articoli eccetera.

venerdì 2 febbraio 2024

Virus VERA.XLS

Stefano Ramacciotti mi ha segnalato questa pagina che parla del virus VERA.XLS: http://www.office-archive.com/2-excel/2996ddbb4f8b3ca7.htm.

La discussione è del 2001. Il mio VERA sarebbe nato 7 anni dopo, inconsapevole dell'omonimia. Molto divertente.

martedì 30 gennaio 2024

Strumento di analisi privacy dei siti web di EDPB

Franco Vincenzo Ferrari mi ha segnalato la pubblicazione del tool "Website auditing" dell'EDPB: https://edpb.europa.eu/news/news/2024/edpb-launches-website-auditing-tool_en.

Facilissimo da installare, permette di verificare i cookie attivi, se ha attivo l'https e altre semplici caratteristiche di un sito web. Onestamente: ne avevo proprio bisogno.

Esperienze sul whistleblowing

Avevo scritto tempo fa del D. Lgs. 24 del 2023 sul whistleblowing e delle Linee guida di Confindustria.

Ho avuto qualche esperienza in merito e ho voluto parlarne con gli Idraulici della privacy. Ho provato a mettere insieme le cose in una presentazione, aggiornata dopo il dibattito, che trovate qui: https://www.cesaregallotti.it/Pubblicazioni.html.

Nulla di nuovo, ma un'occasione per discuterne dopo le esperienze fatte.

Ci sono un paio di riflessioni sul canale di comunicazione da usare (non è detto che sia necessaria una "piattaforma" perché anche l'email può essere sufficiente) e sulla DPIA (che ho fatto senza calcoli).

Norme EN sulla privacy (e la certificazione GDPR)

Da ottobre 2023 sono disponibili due norme EN sulla privacy che potranno essere usate per le "certificazioni GDPR (art. 42 e 43)". Non avevo dato la notizia perché avevo fatto confusione con la numerazione.

La prima è la EN 17799:2023 "Personal data protection requirements for processing operations": https://standards.cencenelec.eu/dyn/www/f?p=205:110:0::::FSP_PROJECT:72146&cs=1542894B837546009C6EA75EEF37A17FB.

Essa è, in poche e imprecise parole, l'erede della UNI/PdR 43. La EN 17799 ha un ambito più ampio della PdR 43, non riducendosi al solo ambito ICT. È più destinata alle PMI.

La seconda è l'EN 17926:2023 "Privacy Information Management System per ISO/IEC 27701 - Refinements in European context": https://standards.cencenelec.eu/dyn/www/f?p=205:110:0::::FSP_PROJECT:73645&cs=1E27CF456A53D1D12798EDA52ADB48A97.

Questa, in pochissime e imprecisissime parole, dice: "Prendi la ISO/IEC 27701 e cambia un paio di cosine, così potrai usare questa EN 17926 per certificarti secondo articoli 42 e 43 del GDPR usando la ISO/IEC 27701". È più destinata alle organizzazioni di dimensione medio-grande.

In tutti e due i casi non sono pronte le norme con le regole di accreditamento (a mio parere non lo saranno prima del 2025) e quindi non sono ancora utilizzabili. Qualche organismo di accreditamento potrebbe lanciare in autonomia uno schema di certificazione, ma dubito che avverrà, visto che l'obiettivo è quello di usarle per uno schema di sigillo europeo e quindi essere approvate dall'EDPB.

Ringrazio gli Idraulici della privacy per avermi forzato a ripensare su queste norme.

Guida per gli adempimenti privacy in Svizzera

Franco Vincenzo Ferrari mi ha segnalato la pubblicazione della "Guida ai provvedimenti tecnici e organizzativi concernenti la protezione dei dati (TOM)" dell'Incaricato federale della protezione dei dati e della trasparenza (IFPDT) della Confederazione Svizzera: https://www.edoeb.admin.ch/edoeb/it/home/kurzmeldungen/km2024/23012024_leitfaden_tom.html.

La versione in inglese ("Guide to Technical and Organisational Data Protection Measures (TOM)"): https://www.edoeb.admin.ch/edoeb/en/home/kurzmeldungen/km2024/23012024_leitfaden_tom.html.

Nulla di nuovo, ma una buona guida, pragmatica e sintetica al punto giusto, per la protezione dei dati personali e la sicurezza delle informazioni.

mercoledì 24 gennaio 2024

Tassonomia dei rischi privacy dovuti all'IA

Dalla newsletter di Project:IN Avvocati, segnalo un documento dal titolo "Deepfakes, Phrenology, Surveillance, and More! A Taxonomy of AI Privacy Risks".

Si può scaricare dal link presente in un articolo di IAPP: https://iapp.org/news/a/shaping-the-future-a-dynamic-taxonomy-for-ai-privacy-risks/.

Dico che, a fronte di tanta (e forse troppa) documentazione sull'intelligenza artificiale, questo mi è sembrato particolarmente interessante perché riassume bene gli aspetti critici dell'IA.

Licenziamento per aver parlato male del datore di lavoro sui social

Segnalo questo articolo dal titolo "Parla male del datore di lavoro sui social? Sì al licenziamento per giusta causa": https://www.altalex.com/documents/news/2024/01/18/parla-male-datore-di-lavoro-su-social-si-a-licenziamento-per-giusta-causa.

Questo genere di notizie mi interessa sempre perché dimostrano (anche se con pochi casi) il rapporto curioso che molti hanno con i social media, dove si sentono in diritto di poter dire qualsiasi cosa, incuranti (o forse spinti) da chi possa venirne a conoscenza. La questione non è solo sociale, è anche di sicurezza delle informazioni: se manca un autocontrollo su quello che si scrive, potrebbero anche essere scritte cose riservate.

Misurazioni della sicurezza. Bozza della NIST SP 800-55

Il NIST ha pubblicato la bozza della nuova versione della SP 800-55 "Measurement Guide for Information Security": https://csrc.nist.gov/News/2024/nist-sp-800-55-draft-available-for-comment.

Come impressione generale mi sembra molto teorica e poco pratica. Manca di esempi significativi (i pochissimi che ci sono mi sembrano più per grandi che per piccole o medie imprese).

Ho trovato interessanti alcuni richiami teorici, anche se ormai faccio fatica a capirli fino in fondo.

lunedì 1 gennaio 2024

Garante privacy, ASL, Tribunale di Udine e DPIA (link alle sentenze)

Avevo scritto un post dal titolo "Garante privacy, ASL, Tribunale di Udine e DPIA": http://blog.cesaregallotti.it/2023/12/garante-asl-tribunale-di-udine-e-dpia.html.

Elia Barbujani (Idraulico della privacy) mi ha mandato un paio di link per approfondire.

Il primo riguarda la motivazione della sentenza del Tribunale di Udine: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9957324.

Il secondo riguarda la sentenza del Tribunale di Pordenone, citata dall'articolo di Silvia Stefanelli che avevo segnalato nel mio post: https://www.agendadigitale.eu/sicurezza/privacy/medicina-di-iniziativa-perche-anche-il-tribunale-di-udine-ha-detto-no-al-garante-privacy/.