Elenco vittime di ransomware

Glauco Rampogna, un Idraulico della privacy, ha segnalato questo elenco
delle vittime di ransomware:
- https://drive.google.com/file/d/1MI8Z2tBhmqQ5X8Wf_ozv3dVjz5sJOs-3/view.

Utile per far capire per bene l'ampiezza del problema, anche se a mio parere
manca qualche caso.

Standard ETSI per i fornitori di servizi IT fiduciari

Franco Vincenzo Ferrari di DNV ha assistito, il 1 giugno 2021, al webinar
"ETSI standards for trust services and digital signatures" organizzato da
ETSI stessa. Bisogna dire che non è facile orientarsi tra gli standard
pubblicati da ETSI e tra gli acronimi usati nell'ambito dei servizi
fiduciari (a partire dal primo, TSP per trust service provider).

Il materiale messo a disposizione da ETSI permette quindi di avvicinarsi
all'argomento o approfondirlo. E' possibile vedere le presentazioni e il
video (di 4 ore, più o meno come Via col vento) a partire dalla pagina di
presentazione del webinar:
-
https://www.etsi.org/events/1926-webinar-etsi-standards-for-trust-services-a
nd-digital-signatures.

Linee guida del Garante sul DPO

Il Garante ha pubblicato alcune linee guida per il DPO.

In particolare segnalo il "Documento di indirizzo su designazione, posizione e compiti del Responsabile della protezione dei dati (RPD) in ambito pubblico":
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9589104.

Sono poi state aggiornate le faq. Tutti i documenti sono reperibili sulla pagina dedicata:
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9589104.

Sono ripresi molti punti che abbiamo già discusso negli ultimi anni e senza grandi novità, anche se un ripasso fa sempre bene. La cosa interessante è quanto queste analisi siano equilibrate e le confronto con gli stracci che ogni tanto vedo volare quando parlano consulenti, aziende, avvocati, auditor eccetera. Vedo in particolare il parere in merito al curriculum del DPO, ma non è il solo.

Ecco: penso che dovremmo tutti imparare da questo documento, non solo tecnicamente, ma anche operativamente.

Aggiornamento legislativo IT

Ho pubblicato una mia presentazione ("Aggiornamento legislativo 2021") sulla normativa legale applicabile alle certificazioni ISO 9001, ISO/IEC 27001 e non solo:
- https://www.cesaregallotti.it/Pubblicazioni.html.

Ogni segnalazione di errore o di omissione sarà ben accetta.

Attacco a Colonial Pipeline

Colonial Pipeline è una società statunitense dedicata al trasporto di carburante. Ad aprile 2021 è stata attaccata da un ransomware e ha quindi dovuto chiudere temporaneamente alcuni chilometri di rete:
- https://www.theguardian.com/technology/2021/may/08/colonial-pipeline-cyber-attack-shutdown.

Infine, ha pagato il riscatto per sbloccare i propri sistemi informatici:
- https://arstechnica.com/gadgets/2021/05/colonial-pipeline-resumes-operations-after-ransomware-prompted-closure/.

Al momento non mi sembra siano stati scritti articoli di maggior approfondimento dei dettagli su come l'attacco sia stato possibile. Ho trovato alcune dichiarazioni di esperti di sicurezza, ma è evidente, dalla loro genericitià, che le hanno fatte senza informazioni ulteriori.

La Cybersecurity and Infrastructure Security Agency aveva lanciato un allarme già a ottobre 2020, dopo aver studiato un altro attacco (mi sembra che la vittima, in questo caso, sia stata anonimizzata):
- https://us-cert.cisa.gov/ncas/alerts/aa20-049a.

Mi aggancio proprio a questo rapporto, dove la misura tecnica più importante è quella della segmentazione delle reti. Ovviamente si tratta di una misura costosa e impopolare presso gli operatori (che dovrebbero quindi avere computer o partizioni distinte per leggere le email e per svolgere le operazioni tecniche), ma sembra sia l'unica possibile. Oltre, ovviamente, all'autenticazione a più fattori per accedere da remoto (altra soluzione "scomoda", ma necessaria).

Tra l'altro, il rapporto approfondisce altre questioni, spesso dimenticate dagli esperti di sicurezza: in certi settori, le emergenze di sicurezza sicurezza IT sono molto sottovalutate rispetto a quelle operative e prevedere opeazioni manuali in caso di indisponibilità dei sistemi IT.

Meglio lasciare la lettura al rapporto (molto sintetico, ma, ripeto, molto significativo) del CISA.

Inutile dire che questo tipo di attacco non riguarda solo le reti di trasporto dei carburanti, ma tutti i settori:
- https://www.theguardian.com/technology/2021/may/13/colonial-pipeline-ransomware-attack-cyber-crime.

Vietato contattare per recuperare il consenso (puntata 2)

Avevo pubblicato un post dal titolo "Vietato contattare per recuperare il consenso negato in precedenza" in cui si segnalava che la Cassazione aveva confermato un parere del Garante sulla questione in oggetto:
- http://blog.cesaregallotti.it/2021/05/vietato-contattare-per-recuperare-il.html.

Davide Foresti mi ha segnalato che ho fatto un po' di confusione sui provvedimenti "originari" del Garante.

Dice che "la sentenza di Cassazione si riferisce al provvedimento del Garante del giugno 2016 ('solo' 5 anni fa..)":
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/5255159.

Io, su LinkedIn, avevo invece fatto confusione e avevo segnalato un altro link, ad un Provvedimento del 2018, sempre relativo al trattamento di utenze telefoniche per finalità di marketing, ma non oggetto della sentenza di Cassazione:
- https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/8233539.

Ringrazio per la correzione e la diffondo.

Codici di condotta privacy

In questo periodo stanno maturando alcune iniziative in merito ai codici di condotta.

