Il principio di Accountability.
Come abbiamo più volte illustrato nei numeri precedenti, uno dei principi cardine, che hanno ispirato il legislatore comunitario, nel delineare l’architettura del Regolamento 679 del 27 Aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali ed alla libera circolazione di tali dati, che sarà applicabile dal prossimo 24 maggio 2018, é quello, riferibile all’operato del Titolare del trattamento, della c.d. accountability, che possiamo tradurre in Italiano con il termine “Responsabilizzazione”.
Tale principio è declinato, in particolare, nel testo dell’art. 24, nella parte della norma in cui é fatto obbligo, al Titolare, non solo di mettere in atto misure tecniche e organizzative adeguate per garantire, che il trattamento sia effettuato in conformità con le disposizioni del Regolamento stesso, ma anche, ed è questo il punto di novità, che rompe con il passato, di essere in grado di dimostrare che ciò che precede, vale a dire l’adozione delle misure di sicurezza, sia in effetti avvenuta.
La portata innovativa della disposizione appena richiamata, è tale da cambiare del tutto, evolvendolo, il modo in cui, in concreto, occorrerà progettare e piani-ficare l’attuazione delle strategie di protezione dei dati personali, spostando l’attenzione, oltre che su di un momento, per così dire, sostanziale, legato alla selezione ed attuazione delle misure organizzative e tecniche adeguate a proteggere i dati, anche sul momento, per così dire, formale della attuazione stessa.
Definendosi, in buona sostanza, nuove modalità, sinora non richieste, di dimostrazione, e quindi di prova, dell’adempimento degli obblighi di sicurezza legalmente imposti, configurandosi, in altre parole, sul titolare un obbligo di documentazione efficace, esatta ed aggiornata, della adozione delle misure previ-ste.
Information Security & Data Protection
All’interno di questo quadro, dovranno, quindi, essere documentate, con riguardo al livello, qualitativo e quantitativo, di sicurezza e protezione, da applicare sui dati personali, oggetto delle varie operazioni di trattamento, in relazione, allo stato 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, 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, appunto: Sicurezza del Trattamento.
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 ed il responsabile non dovranno ne potranno limitarsi ad una mera applicazione statica di misure di sicurezza, tecniche ed organizzative ma, al contrario, non potranno che intendere l’adempimento del dovere di sicurezza, a stregua di un processo ricorsivo, verosimilmente basato sullo schema del Plan, Do, Check, Act, in cui il momento dell’assessment (valutazione dell’efficacia), assurge al ruolo di elemento primario dell’attuazione stessa.
Ethical Hacking e GDPR.
Per fare un esempio concreto che ci consente anche, nel contempo, 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 ed il Responsabile non avranno adempiuto diligentemente ai loro obblighi di sicurezza se, oltre ad implementare e configurare in modo adeguato, una protezione perimetrale, di tipo Firewall, non ne abbiano misurato l’efficacia, attraverso operazioni dedicate, che, nella specie sono quelle di Pe-netration Test e Vulnerability Assessment.
Cioè, se é vero, come è vero, che vi è, un obbligo di protezione dei dati, corre-lato 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. Il che, non può che implicare, a mio avviso, la necessità di documentare procedure che prevedano, appunto, di simulare le minacce stesse, che avviene, tipicamente, attraverso le operazioni di Ethical Hacking sopra menzionate.
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 nel seguito), e quelle invece svolte durante azioni di Vulnerability Assessment, (VA nel seguito), principalmente in ragione del maggior livello di profondità delle prime rispetto alle seconde, che sono, il più delle volte, automatizzate o semiautomatizzate e preliminari, da un punto di vista legale, esse si prestano ad alcune considerazioni valide per entrambe che mi accingo a svolgere di seguito in modo sintetico.
In primo luogo, si deve rilevare come, sia le operazioni di PT sia quelle di VA che, oltre ad essere obbligatorie, nell’ambito, per esempio della certificazione PCI-DSS, possono essere ricondotte nell’area di applicazione dell’art. 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, sono, di fatto essere realizzate le condotte tipiche previste da norme penali incriminatrici, quali ad es.: 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, alla necessità di 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.
Avv. Giuseppe Serafini
