Immuni, i dubbi privacy e sicurezza dopo la release del codice

L’App Immuni tratta, potenzialmente, informazioni e dati personali, in quanto verrà installata negli smartphone degli utenti.

Il rischio, pertanto, che incombe su chi la userà, dipende dalle vulnerabilità contenute nell’app e in tutto il sistema di contact tracing e dalla tipologia di dati ai quali l’App ha accesso.

Come specificano le norme che trattano la sicurezza delle informazioni (per esempio ISO 31000 e ISO/IEC 27005), il livello di rischio di una App dipende infatti dalle vulnerabilità che contiene e dai dati ai quali ha accesso.

Ad esempio, una App che accede in modo continuo a informazioni come dati di geolocalizzazione, ai dati personali e dati relativi alla salute, può essere considerata a rischio più elevato rispetto alle App che non accedono a dati sensibili. Inoltre, le App che dipendono dalle tecnologie di rete wireless (ad es. Wi-Fi, cellulare, Bluetooth) per la trasmissione dei dati possono anche esse essere ad alto rischio, poiché queste tecnologie possono essere utilizzate come vettori per esplorazioni remote. Anche le App che di solito sono considerate a basso rischio possono essere sfruttate e avere un impatto significativo, in modo particolare se trattano big data o dati sulla sicurezza.

È evidente che gli attacchi si orientano verso lo sfruttamento dei punti deboli che si celano all’interno delle applicazioni software. Esaminiamo allora la privacy e la security dell’app Immuni, alla luce delle informazioni che attualmente abbiamo a disposizione.

Il rischio correlato alla App Immuni

I dati ai quali l’App potrebbe avere accesso possono essere dati di geolocalizzazione e dati personali relativi alla positività dell’utente (dati di salute). Inoltre, il trattamento prevede vari trattamenti locali e transiti tra gli smartphone, come anche il transito tra smartphone e i servizi backend su reti pubbliche potenzialmente non sicure e sul Content Delivery Network (CDN) (cioè la rete di server altamente distribuita che consente di gestire efficacemente la mole di connessioni che si prevede per il funzionamento della App Immuni e di server con database sanitari dei dati dei pazienti positivi Covid-19 (del tipo big data)).

Effettuando una valutazione veloce, basandosi sull’elenco delle tipologie dei dati e dei trattamenti (dati “sensibili” e appartenenti probabilmente alla categoria di big data per i database Covid-19, nonché trattati attraverso l’uso di tecnologie innovative e tracciamenti di prossimità come il Wi-Fi e Bluetooth tracking) emesso dal Garante per la privacy^[1], il servizio di contact tracing è soggetto a valutazione d’impatto (art. 35 del GDPR). Di conseguenza possiamo dedurre che il rischio che incombe sulla App Immuni e sul sistema contact tracing è di livello Alto.

Il rischio correlato alle App mobili

Prima di valutare il livello di sicurezza di una App mobile, è opportuno definire i i rischi correlati alle app mobili e i requisiti di sicurezza che l’App stessa deve soddisfare.

Gli agenti portatori di minacce possono utilizzare diversi percorsi attraverso l’applicazione per nuocere l’utente. Alcune volte, questi percorsi sono facili da esplorare e da sfruttare; altre volte invece sono estremamente difficili. Allo stesso modo l’impatto causato può non avere conseguenze gravi.

(fonte OWASP)

Occorre, pertanto, mitigare i potenziali rischi per la sicurezza dei dati associati alle App. È perciò necessario che le aziende creino un software assurance process per garantire un livello di confidenza per il software, che sia privo di vulnerabilità, sia esse create volontariamente o inserite accidentalmente, in qualsiasi momento durante il ciclo di vita dello sviluppo.

Esistono diversi standard per la modellazione delle vulnerabilità e delle minacce. La comunità OWASP (www.owasp.org) sottolinea la necessità di accrescere la consapevolezza sulla sicurezza delle applicazioni, in quanto il software non sicuro mette a repentaglio le infrastrutture finanziarie, sanitarie, difensive, ecc. OWASP periodicamente esegue delle indagini per identificare i dieci rischi critici per la maggior parte delle aziende (The Ten Most Critical Web Application Security Risks). Questo elenco aiuta gli sviluppatori a implementare ogni misura necessarie per garantire la protezione.

I requisiti di sicurezza per le App mobili

