So che esco un po' di tema, ma l'iniziativa de "Il Manifesto della comunicazione non ostile" mi sembra molto interessante: https://www.paroleostili.it/manifesto-della-comunicazione-non-ostile.
Riguarda anche la comunicazione online ed è stato declinato per aziende, l'inclusione, l'infanzia, l'intelligenza artificiale, la politica, la pubblica amministrazione, la scienza e lo sport. E' stato anche tradotto in diverse lingue.
Sull'ISACA Journal, volume 1, 2025, un articolo segnala la disponibilità del report dell'U.S. Department of Homeland Security "Review of the Summer 2023 Microsoft Exchange Online Intrusion": https://www.cisa.gov/resources-tools/resources/CSRB-Review-Summer-2023-MEO-Intrusion.
Nell'estate 2023, un attore di minaccia con intenti di spionaggio compromise e accedette senza autorizzazione a molte caselle email su servizi cloud. Questo avvenne perché usarono una chiave non valida del Microsoft Service Account. La questione è molto tecnica e non cerco neanche di capirla fino in fondo.
La parte interessante riguarda alcune raccomandazioni, fatte anche a seguito del confronto con altri fornitori di servizi cloud. Le prime possono essere considerate generali, richiedendo alla Direzione di Microsoft di concentrarsi maggiormente sulla sicurezza, ma sono anche molto specifiche quando richiedono a Microsoft di "deprioritize feature developments across the company’s cloud infrastructure and product suite until substantial security improvements have been made".
Ancora, richiedono a Microsoft di fornire, in alcuni casi anche gratuitamente, agli utenti strumenti di logging (con tempi di conservazione di almeno 6 mesi), di raccolta prove e di rilevazione di attacco.
Per quanto riguarda il reporting, la raccomandazione 15 richiede: "CSPs should be transparent to U.S. government agencies, customers, and other stakeholders on what they know as well as what they do not know when initially investigating a cyber incident", esplicitando il fatto che la reticenza non è accettabile. Nella 16 richiede poi che "CSPs should promptly correct significant factual inaccuracies as they discover them in their public or customer statements".
Il 13 marzo sono andato al Security summit. Alle 12.20 avevo un intervento con Fabio Guasconi e alle 14.20 volevo assistere al seminario di DFA (di cui sono consigliere) dal titolo "AI forensics, una soluzione?".
Era anche una bella occasione per rivedersi tra Presidente (Maria Elena Iafolla), ex presidenti (io, Mattia Epifani e Valerio Vertua) dell'associazione e anche altri consiglieri (cito Federico Lucia).
Però la moglie ha avuto una promozione (evviva!), un cambiamento di sede e di collaboratori e non poteva stare in casa. Il pargolo adolescente aveva in programma un bel filotto di verifiche e interrogazioni per i successivi giorni e molta poca voglia di studiare. Era necessario che qualcuno stesse in casa ad aiutarlo a concentrarsi: è toccato a me.
Ovviamente il seminario di DFA è andato benissimo e i miei amici si sono trovati benissimo anche senza di me.
Dalla newsletter di Project:IN Avvocati, copio come segue: "È stata pubblicata la terza bozza del Codice di condotta generale per l’intelligenza artificiale, uno strumento volontario pensato per aiutare i fornitori di modelli di IA a dimostrare la conformità con l’AI Act europeo, in vista della sua piena applicazione da agosto 2025. Rispetto alle versioni precedenti, questa bozza è più snella, strutturata e dettagliata, con impegni chiari e misure attuative. Sottolinea l'importanza di un equilibrio tra chiarezza e flessibilità per adattarsi all’evoluzione tecnologica, e di ecosistemi di governance per una gestione condivisa del rischio. La pubblicazione è accompagnata da un riepilogo esecutivo e un sito web interattivo per facilitare il coinvolgimento degli stakeholder. Il testo finale è previsto per maggio 2025. Il Codice, pur essendo volontario, rappresenta un strumento strategico per sostenere la transizione normativa e promuovere fiducia, responsabilità, sicurezza e trasparenza. Il processo resta aperto al contributo attivo delle parti interessate, in linea con l’approccio partecipativo dell’UE per un’IA etica e sicura".
Come è noto, non apprezzo le bozze, ma credo che questa sia utile a chi deve muoversi nell'attesa della versione definitiva.
La pagina di riferimento è questa: https://digital-strategy.ec.europa.eu/en/library/third-draft-general-purpose-ai-code-practice-published-written-independent-experts. I documenti sono in inglese.
Copio e incollo (senza pudore) dalla newsletter Project:IN Avvocati: "La Commissione europea ha pubblicato le clausole contrattuali modello (MCC) aggiornate per l'intelligenza artificiale (IA), distinguendo tra sistemi di IA ad alto rischio e non ad alto rischio, quali misure provvisorie fino a quando l'IA Act non sarà pienamente applicabile".
Le MCC si possono scaricare da qui, in tutte le lingue della UE: https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/eu-model-contractual-ai-clauses-pilot-procurements-ai.
La settimana del 10 marzo si sono tenuti i meeting semestrali del ISO/IEC JTC SC 27 WG 1 (che gestisce le norme della serie ISO/IEC 27000) e WG 5 (che gestisce le norme relative alla privacy).
Per quanto riguarda il WG 1, sono state discusse le seguenti norme:
Per quanto riguarda il WG 3, confermo che non ne seguo i lavori, ma credo sia utile sapere che è prevista la nuova versione della ISO/IEC 15408 (i Common Criteria) per primavera 2026.
Per quanto riguarda il WG 5, ossia gli standard relativi alla privacy, segnalo quanto segue:
Segnalo questo articolo dal titolo "Intelligenza artificiale, certificazione per gli esperti di etica": https://www.altalex.com/documents/news/2025/03/10/intelligenza-artificiale-certificazione-esperti-etica.
Ho il dubbio che si stia inventando una figura professionale inutile. In compenso, sono sicuro dell'utilità delle riflessioni sulle competenze di chi si occupa di intelligenza artificiale.
È stato pubblicato il D. Lgs. n. 23/2025, che adegua la normativa italiana al Regolamento DORA: https://www.normattiva.it/eli/id/2025/03/11/25G00032/ORIGINAL.
Segnalo l'articolo di Altalex per una (credo) buona sintesi: https://www.altalex.com/documents/2025/03/13/decreto-dora-g-u-autorita-competenti-poteri-vigilanza-sanzioni.
AgID ha pubblicato la "Bozza di linee guida per l’adozione di IA nella pubblica amministrazione" per una consultazione pubblica: https://www.agid.gov.it/it/notizie/intelligenza-artificiale-in-consultazione-le-linee-guida-pa.
Non l'ho letta né la leggerò perché è una bozza per consultazione pubblica, non la versione definitiva. Però in molti la stanno segnalando e non vorrei sembrare non aggiornato. Spero che la stessa solerzia si ripeterà quando sarà pubblicata la versione definitiva (anche se sappiamo che troppo spesso questo non succede).
Il Clusit ha pubblicato il suo "Rapporto sulla cybersecurity in Italia e nel mondo" 2025: https://clusit.it/rapporto-clusit/.
A parte le solite statistiche la cui utilità mi sfugge (lo sappiamo da più di 20 anni che viviamo in una foresta oscura), ho trovato particolarmente interessanti:
Il 11-13 marzo, a Milano, si tiene il Security Summit: https://securitysummit.it/milano-2025.
Io parteciperò il 13 marzo, alle 12.20, insieme a Fabio Guasconi, al seminario UNINFO "Norme tecniche, cosa ci attende nel 2025".
Ricordo che sono anche consigliere DFA, che ha organizzato, sempre il 13 marzo, ma alle 14.20, un intervento dal titolo "AI forensics, una soluzione?" con Maria Elena Iafolla, Mattia Epifani e Valerio Vertua. Loro sono sempre tutti bravissimi e propongono questioni interessanti.
Bel caso di sistema di gestione delle porte di un edificio esposto su Internet e con troppe password di default mai cambiate: https://www.ericdaigle.ca/posts/breaking-into-dozens-of-apartments-in-five-minutes/.
Siamo ancora lì, ad avere password di default non cambiate al primo accesso.
Dalla newsletter Project:IN Avvocati, segnalo che la Banca d'Italia, con una Comunicazione del 23 dicembre 2024, ha messo a disposizione un modello per l'autovalutazione rischi ICT ai sensi del Regolamento DORA: https://www.bancaditalia.it/media/notizia/istruzioni-operative-relative-alle-valutazioni-previste-dalla-comunicazione-al-mercato-in-materia-di-sicurezza-ict/.
Non sono assolutamente un esperto di DORA, ma penso sia utile saperlo.
Segnalo questo sito con alternative europee ai servizi informatici più diffusi e residenti negli USA: https://european-alternatives.eu/.
In questo periodo meglio essere preparati.
Grazie ad Alessandro Vallega di Rexilience per la segnalazione.
Segnalo la pubblicazione di un mio articolo dal titolo "Amministratori di sistema: l’inutile pratica di richiedere nominativi": https://www.agendadigitale.eu/sicurezza/amministratori-di-sistema-linutile-pratica-di-richiedere-nominativi/.
Volevo togliermi un sassolino dalla scarpa.
Oggi vorrei parlarvi dei nonni, croce e delizia degli uomini che possono fare tutto, ma non sempre ce la fanno. Li viziano e non seguono le istruzioni, ma intervengono quando c'è bisogno di loro, anche quando gli acciacchi riducono la loro disponibilità.
Così ringrazio mia mamma che è andata a prendere degli esami medici di un figlio in un periodo in cui noi genitori non potevamo passare a prenderli dalle 9 alle 16.30, mio suocero che è andato a prendere un figlio di ritorno dagli scout mentre io ero con l'altro al calcio, tutti e quattro i nonni che tengono compagnia ai nipoti quando noi siamo impegnati.
Questo mese è andato così. Che è arrivato il momento di dire che anche i nonni possono fare tutto, ma è bene non farglielo fare, visto che tocca a noi adesso fare i genitori. Ed è anche il momento di ringraziarli di cuore.
Il giovedì 27 febbraio terrò un intervento su "NIS2: Normativa applicabile all’IT": https://www.coretech.it/it/service/event/eventDetail.php?ID=1223.
In realtà, si parlerà anche di NIS2, ma non solo. Però l'hanno messo davanti al titolo perché oggi sembra richiamare maggiormente l'attenzione.
Dice 10.30 - 11.30, ma potremmo andare avanti più a lungo, ma non oltre l'ora di pranzo.
Io ho preso questi appunti: L’applicabilità della NIS 2 dipende in larga parte dalla dimensione dell’impresa. La clausola di salvaguardia consente alle imprese di richiedere una deroga al calcolo delle dimensioni aziendali (dipendenti, fatturato e bilancio) tenendo conto del grado di indipendenza dai sistemi informativi e di rete delle imprese collegate. Questo per le organizzazioni che, pur facendo parte di un gruppo, operano in modo indipendente. L’esempio tipico è quello di un’azienda che appartiene a un gruppo, ma non utilizza i sistemi informatici del gruppo (https://www.studiolegaledelliponti.eu/guida-pratica-alla-registrazione-dei-soggetti-nis2-sul-portale-acn/).
Hanno approvato il DPCM 221 del 2024 per specificare meglio le condizioni: https://www.normattiva.it/eli/id/2025/02/10/25G00017/ORIGINAL.
La notizia l'ha data Filippo Bianchini agli Idraulici della privacy. Ma non era lui in ritardo, è il DPCM che è stato pubblicato in GU solo il 10 febbraio 2025.
La Commissione europea ha pubblicato due documenti.
Il primo ha titolo "Guidelines on prohibited artificial intelligence (AI) practices": https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-prohibited-artificial-intelligence-ai-practices-defined-ai-act.
Il secondo ha titolo "Guidelines on AI system definition": https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-ai-system-definition-facilitate-first-ai-acts-rules-application.
Temo che saremo travolti da pubblicazioni anche ponderose (il primo è di 150 pagine, per un Regolamento già molto lungo e complesso; il secondo è almeno di sole 13 pagine). Purtroppo manca una pagina, aggiornata e facile da consultare, sul sito web della Commissione. Per il momento, ho scoperto che si può usare il seguente link (dove 25 è il tipo "Policy and legislation" e il 119 è l'argomento "Artificial intelligence"): https://digital-strategy.ec.europa.eu/en/related-content?type=25&topic=119. La ricerca fornisce anche altri documenti, ancora più specifici.
Ho ricevuto notizie da varie fonti in merito a queste linee guida. Cito Franco Vincenzo Ferrari (via email) e alcuni post su LinkedIn.
Il Ministero degli interni ha emanato il DECRETO 21 gennaio 2025 con titolo "Adozione delle linee guida per la prevenzione degli atti illegali e di situazioni di pericolo per l'ordine e la sicurezza pubblica all'interno e nelle immediate vicinanze degli esercizi pubblici": www.gazzettaufficiale.it/eli/id/2025/01/25/25A00562/sg.
Non l'ho letto, ma ho letto il commento molto polemico di Christian Bernieri: https://garantepiracy.it/blog/kapo/.
Non mi occupo di sicurezza pubblica e non lo farò. Però questo mi sembra un bell'esempio di fuffa-sicurezza, che vedo anche in molte aziende: un codice di condotta che nessuno leggerà, videosorveglianza dappertutto, timbri per riconoscere i visitatori (qui i minori, ma il concetto è lo stesso) ma non per riconoscere gli altri.
Mi hanno segnalato un articolo interessante dal titolo "Allarme negli ospedali, dispositivi medici mandano dati dei pazienti in Cina": https://www.tomshw.it/hardware/allarme-negli-ospedali-dispositivi-medici-mandano-dati-dei-pazienti-in-cina-2025-01-31.
L'avviso originale della CISA è questo: https://www.cisa.gov/resources-tools/resources/contec-cms8000-contains-backdoor.
Mi pare interessante anche il commento di una persona che si occupa di marcatura CE di dispositivi medici: "la cybersecurity è ormai un problema serissimo in questo campo e la nostra analisi ai fini della marcatura CE non avrebbe mai e poi mai trovato questa "cosuccia". Forse facendo dei vulnerability assessment e penetration test durante un uso intenso del dispositivo un buon laboratorio avrebbe potuto vedere qualcosa, ma i cinesi sono stati furbi ad usare la porta tipicamente usata per la trasmissione HL7 in ambito sanitario. Oltre a ciò, i VA-PT sono commissionati dal fabbricante e non dall'organismo che verifica".
Questo mi fa ripensare alla mia denuncia sulla "sicurezza di carta", di cui sono vittime anche le marcature CE: tante check list, tante analisi documentali, mentre forse si potrebbero ridurre in favore di VA-PT più tecnologici.
Segnalo il Provvedimento del 27 novembre 2024 [10095810] del Garante privacy: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/10095810.
La notizia sulla newsletter del Garante ha titolo "Data breach, FSE Molise: le sanzioni del Garante privacy": https://www.gpdp.it/home/docweb/-/docweb-display/docweb/10095854#2.
In due parole: il servizio web di Fascicolo sanitario elettronico della Regione Molise presentava un bug, sfruttato da una persone per visualizzare altre pratiche.
Il Garante ha sanzionato, oltra al titolare Regione Molise e il responsabile Società Molise dati anche Engineering Ingegneria Informatica S.p.A. (che a sua volta era responsabile di un responsabile della Società Molise dati, ossia il sub3-responsabile), che aveva in manutenzione il servizio.
La cosa interessante è che Engineering è stata sanzionata perché "omettendo di mettere in atto misure tecniche [...] come previsto anche dall’atto di nomina a responsabile" e perché "avrebbe dovuto -nell’ambito dei doveri di ordinaria diligenza- adottare misure adeguate, e verificarne l’efficacia con l’esecuzione di opportuni casi di test".
Ecco quindi che il responsabile non deve seguire pedissequamente le istruzioni del titolare, ma farsi carico dei "doveri di ordinaria diligenza".
In tanti stanno divulgando la notizia sulla pubblicazione della bozza delle "Guidelines 01/2025 on Pseudonymisation" di EDPB: https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en.
Sono in bozza e in attesa di commenti che possono essere spediti entro il 28 febbraio 2025.
Io le bozze non le leggo. A mio parere vanno lette solo da chi vuole inviare commenti e solo per quello (abbiamo già visto i danni di chi invece ha lavorato sulle bozze del GDPR e altre bozze e schemi).
Il Consiglio dell'UE ha adottato un nuovo atto legislativo sullo scambio dei dati sanitari e l'accesso a livello dell'UE: https://www.consilium.europa.eu/it/press/press-releases/2025/01/21/european-health-data-space-council-adopts-new-regulation-improving-cross-border-access-to-eu-health-data/.
La notizia l'ho avuta dalla newsletter di Project:IN Avvocati via LinkedIn.
Spero che verrà diffuso il numero del Regolamento quando sarà pubblicato.
Segnalo la mia presentazione "Aggiornamento legislativo 2025" (pdf, 2,2 MB): https://www.cesaregallotti.it/Pdf/Pubblicazioni/2025-Aggiornamento-legislativo-20250126.pdf.
E' una presentazione sulla normativa legale applicabile all'IT, con alcuni riferimenti all'applicabilità alle certificazioni ISO 9001, ISO/IEC 27001 e non solo.
Ho anche aggiornato i miei appunti sulla NIS2 e il suo recepimento italiano: https://www.cesaregallotti.it/Pdf/Pubblicazioni/2024-NIS-2-Appunti%20Cesare-recepimento-ITA.pdf.
Questa volta parlo di orientamento alle superiori. Spesso si investe il sabato mattina nel visitare alcune scuole. Fortunatamente abbiamo limitato il numero e siamo arrivati a una scelta senza troppi sacrifici.
Però abbiamo dovuto integrare questa scelta con un ulteriore incontro un giovedì pomeriggio, fissato il venerdì prima. Ho dovuto spostare 3 appuntamenti, tipo gioco del 15, considerando che alcuni clienti hanno un audit a breve e quindi avevo un'agenda fitta e con pochi spazi di manovra. Ma sono stati tutti molto gentili.
Mia moglie ha ovviamente partecipato, perché se i genitori sono due, anche se possono fare tutto, alcune cose devono farle insieme. Lei aveva preso ferie quel giorno, ma il suo capo aveva una questione urgente ed è venuto a prendersi un aperitivo sui Navigli pur di parlarle. Trovo interessante questo fatto che tutti si sono adeguati a fronte di certe esigenze.
EDPB ha approvato il 17 dicembre il "Parere 28/2024 su alcuni aspetti della protezione dei dati relativi al trattamento dei dati personali nel contesto dei modelli di IA": https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en.
Questo Parere affronta le questioni relative al trattamento dei dati personali durante lo sviluppo e l'implementazione dei modelli di IA.
Segnalo questo articolo molto sintetico: https://www.airia.it/post/la-decisione-edpb-sulla-protezione-dei-dati-personali-nell-ai-generativa.
Ringrazio Christian Bernieri per averlo segnalato agli Idraulici della privacy. Christian trova significativa soprattutto la risposta alla quarta domanda, relativa all'uso di modelli di IA creati, aggiornati o sviluppati utilizzando dati personali trattati illegalmente.
Nella newsletter di dicembre 2024 del Garante, una notizia ha titolo "No a foto di minori di 14 anni sui social senza il consenso di entrambi i genitori. Il Garante ammonisce un padre": https://garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10076607#3.
La sintesi: Per postare sui social network immagini che ritraggono minori di 14 anni è necessario il preventivo consenso di entrambi i genitori. Invece se il minore ha compiuto quattordici anni la normativa italiana gli riconosce la facoltà di decidere autonomamente sulla pubblicazione.
Il Provvedimento del 13 novembre 2024 [10076481]: https://garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10076481.
Il SANS NewsBites Vol. 27 Num. 03 segnala che è stato lanciato il US Cyber Trust Mark Program: https://www.sans.org/newsletters/newsbites/xxvii-3/.
Qualche dettaglio in più è fornito dalla pagina della Casa Bianca: https://www.whitehouse.gov/briefing-room/statements-releases/2025/01/07/white-house-launches-u-s-cyber-trust-mark-providing-american-consumers-an-easy-label-to-see-if-connected-devices-are-cybersecure/.
Se ho capito correttamente, i requisiti tecnici sono riportati molto sinteticamente dal documento "Profile of the IoT Core Baseline for Consumer IoT Products": https://csrc.nist.gov/pubs/ir/8425/final.
Non mi sembra chissà cosa, da quello che ho capito. Ho sempre il timore che tutto si ricondurrà alla "sicurezza di carta", visto che i requisiti tecnici sono pochi e generici, mentre quelli documentali sono tanti e precisi.
Vedremo poi quanto si affermerà questo schema, considerando che anche l’EU sta cercando di elaborarne con il CRA (il Cybersecurity act neanche lo considero, visto quanto è lento).
E' stato pubblicato un mio articolo dal titolo (non mio, perché lo ritengo troppo spavaldo) "Data breach Infocert, ecco gli errori che fanno ancora tutti (o quasi)": https://www.agendadigitale.eu/sicurezza/data-breach-infocert-perche-non-e-solo-un-problema-aziendale/.
Nell'articolo non ho inserito i ringraziamenti a Aldo Colamartino che per primo mi aveva scritto per chiedermi alcune riflessioni sull'evento e a Silvia Canzi per avermi inviato il link a un buon articolo di analisi (https://www.cybersecurity360.it/nuove-minacce/infocert-data-breach-che-e-successo-e-quali-rischi-per-milioni-di-italiani/), per quanto possibile fare finora.
Devo aggiungere, rispetto a quanto pubblicato, che ero rimasto molto sconfortato dagli interventi di alcuni esperti di sicurezza, anche molto competenti, perché avevano postato commenti generici, superficiali, spesso supponenti e, quindi, inutili. Probabilmente le persone non competenti sono state favorevolmente colpite da questi commenti e dai giudizi spietati, ma altri vedono il vuoto di chi o non sa come funziona la sicurezza o fa finta di ignorarlo pur di dire qualcosa.
Troppi commenti, preferendo puntare su lamentazioni generiche, sembravano scritti da persone ignare dei problemi delle aziende e dei gruppi di aziende, tra cui: limiti di budget, scarsa consapevolezza del top management, carenza di risorse, carenza di competenze, complessità dei gruppi di aziende e dei rapporti tra i loro componenti, confusione per i troppi riferimenti normativi e tecnici.
Basterebbe essere stati
coinvolti in una delle tante questioni relative alla sicurezza che
pongono le aziende e aver partecipato ad almeno una riunione per cercare
una soluzione a una qualsiasi di queste questioni per capire che nulla è
tanto semplice. E forse per avere un po' più di compassione nei
confronti di chi subisce un incidente (anche se è tanto grande).
Dispiace vedere che anche persone competenti non riescono a fermarsi dal commentare qualsiasi cosa, anche senza avere niente da dire. Dispiace vedere che un incidente di sicurezza diventi il centro di un circo e non un momento di vera riflessione.
Mi si scusi per questo sfogo. Spero che però le riflessioni più tecniche pubblicate da Agenda Digitale possano essere di interesse.
La Polizia postale pubblica annualmente un rapporto annuale sulle sue attività "per la sicurezza cibernetica": https://www.poliziadistato.it/articolo/i-dati-delle-attivita-della-postale-nel-2024 (grazie a Chiara Ponti per la segnalazione).
Purtroppo mancano dettagli sugli attacchi: così dà un quadro troppo generale.
Come cittadino, sono comunque preoccupato dai dati sui reati contro la persona e in particolare i minorenni.
La CNIL (ossia il Garante privacy francese) ha pubblicato la bozza di uno schema di certificazione per responsabili di trattamenti: https://www.cnil.fr/fr/certification-rgpd-des-sous-traitants-la-cnil-consulte-sur-un-projet-de-referentiel-devaluation.
Grazie alla newsletter di Project:IN Avvocati per aver diffuso questa notizia.
La pagina è solo in francese e la bozza è aperta alle consultazioni.
La CNIL usa il termine "sous-traitant" per i fornitori con ruolo di responsabile di trattamenti e il termine "responsable" per quello che in italiano indichiamo come "titolare".
Non si capisce ancora come funzionerà lo schema, visto che la pagina relativa agli organismi di certificazione non è aggiornata (non solo relativamente a questo schema, ma anche per quello Europrivacy; Europrise neanche lo cita).
Tecnicamente, credo che sia una bella proposta: uno schema orientato alle PMI, meno complesso di quelli già attivi.
Per il resto, mi sembra sempre che sia troppo orientato alla documentazione. Troppi requisiti richiedono di documentare, non di fare. Mi rendo conto che il documentare e il regolare poi dovrebbe portare al fare, ma sempre più mi rendo conto che in tutti gli standard e le linee guide troppi requisiti riguardano il solo documentare e questo inevitabilmente porta a un'interpretazione "cartacea" della sicurezza, come è evidente dai risultati degli audit e dagli investimenti in documentazione (e persone che scrivono), a scapito della sicurezza operativa.
Franco Vincenzo Ferrari mi ha segnalato questo articolo dal titolo "Con l’European accessibility act (EAA) l’accessibilità digitale dei prodotti e dei servizi diventa comune per tutti gli Stati UE": https://www.associazionecittadinanzadigitale.org/2024/12/28/con-leuropean-accessibility-act-eaa-laccessibilita-digitale-dei-prodotti-e-dei-servizi-diventa-comune-per-tutti-gli-stati-ue/.
Della Direttiva UE 882 del 2019 e del suo recepimento con il D. Lgs. 82 del 2022 avevo già scritto (https://blog.cesaregallotti.it/2024/04/european-accessibility-act-d-lgs-82-del.html), ma questo articolo ci ricorda la scadenza del 28 giugno e richiama meglio alcune cose.
E' stato pubblicato su Agenda Digitale un mio articolo dal titolo "Cyber resilience act, la sicurezza diventa obbligatoria: cosa cambia per le aziende": https://www.agendadigitale.eu/sicurezza/cyber-resilience-act-la-sicurezza-diventa-obbligatoria-cosa-cambia-per-le-aziende/.
Si tratta quasi di un insieme di appunti, ma può essere un punto di partenza. Come sempre: se vedete errori, segnalatemeli.
Piccolo sfogo pre-natalizio: ancora molti miei clienti, in qualità di responsabili di trattamenti di dati personali, ricevono richiesta dei nominativi degli amministratori di sistema.
Questo è un simpatico caso di non-aggiornamento, ormai dal 2009. A fine del 2008, tutti a correre per adeguarsi al Provvedimento del 27 novembre 2008 [doc. web n. 1577499], ma pochissimi a chiedersi perché il Provvedimento fu modificato il 25 giugno 2009 (a parte chiedere proroghe).
Io fui fortunato perché assistei al dibattito. Però sono sorpreso nel vedere che tanti ancora oggi, dopo più di 15 anni, non abbiano recepito la modifica. Temo che troppi corsi di formazione non siano abbastanza aggiornati e così vengono formate persone in modo scorretto.
E allora ripassiamo. La modifica del Provvedimento riguardava, oltre all'eliminazione di un riferimento obsoleto al DPS e a un chiarimento sul fatto che il mantenimento dei nominativi degli AdS sia da prevedere contrattualmente, all'aggiunta di due "o il responsabile", in modo che gli adempimenti in merito al mantenimento dei nominativi degli AdS non siano necessariamente in carico al titolare.
Uno dei motivi è evitare che vengano diffusi i nominativi di persone che potrebbero essere bersaglio di attacco. Pertanto i responsabili dovrebbero rigettare tali richieste per assicurare la sicurezza dei loro clienti.
Purtroppo il Provvedimento lascia ancora margini di ambiguità e questo dimostra come sia stato concepito e scritto male e, ahinoi, quanto è sbagliato il mantenerlo in vita.
Ultima nota polemica: voglio vedere quanti hanno chiesto i nominativi degli AdS agli OTT (Amazon, Google, eccetera) e li hanno cambiati perché non li hanno ricevuti.
La Cybersecurity and Infrastructure Security Agency statunitense ha pubblicato la Mobile Communications Best Practice Guidance: https://www.cisa.gov/resources-tools/resources/mobile-communications-best-practice-guidance.
Si tratta di una guida molto tecnica, anche se molto breve. Alcune cose dovrò studiarle meglio.
Qualche giorno fa avevo scritto un commento su LinkedIn, rispondendo a un post, più pertinente la sicurezza informatica e in generale la digitalizzazione, di Antonio Ieranò.
Dicevo che la scuola che esce dalle mie competenze professionali, ma rientra in quelle di genitore e mi lamentavo di alcune cose che riporto qui di seguito:
Questo fa sì che i professori diventano ansiosi perché hanno tanta roba da fare, con il risultato che anche i ragazzi vanno in ansia. Oltre a ciò, i professori non sono attrezzati a tenere calma una classe. Oltre a correre, danno note, votacci e verifiche a sorpresa, ma ciò non fa che accrescere il disagio, per ovvi motivi, mentre per ridurre i problemi bisogna assicurare ritmo tranquillo e prevedibilità.
Ed ecco che i ragazzi con qualche problema a monte, fanno ancora più fatica a studiare e imparare.
Non so perché, ma trovo che, quando parlo con gli altri genitori di queste cose, il gruppo è più numeroso di mamme che di papà, soprattutto quando il caso personale rientra tra i "fragili". Peccato, perché mi accorgo sempre più quanto sia importante l'interessamento di ambedue i genitori.
Il Garante per la privacy ha approvato il codice di condotta per il trattamento dei dati personali effettuato dalle imprese di sviluppo e produzione di software gestionale e l'accreditamento dell'organismo di monitoraggio: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/10075998.
In sintesi e imprecisamente: il codice di condotta può essere applicato da chiunque e chi lo applica può chiedere una sorta di certificazione all'organismo di monitoraggio, in questo caso Assosoftware.
Il mio commento è che sarà opportuno, per gli sviluppatori in generale, verificare l'applicazione dei requisiti funzionali e tecnici negli allegati A e B e adottare il modello di DPA in Allegato C.
Purtroppo questo codice arriva dopo 8 anni di fatica a selezionare i requisiti funzionali per i miei clienti e a produrre modelli di DPA. Fosse arrivato prima mi avrebbe risparmiato molta fatica!
Senza togliere niente agli articolisti, suggerisco di leggerlo nella sua versione ufficiale, visto che è di facile lettura.
Ringrazio Chiara Ponti che l’ha segnalato agli Idraulici della privacy.
Segnalo la pubblicazione "Generative Artificial Intelligence: punti di forza, rischi e contromisure": https://www.ictsecuritymagazine.com/pubblicazioni/.
Autore è Vincenzo Calabrò. Si tratta di una pubblicazione di 110 pagine molto tecnica e molto interessante.
ACN ha pubblicato le "Linee guida per il rafforzamento della protezione delle banche dati rispetto al rischio di utilizzo improprio": https://www.acn.gov.it/portale/w/online-le-linee-guida-per-il-rafforzamento-della-protezione-delle-banche-dati-rispetto-al-rischio-di-utilizzo-improprio-.
Grazie a Project:IN Avvocati per la segnalazione.
Che dire? Sono scritte in modo confuso perché le 6 voci di sicurezza sono suddivisa in due paragrafi di testo libero e di "Raccomandazioni di contesto" tra loro incoerenti come linguaggio, livello di spiegazione per principianti o esperti, misure e livello di sicurezza richiesto. Così si crea confusione, non si aiuta.
Poi io temo sempre la loro interpretazione quando si tratta di PMI.
E' stato pubblicato questo articolo dal titolo "Rischi da violazione dei dati personali: guida pratica e normativa": https://www.agendadigitale.eu/sicurezza/privacy/rischi-da-violazione-dei-dati-personali-guida-pratica-e-normativa/.
E' a firma mia e di Chiara Ponti che ringrazio per avermi coinvolto nella riflessione che è soprattutto su come calcolare i rischi di sicurezza delle informazioni e privacy.
ACN ha pubblicato le "Linee guida per il rafforzamento della resilienza dei soggetti di cui all’articolo 1, comma 1, della Legge 28 giugno 2024, n. 90": https://www.acn.gov.it/portale/linee-guida-rafforzamento-resilienza.
Ringrazio Franco Vincenzo Ferrari per la segnalazione e il link.
Della Legge 90 del 2024 avevo già scritto qui: http://blog.cesaregallotti.it/2024/07/legge-90-del-2024-sulla-cybersicurezza_18.html.
La Legge 90 chiede ad ACN di pubblicare tali linee guida nell'articolo 8, comma 1, punto f.
Parto con la critica e la faccio in linea con quanto già espresso in precedenza: con il PNSC e questa Legge 90 (per non parlare della Circolare AgID 2/2007 con le misure minime di sicurezza ICT per le PA, che mi risulta essere ancora valida) penso si faccia più confusione che altro, visto che gli incroci con la NIS2 sono ignorati nella migliore delle ipotesi o non gestiti la meglio. Queste linee guida rientrano nello stesso meccanismo: propongono 26 misure basate sul NIST CSF, né collegate alle misure minime di AgID, né ovviamente a quelle NIS2 (che richiamano di più la ISO/IEC 27001). Inoltre, queste misure sono presentate 4 volte (prima come lista, poi con dettagli in 2 o 3 pagine, poi nella Parte II con le linee guida per l'implementazione sempre di 2 o 3 pagine, infine in Appendice A dove sono indicate le "implementazioni minime attese").
Come consulente di sicurezza delle informazioni sono contento: ci sarà sempre più lavoro per la mia categoria. Ma come cittadino non posso che disapprovare questo accumularsi di norme tra loro non allineate.
Poi, mi è facile ammettere che la lettura è comunque interessante per chi vuole interessarsi alla sicurezza informatica, ma per quello si poteva fare un testo più lineare (sembra il libro di Inglese delle medie di uno dei miei figli, dove gli esercizi di ciascuna Unit sono in 3 posti diversi senza alcun motivo apparente se non quello di far girare pagine e consumarle).
Claudio Sartor, che ringrazio, mi ha segnalato questa interessante puntata del podcast di Paolo Attivissimo (con trascrizione): https://attivissimo.me/2024/11/18/podcast-rsi-un-attacco-informatico-che-arriva-su-carta/.
Il titolo è "Podcast RSI – Un attacco informatico che arriva… su carta?" e presenta il caso di una lettera (falsa) di un'autorità svizzera che richiede ai destinatari di installare un certo software (con malware) sui loro smartphone.
Pubblicato il Regolamento UE 2024/2847, detto cyber resilience act (CRA): https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2847. Ringrazio Chiara Ponti degli Idraulici della privacy per la segnalazione.
In merito avevo letto un breve articolo (la seconda parte): https://www.altalex.com/documents/news/2024/10/28/sistema-ai-provoca-danno-scatta-risarcimento-utente-danneggiato.
In sostanza, il Regolamento mira a garantire "che i prodotti con componenti digitali, ad esempio i prodotti dell'internet delle cose, siano resi sicuri lungo l'intera catena di approvvigionamento e per tutto il ciclo di vita".
Nei considerando, il Regolamento specifica che altre normative, come il Cyber security act e la NIS2, "non contemplano direttamente requisiti obbligatori per la sicurezza dei prodotti con elementi digitali".
Innanzi tutto, segnalo che "Il presente regolamento si applica dall’11 dicembre 2027". L'obbligo di segnalare incidenti che hanno sfruttato vulnerabilità dei propri prodotti scatta invece l'11 giugno 2026.
Di seguito i miei appunti di lettura. Vi prego di segnalarmi errori, dimenticanze, imprecisioni e, in breve, qualsiasi possibile miglioramento.
Distingue tra prodotti con elementi digitali "normali", importanti e critici.
Per i prodotti normali:
Per i prodotti importanti:
Per i prodotti critici:
Ulteriori misure saranno dettagliate in norme armonizzate (probabilmente della ETSI) o in atti di esecuzione della Commissione (art. 27). Bisognerà monitorare con attenzione la pubblicazione di tali norme e atti.
In generale, i fabbricanti devono condurre valutazioni del rischio relativo alla cibersicurezza dei prodotti, identificare e applicare i controlli di sicurezza tecnici e di processo (incluse le attività di manutenzione, assistenza e gestione vulnerabilità). L'assistenza deve essere garantita per almeno 5 anni (art. 13).
Sono quindi fornite indicazioni ulteriori sulla documentazione tecnica (art. 13 e 31, Allegato VII), sul tracciamento dei prodotti (art. 13), sulle informazioni e istruzioni per gli utilizzatori (Allegato II), sui punti di contatto (art. 13), sul ritiro o richiao dei prodotti (art. 13), sul come redigere la dichiarazione di conformità UE (art. 28 e Allegato V), sulla marcatura CE (art. 29 e 30)
L'articolo 14, come in altre normative, richiede ai fabbricanti di notificare al CSIRT gli incidenti determinati dallo sfruttamento di vulnerabilità dei prodotti. L'articolo 15 prevede che fabbricanti e persone possano segnalare vulnerabilità al CSIRT (elemento sicuramente molto interessante).
Gli articoli 24 e 25 sono relativi ai software liberi e open source. C'è anche un richiamo per la certificazione di tali software all'articolo 32.
Ci sono riferimenti alle normative relative alla sicurezza generale dei prodotti (va applicato sia il CRA sia il Regolamento 2023/988), ai sistemi di IA ad alto rischio.
Relativamente alla certificazione (articoli 35-51), deve essere istituita l'autorità di notifica (in Italia sarà probabilmente Accredia, ma non deve esserlo necessariamente), che a sua volta deve approvare gli organismi di notifica (ancora una volta, penso che molti saranno gli organismi di certificazione già presenti sul mercato per la ISO 9001, la ISO/IEC 27001 eccetera).
Interessante osservare che (art. 32): "Si dovrebbe tener conto degli interessi e delle esigenze specifici delle microimprese e delle piccole e medie imprese, comprese le start-up, nel definire le tariffe per le procedure di valutazione della conformità e tali tariffe sono ridotte proporzionalmente agli interessi e alle esigenze specifici di tali imprese".
Il regolamento prevede quindi la possibilità per la Commissione di modificare alcuni punti tra quelli sopra riportati. E' quindi necessario attivare canali di aggiornamento, anche se al momento non ne vedo di affidabili (ENISA non prevede newsletter, ma aggiornamenti solo via social network, che, con tutti i problemi noti, andrebbero sconsigliati; sottoscrivere agli RSS è molto macchinoso, ma almeno ci sono).
Altro riferimento da tenere monitorato è il gruppo di cooperazione amministrativa (ADCO), ma al momento non mi sembra che abbia prodotto cose significative. Vedere la pagina: https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/organisation/adcos_en.
L'articolo 33 prevede "misure di sostegno per le microimprese e le piccole e medie imprese", che includono attività di formazione e di comunicazione. Immagino ne possano beneficiare anche le grandi.
Gli articoli 52-60 trattano delle attività di vigilanza, non di mio interesse, così come gli articoli finali, con l'eccezione delle scadenze riportate all'inizio.
E' stata pubblicata la Direttiva UE 2024/2853 da titolo "Sulla responsabilità per danno da prodotti difettosi": https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX%3A32024L2853&qid=1731949049419.
Intanto ricordo che si tratta di una Direttiva che dovrà essere adottata in Italia entro il 9 dicembre 2026, quindi c'è tempo (se non sbaglio).
Avevo letto questo articolo in merito e quindi rimando ad esso: https://www.altalex.com/documents/news/2024/10/28/sistema-ai-provoca-danno-scatta-risarcimento-utente-danneggiato.
Ho aspettato finora a darne notizia perché il testo non era ancora disponibile. Ringrazio un post su LinkedIn di Andrea Michinelli per l'aggiornamento.
Avevo dato in precedenza informazione sul fatto che la registrazione sulla piattaforma ACN dei soggetti in ambito doveva essere fatta entro il 17 gennaio.
La data l'avevo calcolata io e credo di aver trovato conferma anche altrove. Comunque: il sito ACN indica come data ultima per la registrazione il 28 febbraio.
Faccio riferimento alle FAQ di ACN e a un post su LinkedIn (ringrazio Fabrizio Cirilli per averlo diffuso anche alla sua rete): https://www.linkedin.com/posts/agenzia-per-la-cybersicurezza-nazionale_nis2-acn-activity-7258070188019879936-dekB.
Ho aggiornato i miei post scorretti.
Chiara Ponti degli Idraulici della privacy ha segnalato la sentenza 40295 24 della Cassazione Penale del 31.10.2024 che ha configurato l’ipotesi di “Accesso abusivo ai sistemi informatici aziendali, anche per i superiori gerarchici”.
Cosa dice Chiara: "chiarisce come anche un superiore gerarchico possa commettere il reato di accesso abusivo (art. 615-ter cp) qualora acceda a un sistema informatico aziendale protetto, senza autorizzazione (del dipendente), anche con le credenziali fornite dal collaboratore".
Chiara riporta anche: "'Per la Corte, la protezione del sistema tramite credenziali di accesso dimostra già la volontà dell'azienda di riservare l'accesso solo a determinate persone' Quindi ogni utente autorizzato deve usare solo le proprie credenziali personali per accedere ai dati, lasciando così traccia digitale del proprio accesso. Le mansioni superiori non conferiscono automaticamente l'autorizzazione ad accedere ai dati riservati, salvo diversa disposizione esplicita del datore di lavoro”.
La sentenza l'ho trovata qui: https://www.wikilabour.it/segnalazioni/rapporto-di-lavoro/laccesso-a-un-sistema-informatico-protetto-e-abusivo-anche-se-il-dipendente-usa-la-chiave-richiesta-a-un-sottoposto/.
Chiara Ponti ha segnalato agli Idraulici della privacy la pubblicazione da parte di ENISA del documento "Implementation guidance on NIS 2 security measures - Draft for Consultation": https://www.enisa.europa.eu/publications/implementation-guidance-on-nis-2-security-measures.
La ringrazio.
Attenzione che il documento riguarda il Regolamento di esecuzione (Implementing regulation) 2024/2690, quindi è applicabile solo a: fornitori di servizi DNS, i registri dei nomi di dominio di primo livello, i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i fornitori di mercati online, di motori di ricerca online e di piattaforme di servizi di social network e i prestatori di servizi fiduciari.
Attenzione ancora che si tratta di una bozza per consultazione pubblica.
Ad ogni modo, la lettura può essere utile perché per ogni punto del Regolamento di esecuzione approfondisce le misure richieste e fornisce una sorta di lista di controllo per verificarne l'applicazione. Come tutte le liste di controllo, però, va presa con cautela (per esempio, prevede che il riesame delle politiche sia svolto durante i riesami di direzione, ma potrebbe avvenire anche in altri momenti).
Ulteriormente utili sono le tabelle di correlazione dei punti del Regolamento di esecuzione con ISO/IEC 27001:2022, NIST CFS 2.0, ETSI EN 319 401 (utile per i prestatori di servizi fiduciari) e CEN/TS 18026:2024. Sono anche riportati i riferimenti a norme nazionali belghe, finlandesi, greche e spagnole.
L’Ufficio federale della cibersicurezza (UFCS) svizzero pubblica un rapporto semestrale sempre molto interessante. Ora hanno pubblicato quello relativo alla situazione registrata nel primo semestre 2024: https://www.ncsc.admin.ch/ncsc/it/home/dokumentation/berichte/lageberichte/halbjahresbericht-2024-1.html.
Raccomando, per i più frettolosi, la lettura della sintesi sulla pagina web. Il rapporto principale, in pdf, come sempre, accompagna le analisi degli eventi con raccomandazioni sempre molto utili.
L'attenzione principale è rivolta alle truffe e infatti è dedicato un rapporto dedicato, disponibile sempre alla stessa pagina, però solo in francese e tedesco. A mio parere, chi avesse la capacità di leggerlo potrebbe riutilizzarne gli esempi del capitolo 4 per campagne di sensibilizzazione.
Confermo che, per fare sicurezza, non dobbiamo rincorrere l'ultima notizia. Ma questa volta ci arrivo decisamente tardi, visto che segnalo la pubblicazione della ISO/IEC 29134:2023 Information technology — Security techniques — Guidelines for privacy impact assessment, avvenuta a maggio 2023: https://www.iso.org/standard/86012.html.
Rispetto alla versione del 2017 i cambiamenti sono solo di tipo editoriale, ossia correzione di refusi. Infatti ricordo che ero molto deluso del risultato e forse è per questo che non l'avevo annunciata a suo tempo.
Sappiamo essere notizia il fenomeno dei dossieraggi.
Evito di entrare troppo nel merito e raccomando la lettura dell'analisi di Guerre di rete, visto che è difficile fare di meglio: https://guerredirete.substack.com/p/guerre-di-rete-se-le-banche-dati.
Io e Chiara Ponti abbiamo scritto un articolo per riflettere sulle misure di sicurezza: https://www.cybersecurity360.it/cultura-cyber/dossieraggio-bene-la-task-force-del-garante-privacy-per-vederci-chiaro-in-quanto-successo/.
Come sempre, se qualcuno dovesse avere idee diverse, mi piacerebbe discuterne.
Su questo argomento avevo scritto in precedenza. L'ultimo post è qui: https://blog.cesaregallotti.it/2024/06/garante-privacy-e-conservazione-email-e.html.
Speravo di leggere più articoli e interpretazioni in merito, invece niente (come spesso succede, trovo tante cose che commentano nell'immediato o nel futuro e troppo poche che ragionano anche con un pelo di ritardo; però ho già scritto sul fatto che chi si occupa di sicurezza non debba ricercare la novità e non voglio tediare oltre).
Segnalo l'approccio di un fornitore di email. Per evitare problemi, evito di dare il nome, ma si tratta di un soggetto piuttosto grande.
Questo fornitore dice che tratta i log delle email come titolare. Questo quindi toglie al cliente la titolarità di questi log e non l'obbliga più alla cancellazione.
Questo prevede quindi che il cliente non abbia accesso ai log, nemmeno su richiesta, soprattutto se oltre ai 21 giorni, visto che l'obiettivo del Provvedimento del Garante è evitare l'accesso del datore di lavoro ai dati dei lavoratori.
Le Condizioni contrattuali del fornitore devono riportare qualcosa come: “i dati di cui parla il Provvedimento sono log di comunicazione elettronica; essi non sono oggetto di fornitura di servizio, ma sono trattati dal fornitore in qualità di titolare del trattamento, per sue finalità non rientranti nella disciplina del diritto del lavoro (p.e. controllo prestazioni, sicurezza informatica)”.
Lo stesso fornitore di email dovrebbe quindi mettere a disposizione, per esempio sul sito web, un'informativa per gli utilizzatori dell’email dei clienti (segnalo che l'informativa pubblica del fornitore di cui parlo non mi sembra chiara su questo punto).
A sua volta, il datore di lavoro dovrebbe integrare l'informativa privacy al lavoratore indicando che l'uso dell'email implica il trattamento dei dati da parte di altro titolare. Potrebbe anche riportare il link dell'informativa del fornitore, se disponibile.
Rimarrebbe aperto il caso delle caselle email del personale del fornitore stesso. Per questo, al momento, non ho risposte.
Ferruccio Militello ha segnalato agli Idraulici della privacy il Provvedimento del Garante privacy del 17 luglio 2024 [doc. web 10053224]: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/10053224.
Il titolo dice già tutto. Segnalo però questo articolo (grazie a Franco Vincenzo Ferrari): https://www.cybersecurity360.it/news/il-backup-delle-e-mail-dopo-la-cessazione-del-rapporto-di-lavoro-viola-il-gdpr-la-sanzione/.
Provo a sintetizzare quanto ho capito:
Il Ministero della difesa statunitense (DoD) ha aggiornato il proprio Cybersecurity Maturity Model Certification (CMMC) Program per la qualifica dei suoi fornitori. Dettagli si trovano sulla pagina: https://dodcio.defense.gov/CMMC/Documentation/.
Non sono riuscito a capire bene il funzionamento, ma ho capito che me lo devo ricordare per la prossima volta che mi lamento della complessità nostrana.
Segnalo che è stata pubblicata la ISO/IEC 27019:2024 "Information security controls for the energy utility industry": https://www.iso.org/standard/85056.html.
Riporta, come la ISO/IEC 27017 e la ISO/IEC 27018, controlli di sicurezza aggiuntivi rispetto a quelli già presenti nella ISO/IEC 27001 e linee guida per la loro implementazione aggiuntive rispetto a quelle già presenti nella ISO/IEC 27002. Non mi risulta ci siano cambiamenti significativi se non quelli necessari per allineare la versione del 2017 ai controlli delle ISO/IEC 27001 e ISO/IEC 27002 del 2022.
Avevo appena segnalato l'aggiornamento al Piracy Shield, di cui avevo perso anche la prima versione, dicendo che non era materia mia ma che andava comunque conosciuta, che ecco che un bell'incidente di sicurezza delle informazioni mi smentisce: https://www.linkedin.com/comm/pulse/piracyshield-e-lincidente-google-la-caduta-degli-innocenti-ieranò-i36vf.
In poche parole: il sistema di AGCOM per bloccare (automaticamente e senza intervento umano) i contenuti illeciti ha bloccato anche i contenuti leciti e in particolare Google Drive.
Non commento perché già altri lo stanno facendo con ben superiore competenza (e ironia) della mia.
Come previsto dalla NIS2, la Commissione ha pubblicato il Regolamento di esecuzione (UE) 2024/2690 della Commissione che stabilisce "i requisiti tecnici e metodologici delle misure di cui al paragrafo 2 per quanto riguarda i fornitori di servizi DNS, i registri dei nomi di dominio di primo livello, i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i fornitori di mercati online, di motori di ricerca online e di piattaforme di servizi di social network, nonché i prestatori di servizi fiduciari": https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2690.
Grazie a Franco Ferrari e Alessandro Cosenza che per primi me l'hanno segnalato e a Chiara Ponti per i riferimenti precisi.
Ho però il sospetto che sia stata consultata molto anche la CEN/TS 18026:2024 "Three-level approach for a set of cybersecurity requirements for cloud services" a cui però non ho accesso.
Laura Zarrillo mi ha segnalato la pubblicazione della ISO/TS 22360:2024 "Security and resilience — Crisis management — Concepts, principles and framework": https://www.iso.org/standard/50266.html.
Il testo mi è sembrato pieno di idee interessanti, ma confuso (per esempio, c'è un elenco di possibili eventi naturali, ma non di altra origine) e proponga più analisi di possibili soluzioni.
Va detto che ho letto la bozza quasi-finale, quindi qualche cambiamento ci sarà, ma non strutturale.
Laura Zarrillo mi ha segnalato la pubblicazione della ISO 22336:2024 "Security and resilience — Organizational resilience — Guidelines for resilience policy and strategy": https://www.iso.org/standard/50073.html.
La parte più interessante mi sembra quella relativa ai comportamenti di un'organizzazione (inclusiva, integrata, riflessiva, preparata, robusta, innovativa). Sembrano, e forse sono, cose ovvie e irriealizzabili, però vale la pena rifletterci.
Sandro Sanna mi ha segnalato la notizia del bancario che spiava i conti correnti di numerose persone. Ho trovato un articolo in merito: https://www.lagazzettadelmezzogiorno.it/news/italia/1559851/conti-spiati-l-indagine-su-intesa-sanpaolo-l-ipotesi-non-ha-fatto-tutto-il-possibile-per-evitare-gli-abusi-rischia-richieste-di-risarcimento.html.
Ci sono indagini in corso e io non ho elementi per dire se Intesa Sanpaolo ha attuato tutte le misure possibili. Sandro però mi ha segnalato il comunicato stampa della banca: https://group.intesasanpaolo.com/it/newsroom/comunicati-stampa/2024/10/comunicato-stampa-13-ottobre-2024.
La cosa interessante è che dice “non c'è stato alcun problema di sicurezza informatica”, dimostrando così che spesso il termine “problema di sicurezza informatica” è usato per attacchi di malintenzionati e non anche eventi come questo o disservizi. E’ bene sapere però che, per gli standard, si tratta sicuramente di un incidente di sicurezza delle informazioni.
ACN ha pubblicato le FAQ sulla NIS2: https://www.acn.gov.it/portale/faq/nis.
Ringrazio per questo Severiano Maria Moiso che l'ha segnalato rispondendo a un mio post su LinkedIn.
In particolare, segnala la domanda 1.6 "Come faccio a sapere se sono una grande, media o piccola impresa" che riporta indicazioni utili.
Segnalo anche la domanda 1.12 "Dopo essermi registrato sulla piattaforma di ACN sarò un soggetto NIS?". La risposta è no perché prima bisogna ricevere conferma da ACN.
Non mi ero accorto del "Piracy shield" (da non confondere con il “privacy shield”!) anche perché non rientra nelle mie competenze. Una segnalazione di Alessandro Davanzo di CoreTech mi ha fatto però capire che è necessario sapere almeno di cosa si tratta.
Il “piracy shield” è la Legge 93 del 2023 e ha l’obiettivo di tutelare il “diritto d'autore mediante le reti di comunicazione elettronica”, in sostanza vuole bloccare la diffusione di materiale coperto da diritto d’autore online (video, musica, eccetera) e di piattaforme di streaming illegale (calcio soprattutto). Impone quindi regole per il blocco di contenuti da parte dei “prestatori di servizi di accesso alla rete”.
A ottobre 2024, il DL 113 del 2024 (che riguarderebbe questioni fiscali!), convertito e modificato dalla Legge 143 del 2024, all’articolo 6-bis, modifica la Legge 93 e quindi la estende, oltre ai prestatori di servizi di accesso alla rete, ai “fornitori di servizi di VPN e quelli di DNS pubblicamente disponibili ovunque residenti e ovunque localizzati" e cambia un po’ le regole per bloccare e sbloccare i siti.
Sempre il DL 113 modificato eccetera modifica anche la Legge 633 del 1941 (quella sul diritto d’autore) e le aggiunge un aticolo 174-sexies che:
Non faccio commenti, ma capisco che queste disposizioni sono criticate nella forma e nella sostanza. Segnalo quindi un articolo un po’ più lungo (https://www.wired.it/article/piracy-shield-nuovo-emendamenti-carcere-agcom-white-list/) e uno un po’ più corto (https://www.tomshw.it/hardware/la-nuova-legge-anti-pirateria-italiana-mina-la-liberta-di-internet-2024-10-12).
Per chi vuole leggersi le normative, ecco i link:
Il Consiglio dell'Unione europea ha adottato "un nuovo regolamento sui requisiti di cibersicurezza per i prodotti con elementi digitali al fine di garantire che prodotti quali fotocamere domestiche connesse, frigoriferi, televisori e giocattoli siano sicuri prima della loro immissione sul mercato (regolamento sulla ciberresilienza)": https://www.consilium.europa.eu/it/press/press-releases/2024/10/10/cyber-resilience-act-council-adopts-new-law-on-security-requirements-for-digital-products/.
Dovremo aspettare la pubblicazione in Gazzetta ufficiale dell'Unione europea per studiarlo bene. Con la pubblicazione scatteranno i 3 anni per la sua implementazione. Credo però che dovremo anche capire bene se e quali norme tecniche saranno disponibili.
Ringrazio la newsletter di Project:IN Avvocati, dove ho trovato la notizia.
Chiara Ponti degli Idraulici della privacy ha segnalato la pubblicazione delle "Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR": https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2024/guidelines-12024-processing-personal-data-based_en.
Non l'ho ancora studiata, ma ero convinto che una pubblicazione così ci fosse già, invece questa è la versione 1.0. Nel 2018 avevo segnalato un'altra pubblicazione simile, ma di ben altro valore rispetto a questa.
Solo una nota a margine: la prossima volta che mi dicono che in Italia le leggi sono scritte in modo incomprensibile, segnalerò il titolo di questa pubblicazione, che non aiuta affatto a capire di cosa si tratta (mentre nelle News, gentilmente, EDPB le segnala come "Guidelines on the processing of personal data based on legitimate interest").
Giovanni Ciano degli Idraulici della privacy ha segnalato a noi idraulici la pubblicazione del D. Lgs. 144 del 2024, decreto di adeguamento Data Governance Act (Regolamento europeo 868 del 2022): https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2024-10-07;144!vig=2024-10-13.
Sul DGA avevo scritto al tempo, confessando la mia ignoranza: https://blog.cesaregallotti.it/2022/10/data-governance-act-dga.html. La mia competenza in merito non è aumentata e rimane sempre intorno allo zero.
Giovanni Ciano segnala, come elemento significativo del D. Lgs. 144: "AgID designata autorità competente".
Sempre tenendo conto della mia ignoranza, non mi sembra che ci sia molto altro.
Claudio Sartor mi ha segnalato il podcast di Paolo Attivissimo del 11 ottobre 2024 dal titolo "Password, Microsoft e NIST dicono che cambiarle periodicamente è sbagliato": https://attivissimo.me/2024/10/11/podcast-rsi-password-microsoft-e-nist-dicono-che-cambiarle-periodicamente-e-sbagliato/.
Avevo visto anche un articolo in merito su Agenda Digitale (https://www.agendadigitale.eu/sicurezza/password-stiamo-sbagliando-quasi-tutto-ecco-perche/).
Però: questa non è una notizia. Le pubblicazioni del NIST già nel 2017 dicevano che cambiare le password periodicamente non è corretto (https://blog.cesaregallotti.it/2017/08/del-nist-e-della-lunghezza-e.html) e su Microsoft la notizia è almeno del 2019 (https://blog.cesaregallotti.it/2019/04/microsoft-e-il-cambio-delle-password.html). Per completezza, Attivissimo segnala l'iniziativa di Microsoft del 2019.
Sulla questione, poi, a febbraio avevo pubblicato un post per segnalare posizioni contrastanti: https://blog.cesaregallotti.it/2024/02/sul-cambio-delle-password.html (con Stefano Ramacciotti, se non ricordo male, ci avevamo anche scritto un articolo pubblicato non ricordo più dove).
Perché questa dissertazione? Per dire quanto sono bravo? Un po', ma soprattutto perché mi stupisce moltissimo di arrivare anni (!) prima di persone preparatissime come Paolo Attivissimo e Danilo Bruschi. O forse si sono solo dimenticati di dire che queste regole sono state recentemente confermate? O forse è il risultato di un taglio editoriale un po' troppo esteso?
Però il mio pensiero è ancora diverso: si parla tanto di innovazione, di come sarà la sicurezza tra 10 o 15 anni, di quali strategie prendere, ma penso che chi si occupa di sicurezza non ha il compito di innovare, ma di inseguire chi vuole innovare. Noi al massimo possiamo usare strumenti inventati da altri (l'intelligenza artificiale, il calcolo quantistico quando mai ci sarà, eccetera), ma abbiamo scelto una materia che per sua natura deve inseguire (al massimo riesce a inseguire a pochissima distanza). Facciamocene una ragione.
E così, è normale che guru come Attivissimo e Bruschi arrivino tardi sulle notizie. Mi preoccupano di più quelli che cercano di arrivarci prima del dovuto (come quelli che ci hanno tormentato su GDPR e NIS2 troppo prima della loro pubblicazione, creando falsi allarmi e, poi, stanchezza).
Ah… infine: Claudio Sartor mi segnala la conclusione del pezzo di Attivissimo, dove riporta che i "dirigenti preferiscono passare gli audit" piuttosto che implementare reali misure di security. Claudio accenna al fatto che si tratta di una vecchia storia e ha ragione (e anche questo dimostra quanto la nostra materia non sia di innovazione).
