Guida del produttore per la sicurezza Android a lungo termine

Questa guida descrive le best practice consigliate da Google per l'applicazione delle patch di sicurezza valutate da Android Compatibility Test Suite (CTS). È destinato ai produttori di apparecchiature OEM (produttori) compatibili con Android che saranno supportati per più di tre anni, ad esempio veicoli, TV, set-top box ed elettrodomestici. Questa guida non è destinata agli utenti finali (ad esempio, proprietari di veicoli).

Ringraziamenti e dichiarazioni di non responsabilità

Questa guida non vincola legalmente o contrattualmente Google o altri produttori e non è intesa come un insieme di requisiti. Piuttosto, questa guida è un supporto didattico che descrive le pratiche consigliate.

Feedback

Questa guida non vuole essere esaustiva; sono previste ulteriori revisioni. Invia feedback a produttori-guida-android@googlegroups.com.

Glossario

Informazioni sul sistema operativo Android

Android è uno stack software completo open source basato su Linux progettato per una varietà di dispositivi e fattori di forma. Dalla sua prima uscita nel 2008, Android è diventato il sistema operativo (OS) più popolare, alimentando oltre 1,4 miliardi di dispositivi in ​​tutto il mondo (2016). Circa il 67% di questi dispositivi utilizza Android 5.0 (Lollipop) o versioni successive a marzo 2017 (i dati più recenti sono disponibili sulla dashboard di Android ). Mentre la stragrande maggioranza dei dispositivi sono telefoni cellulari e tablet, Android sta crescendo negli smartwatch, nei televisori e nei dispositivi di infotainment a bordo dei veicoli (IVI).

Il numero di app Android disponibili nel Google Play Store ha raggiunto oltre 2,2 milioni (2016). Lo sviluppo di app Android è supportato dal programma Android Compatibility, che definisce una serie di requisiti tramite Compatibility Definition Document (CDD) e fornisce strumenti di test tramite Compatibility Test Suite (CTS) . I programmi di compatibilità Android garantiscono che qualsiasi app Android possa essere eseguita su qualsiasi dispositivo compatibile con Android che supporti le funzionalità richieste per l'app.

Google rilascia regolarmente nuove versioni del sistema operativo, aggiornamenti di sicurezza del sistema operativo e informazioni sulle vulnerabilità scoperte. Il Bollettino sulla sicurezza di Android dovrebbe essere esaminato dai produttori per verificare l'applicabilità di questi aggiornamenti ai prodotti supportati dal sistema operativo Android. Per una revisione della sicurezza, della compatibilità e dei sistemi di build di Android, vedere quanto segue:

• Proteggi un dispositivo Android
• Aggiornamenti e risorse sulla sicurezza
• Suite di test di compatibilità
• Nomi in codice, tag e numeri di build

Informazioni sui veicoli connessi (prodotti canonici di lunga durata)

I veicoli iniziarono ad essere collegati con l'introduzione della radio AM negli anni '20. Da lì, il numero di connessioni fisiche e wireless esterne ha iniziato a crescere man mano che gli enti regolatori e i produttori di automobili si sono rivolti all’elettronica per facilitare la diagnostica e l’assistenza (ad esempio, la porta OBD-II), migliorare la sicurezza (ad esempio, TPMS) e raggiungere gli obiettivi di risparmio di carburante. . La successiva ondata di connettività ha introdotto funzionalità di comodità per il conducente come l'accesso remoto senza chiave, sistemi telematici e funzionalità di infotainment avanzate come Bluetooth, Wi-Fi e proiezione dello smartphone. Oggi i sensori integrati e la connettività (ad esempio il GPS) supportano i sistemi di sicurezza e di guida semi-autonoma.

All'aumentare del numero di collegamenti dei veicoli, aumenta anche l'area della potenziale superficie di attacco del veicolo. Le connessioni portano con sé una serie di problemi di sicurezza informatica simili a quelli dell’elettronica di consumo. Tuttavia, mentre i riavvii, gli aggiornamenti giornalieri delle patch e i comportamenti inspiegabili sono la norma per l’elettronica di consumo, sono incoerenti per i prodotti con sistemi critici per la sicurezza come i veicoli.

I produttori devono adottare un approccio proattivo per garantire la continua sicurezza di un prodotto sul campo. In breve, i produttori devono essere consapevoli delle vulnerabilità note della sicurezza del prodotto e adottare un approccio basato sul rischio per affrontarle.

