Pubblicato il nuovo NIST Cybersecurity framework (NIST CFS 2.0)

Avevo segnalato la bozza del NIST CSF 2.0: https://blog.cesaregallotti.it/2023/08/nist-cybersecurity-framework-20-in-bozza.html.

Davide Giribaldi di Swiss Cyber Com mi ha informato che ne è stata pubblicata la versione definitiva: https://www.nist.gov/cyberframework.

Mi riporta anche le caratteristiche:

• Aggiunge il pilastro Governance a quelli già presenti;
• Valido non più solo per le infrastrutture critiche;
• Gestione rischio terze parti.

Mi chiede cosa ne penso. Ed ecco cosa ne penso, considerando che l'ho solo sfogliato:

• non ho trovato un file xls (o cvs) come c'era per la precedente versione ed era molto comodo; anzi, è poco chiaro come navigare tra i requisiti;
• i requisiti di sicurezza sono, alla fine, sempre quelli; la differenza tra uno schema e l'altro è la loro facilità d'uso; mi sembra sia diventato più complicato e più prolisso e questo non è un bene; per dare un giudizio completo dovrei contare il numero di controlli e quindi aspetto il formato xls;
• alcuni requisiti sono evidentemente tarati per aziende che possono permettersi una struttura documentale significativa e il CSF non discute possibili alternative (o, meglio, non parte da un minimo che possa essere ampliato).

