domenica 17 marzo 2024

ENISA Telecom security incidents 2022

Franco Vincenzo Ferrari mi ha segnalato la pubblicazione, il 14 marzo 2024, del rapporto ENISA "Telecom security incidents 2022": https://www.enisa.europa.eu/publications/telecom-security-incidents-2022.

Il totale di incidenti segnalato è basso: 155.

Interessante notare che solo il 6% è dovuto ad azioni malevole, il resto è dovuto a guasti (72%), errori umani (15%) e fenomeni naturali (6%).

Questo non vuol dire che si debbano ignorare gli attacchi intenzionali, ma che la sicurezza riguarda anche (e forse soprattutto) la prevenzione degli errori e il controllo di guasti ed eventi naturali, spesso sottovalutati forse perché non richiamano battaglie all'ultimo bit o situazioni da film d'avventura. Da non dimenticare comunque che ogni rete è oggetto di più scansioni ogni giorno (ma questo dato non si trova in questo rapporto di ENISA e, anzi, chiedo dove ritrovarlo perché il mio riferimento risale ai primi anni 2000).

 

 

eIDAS 2.0

eIDAS 2.0 non è stato ancora approvato in modo definitivo, ma si può pensare che il testo sia quello. Per questo Franco Vincenzo Ferrari mi ha segnalato un articolo di Giovanni Manca dal titolo "eIDAS 2.0: tutte le novità": https://www.forumpa.it/pa-digitale/eidas-2-0-tutte-le-novita/.

Ringrazio e ne raccomando la lettura.

Approvato l'AI Act europeo

Negli ultimi mesi sono girate tante notizie sull'AI Act,, però prima che fosse approvato.

Il 13 marzo è stato approvato dal Parlamento Europeo. Io non ne parlo direttamente e preferisco indirizzare a Guerre di rete: https://guerredirete.substack.com/p/guerre-di-rete-ai-act-infine.

Ovviamente ci sono tantissimi altri articoli che ne parlano. Io per ora mi fermo qui.

venerdì 15 marzo 2024

Repository VERA su GitHub

Tanti mi segnalano variazioni a VERA o mi raccomandano aggiunte e modifiche. Io cerco di mantenere il file nel modo più semplice possibile e ho deciso di pubblicarlo su GitHub: https://github.com/CesareGallotti/VERA.

In questo modo, mi sarà forse più facile caricare gli aggiornamenti e chiunque potrà creare un fork per presentare la propria variazione (o forse lo farò io stesso).

Ogni suggerimento sull'uso di GitHub sarà gradito. Se qualcuno vorrà proporre alternative, le prenderò in considerazione (almeno finché non ci saranno fork).