Garantire la sicurezza a lungo termine

Un veicolo connesso è spesso dotato di una o più unità di controllo elettronico (ECU) che includono più componenti software come sistema operativo, librerie, utilità, ecc. I produttori dovrebbero tenere traccia di tali componenti e identificare le vulnerabilità note pubblicate con analisi proattive, tra cui:

• Valutare regolarmente il prodotto rispetto al database delle vulnerabilità e delle esposizioni comuni (CVE).
• Raccolta di informazioni per individuare eventuali falle di sicurezza relative ai prodotti.
• Test di sicurezza.
• Analisi attiva dei bollettini sulla sicurezza Android.

Esempio di aggiornamenti del sistema operativo e delle patch di sicurezza (IVI con Android):

Figura 1. Esempio di implementazione dei principali sistemi operativi e aggiornamenti di sicurezza nel corso della vita del veicolo.

Migliori pratiche di sicurezza

Per rendere più difficili le compromissioni della sicurezza, Google consiglia e utilizza le best practice comunemente accettate per la sicurezza e l'ingegneria del software, come descritto in Implementazione della sicurezza .

Linee guida per la sicurezza

Le pratiche consigliate per la sicurezza includono:

• Utilizza le versioni più recenti di librerie esterne e componenti open source.
• Non includere funzionalità di debug intrusive nelle versioni di rilascio del sistema operativo.
• Rimuovere le funzionalità inutilizzate (per ridurre la superficie di attacco non necessaria).
• Utilizza il principio del privilegio minimo e altre best practice per lo sviluppo di app Android .

Linee guida per lo sviluppo del software

Le pratiche consigliate per lo sviluppo sicuro del software per il ciclo di vita del sistema includono:

• Esegui la modellazione delle minacce per classificare e identificare risorse, minacce e potenziali mitigazioni.
• Eseguire la revisione dell'architettura/design per garantire una progettazione sicura e solida.
• Esegui revisioni regolari del codice per identificare anti-pattern e bug il prima possibile.
• Progettare, implementare ed eseguire test unitari di copertura ad alto codice, tra cui:
  • Test funzionali (compresi casi di test negativi)
  • Test di regressione regolari (per garantire che i bug risolti non riemergano)
  • Test fuzz (come parte della suite di test unitari)
• Utilizzare strumenti di analisi del codice sorgente statico (scan-build, lint, ecc.) per identificare potenziali problemi.
• Utilizza strumenti di analisi dinamica del codice sorgente, come AddressSanitizer, UnfineBehaviorSanitizer e FORTIFY_SOURCE (per componenti nativi) per identificare e mitigare potenziali problemi durante lo sviluppo del sistema.
• Avere una strategia di gestione per il codice sorgente del software e la configurazione/versione del rilascio.
• Avere una strategia di gestione delle patch per la generazione e la distribuzione delle patch software.

Politica del backport di sicurezza

Google attualmente fornisce supporto attivo per i backport di sicurezza delle vulnerabilità di sicurezza scoperte e segnalate per tre (3) anni dal rilascio pubblico a livello API . Il sostegno attivo consiste in:

1. Ricevi ed esamina i rapporti sulle vulnerabilità.
2. Crea, testa e rilascia aggiornamenti di sicurezza.
3. Fornire versioni ricorrenti degli aggiornamenti di sicurezza e dettagli sui bollettini sulla sicurezza.
4. Eseguire la valutazione della gravità secondo le linee guida stabilite.

Dopo tre anni dalla data di rilascio pubblico del livello API, Google consiglia le seguenti linee guida:

• Utilizzare una terza parte (come il fornitore del SoC o il provider del kernel) per il supporto del backport per gli aggiornamenti di sicurezza del sistema operativo più vecchi di tre anni dal rilascio dell'API.
• Utilizzare una terza parte per eseguire revisioni del codice utilizzando gli ASB forniti pubblicamente. Mentre gli ASB identificano le vulnerabilità per la versione attualmente supportata, un produttore può utilizzare le informazioni fornite per confrontare gli aggiornamenti appena rilasciati con le versioni precedenti. Questi dati possono essere utilizzati per eseguire analisi di impatto e potenzialmente generare patch simili per versioni del sistema operativo precedenti a tre anni dal rilascio dell'API.
• Se opportuno, carica gli aggiornamenti di sicurezza nel progetto Android Open Source (AOSP).
• Il produttore deve coordinare la gestione degli aggiornamenti di sicurezza per il codice specifico del fornitore (ad esempio, codice specifico del dispositivo proprietario).
• Il produttore deve aderire al gruppo di notifica NDA Android Security Bulletin Partner Preview (richiede la firma di accordi legali come lo Developer NDA). I bollettini dovrebbero includere:
  • Annunci
  • Riepilogo dei problemi per livello di patch, inclusi CVE e gravità
  • Dettagli sulla vulnerabilità, ove appropriato

