Gli uomini possono fare tutto (Dicembre 2024)

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:

• sembra che abbiano eliminato i programmi statali; quindi i professori seguono i "programmi dei libri" (pompati di pagine per l'avidità degli editori);
• questi programmi sono anche compressi perché l'orario alle medie è sempre di 30 ore dagli Ottanta ad oggi, ma oggi c'è una materia inutile (la seconda lingua, fatta male anche perché spessissimo non ripresa alle superiori) e quindi 2 ore in meno per altre;
• il MIUR chiede di dare almeno 3 voti ad alunno per materia; non chiedetemi il riferimento normativo, ma so che mio figlio ha 14 materie e dovrebbe avere 42 voti, mentre nel secondo quadrimestre dello scorso AS ne aveva 80 (posto che non dovrebbe avere più verifiche lo stesso giorno e i giorni di scuola sono 200 e quindi il secondo quadrimestre dovrebbe essere di 100 giorni, calcolo che ha avuto una verifica scritta o orale quasi ogni giorno);
• molti genitori e docenti pensano che più verifiche (magari a sorpresa) fanno imparare di più e spronino i ragazzi (leggere Lucangeli per capire la sciocchezza).

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.

Codice di condotta privacy per le imprese di sviluppo e produzione di software gestionale

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.

Generative Artificial Intelligence: punti di forza, rischi e contromisure

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.

Linee guida di ACN per il rafforzamento della protezione delle banche dati rispetto al rischio di utilizzo improprio

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.

Mio articolo sul calcolo dei rischi relativi ai dati personali

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: Linee guida per il rafforzamento della resilienza

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/207 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).

Malware "cartaceo"

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 cyber resilience act (CRA)

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:

• sono descritti nell'articolo 6;
• vanno applicate le misure "minime" dell'Allegato 1 e il processo di gestione delle vulnerabilità, sempre in allegato 1.

Per i prodotti importanti:

• Sono descritti all'art. 7 e nell'Allegato III; in sintesi si tratta di prodotti di sicurezza informatica e prodotti i cui malfunzionamenti e compromissioni possono avere impatti significativi su altri sistemi informatici o sulle persone.
• Entro l'11 dicembre 2025, la Commissione fornirà migliori indicazioni (descrizioni tecniche) delle categorie di tali prodotti.
• Vanno applicate le verifiche descritte nell'articolo 32; in particolare, se non sono seguite norme armonizzate (norme ETSI) o specifiche comuni della Commissione, va coinvolto un organismo di certificazione ("organismo notificato") per la verifica o del tipo o del sistema di gestione per la qualità (si tratta quindi di due opzioni distinte, a scelta del fabbricante). Per alcuni prodotti la verifica del tipo va accompagnata anche dalla verifica della produzione. In alternativa, si può usare il meccanismo di certificazione del prodotto.

Per i prodotti critici:

• Sono descritti all'art. 8 e nell'Allegato IV; mi pare che al momento siano molto pochi e alcuni siano già certificati secondo i Common Criteria (ISO/IEC 15408).
• Devono applicare le misure dell'Allegato 1 ed essere certificati con livello di affidabilità almeno "sostanziale", secondo quanto previsto dal Cybersecurity Act (regolamento UE 2019/881), sempre che esista uno schema di certificazione sia stato adottato; mi sembra che, quindi, si possa immaginare un obbligo di certificazione secondo la ISO/IEC 15408 (ossia lo schema EUCC, l'unico adottato secondo il Cybersecurity act per ora con la Implementing Regulation EU 2024/482) di tali prodotti e, sempre che non abbia capito male, con livello EAL anche 1 o 2.
• Nel caso in cui non sia disponibile lo schema di certificazione, va coinvolto un organismo di certificazione ("organismo notificato") per la verifica o del tipo e della produzione o del sistema di gestione per la qualità (si tratta quindi di due opzioni distinte, a scelta del fabbricante).

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.

Nuova direttiva sulla responsabilità per prodotti difettosi (inclusi software e IA)

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.

NIS2: scadenza per la registrazione

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.

Accesso abusivo ai sistemi informatici aziendali, anche per i superiori gerarchici

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/.

ENISA Implementation guidance on NIS 2 security measures - Draft for Consultation

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.

UFCS Rapporto semestrale 2024/1

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.

ISO/IEC 29134:2023 Guidelines for privacy impact assessment

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.

Dossieraggi

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.

Garante privacy e conservazione email e metadati 04

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.

