La sécurité est devenue une composante essentielle du processus de conception des applications destinées au grand public. Tout le monde a déjà reçu des patchs de sécurité sur son téléphone à télécharger ? Toutefois, les applications d’entreprises sont, elles aussi, exposées à des menaces internes ou à des attaquants extérieurs qui parviennent à y accéder par des moyens détournés, notamment via des codes d’accès compromis ou encore en infectant des postes de travail à l’aide d’un logiciel malveillant. Les cyberattaquants en sont conscients : en 2020, près de 55 %[1] des attaques décelées avaient pour cible des applications spécifiques ou des applications Web. La mobilité, favorisée par le télétravail en temps de crise a joué également sur l’augmentation des applications mobiles professionnelles telles que les solutions de travail collaboratif.
Pour autant comment expliquer que ces applications soient autant vulnérables ?
De nombreuses entreprises se reposent sur des applications sur mesure pour mener certaines de leurs opérations essentielles. Toutefois, beaucoup d’applications, même si les fonctionnalités qu’elles comportent sont uniques, sont susceptibles d’être piratées à l’aide de quelques techniques bien connues. La raison ? Les développeurs ont tendance à répéter toujours les mêmes erreurs ; souvent, la manière la plus facile et la plus évidente de développer une application comporte des vulnérabilités inhérentes sur le plan de la sécurité.
Malheureusement, concevoir, mettre au point et assurer la maintenance d’une application sécurisée est loin d’être facile. D’importantes décisions doivent être prises lors de la phase de conception, qui détermineront le niveau de risque global d’une application et les manières de circonscrire ce risque. Une liste des failles de sécurité critiques parmi les plus communes est d’ailleurs publiée dans le Top 10 d’OWASP et devrait systématiquement servir de référence aux développeurs.
Le concept de « Secure by design » ou de sécurité dès la conception fait son chemin depuis plusieurs années, bénéficiant d’un changement de mentalité autour de la sécurité au sein des entreprises : la mauvaise habitude de le percevoir comme un frein se dissipe peu à peu pour laisser place à une prise de conscience au plus haut niveau.
Dans les faits, le « Secure by design » va au-delà du simple codage habituel. Il est important de ne pas chercher à réinventer la roue lorsqu’il s’agit des processus de sécurité essentiels, comme le chiffrement et l’authentification (y compris la fonction « mot de passe perdu »). Pour cela, l’équipe de développement devrait utiliser des mécanismes de chiffrement et d’authentification qui ont fait publiquement leurs preuves. Toute tentative d’en créer soi-même débouche presque toujours sur l’introduction d’erreurs que d’autres avaient déjà commises auparavant (et dont ils ont su tirer les leçons). La création de logithèques pourrait répondre à cette problématique. Ces dernières recensent les codes qui régissent les fonctions critiques au sein de l’application et qui peuvent mener à une faille de sécurité (par exemple, concernant l’entrée utilisateur, l’authentification, l’accès à la base de données ou aux fichiers) afin que ceux-ci soient minutieusement examinés puis validés. Les développeurs devraient se référer à ces logithèques non seulement pour rendre les pratiques de codages cohérentes, mais aussi afin d’éviter les erreurs.
D’ailleurs, une des erreurs récurrentes est de se servir des applications pour la collecte ou le stockage de données sensibles lorsque ce n’est pas utile. Toute donnée sensible recueillie temporairement devrait être supprimée lorsqu’elle n’est plus nécessaire afin de limiter la quantité d’informations auxquelles un cybercriminel a accès en cas d’attaque réussie. Si des données sensibles sont collectées, elles devraient être chiffrées. Cela inclut le chiffrement des données au repos lorsque celles-ci sont stockées dans un fichier ou une base de données, ainsi que pendant les opérations de transfert entre l’application et l’utilisateur ou tout autre système connecté.
La dernière étape de la phase de concept reste encore et toujours le test. Simuler régulièrement des attaques intrusives sur une application permet de repérer les vulnérabilités qui ont échappé aux contrôles internes et de couper l’herbe sous le pied des cybercriminels. Il est également important d’anticiper la maintenance à long terme d’une application, car il est impossible de prévoir quand une nouvelle faille pourrait être découverte et avoir besoin d’être comblée.
Enfin, il est également essentiel de garder à l’esprit que, comme pour tout ce qui concerne la sécurité des systèmes d’information, il n’existe pas de solution uniforme. Les entreprises devraient d’abord évaluer l’efficacité des précautions de sécurité existantes pour évoluer vers un environnement plus sécurisé. Les précautions citées permettent de gérer efficacement ce processus et d’intégrer les principes de « Secure by Design » aux activités de développement logiciel.
Par Marc Ogoli-Socin, Cyber Security Manager Chez NTT LTd
[1] Le Global Threat Intelligence Report de NTT
