Sicurezza organizzativa e operativa

Le basi di buone pratiche di sicurezza iniziano nella tua organizzazione.

Crea un team per la sicurezza e la privacy

Crea un team dedicato alla sicurezza e alla privacy e stabilisci un leader per questa organizzazione.

  • Costruisci una squadra di sicurezza.
    • Garantire che almeno un dipendente sia responsabile della sicurezza, della privacy e della risposta agli incidenti.
    • Definire una missione e un ambito per questo team.
    • Sviluppare un organigramma e descrizioni del lavoro per: Responsabile della sicurezza, Ingegnere della sicurezza, Responsabile degli incidenti.
    • Assumi dipendenti o collaboratori esterni per ricoprire questi ruoli.
  • Definire un ciclo di vita dello sviluppo della sicurezza (SDL) . Il tuo SDL dovrebbe coprire queste aree:
    • Requisiti di sicurezza per i prodotti.
    • Analisi del rischio e modellazione delle minacce.
    • Analisi statica e dinamica di applicazioni e codice.
    • Processi finali di revisione della sicurezza per i prodotti.
    • Risposta all'incidente.
  • Valutare il rischio organizzativo . Creare una valutazione del rischio e sviluppare piani per eliminare o mitigare tali rischi.

Costruisci il processo di verifica

Valuta le lacune nei processi di verifica e approvazione della build interna esistente.

  • Identifica eventuali lacune nel processo di verifica della build attuale che potrebbero portare all'introduzione di un'applicazione potenzialmente dannosa (PHA) nella tua build.
  • Assicurati di disporre di un processo di revisione e approvazione del codice, anche per le patch interne ad AOSP .
  • Migliora l'integrità della build implementando controlli in queste aree:
    • Tenere traccia delle modifiche . Tieni traccia degli ingegneri del software; conservare i registri delle modifiche.
    • Valutare il rischio . Valutare le autorizzazioni utilizzate da un'app; richiedono la revisione manuale delle modifiche al codice.
    • Tenere sotto controllo . Valutare le modifiche apportate al codice privilegiato.

Monitoraggio delle modifiche al codice sorgente

Monitora eventuali modifiche involontarie del codice sorgente o di app/file binari/SDK di terze parti.

  • Valutare le partnership . Valutare il rischio di collaborare con un partner tecnico utilizzando i seguenti passaggi:
    • Stabilire criteri su come valutare il rischio di lavorare con un fornitore specifico.
    • Crea un modulo che chieda al fornitore come risolve gli incidenti e gestisce la sicurezza e la privacy.
    • Verificare le loro affermazioni con un audit periodico.
  • Tenere traccia delle modifiche . Registra quali aziende e dipendenti modificano il codice sorgente e conduci controlli periodici per garantire che vengano apportate solo le modifiche appropriate.
  • Tienine traccia . Registra quali aziende aggiungono file binari di terze parti alla tua build e documenta quale funzione svolgono tali app e quali dati raccolgono.
  • Aggiornamenti del piano . Assicurati che i tuoi fornitori siano tenuti a fornire aggiornamenti software per l'intera vita del tuo prodotto. Le vulnerabilità impreviste potrebbero richiedere il supporto dei fornitori per essere risolte.

Convalidare l'integrità e il pedigree del codice sorgente

Ispeziona e convalida il codice sorgente fornito da un produttore del dispositivo originale (ODM), un aggiornamento via etere (OTA) o un operatore.

  • Gestire i certificati di firma .
    • Archivia le chiavi in ​​un modulo di sicurezza hardware (HSM) o in un servizio cloud sicuro (non condividerle).
    • Garantire che l'accesso ai certificati di firma sia controllato e verificato.
    • Richiedi che tutta la firma del codice venga eseguita nel tuo sistema di build.
    • Revocare le chiavi smarrite.
    • Genera chiavi utilizzando le migliori pratiche.
  • Analizzare il nuovo codice . Testa il codice appena aggiunto con strumenti di analisi del codice di sicurezza per verificare l'introduzione di nuove vulnerabilità. Inoltre, analizza la funzionalità complessiva per rilevare l'espressione di nuove vulnerabilità.
  • Rivedere prima di pubblicare . Cerca le vulnerabilità della sicurezza nel codice sorgente e nelle app di terze parti prima di metterle in produzione. Per esempio:
    • Richiedi alle app di utilizzare comunicazioni sicure.
    • Segui il principio del privilegio minimo e concedi il set minimo di autorizzazioni necessarie per il funzionamento dell'app.
    • Garantire che i dati vengano archiviati e trasferiti su canali sicuri.
    • Mantieni aggiornate le dipendenze del servizio.
    • Applica patch di sicurezza agli SDK e alle librerie open source.

Risposta all'incidente

Android crede nel potere di una solida community di sicurezza che aiuta a individuare i problemi. Dovresti creare e pubblicizzare un modo in cui soggetti esterni possano contattarti in merito a problemi di sicurezza specifici del dispositivo.

  • Stabilire un contatto . Crea un indirizzo email, ad esempio your-company o un sito Web con istruzioni chiare per segnalare potenziali problemi di sicurezza associati al tuo prodotto ( esempio ).
  • Stabilire un programma di premi per la vulnerabilità (VRP) . Incoraggia i ricercatori di sicurezza esterni a inviare rapporti sulle vulnerabilità della sicurezza che influiscono sui tuoi prodotti offrendo premi in denaro per invii validi ( esempio ). Consigliamo di premiare i ricercatori con premi competitivi nel settore, come 5.000 dollari per le vulnerabilità di gravità critica e 2.500 dollari per le vulnerabilità di gravità elevata.
  • Contribuire ai cambiamenti a monte . Se vieni a conoscenza di un problema di sicurezza che interessa la piattaforma Android o i dispositivi di più produttori, contatta il team di sicurezza Android inviando una segnalazione di bug di sicurezza .
  • Promuovere buone pratiche di sicurezza . Valuta in modo proattivo le pratiche di sicurezza dei fornitori di hardware e software che forniscono servizi, componenti e/o codice per i tuoi dispositivi. Ritenere i fornitori responsabili del mantenimento di un buon livello di sicurezza.