Per intanto, ho caricato il VERA 7.3 (l'ultima versione con qualche correzione) in italiano e inglese e il manuale in italiano e in inglese.

Note sulla NIS2

Miei appunti e riflessioni sulla NIS2. In molti mi hanno chiesto cosa ne so e cosa ne penso, quindi pubblico tutto quello che ne so e ne penso.

Due parole sulla NIS 2

NIS 2 (Direttiva UE 2022/2055) entrata in vigore il 17 gennaio 2023. 

NIS2 dovrà essere recepita entro ottobre 2024.

  • Aumentano i soggetti.
  • Richiede un’analisi dei rischi.
  • Le misure dovrebbero essere adeguate al contesto, considerando quindi anche la capacità di spesa.

Soggetti a cui si applica la NIS2

L’applicabilità dipende dai settori e dalla dimensione (più di 50 addetti e giro d’affari superiore ai 10 milioni di Euro; escludendo quindi le piccole e medie) dell’organizzazione. La NIS2 è applicabile quindi a: 

  • soggetti essenziali (essential entities);
  • soggetti importanti (important entities).

La differenza pratica riguarda i controlli e le sanzioni.

La NIS2 coinvolge più aziende rispetto al PNCS.

Con la NIS 2 le entità dovranno riconoscersi come soggetti che devono applicare la NIS 2, non è più l’autorità che le designa come tali. E’ previsto che le entità si registrino secondo regole che saranno fornite.

Sulla base delle registrazioni, entro il 17 aprile 2025, gli Stati membri creano un elenco dei soggetti essenziali e importanti e dei soggetti che forniscono servizi di registrazione dei nomi di dominio.

Lo schema seguente si trova sul sito https://ccb.belgium.be/en/nis-2-directive-what-does-it-mean-my-organization.

Rientreranno nel perimetro di applicazione anche i soggetti definiti “critici” dalla Direttiva (UE) 2022/2557, meglio nota come Direttiva CER.

Ulteriori soggetti potrebbero essere aggiunti dalla normativa nazionale.

Valutazione del rischio

NIS2 è multirischio: logico, fisico, governo, lock in tecnologico, utilities. E considera l’impatto “sociale ed economico” e richiede un “livello appropriato” di sicurezza.

Il Belgio mette a disposizione un approccio piuttosto semplice (ma non capisco bene come funziona): https://ccb.belgium.be/en/choosing-right-cyber-fundamentals-assurance-level-your-organisation.

Interessante la tabella degli impatti, perché forse potrebbe essere riutilizzata per identificare gli incidenti significativi (vedere sotto).

Gli Orientamenti della Commissione del 13.9.2023 indicano di considerare le seguenti minacce, sempre in una logica di multirischio:

  • sabotaggi,
  • furti,
  • incendi,
  • inondazioni,
  • problemi di telecomunicazione,
  • problemi di interruzioni di corrente,
  • qualsiasi accesso fisico non autorizzato in grado di compromettere la disponibilità, l'autenticità, l'integrità o la riservatezza dei dati conservati, trasmessi o elaborati o dei servizi offerti da tali sistemi informativi e di rete o accessibili attraverso di essi,
  • guasti del sistema,
  • errori umani,
  • azioni malevole, fenomeni naturali.

Commento

L’auspicio è che, se saranno date indicazioni su come condurre una valutazione del rischio, non venga riproposto il modello formale, ma non utile, basato su asset, minacce e vulnerabilità, ma invece un modello, come poi si vede negli Orientamenti, basato sugli eventi, per cui non è utile avere un dettaglio di tutti gli asset a questo scopo (è invece necessario per attività operative).

Misure di sicurezza

La Direttiva identifica (articolo 21 paragrafo 2) le misure di gestione del rischio, ossia:

  1. Politiche di analisi dei rischi e della sicurezza dei sistemi informatici
  2. Sistemi di gestione degli incidenti
  3. Soluzioni di business continuity capaci di garantire la continuità operativa e la gestione della crisi, dai backup al disaster recovery
  4. Misure di sicurezza dell’intera supply chain, a comprendere perciò i rapporti tra ogni soggetto e i suoi fornitori
  5. Sicurezza dell’acquisizione, sviluppo e manutenzione dei sistemi e delle reti informatiche, compresa la gestione e la divulgazione delle vulnerabilità
  6. Strategie e procedure per valutare l’efficacia delle misure di gestione dei rischi di cybersecurity
  7. Pratiche di igiene informatica basilari e formazione in materia di sicurezza informatica
  8. Procedure relativa all’uso della crittografia e, se necessario, della cifratura
  9. Misure per la sicurezza delle risorse umane grazie a strategie e politiche di controllo degli accessi (log management) e gestione degli asset
  10. Uso di soluzioni di autenticazione a più fattori o di autenticazione continua, di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza protetti all’interno dell’entità, ove opportuno.
Perri dice che c’è un indice sulla valutazione delle competenze, ma io non l’ho trovato (o forse ho capito male); forse nelle interpretazioni.

Entro il 17 ottobre 2024, la Commissione adotta atti di esecuzione che stabiliscono i requisiti tecnici e metodologici delle misure di cui sopra per quanto riguarda i fornitori di:

  • servizi DNS,
  • registri dei nomi di dominio di primo livello (TLD),
  • servizi di cloud computing,
  • servizi di data center,
  • reti di distribuzione dei contenuti,
  • servizi gestiti,
  • servizi di sicurezza gestiti,
  • mercati online,
  • motori di ricerca online,
  • piattaforme di servizi di social network,
  • prestatori di servizi fiduciari.
Alcuni prevedono che siano quindi da applicare:
  • requisiti specifici settoriali stabiliti dalla Commissione (o, in alternativa, requisiti raccomandati da ENISA o dalle autorità nazionali);
  • requisiti di base comuni (o, in alternativa, certificazione ISO/IEC 27001).

Il Belgio (come l’Italia) propone elenchi di misure basati sul NIST CSF: https://ccb.belgium.be/en/cyberfundamentals-framework.

Allo stato attuale (13 marzo 2024) non sono state stabilite le misure da adottare. In Italia sappiamo che adesso, per i soggetti sotto NIS, sono richieste quelle del Framework Nazionale per la Cybersecurity e la Data Protection (https://www.cybersecurityframework.it/framework2) e così in altri Paesi. Forse con la NIS 2 seguiranno altri schemi.

Attenzione che le misure stabilite dagli Stati membri e di cui all’articolo 21 paragrafo 1 della NIS2 vanno applicate a tutte le attività operative operazioni e a tutti i servizi del soggetto interessato, non solo a risorse informatiche specifiche o a servizi critici forniti dal soggetto. Mia interpretazione: per evitare che un soggetto con servizi “sicuri” e “non sicuri” possa essere violato sfruttando le carenze dei servizi “non sicuri” per poi, con movimenti laterali, compromettere anche quelli “sicuri”.

Commento

Personalmente spero sia adottata la ISO/IEC 27001. Potrebbero anche lasciare più scelte ai soggetti. Infatti delegati italiani potrebbero partecipare agli aggiornamenti e alle estensioni della ISO/IEC 27001, e non subire passivamente gli aggiornamenti del NIST.

In tutti i casi, raccomando di cominciare a implementare la ISO/IEC 27001, su cui, eventualmente, innestare le richieste specifiche che saranno fatte. Un’implementazione ISO/IEC 27001 può essere facilmente convertibile per NIST CSF o altri.

Gestione incidenti

Come già previsto dalla Direttiva NIS 1, anche NIS 2 prevede l’obbligo di notifica al CSIRT e alle autorità competenti (oltre che ai destinatari stessi del servizio) degli incidenti significativi (incidenti informatici capaci di impattare in modo significativo sulla fornitura del servizio).

Le comunicazioni al CSIRT dovranno avvenire:

  • Entro 24 ore dalla conoscenza dell’incidente con una notifica di preallarme (questo per attenuare la potenziale diffusione di incidenti e per consentire di chiedere assistenza);
    • deve riportare i dati strettamente necessari se l'incidente significativo è sospettato di essere il risultato di atti illegittimi o malevoli o se potrebbe avere (ossia se è probabile che abbia) un impatto transfrontaliero;
    • deve contenere una valutazione iniziale dell'incidente significativo, comprensiva della sua gravità e del suo impatto, nonché, ove disponibili, gli indicatori di compromissione.
  • Entro 72 ore dalla conoscenza dell’incidente con aggiornamenti rispetto alle informazioni fornite con il preallarme
  • Entro 1 mese dalla conoscenza dell’incidente con una relazione finale a completamento del processo di segnalazione (questo per poter trarre insegnamenti preziosi dai singoli incidenti);
    • la relazione deve essere comprensiva della sua gravità e del suo impatto, il tipo di minaccia o la causa di fondo che ha probabilmente innescato l'incidente, le misure di mitigazione adottate e in corso e, se opportuno, l'impatto transfrontaliero dell'incidente.

Alcuni soggetti sono soggetti a più normative e quindi a diverse modalità di notificazione degli incidenti. In alcuni casi, il recepimento può essere complesso.

Obbligatorietà:

  • Articolo 23, stabilisce quando è obbligatorio notificare;
  • Articolo 30, indica quando la notifica è volontaria (altri incidenti, minacce, quasi incidenti, anche da parte degli altri soggetti).
Nella NIS2 c’è la definizione di “incidente significativo” nell’articolo 23, paragrafo 3: se ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato o se si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.

Vanno quindi definiti meglio e forse la tabella degli impatti usata per valutare il rischio.

Definiti anche i «quasi incidenti». Un evento che avrebbe potuto compromettere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati conservati, trasmessi o elaborati o dei servizi offerti dai sistemi informatici e di rete o accessibili attraverso di essi, ma che è stato efficacemente evitato o non si è verificato.

La NIS2 istituisce la rete europea delle organizzazioni di collegamento per le crisi informatiche (EU-CyCLONe).

Altri argomenti

La NIS2 prevede ulteriori argomenti:

  • Cooperazione tra Stati membri
  • Sanzioni
  • Punti di contatto nazionali
  • Ruolo dell'ENISA

Questi però non rientrano nelle mie competenze e non li ho approfonditi.

Bibliografia

Sito web del Center for cyber security Belgium: https://ccb.belgium.be/en/choosing-right-cyber-fundamentals-assurance-level-your-organisation. Grazie ad Alessandro Cosenza per la segnalazione.

Presentazione “Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (“NIS2 directive”)”.

Sito web della UE: https://www.enisa.europa.eu/topics/cybersecurity-policy/nis-directive-new. Però non fornisce indicazioni che io ritengo utili.

Criteri interpretativi sulla NIS2 della Commissione: https://digital-strategy.ec.europa.eu/en/library/commission-guidelines-application-article-4-1-and-2-directive-eu-20222555-nis-2-directive. Grazie a Pierluigi Perri.

lunedì 11 marzo 2024

Nuova ISO/IEC 29100

Pubblicata la ISO/IEC 29100:2024 "Information technology - Security techniques - Privacy framework": https://www.iso.org/standard/85938.html.

Le novità principali non sono paticolarmente significative (aggiornati i riferimenti normativi e la bibliografia, cambiato "secondary use” con “secondary purpose”).

Va detto che la ISO/IEC 29100 fissa la terminologia relativa alla privacy nell'ambito delle norme ISO/IEC, in alcuni casi significativamente diversa da quella del GDPR (per esempio usa "PII principal" al posto di "data subject", ossia "interessato").

Forse l'acquisto di 129 CHF non vale lo sforzo, visto che le definizioni sono comunque disponibili sul ISO Online Browsing Platform (OBP): https://www.iso.org/obp/ui.

Grazie a Monica Perego (Idraulica della privacy) per la segnalazione.

 

Accreditamento EA per Europrivacy

Grazie agli Idraulici della privacy, vengo a sapere che EA ha approvato i criteri di Europrivacy per le certificazioni secondo l'articolo 43 del GDPR: https://www.linkedin.com/posts/europrivacy_gdpr-europrivacy-datacontrollers-activity-7172870504884682752-w5x-.

Secondo l'articolo, EA ha esteso quanto già fatto da Accredia. Quindi gli altri organismi di accreditamento potranno riutilizzare il lavoro già fatto.

Sanzione privacy per incompleta informativa

Dalla newsletter del Garante privacy, segnalo il Provvedimento dell'8 febbraio 2024 [9991183]: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9991183.

La cosa che mi ha fatto pensare è che la sanzione è in parte dovuta alla mancata indicazione della base giuridica sull'informativa. Un dettaglio a cui, quindi e giustamente, prestare attenzione.

Sanzione privacy a Unicredit misure di sicurezza

Segnalo, dalla newsletter del Garante privacy, il Provvedimento dell'8 febbraio 2024: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9991020.

Le motivazioni per la sanzione, per una violazione avvenuta a ottobre 2018, sono:

- risposte HTTP del sito di home banking con in chiaro nome, cognome, codice fiscale e codice identificativo dei clienti ed ex clienti (peraltro nota a seguito di vulnerability assessment condotto proprio nei giorni in cui subiva l'attacco);

- mancato controllo della robustezza del PIN scelto dall'utente (evitando, per esempio, quelli composti da sequenze di numeri o coincidenti con la data di nascita).

E' stata condannata anche NTT Data perché aveva dato in subappalto il vulnerability assessment, nonostante il subappalto fosse proibito dal contratto con Unicredit.

C'è da meditare.

Auditing Practice Articles

Segnalo la pubblicazione dell'SC 27 Journal Volume 3, Issue 4 Oct 2023 – Auditing Practice Articles: https://committee.iso.org/sites/jtc1sc27/home/wg2.html.

Si tratta di un insieme di chiarimenti sulla ISO/IEC 27001 non ufficiali scritti dagli stessi esperti del gruppo che ha scritto la ISO/IEC 27001.

Vale la pena leggerli, anche perché troppo spesso opportunità di miglioramento (p.e. di integrazione del SOA o di irrobustimento dei controlli) sono interpretate da troppi auditor e consulenti e docenti come requisiti.

Su questo vale la pensa osservare come molte energie sono spese nella valutazione del rischio e poi nell’implementare i controlli “come nell’Annex A o nella ISO/IEC 27002” e questo sia in contraddizione: la valutazione del rischio deve guidare la scelta dei controlli e di come realizzarli, non il fatto che siano presenti nell’Annex A.

Non c’è solo questo negli articoli e invito a leggerli.

giovedì 7 marzo 2024

Miei webinar su NIS 2 e whistleblowing

Mi vanto un po' e segnalo questi due webinar che terrò prossimamente.

Nel primo, il 18 aprile alle 10.30, parlerò di NIS2: https://www.coretech.it/en/service/event/eventDetail.php?ID=1124.

Nel secondo, l'8 maggio alle 10.30, parlerò di whistleblowing: https://www.coretech.it/en/service/event/eventDetail.php?ID=1125.

Studio ENISA sulla Cyber Insurance

Riccardo Lora (Idraulico della privacy, che ringrazio), mi segnala lo studio ENISA "Cyber Insurance - Models and methods and the use of AI", pubblicato il 21 febbraio: https://www.enisa.europa.eu/publications/cyber-insurance-models-and-methods-and-the-use-of-ai.

Riccardo commenta: il doc è interessante perché evidenzia come è e sarà sempre più complesso per le compagnie trovare il modo di coprire il rischio cyber con gli strumenti adottati finora come il calcolo sullo storico dei sinistri.

Io segnalo quanto segue:

  • il titolo coinvolge l'IA evidentemente per moda, visto che non è un tema così significativo per lo studio;
  • conferma la carenza di dati per poter sviluppare ulteriormente le analisi statistiche;
  • afferma che le ciber-assicurazioni possono dare benefici soprattutto se affiancate da servizi di ciber-assistenza (ma, mi sembra, senza esplicitarli compiutamente).

lunedì 4 marzo 2024

Cybersecurity Certification Scheme europeo ora anche in Italia

Accredia ha pubblicato alcuni chiarimenti in merito al Cybersecurity Certification Scheme europeo recentemente approvato: https://www.accredia.it/2024/02/28/sistema-europeo-di-certificazione-della-cybersicurezza/.

In sostanza, le certificazioni Common criteria secondo il Cybersecurity Certification Scheme europeo dipenderanno da Accredia e ACN.

Ringrazio Franco Vincenzo Ferrari per avermi segnalato la pagina.

Pubblicata la nuova ISO/IEC 27006-1:2024

Pubblicata la nuova versione della ISO/IEC 27006-1 dal titolo " Information security, cybersecurity and privacy protection - Requirements for bodies providing audit and certification of information security management systems — Part 1: General": https://www.iso.org/standard/82908.html.

Questo è uno standard che usano gli organismi di certificazione per le attività di certificazione ISO/IEC 27001 e non fornisce indicazioni utili per le altre organizzazioni.

venerdì 1 marzo 2024

Sanzione privacy a ENEL Energia e misure di sicurezza

Il Garante ha sanzionato per 80 milioni di Euro Enel Energia per non aver protetto adeguatamente i dati di contatto dei propri clienti e, quindi, permettendo ad agenzie di marketing non autorizzate di usarli per contattare tali clienti per attività non autorizzate.

Il Provvedimento (documento 9988710) dell'8 febbraio 2024, segnalatomi da Monica Perego (Idraulica della privacy): https://gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9988710.

Mi interessano soprattutto le misure di sicurezza contestate:

  • Controllo accessi a 2 fattori, ma che non impedisce l'accesso contemporaneo dello stesso utente da due postazioni distinte e che quindi permette a più persone di usare le medesime credenziali. Questo non mi convince perché un operatore può trovare comodo aprire più istanze della stessa applicazione, come ho sperimentato anche personalmente. Questo però mi permette di capire meglio il perché di una vecchia misura minima del DPR 318 del 1999, che peraltro era già stata oggetto di molte contestazioni all'epoca e infatti non fu ripresa dalle misure minime del D. Lgs. 196 del 2003.
  • Mancata analisi dei log per intercettare tecniche di "sottobosco di marketing", peraltro note e identificabili con analisi dei quantitativi di contratti inseriti.
  • Mancata analisi dei log per identificare connessioni multiple e accessi da locazioni geografiche sospette. La giustificazione da parte di Enel Energia si basa sulla poca significatività di tali analisi, considerando l'uso di dispositivi portatili e del lavoro agile.
  • Accettazione di contratti inseriti da società non presenti nella rete vendita. Non trovo approfondimenti su questo aspetto nel Provvedimento. Io lo collegherei alla scorretta attivazione, alla mancata disattivazione o ai carenti riesami delle utenze delle società.
  • Mancato controllo dei responsabili e dei sub-responsabili.

Non mi interessa analizzare deduzioni e controdeduzioni presenti nel Provvedimento, ma solo prendere nota delle misure considerate necessarie e, per me, da considerare nelle mie attività.

Nuove versioni degli standard per i cambiamenti climatici

Molti avranno notato la pubblicazione di Amendment di numerosi standard ISO e ISO/IEC. In particolare della ISO 9001, ISO/IEC 27001, ISO/IEC 20000-1.

Sono state aggiunte due frasi:

  • nell'ambito della comprensione del contesto (4.1), è richiesto di determinare se il cambiamento climatico è una questione pertinente;
  • nell'ambito della comprensione dei requisiti delle parti interessate (4.2), è stata inserita una nota per segnalare che le parti interessate possono avere requisiti relativi al cambiamento climatico.

Monica Perego (Idraulica della privacy) mi ha segnalato la pubblicazione IAF (l'ente che coordina a livello internazionale gli organismi di accreditamento che, a loro volta, controllano gli organismi di certificazione) dal titolo "IAF-ISO Joint Communiqué on the addition of Climate Change considerations to Management Systems Standards". Si trova tra i comunicati dell'IAF su questa pagina: https://iaf.nu/en/iaf-documents/?cat_id=1.

Parere personale: io prendo molto sul serio il cambiamento climatico e sono convinto si debbano fare molte cose anche urgentemente. Non credo però che questa iniziativa, che può creare anche confusione, porterà significativi miglioramenti. Inoltre ogni edizione degli standard non può essere emendate per più di due volte e questa iniziativa ne toglie una.

Avrei preferito una nota e aggiunte in tutte le nuove edizioni degli standard, mano a mano che escono.

Almeno gli Amendment sono gratuiti per tutti gli standard sul sito www.iso.org. Però bisogna registrarsi e dare il numero di carta di credito (mi sono fermato a questo punto).

giovedì 29 febbraio 2024

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.

mercoledì 28 febbraio 2024

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.

giovedì 22 febbraio 2024

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'è.

martedì 20 febbraio 2024

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.

lunedì 19 febbraio 2024

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.

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