Davide segnala che a questo punto dovrà essere aggiornato il Framework Nazionale per la Cybersecurity e la Data Protection (https://www.cybersecurityframework.it/framework2).

Cosa ne penso? Che potrebbe essere l'occasione per ripartire dalla ISO/IEC 27001, standard internazionale a cui collabora anche l'Italia.

Multa ad Avast (fornitore di servizi di sicurezza) per vendita non autorizzata di dati personali

Altre notizie che richiamano sempre la mia attenzione sono quelle relative ai fornitori di sicurezza insicuri.

La notizia riguarda Avast e l'ho avuta dalla newsletter di Project:IN Avvocati: https://www.linkedin.com/comm/pulse/82024-quando-un-software-di-protezione-dal-tracking-jvbdf.

In pochissime parole, i prodotti Avast (antivirus e no-tracker) raccoglievano i dati degli utilizzatori e poi Avast li rivendeva. Dettagli in quantità nell'articolo "FTC Order Will Ban Avast from Selling Browsing Data for Advertising Purposes, Require It to Pay $16.5 Million Over Charges the Firm Sold Browsing Data After Claiming Its Products Would Block Online Tracking": https://www.ftc.gov/news-events/news/press-releases/2024/02/ftc-order-will-ban-avast-selling-browsing-data-advertising-purposes-require-it-pay-165-million-over.

Interruzione della rete AT&T per errore di configurazione

Io sono sempre incuriosito dalle notizie su incidenti relativi alla sicurezza delle informazioni causati da errori. Si parla tanto di attacchi (e le notizie sono tantissime), ma la sicurezza comprende anche la prevenzione di errori o il controllo dei loro impatti ed è bene non dimenticarlo.

Questo comporta la necessità di avere processi di sviluppo e change che non solo considerino le funzionalità e le architetture di sicurezza, ma anche i controlli di qualità.

Ecco quindi un articolo con sottotitolo "AT&T blamed itself for incorrect process used as we were expanding our network.": https://arstechnica.com/tech-policy/2024/02/atts-botched-network-update-caused-yesterdays-major-wireless-outage/.

La rete di AT&T negli USA è rimasta bloccata per alcune ore il 22 febbraio 2024 a causa di un errore di configurazione.

Non sapevano che era impossibile

Qualche tempo fa avevo letto la storia di George Dantzig, che risolse nel 1930 due problemi impossibili, non sapendo che erano impossibili (e dimostrando però che erano possibili).

Non ricordo dove l'avevo letta, ma l'ho citata tante volte e allora l'ho ricercata sul web e ho trovato questa pagina web che la racconta bene: https://it.aleteia.org/2021/02/05/una-lezione-per-il-2021-dallerrore-di-un-matematico/.

Non sono affascinato dalle pagine di aiuto-aiuto (pensiero positivo, elogio dell'impegno a tutti i costi, stay hungry eccetera). Anzi, le rifuggo. Però penso ci sia comunque una lezione in questa storia. Non so ancora quale, ma c'è.

ISO/IEC 42001 sull'intelligenza artificiale (02)

Avevo già scritto in precedenza della ISO/IEC 42001 (https://blog.cesaregallotti.it/2023/12/isoiec-42001-sullintelligenza.html).

Flavio De Pretto mi ha segnalato questo articolo più dettagliato (anche meno critico del mio post), che ha scritto insieme a Attilio Rampazzo e e Stefano Gorla dal titolo "ISO/IEC 42001:2023: un approccio etico per la governance della Intelligenza Artificiale": www.ictsecuritymagazine.com/articoli/regolamentare-lintelligenza-artificiale-iso-ha-gia-pubblicato-la-norma-di-gestione/.

Se un umano ti accusa di aver usato un'AI

Da Guerre di rete del 18 febbraio 2024 (https://guerredirete.substack.com/) segnalo questo articolo dal titolo ‘Obviously ChatGPT’ — how reviewers accused me of scientific fraud: https://www.nature.com/articles/d41586-024-00349-5.

Il suggerimento per chi scrive (senza l'aiuto di chat GPT) è: usare Git per dimostrare gli avanzamenti di quanto prodotto.

Garante privacy e conservazione email e metadati 02

In merito alle indicazioni del Garante privacy sui metadati delle email (ne ho parlato nel post https://blog.cesaregallotti.it/2024/02/garante-privacy-e-conservazione-email-e.html), mi hanno segnalato il lavoro fatto dal Comune di Preganziol (con il supporto di un Idraulico della privacy).

La pagina è questa: https://servizionline.comune.preganziol.tv.it/zf/index.php/trasparenza/index/index/categoria/393 e il documento è la "Informativa sul trattamento dei dati personali e dei metadati nei servizi informatici di gestione della posta elettronica nel contesto lavorativo".

Credo sia molto completa e dia ottime indicazioni su come affrontare questo argomento.

Mi scrive Glauco Rampogna, che ha avuto il supporto di Monica Perego (ambedue Idraulici della privacy) che il Comune non usa servizi cloud per l'email e quindi l'informativa va letta con questa attenzione.

Continuità operativa, sigle (MBCO e RTO) e relativismo

Nell'ambito della continuità operativa, si usa spesso il parametro MBCO, Minimum business continuity objective.

Io, al di là delle definizioni ufficiali, l'ho sempre inteso così: a seguito di un incidente bloccante e di un'interruzione più o meno lunga (la cui durata dovrebbe essere inferiore all'MTPD e all'RTO), le attività possono ripartire con prestazioni inferiori al normale e queste prestazioni sono determinate dall'MBCO.

Venendo dalla continuità operativa in ambito informatico, l'esempio è il DR (disaster recovery): RTO è il tempo di ripartenza massimo, RPO è il tempo tra un backup e l'altro, MBCO è il dimensionamento delle macchine nel sito di DR. Ho imparato subito che, oltre alle macchine, è necessario includere nell'MBCO le persone.

Nel seguito ho imparato che l'MBCO va accompagnato da un tempo massimo in cui si può proseguire con quelle prestazioni (una sorta di RTO-2).

Ho imparato poi che, in fase di emergenza, dall'incidente al riavvio con prestazioni ridotte, sono richieste risorse, soprattutto persone, diverse da quelle necessarie a proseguire le attività con prestazioni ridotte. Infatti è necessario avviare i processi "ridotti" e per questo possono essere necessari tecnici diversi da quelli che poi dovranno presidiarli successivamente. Una sorta di MBCO-0.

Molto recentemente mi hanno fatto invece notare che la definizione di MBCO riguarda le prestazioni che vanno comunque garantite. In altre parole, se ho RTO maggiore di zero (quindi i processi possono rimanere fermi per un certo tempo), l'MBCO deve essere zero.

Non sono molto convinto di questo approccio, ma poco importa. Quello che mi importa è che tutta questa terminologia porta a una semplificazione che non può esistere nella realtà. Infatti ci sono più tempi da rispettare (come minimo: il tempo di interruzione totale, il tempo di attività con prestazioni ridotte) e più risorse necessarie (quelle da garantire in ogni caso, quelle da garantire per far ripartire le attività, quelle per le attività con prestazioni ridotte).

Allora apprezzo maggiormente la terminologia della ISO 22301 che usa "archi temporali" (time frames) e "risorse". Termini più generali, che lasciano aperte più possibilità.

Forse un giorno saranno identificate sigle utili. Per intanto, ho imparato che quando sento "RTO", "RPO" e "MBCO" chiedo sempre cosa intende il mio interlocutore e, tranne casi particolarissimi, lo accetto. Poi trovo sempre sorpresa davanti alla mia domanda, e allora devo spiegare il motivo.

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.

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.

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.

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.

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.

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)?".