Diverse organizzazioni come OWASP, NIAP, MITRE e NIST hanno sviluppato specifiche che possono essere usate come linee guida per definire i requisiti di sicurezza delle applicazioni web.

Le specifiche NIAP definiscono il Profilo di Protezione (Protection Profile) e gli obiettivi di sicurezza (Security Target), i requisiti e le attività di assicurazione che devono essere soddisfatti affinché un prodotto software possa essere certificato in conformità alle norme ISO/IEC 15408. Molte organizzazioni che sviluppano App mobile non sono interessate alla certificazione di conformità alla norma ISO/IEC 15408, ma utilizzano ugualmente questa norma per stabilire il Profilo di Protezione delle loro App.

Stabilire i requisiti di sicurezza per una App mobile utilizzando le norme o gli standard sopra citati, non significa che la App sia sicura. La garanzia migliore è la certificazione o anche quella di far valutare la App da Apple o Google in modo da ospitarla nel proprio store. Per arrivare a questo punto occorre eseguire delle verifiche e test lungo il ciclo di progettazione e sviluppo allo scopo di tracciare i requisiti stabiliti e di valutare la loro soddisfazione e alla fine validare l’App a fronte delle esigenze e dei requisiti di sicurezza stabiliti.

OWASP-Top Ten Security Mobile Risks

OWASP spesso effettua indagini per identificare i Top Ten Security Risks che interessano una vasta gamma di organizzazioni. L’elenco dei dieci rischi più critici per la sicurezza aiuta gli analisti e gli sviluppatori a intraprendere e implementare le misure e i controlli adeguati a garantire la sicurezza nelle App. Ma bastano solo questi dieci rischi? Sicuramente no! Ci sono centinaia di problemi che possono influenzare la sicurezza totale di un’applicazione web. Si consiglia quindi di ampliare l’orizzonte adottando anche altri standard. MITRE, per esempio, ha catalogato più di 700 differenti tipi di vulnerabilità del software nel loro progetto CWE. Queste vulnerabilità sono dovute a differenti modi con cui gli sviluppatori di software operano e commettono errori dannosi per la sicurezza.

L’ultima indagine di OWASP per i Top Ten Security Mobile Risks risale al 2016. I rischi critici che sono stati identificati sono i seguenti:

• M1: Improper Platform Usage
• M2: Insecure Data Storage
• M3: Insecure Communication
• M4: Insecure Authentication
• M5: Insufficient Cryptography
• M6: Insecure Authorization
• M7: Client Code Quality
• M8: Code Tampering
• M9: Reverse Engineering
• M10: Extraneous Functionality

Analisi della Privacy e della Security dell’App Immuni

Per valutare il profilo del livello di security dell’App Immuni abbiamo preso in considerazione le funzioni di sicurezza descritte nella la specifica Immuni-Application Security Description (memorizzata nel Github) e le abbiamo confrontate con i rischi di OWASP Top Ten Security Mobile Risk, 2016.

L’analisi che abbiamo effettuato è di alto livello senza approfondimenti specifichi sulle minacce e vulnerabilità per mancanza di informazioni. La specifica Application Security Description è molto sintetica e spesso rimanda ad altri documenti che non siamo riusciti a reperire. Siamo però convinti che Immuni non si ferma solo a quanto è riportato in questa specifica. Alla data attuale il gruppo di progetto di Bending Spoons sta lavorando e tante funzioni di sicurezza non sono ancora implementate.

Il documento Application Security Description è strutturato in paragrafi che corrispondono a situazioni descrivendo le funzioni e misure intraprese per evitare le vulnerabilità e contrastare le minacce al fine di evitare i rischi specifici.

Information disclosure

Il rischio si riferisce alla Privacy e in modo particolare alla riservatezza dei dati.

Rischio: M2 – Insecure data Storage.

Con questa misura è stata posta la massima cura per mitigare la possibilità che un utente malintenzionato acceda o manometta queste informazioni.

Non sono menzionate le misure specifiche da intraprendere.

Protection of data in transit

Il rischio si riferisce alla Crittografia dei canali e dei dati allo scopo di ridurre la probabilità di attacchi MITM (Man In The Middle) perpetrati falsificando (da spoofing e tampering) il certificato TLS dei servizi di backend.

Rischi: M5 – Insufficient Cryptography, M8 – Code Tampering e Insecure Communication

