Hotel e HotSpot WiFi

La sicurezza degli HotSpot WiFi di Hotel ed Alberghi è uno degli aspetti più trascurati nello scenario italiano.

Negli anni, siamo passati da un servizio a costo aggiuntivo ad un accessorio pressoché obbligatorio da fornire agli ospiti, a titolo gratuito; per questo, spesso non si ritiene utile investire in tale ambito, in quanto non porta utili tangibili.

Talvolta, nei nostri pernottamenti di lavoro in vari hotel, troviamo soluzioni che definire raffazzonate è eufemistico; in taluni casi, viene semplicemente consentito l’accesso alla stessa WLAN del router fornito dal provider internet, con tutta una serie di gravissimi rischi, incombenti sia a carico del gestore alberghiero che dei suoi clienti. In tale situazione, infatti, i dispositivi dei clienti non solo possono compromettere i devices dell’hotel ma anche quelli degli altri ospiti, in quanto possono comunicare tra di loro.

In relazione alla fornitura del servizio di connettività InterNet agli ospiti, sussistono varie normative e regolamenti, ivi compreso il Regolamento UE 679/2016; nella progettazione ed erogazione del servizio, occorre tener conto degli aspetti cogenti del GDPR e dei principi alla base della protezione dei dati personali, in particolare gli aspetti di minimizzazione, gestione del rischio, privacy by design – by default, misure di sicurezza e crittografia.

In relazione invece al famoso decreto Pisanu, pur essendo venuti meno gli obblighi di registrare i dati anagrafici e identificativi degli utenti e di monitorarne le sessioni InterNet, non mi sento di consigliare i proprietari di strutture alberghiere in tal senso, essendo sempre in capo ad essi la responsabilità di eventuali illeciti commessi da terzi nell’utilizzo delle proprie infrastrutture ITC.

Occorre quindi trovare “la quadratura del cerchio”; questa dovrà essere basata sulle specifiche caratteristiche della infrastruttura e delle esigenze della proprietà.


Facebook, passwords in chiaro

Giunge notizia che Facebook abbia mantenuto, per anni, milioni di password dei suoi utenti in chiaro, alla portata dei suoi dipendenti.

Nel post ci illustrano come sia importante, per Facebook, la sicurezza dei propri utenti, come essi debbano cambiare spesso la propria password, e bla bla bla.

Purtroppo la memorizzazione delle password in chiaro è una pratica difficile a morire; da essa scaturiscono enormi problemi di sicurezza a danno degli utenti, specialmente quando le stesse credenziali consentono (come avviene con Facebook) di autenticarsi ad innumerevoli servizi esterni.

Per non parlare di coloro che utilizzano sempre la stessa password.

Verifiche di Restore

Abbiamo messo in atto una fantastica procedura di backup, che salva i dati in due locazioni diverse ed inoltre nel cloud, per maggiore sicurezza.

Siamo assolutamente certi che qualunque cosa accada potremo superarla brillantemente.

Poi, un giorno, viene un consulente dataprotection e ci domanda se abbiamo mai effettuato delle simulazioni di ripristino dei sistemi, ipotizzando che i sistemi “live” siano morti e che ci siano rimasti solo i backup.

Il poveretto viene squadrato con un sorrisetto; la richiesta qualificata come eccessiva e non giustificata, e quindi nessuno si “prende la briga” di provare ad effettuare un restore (ma neanche verificare l’integrità degli archivi costituenti i vari backups).

Poi, un brutto giorno, accade quanto ipotizzato dal consulente ed assolutamente certificato dal MTBF – una semplice rottura di un hard disk, funzionante da 8 anni – e tutte le certezze vengono meno (insieme ai dati); i backups sono inservibili in quanto nessuno, in otto anni, si era mai accorto che la procedura creava degli archivi corrotti.

Un esempio di cosa può succedere, accaduto nel mese di gennaio 2019.

Continuiamo a pensare che le procedure di controllo sono tempo perso.

Il nuovo principio della “sicurezza” nel GDPR

Tra le innumerevoli disamine, valutazioni, interpretazioni e trattazioni sul Regolamento UE, ben pochi hanno “realizzato” uno dei nuovi cardini sui quale esso si basa.

