Il n’est pas forcément aisé d’introduire des correctifs de sécurité ou des normes de codage dans un projet considéré comme ‘terminé’, c’est donc juste du bon sens de prévoir ces paramètres en amont. En effet, plutôt que de corriger les problèmes de sécurité, l’idée est d’identifier les vulnérabilités, d’anticiper les potentielles défaillances et d’intégrer la sécurité en amont, très tôt dans le cycle avec l’approche ‘Security by Design’.

Cette approche a également un intérêt économique non négligeable en limitant les incidents mais également en minimisant les éventuels dommages lors de la survenue de problèmes.

Un logiciel ‘Secure by Design’ est un logiciel dont les facteurs de risque et les aspects de sécurité ont été intégrés dès la conception. Son architecture est pensée pour garantir la sécurité tout au long de son cycle de vie.

Les grands principes de Security by Design

L’objectif est de comprendre et d’identifier les éventuelles menaces auxquels le système pourrait être exposé et notamment :

Minimiser la surface d’attaque : elle peut être logicielle (OS, librairie, accès), réseau (ports ouverts, IP, flux, protocoles), humaine. Plus la surface est étendue, plus les moyens de contrôle seront complexes à mettre en œuvre.

Distinguer et restreindre les privilèges : une répartition claire des tâches, une séparation des rôles, et une attribution des droits en fonction de ces critères permet de garantir le cloisonnement d’un environnement

Rester vigilant vis-à-vis des tiers : exécuter des analyses de vulnérabilité et des tests de pénétration pour améliorer votre posture de cyber sécurité.

Défendre en profondeur : faire reposer la sécurité sur un ensemble d’éléments cohérents plutôt que sur un élément isolé

Cependant, la démarche Security by Design ne doit pas se cantonner à la phase de conception, elle doit pouvoir évoluer tout au long du cycle de vie du logiciel.

Le DevSecOps, qui consiste à intégrer la sécurité dans la démarche DevOps, doit évidemment faire partie intégrante de cette démarche. Il s’agit non seulement de la mise en place d’environnements de tests et de la gestion de tests en continu (que ce soit les tests unitaires menés par le développeur, les tests d’intégration menés par un testeur dédié, les tests du système complet ou encore les tests d’acceptation, menés avec des utilisateurs pilotes) mais aussi et surtout d’intégrer la sécurité en amont dans la démarche DevOps.

Enfin, appliquer le concept de Sécurité as Code parait un incontournable. On parle de plus en plus d’infrastructure as Code comme l’un des piliers du DevOps. L’IaC est le fait d’appliquer les bonnes pratiques DevOps à l’infrastructure de sorte qu’elle soit automatisée, cohérente et reproductible. En appliquant le même concept à la sécurité, non seulement on rapproche les équipes mais surtout on élimine les processus de configuration manuels relatifs à la sécurité, particulièrement sources d’erreurs.

Qu’en est-il d’OWASP ?

OWASP.org (Open Web Application Security Project) fournit des bonnes pratiques et un état des lieux de la sécurité dans le développement, avec un top 10 des risques de sécurité des applications web qui a un peu évolué en 2021. Suivez le guide !

1. Contrôle d’accès défaillant
2. Défaillances cryptographiques : le risque d’exposition aux données peut être minimisé en cryptant toutes les données sensibles et en désactivant la mise en cache* de toute information sensible. En outre, les développeurs d’applications web doivent veiller à ne pas stocker inutilement des données sensibles
3. L’injection de code : le fait d’introduire du code malveillant (SQL, commande systèmes, ORM…). Des outils et des méthodes existent pour pallier ce problème, la revue de code notamment ou la mise en place d’un contrôle SQL
4. Conception non sécurisée : anticiper les contrôles de sécurité nécessaires pour se défendre contre certaines attaques
5. Mauvaise configuration de sécurité incluant XML ExternalEntity (XXE) : le meilleur moyen de prévenir les attaques XEE est de faire en sorte que les applications web acceptent un type de données moins complexe, comme JSON**, ou tout au moins de corriger les analyseurs XML et de désactiver l’utilisation d’entités externes dans une application XML
6. Composants vulnérables et obsolètes : ces composants aident les développeurs à éviter le travail redondant comme React ou les petites bibliothèques qui permettent d’ajouter des icônes de partage ou des tests a/b. Pour réduire les risques, il est préférable de supprimer les composants inutilisés
7. Authentification de mauvaise qualité : ça peut être le cas lorsque les systèmes d’authentification sont vulnérables
8. Manque d’intégrité des données, du logiciel et désérialisation : la sérialisation consiste à prendre des objets dans le code de l’application et à les convertir dans un format qui peut être utilisé à d’autres fins, comme le stockage des données sur disque ou la diffusion en continu
9. Carence des systèmes de contrôle et de journalisation : un système de journalisation et de surveillance ainsi que des plans de réponse aux incidents permet d’être informés des attaques et de réagir aussitôt
10. Falsification de requête

A lire sur le même sujet cloud native, répondre aux enjeux de sécurité