Privacy by design e by default. La sicurezza applicativa negli accordi di servizio
Il GDPR, all’articolo 25 – Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita, con la definizione dei principi di privacy by design e privacy by default, introduce in modo concreto aspetti anche (e soprattutto) di carattere tecnico nelle attività di adeguamento e mantenimento di un soddisfacente regime di compliance in ambito di protezione dei dati personali.
Proprio quest’articolo che, unitamente agli artt. 32 – Sicurezza del trattamento e 35 – Valutazione d’impatto sulla protezione dei dati delineano l’anima del Regolamento, ovvero l’orientamento al principio dell’Accountability, determina un impatto elevato nelle attività di progettazione, realizzazione ed erogazione di prodotti applicativi e servizi IT.
Per di più la questione colpisce trasversalmente tanto le software house, che si occupano di sviluppo, come anche tutti i Titolari che fanno uso di strumenti elettronici per compiere il trattamento di dati personali, siano essi sviluppati internamente oppure acquisiti e spesso manutenuti da terze parti, obbligandoli in ogni caso a mantenere un adeguato presidio sulla catena di fornitura. Quest’ultima capacità è garantita per mezzo di due aspetti fondamentali che però richiedono l’abilità di gestire in modo efficace questioni di natura tecnica come anche aspetti più prettamente legali: da una parte la definizione di adeguati accordi di servizi, inclusivi di clausole correlate a processi e misure di sicurezza (specie nel caso di nomine ex art. 28 – Responsabile del trattamento), dall’altra la conduzione di attività di controllo attraverso due diligence mirate ed audit, anche tecnici, condotti in campo.
In concreto, gli aspetti fondamentali da presidiare riguardano la sicurezza del codice applicativo, inclusa quella degli ambienti nei quali viene generato e testato prima del rilascio, l’adeguatezza delle logiche autorizzative delle singole funzionalità applicative e l’adeguatezza delle persone, dei canali e degli strumenti impiegati per lo svolgimento di attività di manutenzione correttiva ed evolutiva, quando previste.
La sicurezza del codice applicativo
È sufficiente dare un’occhiata alla Top 10 Most Critical Web Application Security Risks dell’OWASP, la community che opera per consentire alle organizzazioni di concepire, sviluppare, acquisire, utilizzare e mantenere applicazioni affidabili, per rendersi conto della gravità dei rischi a cui i sistemi applicativi sono esposti e la complessità tecnica delle questioni ad essi correlate per i non addetti ai lavori. Inquietante è anche la probabilità di accadimento di incidenti relativi alla sicurezza con specifico riferimento al codice applicativo, considerando quanto riportato nel Threat Landscape Report 2017 redatto dall’ENISA (Agenzia Europea per la Sicurezza delle Reti e delle Informazioni), che colloca la minaccia Web application attacks al terzo posto e per la quale segnala un trend crescente.
Inoltre, qualora l’applicazione in questione prevedesse la memorizzazione, elaborazione o trasmissione di dati dei titolari di carta di pagamento e/o dati sensibili di autenticazione, allora è necessario prendere anche in considerazione tutti i requisiti dello standard PA-DSS (Payment Application Data Security Standard), che si applica, unitamente al PCI DSS (Payment Card Industry Data Security Standard), ai fornitori di software e a coloro che sviluppano applicazioni di pagamento.
Basti considerare che un “codice sicuro”, per essere considerato tale, ha affrontato differenti fasi di verifica e validazione prima di essere rilasciato, tra cui quelle di code review e vulnerability assessement. La prima fase, quella di code review, è principalmente condotta da persone incaricate di leggere il codice sorgente per individuare e correggere difetti sintattici che hanno impatto sull’efficienza e sulla sicurezza applicativa. Inoltre, per garantire validità formale e sostanziale a quest’attività di revisione del codice, le persone che controllano il codice, i revisori, non devono aver contribuito allo sviluppo, con l’obiettivo di assicurare un’adeguata separazione dei compiti.
La seconda fase, quella di vulnerability assessment applicativo, riguarda l’impiego di strumenti ad hoc – attività poi controllata e ripulita da eventuali falsi positivi dal personale incaricato – attraverso la quale è possibile identificare eventuali vulnerabilità applicative non adeguatamente gestite in specifiche porzioni di codice. Per fare un esempio, la mancata gestione del carattere “apice” lascia il fianco scoperto al vettore d’attacco Injection, ovvero l’esecuzione di codice malevolo introdotto dall’attaccante attraverso la semplice compilazione di campi di maschere di inserimento o modifica di dati, con effetto potenzialmente disastroso per gli stessi dati.
La sicurezza negli ambienti di sviluppo
Tutto quanto sopra esaminato deve avvenire in ambienti di sviluppo e test adeguatamente separati ed “igienici”, garantendo le proprietà essenziali di dati ed informazioni che saranno oggetto di trattamento, quali l’autenticità, l’integrità, la non ripudiabilità, la riservatezza e la disponibilità. Si rende quindi necessaria l’adozione di modelli in grado di identificare preventivamente le minacce nel codice applicativo e nei sistemi impiegati per il suo sviluppo, rispondendo in modo esaustivo all’incertezza – “cosa può andare storto nel sistema utilizzato?” – senza trascurare i rischi introdotti dall’agente umano non solo riconducibili ad attività involontarie – l’errore – ma anche a pratiche deliberate condotte da insiders oppure da attaccanti esterni attraverso tecniche di ingegneria sociale. Ecco perché non è ipotizzabile possa essere sufficiente l’adozione di tecniche finalizzate a presidiare esclusivamente minacce di natura tecnica – si veda ad esempio il modello STRIDE messo a punto da Microsoft – ma si rende necessaria anche l’adozione di un vero e proprio sistema di gestione per la sicurezza delle informazioni e dei dati personali, in grado di configurare un’ampia gamma di requisiti di natura tecnica ed organizzativa di supporto alle organizzazioni per progettare, operare, controllare e migliorare in modo sicuro.
Le logiche autorizzative nelle applicazioni
All’art. 5 del GDPR – Principi applicabili al trattamento dei dati personali è definito anche quello di adeguatezza, pertinenza e limitazione (lettera c) ) in relazione alle finalità di trattamento, ovvero la minimizzazione dei dati. Lo stesso concetto ricorre all’art. 25 di cui già si è parlato in precedenza. Se da un lato quindi appare difficile ipotizzare che il presidio su questo principio possa essere demandato solamente agli strumenti tecnologici, dall’altro è fondamentale che i sistemi applicativi includano logiche autorizzative adeguate e facilmente modellabili, consentendo di definire, per utenza, quali sono i singoli dati che possono essere trattati e quelli che possono essere visualizzati, anche in relazione ad un periodo massimo di trattamento identificato. In definitiva la logica autorizzativa subisce una profonda modificazione, spostando l’attenzione dalla funzionalità applicativa così come concepita dai singoli vendor alla customizzazione in ottica di analisi ed applicazione delle finalità di trattamento identificabili nelle singole organizzazioni per i differenti set di dati personali trattati.
Inoltre le logiche autorizzative delle applicazioni impiegate devono essere supportate da un’ampia gamma di funzioni che riguardano il “ciclo di vita” dell’utente. Dalla definizione dei requisiti per il controllo degli accessi alla gestione degli accessi degli utenti sino alle responsabilità dell’utente ed il controllo degli accessi alle applicazioni. Tutti obiettivi di controllo e controlli efficacemente declinati nell’Annex A, dominio di controllo A.9 – Controllo degli accessi della ISO/IEC 27001 e nella raccolta di prassi sui controlli ISO/IEC 27002.
Attività di assistenza e manutenzione
Nella definizione degli accordi di servizi diventa fondamentale, una volta “strette le viti” della sicurezza applicativa, non tralasciare le questioni correlate alle attività di assistenza e manutenzione, rammentando sempre che la robustezza di un sistema si misura considerando quella del suo anello più debole. Cosa accadrebbe se venissero impiegate soluzioni di accesso remoto e relativi canali di comunicazione non adeguatamente sicuri? E se nelle attività di manutenzione correttiva, specie quelle originate da eventi bloccanti, prendesse il sopravvento l’esigenza di risolvere in fretta gli errori scavalcando le fasi di processo discusse in precedenza?
Ecco perché risulta quindi fondamentale rendere esplicite le misure di sicurezza da adottare anche nei casi urgenti, avendo cura di definire non solamente i più comuni SLA riferibili ai tempi di presa in carico e gestione delle richieste inviate dal cliente al fornitore ma anche tempi e responsabilità in caso di ripristino di servizi IT (RTO, Recovery Time Objective) e di dati (RPO, Recovery Point Objective) eventualmente persi o corrotti. Tutto ciò al fine di rispondere in modo adeguato agli obblighi del Titolare di trattamenti circa la disponibilità, integrità e riservatezza dei dati e agli obblighi di resilienza circa i sistemi impiegati; il tutto già dalla fase di progettazione.
Questioni di mercato
Identificati tutti gli aspetti, o comunque i più rilevanti, ai quali prestare attenzione, restano ora da sciogliere importanti questioni di carattere economico. L’introduzione di attività integrative rispetto al passato di presidio sulla sicurezza da parte di chi si occupa dello sviluppo applicativo, senza considerare l’impiego di ulteriori strumenti necessari e l’adeguamento delle competenze necessarie del personale, provocherebbero un incremento significativo dei costi di produzione. Ma c’è da domandarsi: chi li sostiene? Ed in quale misura tra il produttore e l’acquirente? E se il mercato, luogo d’incontro tra domanda ed offerta, decidesse che entrambe le parti non se ne vogliono far carico, come si dovrebbero comportare invece i soggetti fortemente orientati alla compliance ma con un potere contrattuale basso nei confronti dei fornitori leader?
Potrebbe essere ancora prematuro tentare di dare una risposta nell’assenza, pressoché totale, di casi di studio. Infatti solamente alcuni player primari di mercato hanno potuto rivolgere al tema l’attenzione che merita, guardando oltre le sole indicazioni tecniche di sicurezza esplicitate nel GDPR, quali anonimizzazione, pseudonimizzazione e cifratura dei dati, mentre un’altra porzione significativa del mercato è ancora completamente work in progress.
Articolo a cura di Alberto Buzzoli
Promuove sinergia, creatività ed innovazione progettando metodologie e strumenti per connettere strategie di business, modelli d’organizzazione, sistemi di gestione e tecnologie dell’informazione. Si occupa di governance aziendale, risk management, compliance e incident handling – formazione specialistica e comunicazione incluse – in ambito di sicurezza integrata, con particolare approfondimento in materia di sicurezza delle informazioni e protezione dei dati personali.
E’ specializzato nella progettazione e nell’auditing di servizi CRM per il mercato bancario, assicurativo e finanziario.
