Les bonnes pratiques de sécurité commencent dans votre organisation.
Créer une équipe chargée de la sécurité et de la confidentialité
Créez une équipe dédiée à la sécurité et à la confidentialité, et désignez un responsable pour cette organisation.
- Créez une équipe de sécurité.
- Assurez-vous qu'au moins un employé est responsable de la sécurité, de la confidentialité et de la gestion des incidents.
- Définissez une mission et un champ d'application pour cette équipe.
- Élaborez un organigramme et des descriptions de poste pour les postes suivants: responsable de la sécurité, ingénieur de la sécurité et responsable de la gestion des incidents.
- embaucher des employés ou des sous-traitants externes pour occuper ces rôles.
- Définir un cycle de développement de la sécurité (SDL) Votre SDL doit couvrir les domaines suivants :
- Exigences de sécurité pour les produits
- Analyse des risques et modélisation des menaces
- Analyse statique et dynamique des applications et du code.
- Processus d'examen de sécurité final pour les produits.
- Réponse aux incidents
- Évaluer les risques organisationnels Créez une évaluation des risques et élaborez des plans pour les éliminer ou les atténuer.
Processus de validation du build
Évaluez les lacunes de vos processus de vérification et d'approbation internes existants.
- Identifiez les lacunes de votre processus de validation de compilation actuel qui pourraient entraîner l'introduction d'une application potentiellement dangereuse (PHA) dans votre build.
- Assurez-vous de disposer d'un processus d'examen et d'approbation du code, même pour les correctifs internes à AOSP.
- Améliorez l'intégrité de la compilation en implémentant des contrôles dans les domaines suivants :
- Suivez les modifications. Suivre les ingénieurs logiciels ; tenir des journaux de modifications.
- Évaluez les risques. Évaluez les autorisations utilisées par une application. Exigez un examen manuel des modifications de code.
- Surveillance Évaluer les modifications apportées au code privilégié
Suivi des modifications du code source
Surveillez les modifications involontaires du code source ou des applications tierces / binaires / SDK.
- Évaluer les partenariats Évaluez le risque de travailler avec un partenaire technique en procédant comme suit :
- Définissez des critères pour évaluer le risque de travailler avec un fournisseur spécifique.
- Créez un formulaire qui demande au fournisseur comment il résout les incidents et gère la sécurité et la confidentialité.
- Vérifiez leurs affirmations à l'aide d'un audit périodique.
- Suivez les modifications. Enregistrez les entreprises et les employés qui modifient le code source, et effectuez des audits périodiques pour vous assurer que seules les modifications appropriées sont apportées.
- Tenir des registres Notez les entreprises qui ajoutent des binaires tiers à votre build, et documentez la fonction de ces applications et les données qu'elles collectent.
- Planifiez les mises à jour. Assurez-vous que vos fournisseurs sont tenus de fournir des mises à jour logicielles pendant toute la durée de vie de votre produit. Des failles imprévues peuvent nécessiter l'aide des fournisseurs pour être corrigées.
Valider l'intégrité et la filiation du code source
Inspectez et validez le code source fourni par un fabricant d'appareil d'origine (OEM), une mise à jour Over-the-air (OTA) ou un opérateur.
- Gérer les certificats de signature
- Stockez les clés dans un module de sécurité matérielle (HSM) ou un service cloud sécurisé (ne les partagez pas).
- Assurez-vous que l'accès aux certificats de signature est contrôlé et audité.
- Exiger que toute signature de code soit effectuée dans votre système de compilation.
- Révoquer des clés perdues.
- Générez des clés en suivant les bonnes pratiques.
- Analyser le nouveau code Testez le code nouvellement ajouté à l'aide d'outils d'analyse du code de sécurité pour vérifier l'introduction de nouvelles failles. De plus, analysez la fonctionnalité globale pour détecter l'expression de nouvelles failles.
- Vérifiez avant de publier. Recherchez les failles de sécurité dans le code source et les applications tierces avant de les mettre en production. Par exemple :
- Exiger que les applications utilisent une communication sécurisée.
- Suivez le principe du moindre privilège et accordez l'ensemble minimal d'autorisations nécessaires au fonctionnement de l'application.
- Assurez-vous que les données sont stockées et transférées via des canaux sécurisés.
- Maintenez les dépendances de service à jour.
- Appliquez des correctifs de sécurité aux SDK et aux bibliothèques Open Source.
Gestion des incidents
Android croit en la puissance d'une communauté de sécurité solide pour aider à détecter les problèmes. Vous devez créer et rendre public un moyen pour les parties externes de vous contacter au sujet de problèmes de sécurité spécifiques à l'appareil.
- Contactez-les. Créez une adresse e-mail, par exemple security@your-company.com, ou un site Web contenant des instructions claires pour signaler les problèmes de sécurité potentiels associés à votre produit (exemple).
- Mettre en place un programme de récompense pour la détection de failles Encouragez les chercheurs en sécurité externes à envoyer des rapports sur les failles de sécurité affectant vos produits en leur proposant des récompenses financières pour les envois valides (exemple). Nous vous recommandons de récompenser les chercheurs avec des récompenses compétitives dans le secteur, comme 5 000 $pour les failles de gravité critique et 2 500 $pour les failles de gravité élevée.
- Contribuez à apporter des modifications en amont. Si vous constatez un problème de sécurité affectant la plate-forme Android ou les appareils de plusieurs fabricants, contactez l'équipe de sécurité Android en envoyant un rapport de bug de sécurité.
- Promouvoir de bonnes pratiques de sécurité Évaluez de manière proactive les pratiques de sécurité des fournisseurs de matériel et de logiciels qui fournissent des services, des composants et/ou du code pour vos appareils. Demandez aux fournisseurs de maintenir un niveau de sécurité optimal.