Tecnica di mitigazione usate: HTTPS con TLS 1.2

Traffic-analysis mitigation

Il rischio si riferisce all’evento che un utente malintenzionato potrebbe ottenere informazioni sensibili analizzando la comunicazione tra il client mobile e i servizi di backend.

Rischi: M4 – Insecure Authentication e M6 – Insecure Authorization

Le tecniche messe in atto per contrastare gli attacchi di analisi del traffico sono descritte nel documento Traffic Analysis Mitigation.

Obfuscation of Apple’s DeviceCheck server-to-server calls

Immuni sfrutta il DeviceCheck di Apple per proteggere il servizio di analisi dagli aggressori che tentano di inquinare i dati di analisi. Questa soluzione utilizza i bit per dispositivo di DeviceCheck per tenere traccia del tipo di Analytics che un dispositivo invia in un determinato mese. Senza adeguate contromisure, un utente malintenzionato che accede al sistema DeviceCheck potrebbe dedurre informazioni sensibili ispezionando i bit per dispositivo. Sebbene riteniamo che la probabilità di questo attacco sia molto bassa, la mitighiamo comunque.

Protection of data at rest

Nel caso in cui il Client Mobile venga rubato, un utente malintenzionato può ottenere l’accesso ai dati immuni memorizzati su di esso accedendo ai dati non elaborati dalla memoria del dispositivo.

Rischi: M2 – Insecure data Storage e M5 – Insufficient Cryptography

Tecniche di mitigazione: dati archiviati dall’app vengono crittografati tramite AES. Le chiavi di decrittazione AES sono archiviate nei database di archiviazione delle chiavi native specifici del sistema operativo (Keychain su iOS e Keystore su Android).

Security of the software development lifecycle

I servizi di App e back-end di Immuni utilizzano librerie di terze parti open source. Poiché queste librerie hanno accesso agli stessi dati a cui accede la base di codice Immuni, è fondamentale che siano sicuri da usare e non possano compromettere la sicurezza del sistema. Per questi motivi, tutte le librerie di terze parti vengono aggiornate alle versioni senza vulnerabilità note. Questo controllo viene eseguito mentre le dipendenze vengono risolte e installate ed è integrato nelle pipeline CI / CD.

Rischio: M7 – Client Code Quality

Tecniche di mitigazione: prima di distribuire un aggiornamento del codice in produzione, è necessario superare i seguenti controlli di sicurezza e qualità:

• Linters and static code quality checks
• Security-focused static code analysis
• Library and operating system vulnerability management

Inoltre, i seguenti controlli vengono eseguiti su base regolare:

• Dynamic service-level testing and penetration tests (both internal and external)
• Continuous vulnerability assessment

Service disruption or alteration

Per essere il più efficace possibile nella lotta contro la pandemia COVID-19, Immuni deve operare in modo affidabile. Sono state messi a punto diverse misure per garantire che il sistema sia altamente resiliente agli attacchi che tentano di comprometterne la disponibilità e modificare il comportamento previsto.

Richi: M3 – Insecure, M4 – Insecure Authentication, M5- Insufficient Cryptography e M6 – Insecure Authorization

Data signing: la chiava pubblica è condivise con Apple e Google e utilizzata dai dispositivi mobili per verificare i dati scaricati e garantirne l’autenticità e l’integrità.

Immuni implementerà inoltre un meccanismo di firma per altri tipi di dati forniti tramite la rete CDN, come ad esempio le Impostazioni di configurazione. Questo non è pronto per la versione iniziale di Immuni, ma sarà disponibile in una versione futura dell’app.

Authorisation of TEKs uploads: Se un utente potesse caricare i propri TEK nel servizio di esposizione per ingestione, un utente malintenzionato potrebbe essere in grado di attivare notifiche di esposizione per gli utenti che non sono effettivamente a rischio. Se eseguito su larga scala, un simile attacco potrebbe interrompere il sistema.

Le misure messe in atto per ridurre al minimo questo rischio sono relative al rischio M4 – Insecure Authentication.

Stato dei test di verifica nel progetto dell’App Immuni

Gli sviluppatori di app mobile utilizzano una vasta gamma di linguaggi e framework di programmazione. Pertanto, vulnerabilità comuni come SQL Injection, Buffer Overflow e Cross-Site Scripting (XSS) possono manifestarsi nelle app quando si trascurano pratiche di programmazione sicure. Per prevenire comportamenti simile è necessario predisporre Policies per lo Sviluppo Sicuro e per la Progettazione ed Esecuzione dei Test.

