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.