Riferimenti aggiuntivi

Per istruzioni sulla codifica sicura e sulle pratiche di sviluppo software, fare riferimento a quanto segue:

• Associazione per l'affidabilità del software dell'industria automobilistica (MISRA) .
• Strumenti e metodi del Software Engineering Institute (SEI) .
• Istituto nazionale di standard e tecnologia (NIST).

Pratiche di prodotto consigliate

Google incoraggia l'utilizzo delle seguenti pratiche consigliate.

Linee guida generali per il lancio

In genere si consiglia di avviare qualsiasi prodotto connesso con la versione più recente del sistema operativo e un produttore dovrebbe tentare di utilizzare la versione del sistema operativo più recente prima di lanciare il prodotto. Sebbene il blocco della versione sia necessario per garantire la stabilità prima del test e della convalida, il produttore deve bilanciare la stabilità del prodotto ottenuta dalle versioni precedenti del sistema operativo con le versioni più recenti del sistema operativo che presentano meno vulnerabilità di sicurezza note e protezioni di sicurezza avanzate.

Le linee guida consigliate includono:

• A causa dei lunghi tempi di sviluppo inerenti al processo di sviluppo del veicolo, i produttori potrebbero dover lanciare il sistema operativo con la versione n-2 o precedente.
• Mantieni la conformità con la compatibilità Android per ogni versione rilasciata del sistema operativo Android con una campagna over-the-air (OTA).
• Implementa il prodotto Android Firmware-over-the-air (FOTA) compatibile per aggiornamenti rapidi e di facile utilizzo. La FOTA dovrebbe essere eseguita utilizzando le migliori pratiche di sicurezza come la firma del codice e la connessione TLS tra il prodotto e il backoffice IT.
• Segnalare le vulnerabilità della sicurezza Android identificate in modo indipendente al team di sicurezza Android.

Nota: Google ha preso in considerazione il tipo di dispositivo o le notifiche specifiche del settore nei bollettini sulla sicurezza Android. Tuttavia, poiché Google non conosce il kernel, i driver o i chipset di un determinato dispositivo (veicolo, TV, dispositivo indossabile, telefono e così via), non dispone di un metodo deterministico per etichettare qualsiasi problema di sicurezza con un tipo di dispositivo. .

Linee guida sul ciclo del prodotto

Il produttore dovrebbe fare ogni tentativo per utilizzare la versione più recente del sistema operativo o gli aggiornamenti di sicurezza per la versione in uso durante i miglioramenti del ciclo del prodotto. Gli aggiornamenti possono essere eseguiti durante gli aggiornamenti periodici ricorrenti del prodotto o per gli hotfix per risolvere problemi di qualità e/o altri problemi. Le pratiche consigliate includono:

• Creare un piano per affrontare gli aggiornamenti di driver, kernel e protocollo.
• Utilizzare un metodo appropriato per il settore per fornire aggiornamenti ai veicoli distribuiti.

Documento di definizione della compatibilità (CDD)

Il Compatibility Definition Document (CDD) descrive i requisiti affinché un dispositivo possa essere considerato compatibile con Android. Il CDD è pubblico e disponibile a tutti; puoi scaricare le versioni CDD da Android 1.6 alla versione più recente da source.android.com .

Soddisfare questi requisiti per un prodotto implica i seguenti passaggi fondamentali:

1. Il partner firma l'impegno di compatibilità Android (ACC) con Google. Viene quindi assegnato un consulente per soluzioni tecniche (TSC) come guida.
2. Il partner completa la revisione CDD per la versione del sistema operativo Android del prodotto.
3. Il partner esegue e invia i risultati CTS (descritti di seguito) finché i risultati non sono accettabili per la compatibilità Android.

Suite di test di compatibilità (CTS)

Lo strumento di test Compatibility Test Suite (CTS) verifica che l'implementazione di un prodotto sia compatibile con Android e che siano incluse le patch di sicurezza più recenti. CTS è pubblico, open source e disponibile a tutti; puoi scaricare le versioni CTS da Android 1.6 alla versione più recente da source.android.com .