Privacy: sanzionato il backup delle e-mail dopo la cessazione del rapporto di lavoro

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 fatto che l'interessato fosse un agente e non un lavoratore dipendente, non cambia il fatto che la società sia titolare del trattamento;
• l'informativa riportava i tempi di conservazione (6 mesi) dei log degli accessi alla posta elettronica e al gestionale; contestati facendo riferimento anche al precedente provvedimento che indica 21 giorni come tempo di riferimento;
• l'informativa prevedeva la possibilità, per la società, di accedere alle email, ma solo per garantire la continuità della prestazione lavorativa e non le indagini;
• l'accesso per garantire la continuità della prestazione lavorativa è contestato perché l'email non è uno strumento che garantisce autenticità, integrità, affidabilità, leggibilità e reperibilità (per questo dovrò ripassare (il provvedimento n. 53 del 01/02/2018 doc. web n. 8159221, e il provvedimento n. 214 del 29/10/2020 doc. web 9518890);
• l'informativa riportava il fatto che le caselle di email sono oggetto di back up, conservato per la durata del rapporto di lavoro e i 3 anni successivi alla cessazione; tali tempi  sono contestati perché non sono giustificati;
• l'informativa riportava il fatto che le caselle di email sono oggetto di back up per finalità di sicurezza informatica, mentre i backup sono stati utilizzati per finalità di indagine;
• in tutti i casi, la conservazione così estesa per un tempo così lungo è considerata non proporzionata e, anzi, porta al controllo sull’attività dei lavoratori, come descritta dallo Statuto dei lavoratori (art. 4 della L. 300 del 1970), e quindi doveva essere avviata in presenza di "accordo con le rappresentanze dei lavoratori o, in assenza, autorizzazione dell’Ispettorato del lavoro".

DoD (USA) Cybersecurity Maturity Model Certification (CMMC) Program Final Rule

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.

Pubblicata la ISO/IEC 27019:2024 con i controlli di sicurezza per il settore dell'energia

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.

Piracy Shield e il blocco di Google Drive

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.

NIS2: Implementing Regulation della Commissione

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.

Preferisco segnalare l'articolo che ho scritto in merito (anche se, rileggendolo, vedo che ho lasciato qualche refuso): https://www.cybersecurity360.it/legal/nis2-ecco-le-regole-della-commissione-ue-per-una-corretta-attuazione-della-direttiva/. 

Su LinkedIn ho provato a scriverne una versione in inglese.

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.

ISO/TS 22360:2024 sulle crisi

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.

ISO 22336:2024 sulla resilienza

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.

 

Minacce e attacchi: Bancario spia i conti correnti (ma non è un "incidente di sicurezza"!)

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.

Normativa: FAQ di ACN su NIS2

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.

"Piracy shield" - Aggiornamento

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:

• impone a tutti i fornitori di servizi internet l'obbligo di segnalare persino il sospetto di attività illecite online, pena sanzioni penali fino a un anno di carcere;
• impone agli stessi di designare e notificare ad (AGCOM) “un punto di contatto che consenta loro di comunicare direttamente, per via elettronica, con l'Autorità medesima ai fini dell'esecuzione della presente legge”; non viene indicato come notificare, ahinoi, e quindi per i più ansiosi rimane l’email che si trova alla pagina https://www.agcom.it/contatti-telefonici-e-posta-elettronica.

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:

• DL 113 del 2024, modificato con la L 143 del 2024: https://www.normattiva.it/eli/id/2024/08/09/24G00136/CONSOLIDATED/20241015;
• L 93 del 2023 (non ancora aggiornata ad oggi): https://www.normattiva.it/eli/id/2023/07/24/23G00103/CONSOLIDATED/20241015;
• L 633 del 1941 (non ancora aggiornata ad oggi): https://www.normattiva.it/eli/id/1941/07/16/041U0633/CONSOLIDATED/20241015.

Adottato il Cyber resilience act

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.

Guida EDPB sul legittimo interesse

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

Data governance act (DGA) - Decreto di adeguamento italiano

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.

NIST, cambio delle password e chi arriva tardi sulle notizie

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

ISO/IEC 29100:2024 liberamente scaricabile

La ISO/IEC 29100:2024 è scaricabile liberamente: https://standards.iso.org/ittf/PubliclyAvailableStandards/.

La ISO/IEC 29100:2024 ha titolo "Privacy framework" e riporta la terminologia ISO per gli standard privacy, oltre ai principi e ad altre indicazioni utili.

Non è una norma di requisiti né di linee guida, ma fornisce una base per queste e infatti i controlli delle ISO/IEC 27701, ISO/IEC 27017, ISO/IEC 27018 e probabilmente altre  sono organizzati secondo i principi specificati dalla ISO/IEC 29100:2024.

4 novembre: Open Day DFA sull'intelligenza artificiale

Il 4 novembre a Milano ci sarà la giornata di studio dell'associazione DFA sull'intelligenza artificiale. Per avere maggiori dettagli e iscriversi (gratuitamente!): https://www.eventbrite.it/e/biglietti-ia-dalla-strategia-alla-pratica-1015451311207.

Questo lo pubblicizzo perché sono consigliere dell'associazione e perché ho contribuito all'organizzazione (in realtà, il mio contributo è stato minimo e gli onori vanno soprattutto agli altri consiglieri che hanno fatto gran parte del lavoro).

Relatori di grande spessore e taglio operativo sono gli obiettivi dell'incontro.

Gli uomini possono fare tutto (ottobre 2024)

Quando i figli vanno alla primaria, i genitori devono accompagnarli e riprenderli. Con la secondaria possono autorizzarli all'uscita autonoma e i genitori tirano un sospiro di sollievo...

...tranne accorgersi che tornano a casa alle 14 con una fame incredibile. E quindi i genitori devono correre ai ripari e i metodi sono numerosi (cucinare al volo, .

Io, quando posso, preferisco preparare al virgulto qualcosa di veloce e appena incontro qualche genitore o nonno chiedo se hanno ricette valide. Quindi ringrazio la nonna di Pietro che quest'estate mi ha spiegato come fare il pesto (sarà facile, ma bisogna anche impararlo).

Anni fa avevo letto il libro "La cucina" di Imma Forino perché ci racconta come gli uomini, tradizionalmente, non schifano la cucina, ma solo quando possono dedicarcisi come Pepe Carvalho. La situazione cambia quando diventa un compito quotidiano e ripetitivo. Vedo infatti che è molto faticoso quando chiedo consigli a certi appassionati (tipicamente maschi), che mi vogliono raccontare come fare correttamente (e con tempo a disposizione) la carbonara o piatti complicati o con ingredienti difficili da trovare, quando invece sono alla ricerca di soluzioni veloci e sane.

Se qualcuno volesse poi darmi suggerimenti, ringrazio.

Stato delle norme ISO/IEC 270xx - Ottobre 2024

La settimana del 30 settembre si è tenuto l'incontro annuale del ISO/IEC JTC 1 SC 27 WG 1, ossia del gruppo che si occupa di redigere le norme della "famiglia ISO/IEC 27001".

Questa volta non ho partecipato perché l'incontro era in remoto, con orari favorevoli ai colleghi dell'estremo oriente (dalle 23 alle 3). Dai resoconti vedo quanto segue:

• la ISO/IEC 27003, guida ai sistemi di gestione per la sicurezza delle informazioni (in sostanza, una guida per implementare la ISO/IEC 27001) rimane in stato di working draft e quindi sarà pubblicata tra non meno di 2 anni; va detto che la norma non tratta dei controlli di sicurezza e quindi il testo basato sulla ISO/IEC 27001:2013 è in grandissima parte ancora valido per la ISO/IEC 27001:2022;
• per la ISO/IEC 27004, sulle misurazioni per la sicurezza delle informazioni, sono iniziati i lavori ufficiali, partendo dal working draft e se ne prevede la conclusione tra 3 anni; dalla discussione fatta 6 mesi fa, non sembrano previsti grandi cambiamenti, ma tutto può succedere;
• la ISO/IEC 27017, con i controlli per i servizi cloud, passa in DIS e quindi dovrebbe essere pubblicata tra meno di un anno.

Prossimo incontro a marzo 2025 in presenza negli USA. Fortunatamente con tutti i WG dell'SC 27 (quindi anche quello sulla privacy di cui parlo altrove).

Stato delle norme ISO/IEC 270xx - Privacy - Ottobre 2024

La settimana del 30 settembre si è tenuto l'incontro annuale del ISO/IEC JTC 1 SC 27 WG 5, ossia del gruppo che si occupa di redigere le norme ISO sulla privacy, inclusa la ISO/IEC 27701.

Questa volta non ho partecipato perché l'incontro era in remoto, con orari favorevoli ai colleghi dell'estremo oriente (dalle 23 alle 3). Dai resoconti vedo quanto segue:

• la ISO/IEC 27701, sui sistemi di gestione per la privacy passa in FDIS e quindi dovrebbe essere pubblicata tra circa 6 mesi; l’approfondisco di seguito;
• la ISO/IEC 27706, sulle regole per certificare ISO/IEC 27701 passa in FDIS e quindi dovrebbe essere pubblicata tra circa 6 mesi; continuo a pensare che le giornate di audit previste siano troppe e questo potrà affossare l’appettibilità della ISO/IEC 27701, ma vedremo;
• la ISO/IEC 27018, con i controlli privacy per i servizi cloud offerti da responsabili del trattamento, passa in FDIS e quindi dovrebbe essere pubblicata tra circa 6 mesi; non sono molto convinto del risultato finale perché non migliora l’attuale versione, però credo sopravvivremo;
• la ISO/IEC 29151, sui controlli per i titolari, basati sulla ISO/IEC 27002, passa in DIS e sarà pubblicata tra un anno. 

 Relativamente alla futura ISO/IEC 27701:

• delle sue caratteristiche ho già scritto in precedenza su https://www.agendadigitale.eu/sicurezza/iso-iec-27701-sui-sistemi-di-gestione-per-la-privacy-come-e-come-sara/;
• purtroppo la norma lascia intendere una distinzione tra “privacy” e “sicurezza delle informazioni” (introducendo il concetto di “security programme”), come se la protezione della riservatezza, integrità e disponibilità dei dati personali non sia parte integrante della “privacy”;
• presenta una lista di controlli tecnici (non saprei come altro chiamarli) che è una selezione incoerente e incompleta dei controlli della ISO/IEC 27001; infatti tali controlli sono stati scelti solo perché sono presenti linee guida aggiuntive per la loro implementazione in ambito privacy, ma ci sono controlli fondamentali anche senza linee guida aggiuntive;
• personalmente avrei preferito una discussione più approfondita, anche a costo di usare ancora per altri 2 anni la versione del 2019, visto che ormai abbiamo imparato a usarla, anche se disallineata con la ISO/IEC 27001:2022, piuttosto che tenerci questa per almeno altri 6 anni.

Ulteriore argomento di interesse è che l’ISO/IEC JTC 1 vuole aprire un “ad hog group”, detto AHG 9, che si occupi della “consumer privacy”, ossia della privacy per i consumatori. Ovviamente, il fatto che ci siano due gruppi (SC 27 WG 5 e AHG 9) che si occupano di privacy è assurdo. Vedremo cosa succederà.

Prossimo incontro a marzo 2025 in presenza negli USA. Fortunatamente con tutti i WG dell'SC 27.

Mio articolo "NIS 2 e recepimento italiano"

Ovviamente non potevo mancare la pubblicazione di un mio articolo su NIS 2 e D. Lgs. 138 del 2024: https://www.cybersecurity360.it/legal/nis-2-e-recepimento-italiano-regole-e-adempimenti-per-le-aziende/.

Diciamo che ho cercato di rendere i miei appunti fruibili anche ad altri e quindi la forma non è superlativa.

Mi piacerebbe soprattutto che mi vengano segnalati errori, omissioni e possibili miglioramenti. Credo infatti di avere ancora molto da imparare su questa materia.

Pubblicato il D. Lgs. 134 del 2024 di recepimento della CER

E' stato pubblicato il Recepimento Direttiva (UE) 2022/2557, detta CER (D. Lgs. 4 settembre 2024, n. 134): https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2024-09-04;138.

La Direttiva CER è quella relativa alla resilienza dei soggetti critici. Può sembrare simile alla NIS2, ma questa CER riguarda la continuità, di cui la sicurezza informatica è solo una parte e infatti un soggetto critico per la CER è automaticamente un soggetto a cui si applica la NIS2.

Per la CER, al contrario della NIS 2, non è l'impresa a dover valutare se è un soggetto critico, ma sono le ASC (autorità settoriali competenti) a identificare i soggetti critici, ossia che forniscono servizi essenziali, e notificare loro il loro stato.

La Direttiva e il D. Lgs. descrivono poi gli obblighi di valutazione del rischio, di adozione di misure di sicurezza e di notifica degli incidenti. Nulla di nuovo e non riporto qui le specificità. Segnalo però l'interessante art. 13 comma 4 che, in poche parole, dice che si possono riutilizzare le valutazioni del rischio già fatte per altri motivi, purché ovviamente considerino i rischi specifici relativi alla resilienza e alla continuità e alla dipendenza da altri soggetti.

Interessante anche la possibilità di chiedere, da parte del PCU (punto di contatto unico in materia di resilienza dei soggetti critici, presso la Presienza del Consiglio) e dell'ASC, una "missione di consulenza" per valutare le misure adottate dal soggetto critico.

Pubblicato il D. Lgs. 138 del 2024 di recepimento della NIS 2

E' stato pubblicato il Recepimento Direttiva (UE) 2022/2555, detta NIS 2 (D. Lgs. 4 settembre 2024, n. 138): https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2024-09-04;138.

Innanzi tutto, le scadenze. Per questo faccio riferimento a chi ha sicuramente studiato meglio di me e rimando all'articolo "Recepimento della Direttiva NIS 2: niente panico": https://www.cybersecitalia.it/recepimento-della-direttiva-nis-2-niente-panico/39245/.

ENISA Threat Landscape 2024

ENISA ha pubblicato il Threat Landscape 2024: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024.

Non vorrei sembrare quello che banalizza tutto, ma non mi sembra ci siano novità significative. Poi, pubblicazioni come questa sono comunque utili per mantenere l'attenzione sulle minacce informatiche e per ripassare le misure di sicurezza (andare direttamente a pagina 110).

ISO Survey 2023

L'ISO pubblica annualmente i dati relativi alle certificazioni ISO 9001, ISO IEC 27001, ISO 20000-1, ISO 22301, ISO 28000 e altre, per un totale di 12 sistemi di gestione (l'anno scorso erano 16, dovrei analizzare meglio per capire dove sono finiti).

I dati possono essere scaricati direttamente, anche in formato Excel, dal sito ISO: https://www.iso.org/the-iso-survey.html.

Notare che i certificati ISO 9001 nel mondo sono circa 850mila, mentre quelli ISO/IEC 27001 sono 50mila. Una bella differenza (a mio parere, dovuta anche all'eccessivo numero di giornate richiesto dalla ISO/IEC 27006, ma non ho prove per sostenerlo).

Sui cercapersone esplosi in Libano

I miei post non si occupano di cronaca "informatica" anche per mia manifesta incompetenza (mi occupo più di organizzazioni). Però c'è Guerre di Rete che lo fa benissimo. Quindi, per quanto riguarda la storia dei cercapersone esplosi in Libano, e soprattutto le analisi su come è stato fatto, rimando al numero del 23 settembre 2024: https://guerredirete.substack.com/p/guerre-di-rete-cercapersone-esplosi.

CIS Critical Security Controls Version 8.1

Segnalo che ad agosto sono stati pubblicati i CIS Critical Security Controls Version 8.1: https://www.cisecurity.org/controls/v8-1.

L'ho saputo da un post su LinkedIn di Davide Giribaldi e copio alcune sue considerazioni:

• I controlli CIS, non sono un vero e proprio framework, ma una serie di 18 controlli di libera adozione, che partendo dalle 6 funzioni stabilite dal Framework NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) propongono un numero crescente di azioni a seconda della maturità digitale dell'azienda.
• Ogni controllo prevede anche 3 livelli d'implementazione a seconda della maturità cyber dell’organizzazione.

Cyber-attacco in Svizzera, muore una mucca. Lezioni sulla digitalizzazione

Segnalo questo breve articolo dal titolo "Cyber-attacco in Svizzera, muore una mucca. Lezioni sulla digitalizzazione": https://formiche.net/2024/08/mucca-cyber-attacco-svizzera/.

Racconta delle conseguenze del controllo di un robot di mungitura da parte di malintenzionati. La lezione finale è "quando si parla di cyber-attacchi, si pensa soltanto alle grandi imprese e infrastrutture", ma bisogna prestare attenzione anche a tutti gli altri ambiti.

Ringrazio Stefano Ramacciotti per la segnalazione.

Gli uomini possono fare tutto (settembre 2024)

In altro post ho avuto modo di citare Gianna Detoni. La conosco di nome, ho letto e apprezzato altri suoi articoli e forse le ho stretto la mano una volta, ma non ci conosciamo personalmente. La sua persona è collegata a una mia disavventura.

Nel 2019 assistei a Milano a un convegno organizzato proprio da Gianna Detoni sulla continuità operativa. Tutto molto interessante. Però a un certo punto mi suona il telefono ed era l'asilo di un mio figlio: non ero andato a prenderlo!

In realtà pensavo di essermi accordato con i suoceri, ma non era così. Ho quindi lasciato tutto e preso un taxi e mi sono precipitato all'asilo del bambino (mia moglie era a lavorare più lontano e con meno flessibilità di me). Una figuraccia che ancora oggi il bambino, ora ragazzino, mi rinfaccia ogni tanto.

Quindi gli uomini possono fare tutto, anche sbagliare in modo terribile.

Alcune riflessioni sulla "cyber resilience"

Pietro Luca Savorosi mi ha scritto per segnalarmi un articolo di Gianna Detoni del 2018 dal titolo "Il Grande Malinteso – Business Continuity e Cyber Resilience": https://www.ictsecuritymagazine.com/articoli/grande-malinteso-business-continuity-cyber-resilience/.

Condivido quanto scritto sulla inutilità del termine "cyber resilience" perché riguarderebbe la continuità e la disponibilità dell'IT in senso esteso, materie già note da tempo. Anche se tendo a essere più rigido con la terminologia, penso che si possa applicare il principio "chiamatelo come volete, purché lo facciate".

L'articolo mi ha fatto riflettere su altri aspetti e ne approfitto per aggiungerli:

• la “continuità operativa” è ormai una materia molto vasta e bisogna evitare l'idea che il business continuity manager sia tuttologo e quindi identificare e monitorare tutte le soluzioni di continuità;
• penso che la continuità operativa sia in realtà "un adempimento in più", che richiede una persona che la segua come suo compito specifico, non necessariamente unico; in caso contrario, altre figure con responsabilità più operative non avranno mai lo stimolo per riflettere, almeno periodicamente, sulla continuità operativa e per fare i necessari test; questo non per incompetenza o mala fede, ma perché la normale attività può essere talmente frenetica che è impossibile seguirne altre sporadiche senza un valido supporto;
• la continuità operativa è una cosa strana perché molte volte non identifica scenari che poi si avverano (i famosi cigni neri, ma soprattutto una pandemia in Europa), quindi va pensata nel modo più appropriato, tale da poter essere essa stessa elastica.

Pietro mi segnala un paio di certificazioni di competenze in cyber resiliency. Su questo penso che una persona con competenze di informatica e di continuità operativa, automaticamente le abbia anche in cyber resiliency. Però il mercato della formazione, come altri, tende a presentare sempre nuovi titoli e sta a noi identificare quelli veramente utili.

Tassonomia degli incidenti IT di ACN

ACN ha pubblicato il documento "La tassonomia cyber dell’ACN": https://www.acn.gov.it/portale/linee-guida-operative.

Mi sono chiesto se la notizia fosse di interesse perché ho il dubbio che si tratti di un'ennesima tassonomia, che si aggiunge a quelle più note usate per ENISA, CVE, ENISA e MITRE. Bisogna dire che il documento di ACN le cità ed esplicita la scelta di voler predisporre un elenco più granulare. L'elenco è di 144 voci, alcune volte alternative tra loro, altre da concatenare.

Lettura forse utile per riflettere sulle misure adottate per contrastare le minacce indicate.

Questa tassonomia, poi, non si collega per niente al report sugli incidenti. L'ultimo del 22 agosto si trova qui: https://www.acn.gov.it/portale/w/minaccia-cyber-il-terzo-report-di-acn (aggiungo che, confrontato con quello del NCSC della Confederazione Svizzera, ci sono ampi margini per migliorarlo).

Ringrazio Franco Vincenzo Ferrari per avermi segnalato il documento sulla tassonomia.

Segnalo ad ACN (ma dubito che questa mia segnalazione possa pervenirle) che è arrivato il momento di riorganizzare il sito web, visto che le linee guida operative si trovano sotto la voce "ISAC" (Information Sharing and Analysis Center), a sua volta sotto la voce "Strategie". Un po' complicato...

Mi rendo conto di criticare spesso alcune cose di ACN (incluso il fatto che per rimanere aggiornati si debbano seguire social network made in USA o comunque registrarsi a strumenti come Telegram, a meno di non voler consultare periodicamente il loro sito), ma non sempre.

Password nel codice software (il caso SolarWinds)

SolarWinds torna nelle cronache della sicurezza informatica perché è stata trovata una password di accesso nel suo prodotto Web Help Desk (WHD). Un articolo (segnalato dal Sans NewsBites), con titolo "SolarWinds fixes hardcoded credentials flaw in Web Help Desk", è questo: https://www.bleepingcomputer.com/news/security/solarwinds-fixes-hardcoded-credentials-flaw-in-web-help-desk/.

SolarWinds ha pubblicato subito una correzione.

So bene che non è facilissimo evitare le password incorporate nel codice, soprattutto se in codice legacy, però è sicuramente il caso di evitare questa pratica, anche per software meno diffusi di quelli prodotti dai giganti USA.

Approfondimento sul regolamento eIDAS n. 2024/1183

Franco Vincenzo Ferrari mi ha segnalato il numero 4 del 2024 della "Rivista elettronica di Diritto, Economia, Management", dedicata al regolamento eIDAS n. 2024/1183: https://www.clioedu.it/marketplace/elenco-completo/item/n-2024-4-rivista-elettronica-di-diritto-economia-management.

Sono 254 pagine che non sono riuscito a leggere. Però è indiscutibile la qualità del lavoro svolto.

Guida alla notifica degli incidenti informatici di ACN

Su LinkedIn avevo notato la pubblicazione della "Guida alla notifica degli incidenti al CSIRT Italia" di ACN: https://www.acn.gov.it/portale/w/acn-pubblica-la-guida-alla-notifica-degli-incidenti-informatici.

Il documento è sicuramente pedante quanto ripete chi sono i soggetti PSNC, quelli OSE e FNC (da NIS), Telco, Legge 90 del 2024 e altri. Infatti, se uno non dovesse già sapere di essere uno di quei soggetti, perché mai dovrebbe apprenderlo da questo documento?

Poi, meno gentilmente, a domande come "Cosa notificare al CSIRT Italia" la risposta è "guarda la normativa", ma almeno riporta l'articolo specifico.

Però io ho clienti che rientrano in alcune delle categorie e questa pubblicazione, opportunamente utilizzata, mi tornerà molto utile perché sintetizza molte cose e le mette insieme.

Studiare il IA Act

Per studiare l'IA Act segnalo due iniziative.

La prima, e sicuramente più autorevole, è "Il regolamento IA commentato riga per riga" di Giovanni Ziccardi (per i pochissimo che non lo conoscono, è professore di “Informatica Giuridica” presso l’Università di Milano), parte del ciclo di video "IA per tutti": https://www.youtube.com/watch?v=XoWldziYrw0&list=PL_JkJ0T5Nq4MbbvxRBaNqvSzbg8t5HxRs.

Si tratta di video e io faccio molta fatica a seguirli (ognuno ha le sue stranezza), però ascoltare Giovanni Ziccardi è sempre un piacere. Quindi, anche se a scatola chiusa, lo raccomando.

La seconda è di Andrea Broglia, che non conosco, ma di cui ricevo il "Frid_AI_news", newsletter su LinkedIn. Anche lui si propone di "esaminare il Regolamento Europeo in materia di Intelligenza Artificiale con brevi articoli settimanali". Mi sembrano una buona lettura e quindi la raccomando: https://www.linkedin.com/newsletters/frid-ai-news-%F0%9F%91%BE-7197237138776588291.

Gli uomini possono fare tutto (luglio 2024)

Mi rendo conto che il mio è un lavoro da privilegiati e che posso svolgerlo quasi dappertutto. Alcune volte è preferibile affiancare fisicamente il cliente anche perché così il rapporto umano si consolida, si colgono meglio alcune cose grazie a una più ampia visione della gestualità e si può rimanere meglio concentrati in alcuni compiti.

Però i figli sono senza scuola per 3 mesi e almeno un genitore deve fare in modo che facciano vacanze (potremmo mandare i nostri anche nei campus con pernottamento, ma, per questioni che non è il caso di spiegare qui, non possiamo ancora farlo). Quindi ringrazio i clienti che nel mese di luglio hanno avuto la pazienza di vedermi lavorare in luoghi da vacanza e non mi hanno insultato troppo. Spero di non essere sembrato troppo poco professionale, ma preferisco questo al tenere i figli in giro a Milano.

Check list EDPB per audit all'intelligenza artificiale

EDPB ha pubblicato alcuni strumenti per l'audit ai sistemi di IA: https://www.edpb.europa.eu/our-work-tools/our-documents/support-pool-experts-projects/ai-auditing_en.

Il documento “Checklist for AI auditing” è forse più lungo del necessario, ma credo sia un’ottima fonte di ispirazione. Essendo dell'EDPB, la privacy è il punto chiave del documento proposto e in effetti forse quello che copre tutti i rischi relativi a questi sistemi.

Gli altri due (“proposal for AI leaflets” e “Proposal for Algo-scores”) non mi sembrano significativi, alla luce del Regolamento IA che già fornisce indicazioni per le informative IA e una classificazione dei sistemi di IA (anche se “vietati”, “ad alto rischio” e “altri” non è una classificazione estremamente raffinata, ammettiamolo; ma non mi convincono neanche gli algo-score proposti).

Ringrazio Chiara Ponti per la segnalazione agli Idraulici della privacy.

Pubblicato l'IA Act

Pietro Calorio ha dato la notizia a noi Idraulici della privacy che il 12 luglio 2024 è stato pubblicato l'IA Act, Reg. UE 2024/1689: https://eur-lex.europa.eu/eli/reg/2024/1689/oj.

La notizia è già stata data da altri e io arrivo più tardi (ma Pietro l'aveva data il 12 luglio stesso!). Sono 144 pagine in Gazzetta ufficiale dell’Unione europea. L'ho letto dopo aver ascoltato un paio di webinar e senza particolare attenzione. Lo approfondirò quando partirà un progetto di applicazione. Per il momento ho cercato di trovare un orientamento nei 113 articoli e 13 allegati.

Le parti più importanti per le organizzazioni sono:

• il Capo I, che delinea l'ambito e le esclusioni (per esempio per scopi personali; ma ci sono anche eccezioni);
• il Capo II che indica i sistemi vietati;
• il Capo III che stabilisce quali sono i sistemi ad alto rischio, insieme alle numerose attività che devono svolgere i produttori e i deployer per metterli a disposizione;
• il Capo IV, che riguarda le informazioni che devono fornire i fornitori di tutti i sistemi IA;
• Capo V, che riguarda i modelli di IA per finalità generali; anche in questo caso ci sono adempimenti da prevedere.

Con questi cinque Capi ho già da tenere sotto controllo 56 articoli. Tutto il resto riguarda iniziative specifiche, sulle quali non credo sarò coinvolto. Nel caso, studierò.

Bloccati sistemi per un aggiornamento CrowdStrike (parte 2)

Claudio Sartor mi ha scritto per darmi un paio di link sul caso CrowdStrike.

Uno è di Paolo Attivissimo: https://attivissimo.blogspot.com/2024/07/due-parole-sul-caos-informatico.html.

Il secondo è un video di Matteo Flora: https://www.youtube.com/watch?v=hyWsFAEkFa0.

Ho letto solo il primo (non ho la pazienza di seguire i video) e mi conforta vedere che il mio commento è in linea.

EDPB approva criteri Europrise

Dalla newsletter di Project:IN Avvocati: il 18 luglio 2024 l’EDPB ha pubblicato il parere 19/2024 sull’approvazione dei criteri di certificazione di EuroPrise, predisposti da EuroPriSe Cert. GmbH, un ente tedesco che li ha presentati all’Autorità garante del Nordreno-Westfalia (Germania). L'EDPB ha ritenuto che i criteri di certificazione siano coerenti con il GDPR, e li registrerà nel Registro pubblico dei meccanismi di certificazione, dei sigilli e dei marchi per la protezione dei dati ai sensi dell'articolo 42 del GDPR.

Link alla newsletter (come al solito, ci sono altre cose interessanti): https://www.linkedin.com/comm/pulse/292024-immaginatevi-se-lo-sciopero-di-windows-avesse-b25nf.

Oltre a Europrivacy, ora c'è questo operatore. Tra l'altro, io non ho notizie di certificazioni Europrivacy. Quindi chiedo se qualcuno ha notizie più fresche. Ho però l'impressione che, dopo il tanto parlare delle certificazioni GDPR, adesso interessino molto molto meno.

Bloccati sistemi per un aggiornamento CrowdStrike (Microsoft)

La notizia del mese è che un aggiornamento del software CrowdStrike aveva un bug che, nella notte del 18 luglio, ha bloccato i sistemi Windows, con impatti e interruzioni in tutto il mondo, anche nei servizi di trasporto e in strutture sanitarie.

Fornisco il link alla notizia, data in formato sinteticissimo e con link e commenti di esperti, dal SANS: https://www.sans.org/newsletters/newsbites/xxvi-55/.

Intanto trovo interessante sapere che CrowdStrike è uno strumento per la sicurezza degli endpoint: sicuramente utile perché permette di centralizzare tante operazioni, ma anche pericoloso, come tutti gli strumenti.

Le riflessioni da fare sono molte. Io mi limito a qualche titolo, anche perché sono in assenza di notizie approfondite:

• non so perché CrowdStrike ha dovuto apportare l'aggiornamento, ma ho sempre il sospetto che, tra correzioni e nuove funzionalità da fare velocemente e a costi ridotti, quasi tutti i produttori di software rischiano di essere causa di incidenti più o meno significativi;
• chissà se CrowdStrike aveva fatto dei test al prodotto; visto l'impatto, un test in ambiente di prova avrebbe dovuto evidenziare il problema; però sappiamo che i test si fanno poco e male per il problema di cui sopra;
• dall'analisi tecnica (che, grazie a Pietro Calorio degli Idraulici della privacy, trovo su https://www.linkedin.com/posts/daniele-zecca-74b64925_memoria-computer-0x9c-activity-7220358324712574976-YWX7) sembra che uno strumento di controllo della qualità e della sicurezza (statica) del codice avrebbe dovuto segnalare il problema; quindi o non è stato usato uno strumento di controllo o la segnalazione è stata ignorata e le cause sono sempre quelle sopra indicate;
• chissà se i conduttori delle infrastrutture critiche che poi si sono bloccate avevano fatto dei test prima di distribuire l'aggiornamento su tutti i sistemi; anche loro, lo sappiamo, soffrono del solito problema per cui gli investimenti nell'informatica non sono proporzionali alla sua importanza (e questo e altri incidenti dimostrano che siamo ben lontani dall'avere manager con la giusta sensibilità);
• se ci sono dei sistemi critici che potrebbero bloccare tutta un'infrastruttura, vanno posti in reti dedicate e separate, come si consiglia in ambito OT e come andrebbe fatto in tutti gli ambiti critici; ma anche questo richiede investimenti (e, purtroppo, temo che NIS2, DORA e compagnia non impongano questa misura, anche perché oggi in pochi sanno valutarla correttamente).

Niccolò Castoldi mi ha segnalato la dichiarazione del CEO di CrowdStrike (https://www.wired.com/story/microsoft-windows-outage-crowdstrike-global-it-probems/) che dice: "Questo non è un incidente di sicurezza o un ciber attacco". Qui si vede un uso del termine "incidente di sicurezza" come sinonimo di "attacco di malintenzionati" molto diffuso. In realtà, lo sappiamo, si è trattato di un errore (causa) che ha provocato un incidente di sicurezza delle informazioni (effetto almeno sulla disponibilità).

E ancora una volta colgo l'occasione per ricordare che chi si occupa di sicurezza delle informazioni non si occupa "solo" di attacchi, ma anche di errori, che sono spesso molto più numerosi e provocano danni molto più estesi (credo che tanti gruppi di criminali se lo possono solo sognare un attacco di così grande impatto).

Legge 90 del 2024 sulla cybersicurezza nazionale

Segnalo la pubblicazione della Legge 90 del 2024 "Disposizioni in materia di rafforzamento della cybersicurezzanazionale e di reati informatici": https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2024-06-28;90!vig=2024-07-10.

Segnalo un articolo di analisi completa della norma (grazie a Luisa di Giacomo degli Idraulici della privacy): https://www.altalex.com/documents/2024/07/03/l-90-2024-cybersicurezza-g-u-adempimenti-p-a-societa-private.

Nel mio piccolo, segnalo alcune cose pensando alle aziende, non alle istituzioni come ACN.

Il primo punto riguarda l’ambito di applicabilità della notifica degli incidenti e, in generale, di tutta la Legge, visto che è dato dall'articolo 1 nei commi 1 e 3, non perfettamente allineati tra loro. La lettura è complicata per i tanti richiami ad altri dispositivi normativi. Riassumendo molto (e anche troppo), la norma è applicabile a pubblica amministrazione, società di trasporto pubblico, aziende sanitarie locali, società in house, società che erogano servizi di raccolta, smaltimento o trattamento di acque reflue urbane, domestiche o industriali o di gestione dei rifiuti.

Le società in house, sono citate due volte: una con l’aggettivo “relative” e l’altra senza, così da rendere ancora più difficile l’interpretazione.

Il secondo punto (articolo 1) riguarda, per le società in ambito, la procedura di gestione degli incidenti, che dovranno essere notificati ad ACN con prima notifica entro 24 ore e rapporto finale entro 72 ore dalla conoscenza dell'incidente. Gli incidenti dovranno essere segnalati alla pagina di ACN https://www.csirt.gov.it/segnalazione (che dovrà quindi essere aggiornata), usando la tassonomia, stabilita dalla Determina del 3 gennaio 2023 di ACN (https://www.gazzettaufficiale.it/atto/serie_generale/caricaDettaglioAtto/originario?atto.dataPubblicazioneGazzetta=2023-01-10&atto.codiceRedazionale=23A00114), che prevede 14 tipologie di incidente (ovviamente diverse dalle 25 previste dal DPCM 81 del 2021 per evitare di renderci la vita troppo facile).

Notare che i tempi sono disallineati rispetto a quelli previsti dal perimetro di sicurezza nazionale cibernetica (PSNC) di 6 ore, ma uguali a quelli della NIS 2.

Notare anche per il PSNC un’altra tassonomia è presente nel DPCM 81 del 2021, quindi sembra che una Determina di ACN abbia annullato parte di un DPCM. Non sono un legale, ma tutto questo mi sembra strano.

Per alcune entità, la norma entrerà in vigore il 17 luglio, per altre, i tempi di adeguamento saranno di 6 mesi e un mio calcolo veloce e sicuramente inesatto dice da gennaio 2025.

L’articolo 8 riguarda la necessità di stabilire una “struttura” (ossia un’unità organizzativa) che si occupi di sicurezza, dal punto di vista sia procedurale sia tecnico, e un “referente per la cybersicurezza” da segnalare ad ACN. E' richiesta professionalità e competenza, ma non mi sembra ci siano requisiti in merito all'indipendenza. Viene segnalato che l'incarico potrebbe essere ricoperto anche dal responsabile della transizione digitale. Da alcuni punti di vista, è positivo che non siano state imposte molte restrizioni in merito a questa figura, soprattutto in questa prima fase di attuazione.

In merito alle competenze e i poteri, ripeto che devono essere tecniche e organizzative, ma una struttura di questo tipo non è facile da trovare nelle realtà più piccole. Anche la possibilità di avere una struttura di questo genere “in forma associata” mi sembra di difficile attuazione, visto che implica l’assegnazione del potere di produrre un organigramma della sicurezza e il piano della sicurezza. Sicuramente alcune PA hanno già l’ufficio per la transizione digitale in forma associata, però il tutto mi lascia perplesso. Ad ogni modo, ho trovato questa pubblicazione di AgID in merito: https://www.agid.gov.it/it/notizie/nomina-del-rtd-e-costituzione-dellutd-forma-associata-online-il-vademecum-le-pa.

Da dire che non sono indicate scadenze per le comunicazioni, né il sito ACN ha ancora messo a disposizione un’area per questo adempimento.

L' articolo 9 richiede che venga verifica "che i programmi e le applicazioni informatiche e di comunicazione elettronica in uso, che utilizzano soluzioni crittografiche, rispettino le linee guida sulla crittografia nonché quelle sulla conservazione delle password adottate dall'Agenzia per la cybersicurezza nazionale e dal Garante per la protezione dei dati personali e non comportino vulnerabilità note, atte a rendere disponibili e intellegibili a terzi i dati cifrati". A questo obbligo sono tenute anche le organizzazioni nel PSNC. Ho qualche dubbio sulla correttezza nel citare un documento tecnico in una Legge (le altre normative fanno in modo diverso). Il documento si può scaricare da qui: https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9962384 (purtroppo il sito di ACN lo ha “nascosto” da qualche parte, né ha un richiamo in home page per una pagina dove reperire tutti questi documenti tecnici).

L'articolo 14 prevede che venga emanato, entro fine 2024, un DPCM con i requisiti da tenere “in considerazione nelle attività di approvvigionamento di beni e servizi informatici”. Questo sarà da utilizzare per le organizzazioni in ambito, ma sarà importante anche per le organizzazioni che lavorano con la PA, visto che dovranno rispettarli. Da notare che questi requisiti saranno applicabili dove è in gioco “la tutela della sicurezza nazionale”. Prevedo però che molti li richiederanno a tutti, visto che sarà più semplice. Sarà importante che le offerte per i soggetti in ambito comincino già a riportare considerazioni di sicurezza informatica.

Segnalo poi che l'articolo 24 bis introduce, nel D. Lgs. 231 del 2001, il reato presupposto di estorsione informatica.

Mia considerazione finale riguarda l'opportunità di questa Legge. Infatti, per ovvi motivi complica il quadro di riferimento al posto di semplificarlo e questo non è un bene. Mi spiego: adesso è in vigore la NIS, deve essere ancora recepita la NIS 2 e devono ancora essere pubblicati gli implementing acts; è in vigore anche il PSNC con i suoi 4 DPCM e altri atti correlati, come dimostrato dai link qui sopra (e con qualche pasticcio qua e là); entreranno in vigore anche altre normative come la CER. Penso che sarebbe stato meglio pubblicare un atto come questo dopo la messa a punto degli altri dispositivi, in modo da cogliere l'occasione per un raccordo tra tutti. Invece è stato pubblicato prima, con anche qualche aspetto che avrebbe richiesto una maggiore cura. Ovviamente, l’aumento di elementi, in questo caso norme, aggiunge sempre confusione nelle cose umane.

Come sempre, sono consapevole che questa è una mia prima analisi. Invito tutti a segnalarmi se ci sono errori o se non concordano.

NB: Questo post sostituisce un post simile inviato in precedenza.