Generalmente nella Policy per lo Sviluppo Sicuro si stabilisce la metodologia e l’impostazione per la gestione dei Test. Per i test di sicurezza delle app mobili le impostazioni da seguire sono due. Nella prima impostazione, del tipo “classico”, i test di sicurezza vengono completati verso la fine del ciclo di vita dello sviluppo. Secondo questa impostazione il tester accede a una versione quasi finita o pronta per la produzione dell’app, identifica i problemi di sicurezza e prepara il Rapporto di Test. L’altra impostazione è caratterizzata dalla definizione dei requisiti di sicurezza, l’implementazione e dell’esecuzione dei test di sicurezza a partire dalle prime attività del ciclo di vita dello sviluppo del software.

Nel progetto dell’App Immuni non è chiaro l’impostazione che è stata seguita per l’esecuzione dei test. Sembrerebbe che sia stata seguita una impostazione mista.

Pertanto, nel documento Application Security Description è riportato quanto segue:

Nella prima parte sembra che venga richiesta un’analisi statica del codice sorgente:

• Static Application Security Testing (SAST) per analizzare la qualità e la sicurezza del codice sorgente, e
• l’esecuzione di un programma che scansiona e analizza il codice sorgente per errori programmatici e stilistici.

Durante l’analisi statica, il codice sorgente dell’app mobile viene riesaminato per assicurare l’implementazione appropriata dei controlli di sicurezza.

Le scansioni automatiche identificano vulnerabilità che potrebbero non essere reali, mentre e il tester umano può esplorare il codice sorgente tenendo presente i contesti specifici di utilizzo.

La seconda parte prevede:

• i test del tipo Dynamic Application Security Testing (DAST) su vari livelli di servizi. Il focus è quello di testare e valutare l’App tramite la loro esecuzione in tempo reale. L’obiettivo principale è quello di trovare vulnerabilità della sicurezza o punti deboli nel programma mentre è in esecuzione. L’analisi dinamica viene condotta sia a livello di piattaforma mobile sia rispetto ai servizi back-end e alle API, dove si trova l’app mobile.

L’analisi dinamica viene utilizzata per verificare la presenza di meccanismi di sicurezza che offrano una protezione sufficiente contro i tipi di attacco più diffusi, come disclosure of data in transit, authentication and authorization issues, and server configuration errors.

• Penetration Test (eseguibili dall’interno e dall’esterno)
• Valutazioni continui per scoprire vulnerabilità nel codice.

Tutto questo sono solo misure descritte nella specifica in modo generico senza rimandare ad altri documenti di dettaglio.

Possiamo dire che sono buone intenzioni!

Sulla base, dunque, di quanto è stato dichiarato, siamo interessati a sapere se:

• esistono le specifiche dei test,
• sono stabiliti i livelli e la tipologia dei test (unit test, integration test, system test),
• esistono le specifiche per la preparazione degli ambienti e dei tool per i test,
• esistono le catene e i casi di test,
• stabiliti i risultati attesi,
• sono eseguiti i test e i risultati ottenuti,
• esiste una procedura per il bug fixing, e
• i system test sono eseguiti da tester indipendenti.

Conclusioni

La documentazione che abbiamo avuto a disposizione non ci permette di esprimere un giudizio complessivo sulla sicurezza reale dell’App Immuni.

Apprezziamo molto lo sforzo del gruppo di progetto, ma con quanto abbiamo a disposizione non possiamo dire se si tratta di una App resiliente, che rispetta la privacy e la sicurezza delle informazioni.

Come cittadino interessato all’installazione dell’App Immuni nel mio smartphone ho il desiderio di sapere se le analisi, i controlli e i test sono stati eseguiti, con quale granularità e se i risultati dei testi per la sicurezza e privacy sono stati positivi.

Abbiamo voglia di dare un giudizio positivo e contribuire alla diffusione dell’App Immuni.

Riferimenti

Ioannis Tsiouras, GDPR-Privacy Risk Management, Edizioni Youcanprint 

1. Allegato al provvedimento n° 467 dell’11/10/2018, doc. web n. 9058979 (Pubblicato sulla Gazzetta Ufficiale n. 269 del 19 novembre 2018). ↑