Ogni build di software Android rilasciata al pubblico (immagini di installazione di fabbrica e di aggiornamento sul campo) deve dimostrare la compatibilità con Android attraverso i risultati CTS. Ad esempio, se il dispositivo esegue Android 7.1, è necessario fare riferimento all'ultima versione corrispondente di CDD 7.1 e CTS 7.1 quando viene creata e testata un'immagine di build con intento di rilascio. I produttori sono fortemente incoraggiati a utilizzare CTS tempestivamente e frequentemente per identificare e risolvere i problemi.

Flusso di lavoro CTS

Il flusso di lavoro CTS prevede la configurazione dell'ambiente di test, l'esecuzione dei test, l'interpretazione dei risultati e la comprensione del codice sorgente CTS. Le seguenti linee guida hanno lo scopo di aiutare gli utenti di CTS (ad esempio, sviluppatori, produttori) a utilizzare il CTS in modo efficace ed efficiente.

• Esegui frequentemente i test . CTS è progettato come uno strumento automatizzato che si integra nel tuo sistema di build. L'esecuzione frequente di CTS può aiutarti a individuare i difetti in modo rapido e tempestivo quando si verificano degrado o regressioni del software.
• Scarica ed esamina il codice sorgente CTS . Il codice sorgente CTS completo è un software open source che chiunque può scaricare e utilizzare (il codice sorgente scaricato è completamente costruibile ed eseguibile). Quando un test sul dispositivo fallisce, esaminare la sezione pertinente del codice sorgente può aiutarti a identificarne il motivo.
• Ottieni l'ultimo CTS . Le nuove versioni di Android possono aggiornare il CTS con correzioni di bug, miglioramenti e nuovi test. Controlla frequentemente i download CTS e aggiorna il tuo programma CTS se necessario. Il produttore e Google concorderanno sulla versione CTS da passare per il lancio del prodotto poiché il prodotto deve essere congelato ad un certo punto mentre il CTS continua ad essere aggiornato.

Supera il CTS

Per un prodotto compatibile con Android, Google garantisce che i risultati dei test dei report CTS e CTS Verifier del dispositivo siano accettabili. In linea di principio, tutti i test devono essere superati. Tuttavia, un test che fallisce per ragioni diverse dalla mancata conformità del dispositivo ai requisiti di compatibilità Android è soggetto a revisione da parte di Google. Durante questo processo:

1. Il produttore fornisce a Google le patch CTS proposte, le convalide delle patch e le giustificazioni per dimostrare l'argomentazione.
2. Google esamina il materiale inviato e, se accettato, aggiorna i test CTS pertinenti in modo che il dispositivo superi la successiva revisione del CTS.

Se un test CTS fallisce improvvisamente dopo l'applicazione di una patch di sicurezza, il produttore deve modificare la patch in modo che non interrompa la compatibilità OPPURE mostrare che il test è sbagliato e fornire una correzione per il test (come descritto sopra).