La sicurezza è adesso divenuta un principio.

Art. 5 - Principi applicabili al trattamento di dati personali

1. I dati personali sono:
...
f) trattati in maniera da garantire un’adeguata sicurezza dei dati personali, compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali («integrità e riservatezza»).

Lo ripeto: “adeguata sicurezzamisure tecniche ed organizzative adeguate“; non c’è più sordo di chi non vuol sentire!

GDPR e le misure minime di sicurezza

Domande ricorrenti: esistono sempre le misure minime di sicurezza? Quali sono? Dobbiamo adottarle o no?

Le famigerate misure minime di sicurezza erano allegate al D.Lgs. 196/03 (allegato B); il D.Lgs. 101/2018 le ha abrogate (art. 27, comma 1, lett. d).

Per 14 anni sono state oggetto di critica (troppo oppure troppo poco), ridicolizzate dagli estremisti, snobbate dagli asceti, sottovalutate dai qualunquisti.

Posso tranquillamente affermare che, ad oggi, molte organizzazioni non hanno neanche adottato tutte le (abrogate) misure minime di sicurezza introdotte nel 2004. Non ci credete? Ne cito una, forse tra le più disattese:

25. Il titolare che adotta misure minime di sicurezza avvalendosi di soggetti esterni alla propria struttura per provvederne alla esecuzione, riceve dall'installatore una descrizione scritta dell'intervento effettuato che ne attesta la conformità alle disposizioni del presente disciplinare tecnico.

IL GDPR assegna oggi al Titolare (l’azienda) l’onere di definire le più appropriate misure di sicurezza (non quelle minime) e l’onere di dimostrare che esse sono appropriate (ed adottate, oltre che verificate periodicamente).

Quindi le misure minime del D.Lgs. 196/03 sono la base di partenza, ma non sono sicuramente le misure appropriate da adottare, almeno nelle realtà diverse dalle piccolissime.

Il nuovo approccio del GDPR richiede quindi alle aziende responsabilizzazione, adozione di misure e stumenti di sicurezza ed il loro avvallo; siamo passati (a mio modesto parere) da un approccio di tipo “civil law” (con il tutore che prescrive) a quello “common law” (con le aziende che in piena autonomia decidono, adottano e sono successivamente in grado di dimostrare “il valore” delle loro scelte).

GDPR security assessment

Security Assessment, Vulnerability Assessment e Penetration Test, cosa sono?
Si tratta della stessa attività o di attività diverse?

Qeste tre definizioni, che spesso vengono confuso e/o scambiate, si riferiscono a tre attività diverse che afferiscono però ad una sola finalità: migliorare notevolmente la sicurezza dei sistemi informativi.

Per attività di Vulnerability Assessment (che qualcuno indica anche come Vulnerability Scan) si intendono quelle attività tecniche (molto specifiche), effettuate di norma con strumenti automatici, che evidenziano eventuali vulnerabilità presenti nei dispositivi informatici e/o nel software.

Le attività di Penetration Test sono le attività di soggetti dotati di particolari competenze che, “indossato il cappello dell’hacker”, operano per superare le misure di sicurezza e le difese messe in atto per proteggere i sistemi. Dato che di norma le attività di penetration test, per avere successo, sfruttano le vulnerabilità di strumenti, software, sistemi e loro configurazioni, tali attività vengono effettuate dopo aver eseguito il Vulnerability Assessment ed averne risolto le vulnerabilità emerse.

Per Security Assessment (o valutazione della sicurezza) intendiamo la somma di tutte le specifiche attività di valutazione della sicurezza; spesso dimentichiamo che la sicurezza di un sistema informativo è funzione anche della relativa sicurezza fisica degli ambiti nel quale esso si trova.

Il Regolamento Europeo ha aumentato esponenzialmente il livello di sicurezza necessario per tutte le tipologie di trattamenti, mettendo in capo al titolare del trattamento la definizione delle misure necessarie da adottare e l’obbligo di testarle, verificarle e valutarne regolarmente l’efficacia (art. 32 comma d GDPR).

Regolarmente, non una tantum, perchè un sistema sicuro oggi potrebbe non esserlo in futuro.