Il primo che segnalo è stato approvato da EDPB (anche se non è ancora disponibile il resoconto dell'incontro 49 del 19 aprile), e quindi si promuove come codice a livello europeo. Esso riguarda i servizi cloud:
- https://www.codeofconduct.cloud/.

Esso è un codice che esisteva già in passato e adesso è stato approvato da EDPB. Purtroppo il sito è fuorviante perché presenta il registro degli aderenti pre-2021.

Non mi risulta poi che siano stati identificati gli organismi di monitoraggio dei codici di condotta.

Il secondo è sempre stato oggetto di decisione da parte di EDPB il 19 aprile. La pagina del Garante belga, che ha avviato la procedura, fornisce alcuni dettagli, oltre al provvedimento di accreditamento dell'OdM (Scope Europe):
https://www.autoriteprotectiondonnees.be/citoyen/lautorite-de-protection-des-donnees-approuve-son-premier-code-de-conduite-europeen.

Il sito è questo:
- https://eucoc.cloud/.

Il Codice, purtroppo, può essere richiesto solo fornendo i propri dati (alla faccia della minimizzazione). Inoltre anche qui c'è un registro di aderenti quando ancora il tutto non era accreditato e, anche in questo caso, la cosa mi lascia perplesso.

Il terzo è il codice relativo alle informazioni commerciali, ossia alle attività che svolgono alcune società ("i fornitori") di analisi di potenziali clienti e partner, ed è solo a carattere nazionale (italiano). Non è nuovo perché era già stato approvato nel 2019, ma è stato modificato dopo aver accreditato l'Organismo di monitoraggio (indicato sempre e solo come "OdM" e quindi non capisco se è una società già esistente o un ente specifico per questo scopo).

Do il link alla notizia, da cui è possibile accedere al codice e all'accreditamento dell'OdM:
https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9585460.

Ho il timore di aver sbagliato qualcosa e quindi sono benvenute le
correzioni.

Assicurazioni e ransomware

L'assicurazione Axa ha ufficialmente smesso di offrire copertura per il pagamento di ransomware.

Questo dopo che sono state espresse delle preoccupazioni da parte di esponenti della sicurezza francese sulla eccesiva diffusione del ransomware:
- https://www.insurancejournal.com/news/international/2021/05/09/613255.htm.


Per tutta risposta il mondo del cybercrime afferma di avere compromesso Axa per punire la sua presa di posizione.
- https://www.bleepingcomputer.com/news/security/insurer-axa-hit-by-ransomware-after-dropping-support-for-ransom-payments/.

Questa notizia me l'ha data Enos D'Andrea che ringrazio.

When AIs start hacking

Segnalo questo articolo di Bruce Schneier dal titolo "When AIs Start Hacking":
- https://www.schneier.com/blog/archives/2021/04/when-ais-start-hacking.html.

Non mi pare dica nulla di innovativo, ma è comunque un piacere leggerlo.

Schneier fa riferimento a un suo documento molto più esteso (54 pagine, quasi un libro) dal titolo "The Coming AI Hackers":
- https://www.belfercenter.org/publication/coming-ai-hackers.

Non ho avuto il coraggio di leggerlo, ma non mi pare aggiunga molto, tranne il fatto che Bruce Schneier scrive sempre molto bene e dice comunque cose interessanti e intelligenti.

Rapporto semestrale NCSC 2020/2

Si chiamava MELANI, oggi si chiama NCSC e a mio parere pubblica uno dei rapporti di sicurezza informatica più interessanti e chiari. Lo si trova in italiano:
https://www.ncsc.admin.ch/ncsc/it/home/dokumentation/berichte/lageberichte/halbjahresbericht-2020-2.html.

E' anche disponibile in inglese, ma, a dimostrazione della qualità del rapporto, l'italiano è molto corretto e chiaro (tra l'altro, senza inutili e vezzose maiuscole e inglesismi fuori luogo).

Articolo su evoluzione e confusione nelle norme ISO/IEC 27xxx

Paolo Sferlazza ha pubblicato un articolo dal titolo "Evoluzione e confusione nella famiglia delle norme ISO/IEC 27xxx":
https://www.ictsecuritymagazine.com/articoli/evoluzione-e-confusione-nella-famiglia-delle-norme-iso-iec-27xxx/.

Non penso che la situazione sarà così confusa come paventato da Paolo, ma credo comunque che valga la pena considerare il suo punto di vista e prepararsi all'uscita della nuova edizione della ISO/IEC 27002, prevista per fine 2021 o inizio 2022.

Sul regolamento europeo per l'intelligenza artificiale

In questi giorni si è parlato molto della bozza di regolamento europeo sull'intelligenza artificiale. Non mi piace parlare delle bozze di leggi e regolamenti perché poi le versioni definitive sono diverse (come abbiamo visto con le bozze del GDPR).

Però questo articolo di Luca Sambuci, a mio parere, chiarisce alcuni aspetti relativi all'intelligenza artificiale che a mio parere è bene conoscere:
- https://www.notizie.ai/sul-regolamento-europeo-per-lintelligenza-artificiale-ce-ancora-molto-da-fare/.

Vietato contattare per recuperare il consenso negato in precedenza

Glauco Rampogna ha segnalato agli idraulici della privacy un interessante articolo dal titolo "Vietato contattare i consumatori per incassare il consenso negato in precedenza":
- http://www.cassazione.net/vietato-contattare-i-consumatori-per-incassare-il-consenso-negato-in-precedenza-p43393.html.

La lettura dell'articolo richiede l'abbonamento a cassazione.net.

Esso fa riferimento alla sentenza 11019/2021 della Sez prima della Cassazione Civile del 26 aprile 2021. Si può leggerla indicando il Numero/Anno sentenza sulla pagina http://www.italgiure.giustizia.it/sncass/.

Direi che già il titolo fa capire completamente la questione.

A me interessa anche perché qualche cliente in passato mi aveva fatto domande proprio su questa questione.

Purtroppo sul sito del Garante non sono riuscito a trovare il provvedimento specifico.

Privacy: Blacklight analizzatore di siti web

Mi scrive Glauco Rampogna, Idraulico della privacy: non male questo analizzatore di siti web:
- https://themarkup.org/blacklight.

Anche a me sembra ben fatto.

Decreto sulle certificazioni richieste dal perimetro di sicurezza

Giancarlo Caroti di Neumus mi ha segnalato la pubblicazione del decreto del Presidente della Repubblica numero 54 del 5 febbraio 2021.

Giancarlo mi sintetizza: "sono definite le procedure, le modalità e i termini da seguire ai fini delle valutazioni da parte del CVCN (Mise) ed i CV (MinInt e Difesa)". E commenta: "Pare molto impattante sulle dinamiche di acquisizione di prodotti e servizi ICT dei soggetti nel perimetro e dunque merita attenzione e credo che sarà spesso invocato (non sempre per lodarlo)!".

Dove reperirlo:
- www.gazzettaufficiale.it/eli/id/2021/04/23/21G00060/sg.

Qualche mio commento:
- gli enti all'interno del perimetro dovranno fare un'analisi del rischio e della sicurezza di ciascun prodotto o servizio ICT che intendono acquistare; credo che in molti copi-incolleranno, ma penso che sarà comunque una pratica utile (purché l'approccio richiesto, che dovrà essere pubblicato tra un paio di mesi, non sarà inutilmente oneroso);
- CV e CVCN potranno specificare quali test dovranno essere condotti prima di approvare un acquisto; anche questi saranno pubblicati tra un paio di mesi e, secondo me, permetteranno, nel tempo, di innalzare il livello complessivo della sicurezza informatica, grazie alla condivisione delle competenze, anche a chi è fuori dal perimetro.

Sicurezza dei servizi cloud MS

Segnalo questa interessante presentazione sulla sicurezza (e su come configurare) dei servizi cloud di microsoft:
- https://drive.google.com/file/d/13Hmi2lSZEZfrvaAfc72EEsmK1iDcuNtM/.

C'è anche il video della presentazione fatta il 28 aprile 2021:
- https://www.youtube.com/watch?v=XOF8fw_aW5E.

Privacy: Sulle sanzioni del Garante

Andrea Veneziani di Yioroi mi ha scritto in merito alle mie riflessioni sulle sanzioni del Garante privacy:
- http://blog.cesaregallotti.it/2021/03/sulle-sanzioni-del-garante.html.

Secondo lui le sanzioni non sono abbastanza elevate perché "la nostra storia ci ha insegnato che, a fronte di sanzioni basse o lievi, poco o nulla si è ottenuto in tema di applicazione della protezione dei dati personali. Mi riferisco alle leggi anteriori al GDPR".

Aggiunge poi: "capisco che le aziende sono tartassate su molteplici fronti (costi per sicurezza sul lavoro, diritti dei lavoratori, agenzia entrate, ecc.), non capisco però le aziende che continuano a fare finta di niente in un mondo dove il singolo cittadino subisce attacchi e tentativi di frode, spamming di pubblicità da società di ogni genere, chiamate da call center al limite dello sfinimento, ecc.".

Io però vorrei ricordare che non chiedo sanzioni meno elevate. Solo mi sembra che, se le sanzioni sono elevate anche per chi si auto-denuncia (anzi, sembra che siano le più elevate in Europa), è inutile lamentarsi se le auto-denunce sono poche.

Comunque la si voglia leggere, rimane una conclusione di Andrea che condivido: "Le sanzioni fanno sì che ogni tanto ci sia una scossa e qualcuno prenda maggiori (o migliori) provvedimenti rispetto alla protezione dei dati personali e delle informazioni in genere".

ISO 37301:2021 - Compliance management systems

Monica Perego mi ha segnalato la pubblicazione della norma ISO 37301:2021 dal titolo "Compliance management systems — Requirements with guidance for use":
- https://www.iso.org/standard/75080.html.

E' facile immagirare i requisiti che riporta, visto che si basa sull'High level structure. E' però chiaro che, a chi intende certificarsi, è richiesto un livello di rigore superiore rispetto al "ogni tanto controllo qualche sito" per dimostrare la propria gestione della conformità. Per questo ci sono alcuni requisiti interessanti.

La norma ha un'Appendice A con anche una guida per l'interpretazione dei requisiti.

Non so che successo avrà questa norma, ma la trovo interessante.

Minacce e attacchi: caso di SIM swap - Commento

Gabriele Marelli mi ha inviato un commento sul post "Minacce e attacchi: caso di SIM swap":
http://blog.cesaregallotti.it/2021/03/caso-di-sim-swap.html.

Riporto nel seguito le sue parole e lo ringrazio.

Condivido la sua osservazione sul fatto che appaia strano che la banca abbia risarcito il cliente pur non avendo una reale colpa per l'attacco e, aggiungo, pur avendo negato le proprie responsabilità nella risposta fornita al cliente. E in effetti in casi simili è raro leggere notizie di rimborsi, anche in relazione a presunte o potenziali corresponsabilità del correntista.

In questo caso mi sembrano però dirimenti i punti 3, 4 e 15.7 della perizia del Dott. Rapetto (e forse anche l'autorevolezza del perito…), che si riferiscono ad una procedura di "Recall", forse colpevolmente non eseguita o eseguita fuori termine da parte della Banca, o forse eseguita correttamente e che quindi ha consentito di recuperare i fondi indebitamente sottratti.

E' infatti evidente che in questo caso specifico sussistessero le condizioni per l'applicazione della suddetta procedura (BEU eseguito in modo fraudolento + richiesta di "Recall" entro 10 giorni lavorativi).

Senza questo elemento a mio avviso l'esito non sarebbe stato così scontato. Temo che il diffuso e ormai annoso problema dello "SIM Swap" permanga…

Stato delle norme ISO/IEC 270xx - Aprile 2021

Si è concluso il 14 aprile 2021 il meeting semestrale dell'ISO/IEC JTC 1 SC 27. Si è svolto tutto in virtuale.

Come al solito indico le cose che a me hanno interessato di più.

Per i lavori collegati alla ISO/IEC 27001:
- la ISO/IEC 27002, sui controlli di sicurezza, sarà discussa a metà giugno e si spera passi in FDIS e quindi sia pubblicata entro fine 2021 (ma penso che più probabilmente sarà pubblicata a inizio 2022);
- proseguono i lavori sulla ISO/IEC 27005 sulla valutazione del rischio (pubblicazione prevista per fine 2022);
- ripartiranno i lavori per aggiornare la sola appendice A della ISO/IEC 27001 in modo che sia allineata alla nuova ISO/IEC 27002 (si cercherà di seguire una strada veloce, che prevede anche il fatto che la norma non cambierà edizione e rimarrà quindi ISO/IEC 27001:2013);
- partiranno i lavori per aggiornare la ISO/IEC 27006-1 in modo che sia progettata in modo da rendere meglio gestibili le altre parti (l'attuale ISO/IEC 27006-2 e le eventuali future parti dedicate ad altri schemi di estensione della ISO/IEC 27001);
- si è anche discusso dei lavori che dovranno riguardare alcune norme (p.e. la ISO/IEC 27017) strettamente collegate alla ISO/IEC 27002.

Per quanto riguarda le norme sulla privacy, segnalo:
- la discussione sulla ISO/IEC 27006-2 (regole di accreditamento, e quindi di certificazione, per la ISO/IEC 27701), perché si ha l'intenzione di riprenderla in mano in modo da correggere alcune cose, migliorare il calcolo delle giornate di audit e farla uscire come International standard e non più come TS entro fine 2023; non penso che per noi italiani questo aggiornamento sia particolarmente urgente, ma sembra che per altri Paesi lo sia e quindi dobbiamo rispettare le loro esigenze;
- i lavori della ISO/IEC 27557 (Organizational privacy risk management), che ho seguito per il dibattito su alcuni concetti interessanti e non per l'importanza della norma;
- la prossima pubblicazione in autunno 2021 della ISO/IEC 27555 sulla cancellazione dei dati personali.

Sicuramente avrò dimenticato qualcosa per colpa della fretta e me ne scuso
con tutti i lettori.

Not boring privacy

Un'iniziativa degli Idraulici della privacy è il canale Instagram notboringprivacy:
- https://www.instagram.com/notboringprivacy/.

Io dico che mi sono iscritto a Instagram solo per seguirlo.

L'iscrizione però è inquietante e non la capisco: se inserisco la mia email (cesare@dominio.it), mi dice "Another account is using cesare@dominio.it". Allora gli dico che ho dimenticato la password e mi dice "No users found". Boh...

Ma la cosa importante, dicevo, è che il canale raccoglie vignette amene sulla privacy. Lo raccomando.

Anche perché si tratta di un'iniziativa degli Idraulici della privacy (e in particolare di Glauco Rampogna).

Android e iOS inviano dati anche se non vogliamo

E' stata pubblicata una ricerca in cui si dimostra che i dispositivi con Android e iOS inviano molti dati a Google e Apple anche quando gli utenti li configurano affinché non lo facciano:
- https://www.theregister.com/2021/04/01/android_ios_location/.

L'articolo segnalato riporta il link alla ricerca completa (in pdf) e le risposte, sempre inquietanti, di Google.

App medicali e sicurezza

A metà 2017 avevo segnalato un articolo sul "futuro" regolamento UE sui dispositivi medici. Poi il regolamento è stato pubblicato, ma non ho più trattato l'argomento, anche se, in questi anni, ho collaborato in alcuni progetti relativi ai dispositivi medici e all'attenzione che il nuovo regolamento pone sulla sicurezza informatica.

Mi ha risvegliato Enos D'Andrea che ringrazio. Mi ha ricordato che il 26 maggio 2021 scade il termine per l'applicazione del regolamento europeo sui dispositivi medici approvato nel 2017. La scadenza era inizialmente prevista per l'anno scorso ed è stata posticipata di un anno causa COVID.

Il regolamento include anche requisiti di privacy e sicurezza per il software con finalità diagnostiche, incluse le applicazioni che monitorano i parametri di salute con finalità diagnostiche, che dovranno quindi obbligatoriamente certificarsi. Complesso è capire la differenza tra app di fitness e mediche.

Innanzi tutto ricordo l'articolo "iniziale" che avevo segnalato nel 2017:
- https://www.filodiritto.com/app-medicali-e-nuovo-regolamento-ue-sui-dispositivi-medici.

Poi segnalo dove trovare il Regolamento aggiornato ad oggi (ultimo aggiornamento del 23 aprile 2020):
- https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:02017R0745-20200424.

Quindi segnalo la "MDCG 2019-16 - Guidance on Cybersecurity for medical devices":
- https://ec.europa.eu/docsroom/documents/41863.

Comunque io non sono esperto di questa materia, ma credo sia giusto tenerla monitorata.

Materiale di formazione su OWASP Top 10 per il web

Glauco Rampogna (questo mese mi ha fornito molte indicazioni interessanti!) mi ha segnalato questo sito dove sono disponibili applicazioni interattive per formazione delle OWASP Top 10 per il web:
- https://application.security/free/owasp-top-10.

Come dice Glauco, può essere usato "al posto di mille webinar a pagamento". E in effetti ho trovato più indicazioni utili e approfondite qui che nelle presentazioni che ho sentito finora, tranne una di Paolo Perego (https://codiceinsicuro.it/) ormai troppi anni fa.

Io confesso di aver guardato solo la ricostruzione dell'attacco a Capital One con un attacco SSRF e la "Vertical Privilege Escalation". Non ho capito proprio tutto, ma penso proprio si tratti di un buon approccio per spiegare ai non tecnici come me alcune possibili vulnerabilità e ai tecnici come mitigarle.

Il furto di dati personali da Facebook

Glauco Rampogna mi ha segnalato questo articolo sul furto di dati personali da Facebook:
- https://www.businessinsider.com/stolen-data-of-533-million-facebook-users-leaked-online-2021-4?IR=T.

Ormai questa è una notizia super nota e richiamata da tutte le testate giornalistiche. Non mi sembra però di aver letto articoli tecnicamente significativi.

Tranne questo (sempre segnalato da Glauco qualche giorno dopo):
- https://www.reuters.com/article/us-facebook-data-leak/facebook-does-not-plan-to-notify-half-billion-users-affected-by-data-leak-idUSKBN2BU2ZY.

La cosa interessante è che Glauco ha cercato il mio nome e l'ha trovato con il numero di cellulare. Ora... non mi sembra di averlo mai dato a Facebook. Mi sa che l'ha reperito da WhatsApp e infatti sul profilo di Facebook il mio cellulare non risulta disponibile. Quindi vuol dire che ha aggregato dati credo senza una vera necessità. Ottimo...

Tra l'altro, in questi giorni ci sono stati altri attacchi (dati rubati a LinkedIn, blocco dei servizi a Brescia per ransomware e del servizio Axios per le scuole sempre per ransomware, analisi del Garante dell'incidente a Booking.com a inizio 2019), però nessuno degli articoli che ho visto ci insegna veramente qualcosa, tranne la necessità di stare attenti.

Risoluzione del Parlamento EU sull'applicazione del GDPR

Glauco Rampogna (un Idraulico della privacy) ha segnalato la pubblicazione della "Valutazione della Commissione sull'applicazione del regolamento generale sulla protezione dei dati due anni dopo la sua attuazione" e la "Risoluzione del Parlamento europeo" in merito alla valutazione della Commissione:
- https://www.europarl.europa.eu/doceo/document/TA-9-2021-0111_IT.html.

Il testo è di 14 pagine (il link proposto riporta all'edizione italiana). Io però preferisco riportare quello che mi ha segnalato Glauco.

Glauco segnala il punto 7:
esprime preoccupazione per il fatto che il "legittimo interesse" è molto spesso citato in modo improprio come base giuridica del trattamento; rileva che i titolari del trattamento continuano a basarsi sul legittimo interesse senza effettuare il necessario esame del bilanciamento degli interessi, che comprende una valutazione dei diritti fondamentali; esprime particolare preoccupazione per il fatto che alcuni Stati membri stanno adottando una legislazione nazionale per determinare le condizioni per il trattamento sulla base del legittimo interesse, prevedendo il bilanciamento dei rispettivi interessi del titolare del trattamento e delle persone interessate, mentre il GDPR obbliga ogni singolo titolare del trattamento a effettuare tale esame del bilanciamento a livello individuale e ad avvalersi di tale fondamento giuridico; teme che alcune interpretazioni nazionali del legittimo interesse non rispettino il considerando 47 e vietino di fatto il trattamento sulla base del legittimo interesse; si compiace che l'EDPB abbia già avviato i lavori per aggiornare il parere del gruppo di lavoro "Articolo 29" sull'applicazione del legittimo interesse quale base giuridica per il trattamento, al fine di affrontare le questioni evidenziate nella relazione della Commissione.

e il punto 23:
si rammarica del fatto che il ricorso, da parte degli Stati membri, alle clausole di specificazione facoltative (ad esempio, il trattamento nell'interesse pubblico o da parte delle autorità pubbliche sulla base del diritto dello Stato membro e dell'età del consenso dei minori) abbia pregiudicato il conseguimento di una piena armonizzazione della protezione dei dati e l'eliminazione di condizioni di mercato divergenti per le imprese in tutta l'UE, ed esprime preoccupazione in relazione al fatto che ciò può far aumentare il costo della conformità al GDPR.

Personalmente trovo particolarmente interessante il fatto che l'EDPB voglia aggiornare l'opinione del WP Art. 29 del 2014 in merito al legittimo interesse, in quanto basato sulla precedente Direttiva privacy.

Rapporto Clusit 2021

Come ogni anno, anche nel 2021 il Clusit ha pubblicato il suo rapporto:
- https://clusit.it/rapporto-clusit/.

I numeri, di per sé stessi, non mi entusiasmano molto, anche perché sono sempre alti e, oltre una certa soglia, non dicono altro che "bisogna stare attenti". Da questo punto di vista, il rapporto Clusit ogni anno trova un messaggio nuovo e nel 2021 è "siamo sotto assedio".

Alcuni aspetti sono però degni di nota. Ovviamente le tipologie di attacco più diffuse, che confermano il malware e il social engineering e quindi la necessità di educare le persone a riconoscere ed evitare questi attacchi (sempre più difficile, anche per la qualità sempre più alta delle email di accompagnamento di questi attacchi).

Vedo che anche l'attacco BEC (Business email compromise) è molto diffuso e devo dire che in questi anni l'ho sempre sottovalutato, ma nel 2020 un paio di miei clienti ne sono rimasti vittima e quindi sbagliavo. Questo mi impone di proporre alle organizzazioni per cui lavoro qualche forma di formazione su questo tema (accetto suggerimenti). Ed ecco quindi che già questo rapporto Clusit si è dimostrato per me molto utile.

Ho trovato anche molto interessante lo speciale sulla supply chain security, altro argomento a mio avviso o sottovalutato o trattato molto male (vedo ancora troppi questionari inutili che girano, come se potessero risolvere la situazione).

Io ho segnalato gli argomenti che a me hanno interessato maggiormente, ma sono sicuro che ciascuno troverà pane per i suoi denti e quindi ne raccomando la lettura.

EN 50518:2020 per i centri di monitoraggio

Monica Perego (Idraulici della privacy) mi ha segnalato l'esistenza della UNI CEI EN 50518:2020 dal titolo "Centro di monitoraggio e di ricezione di allarme":
- http://store.uni.com/catalogo/uni-cei-en-50518-2020/.

E' interessante perché propone requisiti per centri di due categorie: una più robusta (la categoria I) e una meno (la categoria II).

Lo standard permette di certificare questi centri come prodotto, servizio o processo (ISO/IEC 17065).

La versione in inglese (EN 50518:2019 "Monitoring and Alarm Receiving Centre"):
- https://www.cenelec.eu/dyn/www/f?p=104:110:2529540743028801::::FSP_ORG_ID,FSP_PROJECT,FSP_LANG_ID:1257171,46163,25.

Illegale usare un fornitore di servizi IT USA senza ulteriori analisi

Da una segnalazione di Pierfrancesco Maistrello (con supporto di Biagio Lammoglia) degli Idraulici della privacy, segnalo questa notizia.

L'Autorità per la Protezione dei Dati bavarese (BayLDA) ha ritenuto che l'uso dello strumento di newsletter Mailchimp da parte di una società tedesca illegale in quanto Mailchimp potrebbe qualificarsi come "fornitore di servizi di comunicazione elettronica" soggetto alla legge di sorveglianza degli Stati Uniti.

Attenzione che il trasferimento era basato sulle clausole contrattuali tipo (standard contractual clauses, SCC), ma l'azienda non aveva valutato se erano necessarie ulteriori misure per assicurare la protezione dei dati dalla sorveglianza USA.

Una sintesi in inglese:
- https://gdprhub.eu/index.php?title=BayLDA_-_LDA-1085.1-12159/20-IDV.

Questo varrebbe un approfondimento. Infatti dice che le SCC sono insufficienti (e già si evinceva dalle linee guida EDPB). Ma un DPO o consulente medio (e magari mediocre come me), come fa a fare analisi approfondite sulla possibilità che i dati siano visti dalle agenzie di sorveglianza statunitensi? e quali misure potrebbe mai mettere in campo?

Perché allora tanto vale dire che, per le PMI, è vietato trasferire i dati negli USA in tutti i casi, visto che non possono permettersi valutazioni significative.

Poi ancora, mi pare che si limiti a una società usa con dati negli USA. Chissà se si estende a società USA con dati in EU?

Contributi e segnalazioni sono ben accetti.

Caso di SIM swap

Franco Vincenzo Ferrari di DNV mi ha segnalato questa notizia:
- https://www.infosec.news/2021/03/19/news/campanello-di-allarme/sapete-che-intesa-sanpaolo-ha-restituito-77-000-euro-ad-una-vittima-di-sim-swap/.

In breve, un cliente di Intesa Sanpaolo è stato vittima di un attacco SIM swap (un tizio ottiene una SIM sostitutiva al posto del legittimo intestatario) e successivamente di prelievi fraudolenti dal proprio conto bancario.

La cosa buffa, da quello che capisco, è che Intesa Sanpaolo ha risarcito il cliente pur non avendo una reale colpa per l'attacco, visto che è stato un centro TIM a consegnare una SIM senza i necessari controlli.

Attenzione che oggi, poi, le banche stanno sostituendo gli SMS con specifiche app, che hanno maggiori livelli di sicurezza, almeno allo stato attuale delle conoscenze, visto che la loro attivazione richiede una password.

Come sminuire il valore delle certificazioni

In questi giorni mi sono arrivate due segnalazioni sulle certificazioni. Allora provo a scrivere due righe in merito (temo di aver inserito qualche inesattezza, ma la sostanza è questa).

La prima me l'ha girata Fabio Guasconi di BlackSwan riguarda la certificazione ISO/IEC 27037:
- https://www.csqa.it/Sicurezza-ICT/News/Digital-Evidence-ISO-IEC-27037,-CSQA-rilascia-il-p.

In realtà ci sono anche molti altri casi e il problema non è CSQA, che, conoscendoli, hanno sicuramente fatto il loro lavoro con scrupolo e correttezza, ma di Accredia, che deciso di inventarsi delle "certificazioni estese" rispetto alla ISO/IEC 27001. Alcune di queste estensioni sono previste da standard come le ISO/IEC 27017 e ISO/IEC 27018, che hanno una parte di controlli scritti apposta per integrare una Dichiarazione di applicabilità già prevista dalla ISO/IEC 27001. Purtroppo hanno deciso di estendere questo meccanismo per tutti gli standard della famiglia ISO/IEC 27000, anche se non scritti con quell'intenzione e quindi usati e interpretati male.

Accredia ha fatto questo perché alcuni fantasisti avevano chiesto, in bandi di gara, certificazioni inesistenti come sulla ISO/IEC 27035. Però, così facendo, Accredia non ha fatto un buon lavoro di regolamentazione del mercato, visto che avalla un uso scorretto delle linee guida che, appunto, sono state scritte con uno spirito diverso da quello previsto per uno standard di requisiti.

Se si ritiene necessario uno standard di requisiti per i laboratori di analisi forense, allora sarebbe opportuno fare in modo che venga preparato ed elaborato (magari inizialmente con il supporto di UNI e UNINFO per poi essere presentato a livello internazionale), non inventarsi ciofeche che sembrano confermare il mito degli italiani fantasiosi (anche a sproposito).

Ma Accredia non è nuova a certi colpi di fantasia, come abbiamo visto con il regolamento sulla ISO/IEC 27701 (che verrà cambiato presto, con l'uscita della ISO/IEC 27006-2) e altri requisiti bizzarri quando richiede competenze ITIL a auditor di sicurezza (che è sempre bene avere, ma non obbligatoriamente).

La seconda me l'ha girata Paolo Sferlazza di Gerico e riguarda le certificazioni personali:
- https://www.skillfront.com/ISO-IEC-27001-Information-Security-Lead-Auditor.

Questi almeno sono svizzeri. Si sono inventati i certificati auditor e lead auditor ISO/IEC 27001 "veloci": con 70 Euro ti danno un libretto di 63 pagine (non l'ho visto, sarà anche fatto benissimo) e un audio libro di 58 minuti e poi ti puoi fare comodamente a casa l'esame con 40 domande a scelta multipla.

Io sono convinto che sia un fastidio per alcuni farsi un corso di 5 giornate su una materia che, magari, già conoscono. Io mi sono trovato in condizioni simili con la ISO 22301 (in questo caso ho fatto l'esame del The BCI). Però ridursi a un questionario di 40 domande (con rimborso se non si passa!) squalifica prima di tutto il professionista che accetta questa offerta.

Chi chiede i "certificati LA ISO/IEC 27001" dovrebbe innanzi tutto chiedersi se sono utili quando si cerca un consulente. Poi dovrebbe richiederli emessi da organismi accreditati dagli enti previsti dal Regolamento europeo 765 del 2008 (a questo proposito, il sito di SkillFront dice che sono accreditati, ma non si capisce da chi e, anzi, confonde un po' le cose mettendo la parola "accreditamento" vicino a un "accreditamento" svizzero che però è equivalente alla nostra registrazione di un'azienda alla  Camera di commercio).

Io continuo a pensare che dobbiamo chiedere il rispetto delle regole e ad Accredia di svolgere gli opportuni controlli (visto che anche io pago Accredia, essendo iscritto a due registri di persone certificate e accreditati proprio da Accredia), però dobbiamo anche pensare che non vale la pena competere con questi soggetti. Fatte le dovute proporzioni, è come se la Ferrari volesse competere con la Tata. Io non posso equipararmi alla Ferrari e non voglio offendere la Tata, però spero di aver reso l'idea.

Sulle sanzioni del Garante

Pierfrancesco Maistrello mi ha segnalato questo intervento di Guido Scorza, membro del Garante privacy:
- https://www.youtube.com/watch?v=LEv1Z_IBk1k.

Me lo ha segnalato soprattutto perché dice che l'Italia è il paese UE con le sanzioni più alte e, contemporaneamente, quello con meno notifiche di violazioni. L'analisi è che i titolari si astengono dal notificare, pensando di farla franca. Questo però comporta che l'autorità sia costretta, in molti casi, a scavare per recuperare informazioni, cosa che comporta il reperimento di una bella quantità di informazioni non sempre a vantaggio del titolare.

Di fatto, senza dirlo palesemente, suggerisce a tutti di essere onesti in ciò che si notifica, tenendo conto che spesso loro sono informati ("dai giornali, ma anche via whatsapp…") di certe situazioni.

Io però dico che forse si potrebbe ragionare in altro modo, ossia che proprio le sanzioni elevate (più elevate che negli altri Paesi) sconsigliano ai titolari di segnalare le violazioni, tanto più che, come ho già segnalato in precedenza, i provvedimenti di sanzione fanno emergere un approccio basato sul principio "se c'è stata violazione, vuol dire che le misure non sono adeguate e quindi sei in difetto".

Io ovviamente non ho tutti i dati e forse i provvedimenti non chiariscono tutte le analisi fatte e forse il rapporto tra causa ed effetto (ossia che le mancate violazioni portano a sanzioni più elevate) è proprio quello indicato da Scorza e non viceversa (ossia che le sanzioni elevati portano a meno sanzioni). Però il dubbio mi rimane.

Libro "Intelligenza artificiale e sicurezza"

Il 18 sarà disponibile il libro "Intelligenza artificiale e sicurezza" della Community for Security del Clusit:
- https://iasecurity.clusit.it/.

Io ho avuto l'opportunità e il privilegio di fare da editor, ossia di consolidare i contributi ricevuti e precedentemente ottimamente organizzati dai team leader. Lo dico perché all'inizio ero completamente ignorante in materia di intelligenza artificiale (a parte una certa conoscenza di Hal 9000 e delle tre leggi della robotica di Asimov) e ho avuto la possibilità di poter chiedere chiarimenti agli autori (tutti validissimi) mano a mano che non capivo qualcosa.

Spero quindi di essere riuscito a limare il testo in modo che possa essere utile ai principianti. Sono anche sicuro che sarà utile a chi conosce già l'intelligenza artificiale, visto che gli autori sono di altissimo livello e il testo è stato riesaminato da persone molto preparate sulla materia.

Io personalmente ho già avuto modo di verificare i benefici personali che ho avuto da questo lavoro. Sono infatti riuscito a seguire alcuni ragionamenti sull'intelligenza artificiale senza sentirmi perso.

Sono grato a tutti quelli che hanno partecipato a questo lavoro, coordinati dal bravissimo Alessandro Vallega di P4I, per l'opportunità non solo di imparare, ma anche e soprattutto di potermi confrontare con persone (non solo professionisti) eccezionali. Per fare un esempio: è stato bello assistere alla neo-paternità di un partecipante.

Security Summit 2021

Dal 16 al 18 marzo ci sarà il Security summit:
- https://securitysummit.it/eventi/2021-milano/agenda.

Io terrò un fugace intervento, insieme ad altri, sullo stato delle norme internazionali:
- https://securitysummit.it/eventi/2021-milano/sessioni/tutte-le-novita-delle-norme-internazionali-in-arrivo-nel-2021-su-dati-personali-iso-iec-27002-pec-e-iot.

Ma vale la pena fare un giro in tutte le sessioni.

Multa per non aver nominato il responsabile del trattamento

La Regione Lazio è stata multata per 75.000 Euro per non aver designato un fornitore esterno (contact center) come responsabile del trattamento dei dati:
- https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9542113.

Molte organizzazioni sono indietro relativamente a questi adempimenti (e altre si ostinano a "nominare" come responsabile del trattamento il legale rappresentante e non la società) e forse questa ordinanza smuoverà qualcosa.

Incendio al data center di OVH a Strasburgo

Sandro Sanna mi ha segnalato la notizia dell'incendio presso il data center di OVH a Strasburgo:
- https://www.ilmattino.it/primopiano/esteri/strasburgo_data_center_ovh_incendio_cosa_e_successo_ultime_notizie_news-5821804.html.

Anche Serena Giugni di Register me l'ha segnalata quasi in contemporanea, però con un articolo in inglese:
- https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-data-center-sbg2.

Con le notizie a disposizione, penso solo che chi si appoggia a questi servizi cloud non deve mai dare per scontato il servizio di disaster recovery. Ma questa è una cosa che diciamo da molto tempo.

Nota amena: questo evento mi è stato segnalato mentre stavo tenendo un corso sulla ISO 22301, la norma sui sistemi di gestione per la continuità operativa.

Perimetro di sicurezza: decreto sugli incidenti (errata corrige)

Avevo segnalato la bozza del DPCM per la comunicazione degli incidenti da parte delle organizzazioni che rientrano nel perimetro di sicurezza nazionale:
- http://blog.cesaregallotti.it/2021/02/perimetro-di-sicurezza-decreto-sugli.html.

Giancarlo Caroti di Neumus mi segnala un errore dove dico che lo schema di DPCM richiede ai soggetti inclusi nel perimetro di "adottare le misure minime di sicurezza già previste da AgID".

Giancarlo mi fa notare che le "misure richieste non sono quelle minime di AgID ma provengono dalle Linee Guida emesse dal Comitato che riunisce le Autorità NIS (che in base all'art 12 del DL 65/2018 possono definire specifiche misure di sicurezza), che ha condiviso l'opportunità di utilizzare il Framework Nazionale di Cyber Security (Versione 2.0 Febbraio 2019) predisposto dal CINI a sua volta ispirato al CS Framework NIST 2014, come base di riferimento.

Si tratta essenzialmente di meno della metà dei controlli proposti nel FNCS CINI, cioè 47 subcategorie sul totale delle 116 (che a loro volta sono 8 in più del CSF NIST 2014). Certamente però molte misure si mappano agevolmente sui controlli che AgID ha stabilito nel 2017".

Ringrazio Giancarlo per la precisazione e mi scuso con i miei lettori.

Pubblicata la ISO 22300

E' stata pubblicata la "ISO 22300:2021 Security and resilience — Vocabulary":
- https://www.iso.org/standard/77008.html.

Il titolo dice già tutto sul suo contenuto. Essa sostituisce la versione del 2018.

18 marzo 2021: Presentazione sulle novità delle norme internazionali

Il 18 marzo 2021, nell'ambito del Security Summit, parteciperò alla presentazione "Tutte le novità delle norme internazionali in arrivo nel 2021 su: dati personali, ISO/IEC 27002, PEC e IoT":
- https://securitysummit.it/eventi/2021-milano/sessioni/tutte-le-novita-delle-norme-internazionali-in-arrivo-nel-2021-su-dati-personali-iso-iec-27002-pec-e-iot.

Avremo un'ora per parlare molte cose. Ce la faremo!

Cosa prevede la nuova ISO/IEC 27002

Ho scritto questo articolo dal titolo "Sicurezza delle informazioni, cosa prevede la nuova ISO/IEC 27002/2021":
- https://www.key4biz.it/sicurezza-delle-informazioni-cosa-prevede-la-nuova-iso-iec-27002-2021/348311/.

Nel titolo c'è un refuso e ho chiesto di correggerlo. Spero succeda.

Tra l'altro, il 18 marzo, nell'ambito del Security Summit, presenterò molto brevemente le novità della ISO/IEC 27002 (parteciperà anche Fabio Guasconi che quindi potrà dare ulteriori spunti).

Pubblicata la ISO/IEC 27006-2 per le certificazioni ISO/IEC 27701 (PIMS)

E' stata pubblicata la ISO/IEC TS 27006-2 "Requirements for bodies providing audit and certification of information security management systems — Part 2: Privacy information management systems":
- https://www.iso.org/standard/71676.html.

Di questa norma ho già accennato in precedenza. Essa regolamenta le certificazioni dei sistemi di gestione per la privacy rispetto alla norma ISO/IEC 27701.

Ricordo ancora che questa certificazione non soddisfa quanto previsto dagli articoli 42 e 43 del GDPR, ma è comunque una "buona" certificazione.

Evito di ripetere cose già dette e rimando a un articolo che avevo scritto insieme ad Andrea Caccia e Fabio Guasconi a gennaio 2020 ma ancora attuale:
- https://www.cybersecurity360.it/soluzioni-aziendali/gdpr-e-certificazioni-tutto-sulla-norma-iso-iec-27701/.

Personalmente spero che Accredia si allinei al più presto a questa norma, mettendo fine allo schema attuale, visto che non ne apprezzo alcune scelte.

Elementi particolarmente significativi:
- stabilito il calcolo delle giornate di audit (anche se il metodo è incompleto perché non considera il caso in cui l'ambito ISO/IEC 27701 sia un sottoinsieme di quello ISO/IEC 27001);
- indicate le competenze degli auditor e del gruppo di audit;
- specificato come deve essere il certificato ISO/IEC 27701 (che deve essere a sé stante, anche se collegato a un certificato ISO/IEC 27001).

Storia delle norme di sicurezza informatica (molto breve)

Mi sono divertito a scrivere una brevissima storia delle norme di sicurezza informatica:
- https://www.key4biz.it/storia-delle-norme-degli-standard-e-delle-linee-guida-di-sicurezza-informatica/346992/.

L'ho impostata facendo riferimento al diverso livello di prescrittività delle norme nel tempo.

L'articolo riprende e in parte approfondisce il mio intervento al Dig.eat 2021.

3 violazioni di dati personali in strutture sanitarie e problemi vari

La newsletter del Garante privacy del 19 febbraio 2021 riporta la notizia "Data breach sanitari, il Garante privacy sanziona tre strutture":
- https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9544567.

In due casi, un invio cartaceo è stato indirizzato alla persona sbagliata, mentre nel terzo caso un'infermiera aveva contattato i familiari di una paziente, nonostante questa avesse richiesto di non farlo.

Il terzo caso è abbastanza semplice da capire: la richiesta della paziente non era stata archiviata in modo opportuno e la struttura sanitaria non aveva ben stabilito come gestire questo tipo di richieste in modo che il personale non faccia errori (p.e. con maschere che ricordano le opzioni indicate dai pazienti oppure cancellando i numeri di telefono non più dichiarati accettabili dai pazienti).

Gli altri due casi sono invece di difficile comprensione. I provvedimenti indicano che "sono ricostruite le dinamiche dell'accaduto, analizzate le cause e definite le azioni correttive", ma io non e trovo traccia. Certamente i provvedimenti non sono sempre il posto dove trovare queste informazioni, ma così ho avuto l'idea di una giustizia un po' cieca, che non ammette l'errore.

Infatti il GDPR non richiede che non vengano fatti errori, ma che vengano valutati i rischi privacy. I provvedimenti non specificano niente in merito alla valutazione del rischio delle aziende ospedialiere. E qui si palesa lo scenario peggiore quando si parla di valutazione del rischio, ossia l'affermazione (scorretta) secondo cui "se c'è stato un incidente, vuol dire che la valutazione del rischio non era adeguata".

Dispiace che si sia arrivati a questo. Così la valutazione del rischio rimarrà sempre più un esercizio formale (utile solo a qualche auditor o consulenti per lanciarsi in noiosissime disqusizioni; l'ultima lezione che ho ricevuto, in un'azienda di 5 persone, riguardava i rischi inerenti, correnti, attesi e residui).

Spero che la rotta cambi, ma non credo che succederà in tempi brevi: l'approccio basato sul rischio è bello da raccomandare e da sbandierare, ma è difficile da capire e accettare fino in fondo.

Pubblicazioni ENISA per TSP

Franco Ferrari di DNV mi ha segnalato la recente pubblicazione (16 febbraio) di nuovi documenti da parte di ENISA, significativi per i TSP (e forse non solo per loro).

Security Framework for Trust Providers
- https://www.enisa.europa.eu/publications/security-framework-for-trust-providers/.

Security Framework for Qualified Trust Providers
- https://www.enisa.europa.eu/publications/security-framework-for-qualified-trust-providers.

Remote ID Proofing
- https://www.enisa.europa.eu/publications/enisa-report-remote-id-proofing.

Assessment of Qualified Trust Service Providers
- https://www.enisa.europa.eu/publications/assessment-of-qualified-trust-service-providers/.

Recommendations for QTSPs based on Standards
- https://www.enisa.europa.eu/publications/reccomendations-for-qtsps-based-on-standards/.

Me li dovrò studiare per bene, ma sono sicuro che siano estremamente validi.

Purtroppo ENISA ha un sito web che non aiuta a trovare i documenti: la pagina "Publications" non evidenzia questi nuovi documenti e, in realtà, si concentra sui rapporti, sui documenti interni e altra roba non molto importante per gli altri. Poi ha etichette e argomenti (topic) non aggiornati alle attuali esigenze. Insomma, la situazione è molto difficile e ritengo che sia un peccato vista la qualità della documentazione di ENISA.

Disponibili gli interventi di DIG.eat 2021

Segnalo che si è chiusa la manifestazione DIG.eat 2021.

Io ho tenuto un intervento, ma gli argomenti trattati sono molto vari e interessanti. Tutti gli interventi sono disponibili al pubblico e raccomando a tutti di guardare se ci sono cose di interesse:
- https://anorc.eu/attivita/il-netflix-della-cultura-digitale-chiuso-il-dig-eat-2021-la-piattaforma-offrira-contenuti-gratis-e-on-demand.

Il difetto è che è necessario registrarsi per poter accedere ai contenuti. Però ne vale la pena.

Linee guida EDPB sulla gestione degli incidenti

L'EDPB (la commissione dei garanti privacy europei) ha pubblicato le "Guidelines 01/2021 on Examples regarding Data Breach Notification" (grazie a Giancarlo Caroti di Neumus che me le aveva inoltrate qualche giorno fa):
- https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2021/guidelines-012021-examples-regarding-data-breach_en.

Per ora sono solo in inglese.

Non dicono nulla di nuovo a chi si occupa di privacy e sicurezza delle informazioni. Ma... lo dicono bene.

Innanzi tutto sono presentati 18 casi di incidente. Essi possono essere causati da alcuni attacchi (ransomware, intrusione in un sito web, copia di dati da parte di un interno, accesso non autorizzato da parte di un interno a causa di un errore di configurazione, perdita o furto di dispositivi IT, perdita o furto di documenti cartacei, invio di email o posta cartacea a destinatari sbagliati, furto di identità con attacco di social engineering, riconfigurazione malevola di un server di posta). Già qui abbiamo una sorta di lista di minacce da considerare perché significative.

Poi sono anche elencate le misure di sicurezza preventive raccomandate. Ripeto: nulla di nuovo, ma messo per bene.

Inoltre l'EDPB raccomanda la redazione di un "Manuale per gestire gli incidenti". E proprio il documento stesso, se utilizzato opportunamente, fornisce la base per una prima versione di questo manuale (proprio prendendo i casi riportati e personalizzando i relativi processi di "mitigazione e obblighi").

I casi sono accompagnati anche da considerazioni in merito alla necessità di notificare all'autorità garante e agli interessati l'evento.

Finalmente, dopo tantissimi documenti fumosi, che raccomandano le "solite" misure di sicurezza, un documento facilmente leggibile e pratico.

Mio intervento il 18 febbraio 2021

Interverrò, per un tempo brevissimo con qualche riflessione sulla valutazione del rischio, il 18 febbraio alle 14.30:
- https://www.linkedin.com/posts/coretech-s-r-l_cybersecurity-coretech-coretalks-activity-6767035215618555906-li0e.

Si parlerà di privacy e violazioni di dati personali.

Furto di dati con il lavoro da remoto

Questa notizia l'ho letta su Crypto-gram di febbraio 2021:
- https://www.schneier.com/blog/archives/2021/01/dutch-insider-attack-on-covid-19-data.html.

In breve: due persone sono state arrestate nei Paesi Bassi perché hanno venduto dati dai sistemi del Ministero della salute. Li raccoglievano scattando foto al proprio schermo.

Ovviamente questo sarebbe stato immediatamente rilevato in caso di lavoro in un ufficio con altri colleghi a guardare. Quindi questo caso può permetterci di considerare questa minaccia.

Attacco a un impianto idrico in Florida

Il SANS NewsBites segnala la notizia di un attacco a un impianto di trattamento dell'acqua in Florida. Uno degli articoli suggeriti è questo:
- https://www.zdnet.com/article/following-oldsmar-attack-fbi-warns-about-using-teamviewer-and-windows-7/.

Sembra che gli attaccanti abbiano sfruttato una cattiva configurazione di TeamViewer, usato dal personale dell'impianto per accedere ai sistemi con un'unica password condivisa. Nell'impianto erano usati anche dei pc Windows 7, ma forse non c'entrano con l'attacco.

Riassumo i commenti degli editor del SANS NewsBites perché mi sembrano decisamente interessanti. Li trovate al completo qui:
- https://www.sans.org/newsletters/newsbites/xxiii/12.

Ecco i commenti da me selezionati.
- Le applicazioni per il controllo remoto, come TeamViewer, dovrebbero essere configurati con credenziali personali per ciascun utente.
- Gli accessi da Internet dovrebbero basarsi sull'autenticazione a più fattori (TeamViewer lo permette e permette anche l'integrazione con altri sistemi di SSO).
- Se, nell'ambito degli impianti industriali, non è possibile aggiornare vecchi sistemi operativi (come Windows 7) allora questi vanno protetti con firewall.

Nulla di innovativo. Le misure da applicare sono sempre le stesse: qualcuno non le applica e comunque ripetercele non fa male.

PS: mi viene da pensare che è ormai quasi un anno che ci ripetiamo di mettere la mascherina. E' vero che inizialmente non c'erano le mascherine, ma adesso ancora troppi pensano di poterne fare a meno. Chi si occupa di sicurezza (delle informazioni, informatica, delle persone, eccetera) non può che ritrovare la ripetizione degli errori e delle superficialità.

Patent box

Fabrizio Monteleone del DNV Italia mi ha segnalato le agevolazioni fiscali dette "Patent box":
- https://www.mise.gov.it/index.php/it/incentivi/impresa/patent-box.

Le imprese possono avere agevolazioni fiscali per l'utilizzo di determinati beni immateriali (software protetto da copyright, brevetti industriali, disegni e modelli, processi, formule e informazioni relativi a esperienze acquisite nel campo industriale, commerciale o scientifico giuridicamente tutelabili). Questi beni devono essere dichiarati all'Agenzia delle entrate.

Io non capisco quasi niente di fiscalità, però mi pare di capire che, nel caso una valutazione del rischio dovesse considerare questi beni immateriali, essa dovrà essere in qualche modo allineata a quanto dichiarato all'Agenzia delle entrate.

Perimetro di sicurezza: decreto sugli incidenti

Del provvedimento in merito al perimetro di sicurezza nazionale avevo scritto a suo tempo:
- http://blog.cesaregallotti.it/2019/09/perimetro-di-sicurezza-nazionale.html.

Ora è in discussione il DPCM per la comunicazione degli incidenti da parte delle organizzazioni che rientrano nel perimetro. La bozza ("schema") è reperibile sul sito della Camera:
- https://www.camera.it/leg18/682?atto=240&tipoAtto=Atto&idLegislatura=18&tab=1#inizio.

Ringrazio Giancarlo Caroti per la segnalazione.

Non mi piace annunciare provvedimenti in bozza (e infatti non lo faccio quasi mai, nonostante ne riceva alcune volte notizia), ma questo merita alcune brevi considerazioni:
- acquista importanza lo CSIRT nazionale, a cui vanno comunicati gli incidenti;
- i tempi di comunicazione sono strettissimi e sono di un'ora per gli incidenti più gravi e 6 ore per quelli meno gravi; forse eccessivamente brevi per un'organizzazione che sarà impegnata nella loro chiusura;
- non viene detto da dove è stata ricavata la tassonomia degli incidente in allegato A ed è un peccato, visto che un riferimento autorevole ed esplicito era auspicabile;
- mi chiedo come questa tassonomia si integri con quella di ENISA per i fornitori di servizi eIDAS (https://www.enisa.europa.eu/publications/article19-incident-reporting-framework); non vorrei che troppe tassonomie tra loro scollegate facciano più
male che bene;
- è richiesto che le informazioni sugli incidenti vengano comunicate a molti
soggetti e penso che questa diffusione di informazioni sia rischiosa (anche
se l'allegato C specifica le misure di sicurezza da prevedere per queste
informazioni, bisogna dire che sono talmente generica da non essere
significative);
- Il DPCM richiede anche esplicitamente ai soggetti inclusi nel perimetro di
adottare le misure minime di sicurezza già previste da AgID.

PS: non annuncio più provvedimenti in bozza da quando, in epoche
preistoriche, avevo annunciato la morte del DPS, poi annullata, e
l'inserimento della privacy nel D. Lgs. 231, poi non avvenuto. Inoltre le
bozze sono spesso modificate (come ha dimostrato il GDPR). Infine, i
commenti possono aspettare l'approvazione definitiva dei provvedimenti,
visto che sono sempre previsti dei tempi di adozione che lasciano il tempo
anche per queste cose.

"Un piccolo libro sulla privacy, il GDPR e come attuarlo" e beneficenza

Pubblicizzando il libro degli Idraulici della privacy "Un piccolo libro sulla privacy, il GDPR e come attuarlo", avevo detto che i ricavati sarebbero andati in beneficenza.

Mi sembra giusto dire come sono andate le cose.

Innanzi tutto abbiamo pubblicato la versione digitale su Streetlib e quella cartacea prima su Lulu e poi su Youcanprint (distribuisce in più posti rispetto a Lulu). Ovviamente non abbiamo potere contrattuale con queste piattaforme che quindi si sono tenute il loro margine.

In tutto al 31 gennaio abbiamo ricavato 1133 Euro. Metà è andata alla Fondazione Meyer (https://donazioni.fondazionemeyer.it/) e metà alla Parrocchia di San Stanislao a Roma che si occupa del supporto alimentare alle famiglie in difficoltà (soprattutto adesso con le difficoltà legate all'emergenza COVID).

Grazie a quanti hanno sostenuto, anche promuovendola, l'iniziativa.

CSA Cloud Controls Matrix v4

La Cloud security alliance ha pubblicato il 20 gennaio 2021 la versione 4 della sua Cloud Controls Matrix v4:
- https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4/.

Ho lavorato sulla versione 3 e l'ho trovata in alcuni punti non chiara, in altri inutilmente ripetitiva e in altri ancora (la maggior parte) utilissima e molto significativa. Non ho ancora letto la versione 4 e quindi non mi pronuncio.

Penso che, al di là dei suoi difetti, sia un documento fondamentale per chi si occupa di sicurezza informatica. Infatti è di alta qualità, autorevole e ampiamente riconosciuto. Oltre a ciò, su di esso si basa il porgramma STAR, una sorta di certificazione dei servizi cloud.

Ringrazio Antonio Salis di Engineering per avermi segnalato la novità.

Antonio mi segnala che hanno anche pubblicato due ulteriori documenti:
- Enterprise Architecture CCM Mapping (sulla versione 3.0.1): https://cloudsecurityalliance.org/artifacts/enterprise-architecture-ccm-v301-mapping;
- Enterprise Architecture CCM Shared Responsibility Model:
https://cloudsecurityalliance.org/artifacts/enterprise-architecture-ccm-shared-responsibility-model/.

Cito la email di Antonio Salis: "Questi propongono una mappatura dei controlli CCM secondo un modello di responsabilità condivisa per IaaS, PaaS e SaaS. Vorrebbero dare una vista delle responsabilità lato cloud con il dominio di controllo specifico (per il cloud provider o per il cloud user). Forse per evitare di aggiungere altre colonne al CCM e renderlo ancor più difficile da consultare, hanno gemmato due documenti, ma il risultato non è un esempio di chiarezza". Condivido.

Sugli schemi di certificazione per GDPR

Fabio Guasconi ha tenuto un interessante webinar il 12 gennaio per il Clusit e Osservatori (ringrazio poi Franco Vincenzo Ferrari di DNV GL per avermelo ricordato):
- https://www.osservatori.net/it/eventi/on-demand/webinar/isoiec-27701-certificazione-gdpr-approccio-oggi-domani-webinar.

L'evento è a pagamento. Io mi permetto solo di segnalare due cose che mi erano sfuggite sui lavori di standardizzazione per gli schemi di certificazioni previsti dal GDPR.

In poche parole, a livello CEN, ossia europeo, sono in discussione due standard per la certificazione prevista dal GDPR:
- uno basato sulla ISO/IEC 27701, che prevede un suo "raffinamento" per poterla usare con la ISO/IEC 17065 (come previsto dal GDPR) in ambito europeo;
- uno che prevede un nuovo standard basato sull'italiana PdR 43-2, non più limitata all'ambito ICT e più orientata alle PMI.

La previsione è di finire i lavori entro fine 2021. Poi, ovviamente, bisognerà vedere come saranno recepiti dall'EDPB, visto che questi sarebbero gli standard per le organizzazioni da certificare, ma vanno ancora creati gli schemi di certificazione con le caratteristiche degli organismi di certificazione e le modalità per verificare se gli organismi hanno le caratteristiche previste, le competenze richieste agli auditor, il calcolo dei tempi di audit, eccetera.

Microsoft Teams (e non solo) e la privacy

Glauco Rampogna degli Idraulici della privacy mi ha segnalato questo articolo dal titolo, un po' lungo, "I looked at all the ways Microsoft Teams tracks users and my head is spinning":
- https://www.zdnet.com/article/i-looked-at-all-the-ways-microsoft-teams-tracks-users-and-my-head-is-spinning/.

L'articolo è forse troppo emotivo, ma pone due problemi importanti. Il primo è quello della privacy e del controllo a distanza dei lavoratori. Dovrei capire meglio se e come le funzionalità di monitoraggio possano essere messe a disposizione dei manager, però dovrò approfondire la questione, visti gli impatti sulla privacy.

Il secondo tema è quello delle tecniche gestionali, che vorrebbero, erroneamente, essere quantitative. Come si chiede l'autore, il numero di messaggi inviati è veramente sintomo di una buona produttività (e, aggiungerei, non di inutile spreco di risorse)? Purtroppo il mito del management by objective continua a sopravvivere, nonostante fosse già stato criticato negli anni Quaranta da Deming (non un tizio qualsiasi).

Ovviamente le stesse considerazioni valgono per tutti questi strumenti che da una parte aiutano i lavoratori e le organizzazioni, ma dall'altra mettono a disposizione strumenti per controllare i lavoratori stessi.

Libro su sicurezza delle informazioni e GDPR

Chiara Ponti e Renato Castroreale pubblicheranno (a febbraio) un libro dal titolo "Il sistema integrato per la sicurezza delle informazioni ed il GDPR":
- https://www.epc.it/Prodotto/Editoria/Libri/Il-sistema-integrato-per-la-SICUREZZA-delle-INFORMAZIONI-ed-il-GDPR/4909.

Mi hanno chiesto di scrivere la presentazione e io l'ho fatto molto volentieri. Il testo, infatti, tratta di un argomento fondamentale, ossia, come dice il titolo, dell'integrazione delle attività relative alla sicurezza delle informazioni e al GDPR. Oggi sempre più organizzazioni stanno seguendo questo approccio, ma ancora troppe separano quasi completamente le due materie, spesso affidando la prima ai tecnici e la seconda ai legali, senza capire le tantissime relazioni reciproche e la necessità di avere un approccio interdisciplinare in ambedue.

A questo proposito ho ricordato come queste materie permettono di avere grandi soddisfazioni, soprattutto perché: 1) si ha l'opportunità di conoscere persone validissime e molto professionali con esperienze e competenze diverse; 2) questa diversità ci richiede di approfondire il rapporto; 3) alcune volte questo approfondimento sfocia nell'amicizia.

Concludo quindi ringraziando Chiara e Renato per avermi dato l'opportunità di riflettere su queste cose.

Password manager

Segnalo questo articolo dal titolo "Gestione delle credenziali: un'analisi comparativa dei principali strumenti di Password Management":
- https://www.ictsecuritymagazine.com/articoli/gestione-delle-credenziali-una-comparazione-tra-i-principali-strumenti-di-password-management/.

Mi accorgo di non aver mai scritto alcunché sui password manager, ma sono strumenti oggi essenziali per gestire qualunque ambiente e pertanto vanno conosciuti.

Analisi dei vulnerability scanner

Segnalo questo articolo dal titolo "I migliori scanner di vulnerabilità per valutare la sicurezza di un'applicazione Web?":
https://www.ictsecuritymagazine.com/articoli/i-migliori-scanner-di-vulnerabilita-per-valutare-la-sicurezza-di-unapplicazione-web/.

Il titolo è forse più pretenzioso di quanto è il contenuto reale dell'articolo. Però è molto interessante vedere come nessuno dei 7 strumenti di scansione delle vulnerabilità analizzati abbia identificato tutte le vulnerabilità.

Mi sembra che forse altri strumenti avrebbero potuto essere analizzati (i più noti sono Nessus e OpenVAS), ma mi sembra che l'analisi non avesse ambizioni di completezza, essendo stata condotta nell'ambito di una tesi universitaria.

Attacco a Leonardo S.p.A.

A dicembre è stato identificato un attacco a Leonardo S.p.A., azienda italiana parzialmente pubblica e presente su molti progetti, inclusi quelli di difesa.

Glauco Ramponga degli Idraulici della privacy mi ha fatto inviato un buon link:
- https://reaqta.com/2021/01/fujinama-analysis-leonardo-spa/.

Ecco il super-riassunto di Glauco, che ringrazio.
ReaQta Threat Intelligence Team ha identificato il malware utilizzato in un'operazione di esfiltrazione contro Leonardo Spa. L'analisi del malware, che hanno soprannominato Fujinama, ne evidenzia le capacità di furto ed esfiltrazione dei dati mantenendo un profilo ragionevolmente basso, nonostante la mancanza di sofisticazione, principalmente a causa del fatto che il vettore dannoso è stato installato manualmente da un insider.

Quindi il punto chiave è che si sia avverato il caso peggiore: un interno, con responsabilità nella sicurezza informatica, ha installato software dannoso nella rete che avrebbe dovuto proteggere.

Sandro Sanna mi aveva inviato un ulteriore link che riporta la notizia dell'arresto di due possibili responsabili, che avevano l'obiettivo di reperire informazioni relative ad un preciso progetto:
- https://www.startmag.it/innovazione/neuron-ecco-il-vero-bersaglio-dellattacco-hacker-a-leonardo/.

Ricordo che uno dei rischi delle valutazioni del rischio è la cosiddetta sindrome di Fort Apache: si pensa che i "cattivi" siano tutti fuori, mentre dentro ci sono solo i "buoni". Questo caso, veramente significativo, ci ricorda di stare molto attenti.

Sintesi dell'attacco SolarWinds

Per capire bene il caso SolarWinds raccomando l'articolo di Bruce Schneier:
- https://www.schneier.com/blog/archives/2020/12/russias-solarwinds-attack.html.

La prima parte descrive in modo estremamente sintetico, da uno dei più noti esperti di sicurezza informatica (che scrive anche benissimo, cosa molto rara) il caso.

La seconda parte è forse più "strategica" e per me meno interessante.

EU National capabilities assessment framework

Claudio Sartor (lo ringrazio) mi ha segnalato il "National capabilities assessment framework" di ENISA:
- https://www.enisa.europa.eu/publications/national-capabilities-assessment-framework.

Mi astengo dal commentarlo perché finora mi sono occupato di sicurezza per organizzazioni private o pubbliche, non a livello nazionale. Però credo che possa essere di interesse per molti.

In particolare, noto che il livello di maturità non è determinato dalla quantità di documentazione prodotta e questo mi sembra un approccio migliore rispetto ad altre pubblicazioni del genere.

EU Cloud Certification Scheme

Enisa ha avviato la consultazione pubblica per lo schema di certificazione di sicurezza informatica per i servizi cloud (ringrazio Giovanni Francescutti di DNV GL Business Assurance e Giancarlo Caroti di Neumus per avermelo segnalato):
- https://www.enisa.europa.eu/news/enisa-news/cloud-certification-scheme.

Ricordo brevemente che questo schema nasce per le certificazioni promosse dal Cybersecurity act europeo. Questo Regolamento prevede quindi che ENISA proponga degli schemi di certificazione per la sicurezza dei prodotti e servizi informatici. Alcuni schemi sono già attivi (il più celebre è quello noto come Common Criteria, ISO/IEC 15408), ma non sotto il cappello del Cybersecurity act. Ad ora l'unico schema candidato e ufficiale e proprio questo per i servizi cloud.

Va detto che lo schema non necessariamente si baserà sul modello già noto per le certificazioni dei sistemi di gestione (ISO/IEC 27001, per intenderci), ma richiede che ogni Stato membro indichi una NCCA (National cybersecurity certification authority). Non mi risulta che in Italia sia stata ancora indicata. Se però qualcuno ha notizie più aggiornate, gli chiedo di farmele avere.

Per quanto riguarda questa bozza, ho analizzato soprattutto l'Annex A, con i requisiti che devono rispettare i CSP (cloud service provider) che intendono certificarsi. In generale mi sembra scritto male, con molte imprecisioni, ripetizioni e anche cose decisamente discutibili. Vale comunque la pena leggerselo e studiarselo per avere una buona idea dei requisiti che dovrebbero rispettare i CSP.

Spero poi che la versione finale del documento sarà molto migliore di questa bozza.

A questo proposito rimango perplesso su una consultazione pubblica di un documento che ha molti punti dichiaratamente ancora in fase di elaborazione (vedi Annex E e G).

Per quanto riguarda le modalità di verifica, ho letto le appendici senza la dovuta attenzione e quindi è meglio che mi astengo dal commentarle.

DFA Open Day 2021

Il 29 gennaio pomeriggio ci sarà il DFA Open Day:
- http://www.perfezionisti.it/open-day/dfa-open-day-2021/.

DFA è un'associazione che raccoglie consulenti, legali, esperti di privacy e tecnici di digital forensics. Ne sono presidente da 2 anni e sono molto contento di questa edizione. Spero parteciperete numerosi.

Io non tengo nessun intervento (tranne uno sconnesso balbettio che sono costretto a fare in virtù del mio ruolo): sarà molto più interessante ascoltare quelli degli altri.

Dig.eat 2021

Parteciperò al Dig.eat 2021 con una breve relazione sulla storia degli standard e della normativa in materia di sicurezza delle informazioni.

Il Dig.eat sarà dal 18 gennaio al 12 febbraio e il mio intervento sarà proprio il 18 gennaio (ore 15). In apertura, quando la gente non avrà ancora ben capito che è partita l'iniziativa.

Mi sono divertito molto a fare il messaggio di invito (ne avevo fatti 3 ed era previsto che ne selezionassero uno... invece...):
- https://www.linkedin.com/posts/anorc_digeat2021-digitalizzazione-activity-6749980650977144832-sCdZ.

Per iscriversi:
- https://anorc.eu/dig-eat/.

Difetto: per vedere il programma della manifestazione è necessario iscriversi.

Lezioni dall'attacco SolarWinds

A inizio dicembre è stato individuato un attacco verso il software SolarWinds Orion, usato per la gestione delle reti. Questo software è usato in molte realtà, in particolare presso i fornitori di servizi di sicurezza. La sua compromissione ha permesso agli attaccanti di creare backdoor presso gli utilizzatori. Sembra poi che forse altri software e servizi, non solo SolarWinds Orion, sono stati compromessi.

Il mio riassunto è molto sintetico. Questo, in inglese, è un po' più approfondito, anche se non troppo:
- https://www.darkreading.com/5-key-takeaways-from-the-solarwinds-breach/d/d-id/1339764.

L'articolo che ho segnalato permette anche di individuare utili lezioni per tutti. Infatti, quando sono venuto a conoscenza dell'attacco, ho inizialmente pensato che fosse importante, ma dimostrava solo che anche i prodotti di sicurezza possono essere anch'essi vettori di attacco, ma questo lo sapevamo già da parecchio tempo. Invece, ecco qui due delle lezioni proposte:
- gli strumenti di sicurezza e di gestione dei sistemi e della rete informatica non dovrebbero essere tutti integrati in un'unica piattaforma;
- gli ambienti di sviluppo, non solo quelli di produzione, vanno considerati critici per la sicurezza (ma anche questo lo sapevamo già).

Privacy: nuova pagina del Garante per notificare le violazioni

Il Garante lancia un nuovo servizio online per la notifica di violazioni di dati personali:
- https://servizi.gpdp.it/databreach/s/.

Interessante non solo la semplificazione della procedura (grazie al personale del Garante, che dimostra sempre più, con il passare degli anni, di sapersi interfacciare con le parti interessate), ma anche la procedura di auto-valutazione.

ENISA Artificial Intelligence Cybersecurity Challenges

ENISA ha pubblicato il documento "AI cybersecurity challenges" (grazie a Chiara Ponti degli Idraulici della privacy):
- https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges.

Non avevo mai parlato di intelligenza artificiale perché è una materia che ignoravo completamente. Adesso ne so qualcosa in più perché sto partecipando (come correttore di bozze, vista la mia incompetenza) a un libro in materia che uscirà a marzo. Così adesso ne so un pochino, almeno per evitare di annaspare quando vedo l'acronimo IA (o AI) al di fuori dei film e dei libri di fantascienza.

Devo dire, con sollievo, che gli autori della nostra pubblicazione avevano già considerato i punti presentati da ENISA. Anzi, in alcuni casi forse ENISA va troppo nei dettagli e ogni tanto si rischia di perdere di vista l'obiettivo dell'analisi. Però ci sono cose molto interessanti e ne raccomando la lettura.

GDPR e linee guida per lo sviluppo del CNIL

Pietro Calorio degli Idraulici della privacy mi ha segnalato la pubblicazione del "GDPR Guida per sviluppatori: La CNIL pubblica una GDPR guida per sviluppatori". Essa è la traduzione italiana della guida che avevo già commentato a giugno:
- http://blog.cesaregallotti.it/2020/06/gdpr-developers-guide-del-cnil.html.

Per chi volesse la versione originale in francese, in versione 1.0.1, è su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

Le recenti versioni in inglese e in italiano sono anch'esse su GitHub:
- https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0.

L'attuale versione è decisamente molto migliore di quella che avevo letto a giugno. Ancora una volta sono accennati molti elementi per la sicurezza dello sviluppo e delle applicazioni e quindi le persone interessate dovrebbero approfondirli con i link messi a disposizione. E', insomma, una lettura che raccomando.

La guida è molto concentrata sul processo di sviluppo e sulla sicurezza dell'ambiente di sviluppo, mentre i requisiti (funzionali e tecnici) da considerare per le applicazioni sono molto pochi. Speriamo nelle prossime versioni.

Webinar sulle nuove regole per i conservatori

Di conservazione e delle nuove regole pubblicate da AgID avevo parlato a suo tempo:
- http://blog.cesaregallotti.it/2020/09/nuove-linee-guida-agid-sulla-gestione.html.

Segnalo quindi questo webinar organizzato da ANORC in cui sono approfonditi alcuni aspetti:
- https://www.youtube.com/watch?v=_E-gUQS1e_M.

Segnalo in particolare il secondo intervento di Patrizia Gentili di AgID, dal minuto 44 al minuto 125, perché permette di capire le scelte fatte per le nuove regole.

Privacy e videosorveglianza: FAQ del Garante

Il Garante ha aggiornato le sue FAQ sulla videosorveglianza per adeguarle alle linee guida dell'EDPB.

Per completezza, qui segnalo l'URL della pagina del Garante sulla videosorveglianza da dove si può accedere alle FAQ (e ad altre risorse):
- https://www.garanteprivacy.it/temi/videosorveglianza.

Delle linee guida dell'EDPB avevo scritto quando furono pubblicate (febbraio 2020):
- http://blog.cesaregallotti.it/2020/02/linee-guida-edpb-su-videosorveglianza.html.

Ringrazio Franco Vincenzo Ferrari del DNV GL per la segnalazione.

ISO/IEC 27035 sugli incidenti ICT

A settembre è stata pubblicata la norma ISO/IEC 27035-3 dal titolo "Information technology — Information security incident management — Part 3: Guidelines for ICT incident response operations":
- https://www.iso.org/standard/74033.html.

Questa norma, rispetto alle altre 2 parti della ISO/IEC 27035, si concentra sulla gestione degli incidenti di tipo informatico.

Ci sono cose interessanti, per esempio sulle attività di analisi e sulle diverse possibili reazioni. Però la norma è molto confusa e gli argomenti sono organizzati malissimo, con molte ripetizioni e incongruenze. Peccato.

Privacy: sui cookie wall (seconda puntata)

Continuo a occuparmi delle modalità con cui i siti web gestiscono i cookie. Questo articolo, dal titolo "Cookie: consenso dell'interessato al legittimo interesse del Titolare" tratta della pratica, ora sempre più diffusa, di installare cookie sulla base del legittimo interesse e non del consenso:
- https://www.altalex.com/documents/news/2020/12/03/cookie-consenso-interessato-legittimo-interesse-titolare.

Io aggiungo che molti siti distribuiscono in modo a me incomprensibile le opzioni sui cookie: in parte sul consenso, in parte sul legittimo interesse. Forse per confondere l'utente o per altri motivi che non ho approfondito?

Aggiungo inoltre che, in caso di diniego del consenso, il cookie wall mi si ripresenta ogni volta che ritorno su certi siti. Cosa che non succede a chi fornisce un consenso positivo. Penso che anche questa sia una pratica scorretta.

L'articolo mi è stato segnalato da Costanza Mottino degli Idraulici della privacy e la ringrazio.

La privacy ai tempi del COVID - Un piccolo caso

Segnalo questo "piccolo" incidente per cui è stato mandato un reclamo (o una segnalazione di violazione) al Garante.

Penso sia interessante per ricordarci come la privacy richieda attenzione anche nelle cose apparentemente più semplici.

In una scuola un bambino ha segnalato la propria positività al COVID. Allora la scuola ha fatto una comunicazione in bacheca raccomandando a tutti i suoi compagni di classe di fare il tampone e fornendo indicazioni su dove andare.

Però... la circolare in bacheca riportava i destinatari: tutti gli alunni della classe, tranne il positivo!

Guida (parziale) alla privacy nel mondo

Claudio Sartor, che ringrazio, mi ha scritto quanto segue.

Ho letto il suo articolo in merito alle raccomandazioni dell'EDPB per i trasferimenti extra SEE (http://blog.cesaregallotti.it/2020/11/privacy-e-edpb-raccomandazioni-per-i.html). Sebbene al momento anche io non sia al corrente di un sito contenente "tutti i 200 Paesi del mondo con indicate le caratteristiche da considerare quando vi si vogliono esportare dati personali", segnalo il lavoro "Deloitte Asia Pacific Privacy Guide" che almeno indirizza l'area Asia Pacific (APAC):
- https://www2.deloitte.com/nz/en/pages/risk/articles/deloitte-asia-pacific-privacy-guide.html.

In effetti il documento è molto interessante, anche se forse è troppo prudente nell'esplicitare le criticità relative alla privacy e presenti nei Paesi considerati.

ENISA Guidelines for Securing the IoT

ENISA ha pubblicato nuove linee guida sulla sicurezza dell'IoT dal titolo "Guidelines for Securing the Internet of Things":
- https://www.enisa.europa.eu/publications/guidelines-for-securing-the-internet-of-things.

Introduce alcuni concetti che mancavano dalla precedente "Good practices for security of IoT: Secure Software Development Lifecycle", dedicata al solo software e che segnalai a suo tempo
(http://blog.cesaregallotti.it/2019/11/enisa-good-practices-for-security-of-iot.html). Questa guida tratta di tutti componenti dell'IoT, inclusi quelli fisici.

Commento: apprezzo molto questi lavori di ENISA. Purtroppo però l'organizzazione dei documenti di ENISA rende difficile capire i collegamenti tra loro e questo è un peccato.

Privacy e EDPB: Linee guida sulla privacy by design e by default

Mi hanno segnalato la pubblicazione della versione 2.0 delle "Guidelines 4/2019 on Article 25: Data Protection by Design and by Default":
- https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en.

La lettura è molto interessante e in qualche modo riassume efficacemente molti concetti del GDPR. Però attenzione che non si tratta di una guida alle misure di sicurezza. Queste sono trattate in modo molto sommario e con un solo esempio al punto 3.8 quando parla di integrità e riservatezza.

Un'altra cosa mi ha dato da pensare ed è il suggerimento di determinare KPI per valutare l'efficacia delle misure privacy. Qui l'EDPB, purtroppo, dà ascolto ai cattedradici e promuove KPI quantitativi e qualitativi, senza però proporne di veramente significativi. Gli esempi per i quantitativi sono: percentuali di falsi positivi e falsi negativi (senza però dire di cosa), riduzione dei reclami, riduzione dei tempi di risposta agli interessati quando esercitano i propri diritti (notare che questi KPI sono dichiarati male, visto che le "riduzioni" sono obiettivi che, inoltre, oltre un certo limite, dovrebbero diventare "mantenimento"). Gli esempi per i qualitativi sono talmente generici che non aiutano molto. Però poi arriva la vera raccomandazione appropriata e applicabile: dimostrare le ragioni per cui le misure scelte si ritengono efficaci (ossia, traduco io, presentare una valutazione del rischio).

Infine: mi fa specie vedere che anche l'EDPB fa un uso inutile e scorretto di iniziali maiuscole, soprattutto quando il GDPR, da questo punto di vista, è corretto.

Comunque sia: raccomando la lettura di queste linee guida per la loro ottima sintesi (38 pagine, inclusive di copertina e indice), il rigore, la completezza e la pragmatica. Al di là delle mie insignificanti critiche, questo è un documento esemplare.

Privacy e EDPB: raccomandazioni per i trasferimenti extra SEE

L'EDPB ha messo in consultazione pubblica le raccomandazioni sui trasferimenti dei dati personali al di fuori dello SEE: "Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data":
- https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2020/recommendations-012020-measures-supplement-transfer_en.

Innanzi tutto ricordiamoci che non è ancora un documento ufficiale, ma in consultazione pubblica.

Non tratta solo del trasferimento dei dati negli USA, ma è un'opinione più generale. E sono generali anche le raccomandazioni, tra cui quella di verificare per bene la normativa del Paese importatore, e non sono forniti strumenti semplici da consultare. Ovviamente il sogno sarebbe un sito con tutti i 200 Paesi del mondo con indicate le caratteristiche da considerare quando vi si vogliono esportare dati personali. Devo dire che siamo ancora lontanissimi da questo sogno e organi come l'EDPB dovrebbero farsi carico di queste necessità, visto che non è pensabile che migliaia di aziende (e non parlo dei DPO, le cui competenze sono troppo spesso dubbie sulle basi e quindi non possiamo aspettarci molto quando si tratta di un argomento complesso come questo) si facciano le proprie analisi di adeguatezza così come suggerite.

Grazie a Glauco Rampogna degli Idraulici della privacy per la segnalazione.

Privacy: sui cookie wall

Segnalo questo interessante video di Pietro Calorio su LinkedIn su come funzionano (male) i cookie wall:
- https://www.linkedin.com/posts/pietrocalorio_privacy-dataprotection-eprivacy-activity-6732293325866504192-j1b5.

Il video è artigianale, ma fa vedere chiaramente come sono fatti male i cookie wall. Nella migliore delle ipotesi sono estenuanti per l'utente che li rifiuta. Ne sono testimone ogni volta che vado sui siti di Amazon e molti altri perché ogni volta mi chiedono di confermare le scelte (cosa che non fanno con chi accetta i loro cookie).

Furto di dati a causa di un server AWS mal configurato

La notizia, dal SANS NewsBites del 10 novembre, è che sono stati violati 24,4 GB di dati relativi a ospiti di hotel a causa di un AWS S3 bucket mal configurato:
- https://www.websiteplanet.com/blog/prestige-soft-breach-report/.

Sul SANS ricordano che sono disponibili linee guida per configurare in modo sicuro i server sul cloud. Quello del CIS specifico per AWS:
- https://www.cisecurity.org/blog/cis-benchmarks-september-2020-update/.

La stessa Amazon mette a disposizione strumenti e linee guida per la corretta configurazione e verifica dei server:
- https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html.

Non so esattamente quale errore di configurazione sia stato sfruttato, né so se è stato frutto di distrazione o di incompetenza. Vedo però che ancora molti sottovalutano l'importanza di una corretta configurazione dei server cloud. Allora è bene ripeterlo: la configurazione iniziale dei server cloud non è ottimale per la sicurezza e quindi vanno sempre previste attività di hardening e quindi chi si occupa di questi server deve avere (o acquisire) le necessarie competenze.

Allegati nocivi per email

Mi hanno fatto notare che gli incidenti informatici registrati dovuti ad allegati nocivi alle email hanno avuto come effetto la riconfigurazione di alcuni servizi.

Un buon esempio è la pagina di Actalis che elenca gli allegati vietati per il loro servizio PEC:
- https://www.actalis.it/news-eventi/tipi-di-file-che-non-e-possibile-allegare-ad-un-messaggio-pec.aspx.

MELANI Rapporto semestrale 2020/1

Melani è la Centrale d'annuncio e d'analisi per la sicurezza dell'informazione svizzera. Ogni 6 mesi pubblica un interessantissimo rapporto con indicati eventi, minacce e raccomandazioni relativi alla sicurezza informatico. Io sono estimatore di questo rapporto che ormai da molti anni si conferma pragmatico e preciso.

E' stato pubblicato il rapporto relativo al primo semestre 2020 ed è concentrato su come l'emergenza COVID-19 sia stata sfruttata da malintenzionati:
- https://www.melani.admin.ch/melani/it/home/dokumentation/rapporti/rapporti-di-situazione/rapporto-semestrale-2020-1.html.

Il bello di questo rapporto è che parla anche di molto altro.

Multa per smantellamento scorretto di data center

Lo smantellamento scorretto di un data centre può costare caro:
- https://www.linkedin.com/posts/nicola-vanin-b03a5451_datacenter-morganstanley-rischio-activity-6720715622830944256-XjGS.

Il post non fornisce i dettagli esatti (chi ha dato la multa e quale esattamente è stata la violazione), ma sono interessanti le considerazioni: più difficile della costruzione di un data centre è il suo smantellamento perché può comportare l'interruzione imprevista di attività. Quindi, prima di procedere, è necessario inventariare correttamente le risorse e le loro dipendenze.

Il modello Emmental per valutare gli eventi

Ho trovato divertente questa vignetta che presenta il modello Emmental per la difesa da COVID-19 (i nordamericani, ahinoi, dicono "Swiss cheese"):
- https://t.co/0vFX7vaHIS.

Mi sembra una bella rappresentazione del concetto di "difesa in profondità", per cui un solo livello di protezione non è sufficiente.

Ho poi cercato di approfondire la cosa e ho trovato questo articolo:
- https://blog.enterprisetraining.com/swiss-cheese-accident-causation-model/.

Ed ecco quali sono le lezioni che fornisce il modello Emmental:
- gli incidenti sono spesso causati dalla convergenza di più fattori;
- i fattori possono essere di molti tipi, dai comportamenti scorretti dei singoli a errori organizzativi;
- fattori molto importanti sono gli "errori latenti", che rimangono dormienti fino a quando non sono attivati da errori attivi;
- gli esseri omani sono inclini agli errori e quindi richiedono sistemi ben progettati e realizzati per prevenirli e mitigarli.

Ho letto un altro articolo dal titolo "Revisiting the Swiss cheese model of accidents":
- https://www.researchgate.net/publication/285486777_Revisiting_the_Swiss_Cheese_Model_of_Accidents.

Questo propone un'idea interessante: affinché si verifichi un incidente, devono verificarsi:
- difese inadeguate;
- comportamenti scorretti;
- precursori psicologici per i comportamenti scorretti;
- carenze organizzative (line management deficencies);
- decisioni errate della Direzione.

Sarebbero da approfondire i "precursori psicologici per i comportamenti scorretti".

Concludo sperando che qualcuno faccia (e me lo faccia vedere!) un disegno altrettanto bello di quello che ho segnalato inizialmente, ma dedicato alla sicurezza delle informazioni.