Anche il mercato delle app mobile è stato interessato dalla rivoluzione di mercato che prende il nome di privacy e che sta spingendo sempre più verso uno sviluppo che rispetti il principio di privacy by design.
Già da qualche tempo i colossi dell’economia digitale hanno colto il valore di questa rivoluzione, iniziando a spingere i propri prodotti dal punto di vista della privacy e sicurezza dei dati. Apple ne ha fatto addirittura un vero e proprio mantra, con la creazione di spot pubblicitari in cui al consumatore si comunica l’unico vero punto di forza del nuovo iPhone rispetto alla concorrenza: la privacy, appunto.
Questo sentimento è stato in ultimo abbracciato da IKEA, che ha presentato al pubblico il suo progetto di rivoluzione della gestione della privacy dei suoi clienti, partendo dalla sua app di e-commerce. IKEA ha perfettamente compreso il sentimento di mercato: da un lato, i consumatori pretendono sempre più controllo sui loro dati, dall’altro bramano servizi digitali accattivanti e in grado di soddisfare i loro interessi.
Purtroppo, salvo casi virtuosi come IKEA, la consapevolezza del tema privacy e sicurezza nel campo degli sviluppatori di app e servizi digitali è ancora pressoché assente.
La normativa non aiuta, perché le prescrizioni del GDPR e delle leggi nazionali sono quasi del tutto rivolte ai titolari del trattamento, cioè coloro che di fatto si trovano a trattare dati personali per il perseguimento dei propri obiettivi. In teoria, una software house il cui core business è sviluppare applicativi per le aziende, non ha alcun obbligo giuridico per ciò che riguarda privacy e sicurezza dei dati che saranno trattati attraverso questi applicativi.
Dove però non arriva la legge, arriva il mercato.
Un recente studio benchmark di Cisco (“From privacy to profit”, 2020) mostra che su un campione di circa 2.800 aziende, la stragrande maggioranza ha riscontrato un ritorno economico positivo degli investimenti in privacy. In Italia, il ritorno è pari a circa 2,4 volte l’investimento. Oltre a questo, quasi tutte le aziende intervistate hanno affermato di preferire fornitori con certificazioni specifiche in privacy e/o sicurezza, come la nuova ISO 27701. Il trend è evidente: la privacy non è più soltanto una questione di compliance, ma un vero e proprio motore di mercato.
Le aziende che commissionano lo sviluppo di un’app, per i motivi più disparati, nella stragrande maggioranza dei casi tratteranno dati personali come titolari del trattamento. Su queste aziende ricadranno quindi tutti gli obblighi derivanti dal GDPR e leggi nazionali. Il trattamento di dati personali ormai avviene quasi del tutto attraverso sistemi informativi, servizi informatici e applicativi, anche come software as a service.
Utilizzare servizi informatici e applicativi che non tengono conto delle esigenze di legge pone i titolari del trattamento in una scomoda situazione: continuare a usare il software, rischiando di violare la legge, o cambiare software.
È chiaro che il GDPR, pur se non rivolto direttamente agli sviluppatori software, avrà importanti ricadute a cascata su tutto il mercato. In questo senso, deve ritenersi applicabile anche agli sviluppatori di software il principio di privacy by design, previsto dall’art. 25 del GDPR.
Indice degli argomenti
Sviluppare app mobile rispettando il principio di privacy by design
Privacy by design significa adottare appropriate misure tecniche e organizzative per dare attuazione concreta ai principi della protezione dei dati personali.
Dal punto di vista dello sviluppo di app o servizi destinati alle aziende significa creare prodotti in grado di agevolare il rispetto dei requisiti di legge. Ad esempio: un applicativo CRM (Customer Relationship Manager) che non sia in grado di consentire una data retention granulare, o che abbia determinate capacità di ricerca ed estrazione di dati personali, non sarà un prodotto appetibile sul mercato del prossimo futuro.
L’obiettivo della privacy by design è mettere le persone al centro. Dare alle persone (e alle aziende che li trattano) il controllo dei loro dati, assicurando la tutela dei loro diritti e la sicurezza dei flussi di dati.
Sviluppare un’app o un servizio digitale nel rispetto del principio di privacy by design richiede approfondita conoscenza della normativa Europea e degli stati membri, nel caso in cui si voglia commercializzare il prodotto anche al di fuori dei confini nazionali. Ma non basta, è anche necessario uno sforzo tecnico e procedurale, perché è essenziale essere in grado di tradurre i principi normativi in requisiti tecnici e soluzioni concrete.
L’unione di competenze legali e competenze procedurali e tecniche da luogo all’attività chiamata privacy engineering, attraverso la quale è possibile integrare i processi di sviluppo di un software con i requisiti privacy.
Metodologia di sviluppo software e privacy engineering
Lo sviluppo di software dovrebbe seguire una metodologia adeguata a garantire che il prodotto finale sia in grado di rispettare le richieste di mercato e di legge (che nel caso della privacy, come visto, spesso combaciano).
Seppur al momento il campo della privacy engineering sia ancora acerbo, esistono già dei tentativi per definire le metodologie più corrette per incorporare lo sviluppo di software con i requisiti privacy.
Tra le metodologie proposte, la più diffusa è certamente quella che fa riferimento al Secure Development Lifecycle (SDLC). Questa particolare metodologia è nata per consentire l’integrazione di requisiti di sicurezza all’interno dei processi di sviluppo di software, così da assicurare la produzione di software adeguatamente sicuro.
Date le affinità e punti di contatto tra privacy e sicurezza, molte Autorità di controllo europee e l’ENISA suggeriscono la possibilità di adottare questa metodologia di sviluppo anche per ciò che riguarda la privacy by design.
La metodologia SDLC prevede lo sviluppo di software attraverso dei cicli iterativi, come segue:
- pianificazione e analisi dei requisiti;
- design;
- implementazione (coding);
- testing;
- rilascio e manutenzione.
I developers solitamente effettuano attività di security assessment soltanto in fase di testing, che nella maggior parte dei casi comporta la scoperta tardiva di vulnerabilità, o l’incapacità di identificarle. In entrambi i casi, il risultato sarà un prodotto poco sicuro che aumenterà il cyber risk in tutto l’ecosistema.
Proprio per evitare questi problemi è nata la metodologia SDLC, che prevede l’integrazione di attività relative alla sicurezza in ogni fase del processo di sviluppo, e non soltanto durante il testing finale.
La stessa metodologia può essere utilizzata per la privacy engineering, aggiungendo ai requisiti di sicurezza quelli di privacy, che spesso si sovrappongono in ogni caso.
Prima di iniziare lo sviluppo di un software è necessario fare formazione al team, per assicurare che tutti i soggetti coinvolti possano parlare la stessa lingua ed essere consapevoli delle necessità e rischi. Privacy e sicurezza richiedono competenze specifiche che esulano dalle competenze di un software developer. Le software house dovrebbero cominciare ad integrare i propri team di sviluppo con figure in grado di supportare le necessità di privacy e sicurezza.
Vediamo come si potrebbe comporre un ciclo di sviluppo software attraverso la metodologia SDLC integrata con l’attività di privacy engineering.
Pianificazione
La fase di pianificazione è forse la più importante di tutte. In questa fase si dovranno individuare correttamente i requisiti privacy da progettare e implementare successivamente.
Tra le principali attività: identificare quali categorie di dati saranno trattate dal software, quali potranno essere le interconnessioni tra dati, quali saranno i soggetti coinvolti (anche tenendo conto di SDK e API), verificare i requisiti di legge, verificare che ogni futura attività di trattamento sia fondata su una delle basi giuridiche previste dal GDPR, o ancora pianificare i diversi tempi di conservazione dei dati che saranno trattati, in relazione alle diverse finalità.
Tutti questi elementi dovranno essere integrati nel progetto di sviluppo, assieme ai requisiti tecnici. Ciò che importa in ogni caso è che siano tenuti nella dovuta considerazione i tre pilastri fondamentali della privacy: minimizzazione, trasparenza, controllo.
Nel caso di app mobile, la pianificazione dei requisiti dovrebbe riguardare anche la struttura dei permessi che saranno richiesti all’utente finale. I modelli differiscono a seconda del sistema operativo scelto e dei device, ma è comunque utile ricordare che l’architettura Android prevede due diverse tipologie di permessi: normal e dangerous. I permessi dangerous sono quelli che, secondo le valutazioni fatte da Google, espongono più a rischio la privacy degli utenti, come geolocalizzazione e uso di sensori di vario tipo.
Per quanto riguarda iOS invece la differenza è tra entitlements e permissions. Gli entitlements non saranno modificabili mentre le permissions potranno essere accettate o revocate dall’utente. Va notato che le librerie di terze parti spesso contengono permessi al di fuori del controllo degli sviluppatori dell’app, ed è il motivo per cui capita spesso che alcune app chiedano permessi assolutamente inopportuni e non necessari al loro funzionamento.
Durante la fase di pianificazione è altrettanto utile iniziare un processo di risk assessment, che tenga conto dei rischi per i diritti e libertà dei soggetti interessati e che possa influenzare successivamente le scelte di progettazione.
Eventualmente, questo è il momento giusto per iniziare una DPIA che seguirà parallelamente tutte le fasi di sviluppo dell’app.
Design
La successiva fase di design è dedicata ad assicurare che i requisiti individuati durante la pianificazione siano correttamente progettati e integrati dell’architettura del software.
Ogni caratteristica tecnica del software dovrebbe essere implementata nel rispetto dei requisiti identificati, ad esempio progettando tecniche per la gestione della data retention in modo granulare, o ancora sviluppando sistemi in grado di limitare le correlazioni tra dati o tecniche di astrazione o aggregazione di dati.
Allo stesso modo tutte le impostazioni relative alla raccolta e trattamento dei dati dovrebbero essere progettate in modo tale da garantire per impostazione predefinita la configurazione più privacy-friendly.
Nella fase di design è anche opportuno analizzare le superfici di rischio e ricercare soluzioni per limitare le fonti di rischio e vulnerabilità.
Coding
La vera e propria fase di coding del software dovrebbe partire con la definizione degli strumenti, processi e frameworks permessi – evidenziando anche i relativi ambiti di utilizzo.
Oggigiorno i software sono prodotti che si compongono di servizi e strumenti spesso sviluppati da terzi, come SDK (software development kit), APIs, librerie e moduli che spesso aggiungono fonti di rischio e vulnerabilità sia dal punto di vista della privacy che cyber sicurezza.
Non sempre i developers hanno il potere di modificare gli strumenti utilizzati (come, ad esempio, succede per le API Android o librerie di terzi), ma quando possibile dovrebbero essere disabilitate tutte le funzioni e moduli ritenuti poco sicuri o non rispettosi dei requisiti privacy pianificati.
Altrettanto importante è la fase di code review, che dovrebbe essere realizzata periodicamente.
Testing
La fase di testing è fondamentale per ricercare vulnerabilità tecniche e identificare ulteriori fonti di rischio introdotte dalla fase di coding. Per farlo, può essere opportuno realizzare anche penetration testing ad intervalli regolari.
Vulnerability assessment e penetration testing periodici sono alcune delle misure espressamente previste dal Cybersecurity Act (Reg. UE 2019/881) per ottenere le future certificazioni di sicurezza.
Il testing però non deve riguardare soltanto la sicurezza dei dati, ma anche la verifica della corretta implementazione dei requisiti privacy durante la fase di coding. Ad esempio, è importante verificare in questa fase il funzionamento delle misure tecniche previste per garantire il diritto dei soggetti interessati, come diritto di accesso o portabilità. O ancora, per verificare che i meccanismi per ottenere e revocare i consensi siano stati implementati come previsto.
È importante ricordare che le linee guida WP29 ed i principali framework di cyber sicurezza raccomandano l’uso di dati fittizi durante il testing di qualsiasi software, per evitare rischi di violazione di dati personali (data breach).
Release e manutenzione
L’ultima fase, quella di rilascio e manutenzione non è priva di accortezze. In questa fase è opportuno preparare un piano di incident response e procedure per aggiornare periodicamente l’applicativo.
Allo stesso modo, prima del rilascio, è raccomandabile fare una revisione completa del software, che sarà poi documentata e conservata insieme a tutta la documentazione prodotta durante le fasi precedenti.
Anche dopo il rilascio il software dovrebbe essere sottoposto a periodici vulnerability assessment e penetration test, oltre che debugging, patching e audit dei log.
È importante ricordare che i logs spesso raccolgono tantissime informazioni riguardanti metadati che possono essere qualificabili come dati personali, rientrando quindi nell’alveo delle tutele previste dal GDPR.
Conclusioni
Lo sviluppo di app e software nel rispetto del principio di privacy by design così come previsto dall’art. 25 GDPR è un campo ancora molto acerbo, che richiede ancora approfondimento e innovazione da parte delle software house.
La direzione del mercato e dei legislatori è tuttavia chiara: fra qualche tempo sviluppare app senza tener conto delle esigenze legali in materia di privacy e sicurezza sarà sempre più difficile. Chi riuscirà a rinnovare il proprio business model, aprendo le proprie porte a figure professionali in grado di guidare la rivoluzione privacy-centrica, avrà indubbiamente un rilevante margine competitivo negli anni a venire.
