Autore: wp_6910267

Il gruppo Strawood, la catena di alberghi che controlla gli Sheraton, i Westin ed i St. Regis e che fa parte del megagruppo Marriott International, ha subìto un attacco informatico: sembra che siano stati sottratti tutti i dati personali che si possono sottrarre ad un albergo (dati anagrafici, numero di carta di credito, indirizzi email, ecc.). Solo che, in questo caso, stiamo parlando di un attacco persistente, almeno qualche anno, e di milioni di clienti, almeno 200.

È l’occasione giusta per inquadrare la rilevanza delle recenti Guidelines 3/2018 on the territorial scope of the GDPR poste in consultazione pubblica il 16 novembre scorso dall’EDPB. Il documento approfondisce l’art. 3 del GDPR ovvero l’ambito territoriale di applicazione del GDPR che, com’è noto, non coincide con i confini fisici dell’Unione Europea.

Le linee guida, tra le altre questioni, affronta la definizione di interessato (cioè chi ha diritto a ricevere le tutela del GDPR) che è “chiunque si trovi nell’Unione Europea”. Quindi, non solo i cittadini degli Stati Membri ma anche i turisti extra‑UE o gli immigrati, se vengono offerti loro prodotti o servizi. Questo significa, applicato al caso di Starwood, che la società aveva l’obbligo di garantire i suoi clienti applicando ai loro dati personali le prescrizioni del GDPR, a prescindere dalla sua sede legale che, a quanto pare, si trova negli Stati Uniti.

Il mondo è piccolo, soprattutto per le multinazionali.

Molte volte ci è capitato di esaltare il lavoro dell’Agenzia per l’Italia Digitale (AGID) cioè l’organismo governativo che coordina l’evoluzione tecnologica nel nostro paese.

Questa volta, però, pur apprezzando l’impegno, non possiamo esprimerci del tutto positivamente. L’occasione è la pubblicazione, di qualche giorno fa, da parte dell’AGID della “Guida tecnica all’uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni”; il documento ha il merito di sensibilizzare le organizzazioni pubbliche a misurare il “valore” del software che commissioneranno o che, comunque, hanno commissionato in passato. A questo proposito offre una serie di metriche (termine tipicamente tecnico per definire “una misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, un componente, un processo”) per misurare il software, suggerendo, per ogni indicatore, l’ambito di utilizzo più opportuno.

A partire da pagina 49 della Guida, vengono presentate alcune metriche di sicurezza (suddivise per riservatezza, integrità, ecc.): ci aiuterebbero a capire quanto possono essere efficaci i meccanismi di riduzione dei rischi integrati nel nostro software (già sviluppato o da sviluppare). Tuttavia, alla successiva pagina 50 appare una frase che dice, in sostanza: queste metriche hanno scarsa rilevanza perché sarebbe opportuno applicare i sistemi di gestione descritti dalla norma ISO 27001.

E ci mancherebbe altro!!! Magari tutte le pubbliche amministrazioni potessero permettersi la conformità alla ISO 27001… Tra l’altro le metriche suggerite derivano da un’altra norma standard ovvero la ISO 25023 e certamente due norme ISO non potranno mai essere incompatibili.

Quindi, cominciamo ad usare le metriche di sicurezza affinché il software delle pubbliche amministrazioni possa offrire la prima barriera ad eventuali eventi sfavorevoli o ad attacchi di malintenzionati.