Développement d'applications mobiles d'entreprise : stratégie, architecture et processus

La norme de référence est la « Mobile Application Security Verification Standard » (MASVS) de l’OWASP, actuellement en version 2.1.0. Elle fournit un cadre couvrant huit domaines distincts, répartis en 24 contrôles différents, portant sur le stockage, la cryptographie, l’authentification, les communications réseau, l’interaction avec la plateforme, la qualité du code, la résilience et la confidentialité. Un test d'intrusion mobile est généralement évalué selon la norme MASVS, qui sert de référence commune entre votre équipe de sécurité, le fournisseur de l'application mobile et même tout auditeur. Au stade de l’appel d’offres, n’hésitez pas à demander à un fournisseur selon quel profil de test du « Mobile Application Security Testing Guide » (MASTG) il élabore ses tests, et à consulter les résultats de ces tests. Alors que la norme MASVS définit les contrôles de sécurité qui doivent être mis en œuvre, le MASTG fournit les procédures de test spécifiques et les directives techniques permettant de vérifier ces contrôles.

Certaines entreprises s’appuient sur le modèle “ Zero Trust ” pour définir leurs politiques de gestion des appareils mobiles (MDM). Cela implique la mise en place de contrôles de l’état des appareils et de décisions d’accès contextuelles. Cela revêt d’autant plus d’importance aujourd’hui que le « Bring Your Own Device » (BYOD) est devenu la norme. On estime que les deux tiers des appareils accédant aux données de l’entreprise appartiennent à des particuliers. C’est pourquoi la gestion varie en fonction du propriétaire de l’appareil. Les appareils d’entreprise sont gérés via le MDM. Dans ce cas, le service IT contrôle l’intégralité de l’appareil. Les appareils personnels sont gérés via la gestion des applications mobiles (MAM) et les politiques de sécurité des applications. Les données et applications d’entreprise sont stockées dans un conteneur que le service IT peut supprimer de son propre chef, tandis que le reste du téléphone reste hors du champ d’application du système.

Lors du développement d'applications destinées à des secteurs réglementés, l'architecture de sécurité doit être conforme aux exigences légales applicables. Par exemple, le RGPD régit le traitement des données à caractère personnel des résidents de l’UE ; la loi HIPAA protège les informations de santé protégées (PHI) détenues par les organisations soumises à cette loi et leurs partenaires commerciaux aux États-Unis ; et la norme PCI DSS définit des exigences de contrôle pour les organisations qui traitent les données des titulaires de cartes bancaires. En outre, les organisations peuvent être amenées à se conformer à des normes ou réglementations sectorielles, telles que les rapports SOC 2, les directives de la FFIEC ou les exigences bancaires locales, en fonction de leur contexte opérationnel spécifique et de leur secteur d’activité.

La gouvernance est souvent abordée en dernier, mais elle est essentielle dès le début. Avant le lancement, vous devez déterminer à qui appartiendra l’application après sa mise en production, qui approuvera sa version pour une utilisation en environnement de production, quelles sont les conditions du SLA en matière d’assistance, et comment l’unité opérationnelle peut demander des modifications. Vous devez aborder deux aspects opérationnels dans un seul document : la rotation des certificats et des clés, et ce qu’il advient des données d’entreprise stockées sur un appareil lorsqu’un salarié quitte l’entreprise.