GDPR, ethical hacking e sicurezza delle informazioni

Information Security & Data Protection
All’interno di questo quadro dovranno quindi essere documentate le specifiche misure adeguate che dovranno essere messe in atto dal Titolare e dal Responsabile del trattamento, quali indicate dall’art. 32 del Regolamento dal titolo: Sicurezza del Trattamento. Questo con riguardo al livello sia qualitativo e quantitativo sia di sicurezza e protezione da applicare sui dati personali oggetto delle varie operazioni di trattamento in relazione allo sta to dell’arte ai costi di attuazione, alla natura, all’oggetto, al contesto e alle finalità del trattamento stesso, come anche al rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche,
Al fine di quanto ci occupa rileva segnatamente quanto previsto dalla lettera d) del primo comma del richiamato articolo 32 che espressamene obbliga sia il Titolare sia il Responsabile, congiuntamente anche sotto il profilo delle eventuali responsabilità per l’inosservanza, a mettere in atto: procedure per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento. In forza della norma da ultimo citata, quindi, il Titolare e il Responsabile non dovranno né potranno limitarsi a una mera applicazione statica di misure di sicurezza, tecniche ed organizzative ma, al contrario, non potranno che intendere l’adempimento del dovere di sicurezza alla stregua di un processo ricorsivo verosimilmente basato sullo schema ‘Plan Do Check Act’ in cui il momento dell’assessment si configura come valutazione dell’efficacia e assurge al ruolo di elemento primario dell’attuazione stessa.

Vediamo quindi un esempio concreto che ci consente anche di introdurre il tema dell’ethical hacking, nel contesto degli obblighi di sicurezza di cui al Regolamento Comunitario in commento. Sulla base delle osservazioni sin qui svolte, il Titolare e il Responsabile non avranno adempiuto diligentemente ai loro obblighi di sicurezza se, oltre a implementare e configurare in modo adeguato una protezione perimetrale di tipo Firewall, non ne abbiano misurato l’efficacia attraverso operazioni dedicate quali i penetration test e i vulnerability assessment. Cioè se è vero, come è vero, che vi è un obbligo di protezione dei dati, correlato al quale sussiste un obbligo di verifica e di relativa documentazione, deve essere, ed è, altrettanto vero che la verifica di resistenza (i.e. efficacia) di determinate soluzioni tecniche e tecnologiche non può che essere condotta sottoponendole alla minaccia dalla quale le stesse devono proteggere. Ciò non può che implicare, a mio avviso, la necessità di documentare procedure che prevedano di simulare le minacce stesse attraverso le operazioni di ethical hacking.

Penetration test vs vulnerability assessment
Anche se dal punto di vista della teoria della sicurezza delle informazioni esistono profonde differenze tra le operazioni relative alle attività di penetration test (PT) e quelle invece svolte durante azioni di Vulnerability Assessment, (VA), principalmente in ragione del maggior livello di profondità delle prime rispetto alle seconde, che risultano il più delle volte automatizzate o semiautomatizzate e preliminari, da un punto di vista legale esse si prestano ad alcune considerazioni valide per entrambe. In primo luogo si deve rilevare come sia le operazioni di PT sia quelle di VA che, oltre a essere obbligatorie nell’ambito per esempio della certificazione PCI-DSS, possono essere ricondotte nell’area di applicazione dell’ar t. 32 lett. d) del Regolamento 679/2016, non possano essere ritenute lecite in mancanza di specifica, espressa e documentata autorizzazione dell’avente diritto.

Consenso dell’avente diritto
In effetti, attraverso le tecniche di VA e le metodologie di PT non solo si interagisce con beni hardware e software che sono di proprietà di un soggetto diverso da colui che le svolge, ma soprattutto perché, nel corso ovvero all’esito alle predette operazioni, possono di fatto realizzarsi le condotte tipiche previste da norme penali incriminatrici, quali per esempio: l’art. 615 ter del Codice Penale, che punisce l’accesso abusivo a sistema informatico o telematico oppure, l’art. 635 bis stesso codice che punisce il danneggiamento di sistemi informatici o telematici. Inoltre, sia le operazioni di PT che quelle di VA, determinano rapporti contrattuali atipici la cui disciplina, in termini di determinazione esatta della misura dell’adempimento o del livello di diligenza richiesto risulta essere tutt’altro che agevole, tanto più allorché, come sempre più frequentemente avviene nella pratica quotidiana, vi siano differenze tra il soggetto che usa determinate soluzioni tecnologiche, e vuole verificarne l’efficacia, e il soggetto che ne è proprietario. Si pensi, per concludere, quanto può rivelarsi complesso e laborioso acquisire l’autorizzazione anche da parte dell’hosting service provider per lo svolgimento di operazioni di ethical hacking sulla piattaforma in cloud utilizzata dal cliente di quest’ultimo.