Il CTS rimane aperto per la revisione delle correzioni dei test. Ad esempio, Android 4.4 continua ad accettare correzioni (vedi https://android-review.googlesource.com/#/c/273371/ ).

Domande frequenti (FAQ)

D: Chi è responsabile dell'applicazione degli aggiornamenti di sicurezza a un'implementazione specifica di Android?

R: Il produttore che fornisce direttamente il dispositivo è responsabile. Questa entità non è Google, che pubblica aggiornamenti di sicurezza in AOSP e non per un dispositivo specifico (come un veicolo).

D: In che modo Google gestisce i problemi di sicurezza in Android?

R: Google indaga continuamente sui problemi e sviluppa potenziali soluzioni, che Google rende disponibili a tutti i livelli API supportati come parte del regolare processo di aggiornamento della sicurezza. Dall'agosto 2015, Google ha mantenuto una cadenza regolare nella pubblicazione di bollettini e collegamenti agli aggiornamenti su source.android.com ; Google pubblica anche aggiornamenti di sicurezza come parte delle principali versioni del sistema operativo. Vedi anche la policy del backport di sicurezza .

D: Se un produttore ha integrato tutte le patch AOSP di un ASB ma non ha integrato le patch del fornitore BSP menzionato nello stesso bollettino, può comunque aumentare il livello di sicurezza (ad esempio, applicare la patch corrispondente alla piattaforma/build)?

R: Per dichiarare un livello di patch di sicurezza (SPL) Android, un produttore deve risolvere tutti i problemi richiesti pubblicati nell'Android Security Bulletin ( inclusi i bollettini precedenti ) e associati a un particolare Android SPL. Ad esempio, un produttore che utilizza il bollettino sulla sicurezza di marzo 2017 (2017-03-01 SPL) ha risolto tutti i problemi richiesti documentati nel bollettino di marzo 2017 per tale SPL e tutti gli aggiornamenti precedenti, inclusi gli aggiornamenti specifici del dispositivo per tutti i precedenti bollettini sulla sicurezza Android, inclusi gli aggiornamenti specifici del dispositivo associati alla SPL del 05-02-2017.

D: Cosa succede quando il produttore non accetta gli aggiornamenti di sicurezza forniti dal fornitore BSP OPPURE quando gli aggiornamenti di sicurezza richiesti da un ASB non vengono forniti dai fornitori?

R: Un ASB descrive le vulnerabilità della sicurezza (elencate da un elenco di CVE) e spesso fornisce test di sicurezza corrispondenti. L'obiettivo è garantire che le vulnerabilità elencate non possano più essere riprodotte su un dispositivo e che il dispositivo possa superare i test di sicurezza associati. Pertanto, il problema non riguarda l'adozione di un aggiornamento di sicurezza fornito da Google o da un fornitore di terze parti, ma il produttore che attesta che il dispositivo non è vulnerabile all'elenco dei CVE nell'ASB. Il produttore è libero di utilizzare gli aggiornamenti di sicurezza forniti o, se dispone di una modifica più adatta al proprio dispositivo, utilizzare invece tale modifica.

Consideriamo ad esempio il caso in cui Google risolve una vulnerabilità di sicurezza AOSP utilizzando una modifica del codice che consente al componente di rimanere pienamente funzionale e conforme alla CDD. Se il produttore determina che il componente non è necessario sul dispositivo o non è richiesto dal CDD (o dai relativi test di certificazione), può rimuovere il componente per ridurre le future esigenze di manutenzione e ridurre la superficie di attacco. Anche se il produttore non ha utilizzato l'aggiornamento di sicurezza fornito, ha garantito che il dispositivo non fosse vulnerabile al CVE documentato nel bollettino sulla sicurezza. Tuttavia, deviando dall'aggiornamento di sicurezza consigliato, il produttore corre il rischio di affrontare il problema in modo errato, introducendo nuove vulnerabilità di sicurezza o riducendo in altro modo la funzionalità della build finale.

Mentre collaboriamo con tutti i partner SoC per garantire che esistano soluzioni per tutti i problemi in un ASB, consigliamo ai produttori di stipulare un accordo di assistenza con i fornitori di SoC per il ciclo di vita di un dispositivo. I SoC potrebbero interrompere la manutenzione di un chipset prima del previsto, quindi stabilire accordi prima della selezione del chipset del dispositivo è una parte importante del processo di lancio del dispositivo.

Infine, nei casi in cui sia impossibile acquisire direttamente o creare in modo indipendente una correzione per un problema documentato in un ASB, un produttore potrebbe mantenere la precedente SPL di Android e comunque aggiungere le nuove correzioni disponibili alla build. Tuttavia, questa pratica alla fine porterà a problemi con la certificazione della build (poiché Android garantisce che sui dispositivi certificati sia disponibile il livello di patch di sicurezza più recente). Google consiglia di lavorare in anticipo con il tuo SoC per evitare questa pratica.

D: Se il produttore determina che un articolo ASB non è applicabile al suo prodotto, è comunque necessario applicare o applicare patch all'articolo per soddisfare gli altri requisiti di Google o per superare il CTS?

R: Non è necessario acquisire patch per dichiarare un livello di patch di sicurezza Android (SPL); richiediamo che il produttore attesti che la sua build non è vulnerabile al problema.

Un esempio è il caso in cui un componente a cui viene applicata una patch non esiste nel sistema del produttore oppure un componente viene rimosso dal sistema del produttore per risolvere un problema. In tal caso il sistema potrebbe essere conforme senza richiedere al produttore di adottare una patch.

Ciò è fondamentalmente diverso dal fatto che un produttore voglia, ad esempio, correggere solo le patch critiche, senza adottare altre patch applicabili che potrebbero causare il fallimento di un test di sicurezza. In questo caso si presuppone che la SPL non sia stata rispettata.