Pour éviter de retarder la livraison de vos projets IT, la sécurité doit être prise en compte dès la conception.
Sécurité et agilité ne sont pas incompatibles. Les entreprises commettent bien souvent l’erreur de sacrifier les mesures d’
Le modèle DevSecOps en trois points :
- Instaurer une culture sécurité auprès de tous les collaborateurs, en les formant aux techniques nécessaires et en les incitant à faire régulièrement de la veille technologique.
Tout le monde peut se sentir acteur de la sécurité. Mais pour cela il faut donner à ses collaborateurs le moyen d’y arriver. Cela peut se traduire par l’organisation de courtes sessions de sensibilisation autour de sujets sécurité liés à l’actualité, et pourquoi pas autour d’un petit déjeuner ? Mais aussi en permettant à ses collaborateurs de monter en compétences à l’aide de formations, éventuellement à distance grâce aux solutions d’e-learning. On peut aussi imaginer désigner un référent sécurité dans chaque équipe participant au projet. - Mettre en place des processus et des procédures liés à la sécurité alignés avec les méthodes de production agile.
L'intégration de la sécurité dans un cycle de développement agile doit commencer le plus tôt possible, soit, dans la plupart des cas, dès la phase de définition des exigences. Cette approche, appelée « Shift Security Left », permet aux organisations de disposer d'un flux de travail entièrement sécurisé à chaque étape du cycle de développement du projet.
Pour y parvenir, il faut veiller à intégrer la sécurité dans les processus opérationnels et de développement, en mettant en place des dispositifs capables de détecter et d’alerter sur les problèmes de sécurité, mais aussi pour réagir en cas d’incident.
La mise en place de ces mécanismes permet d’identifier et de traiter plus tôt les problèmes de sécurité. Ils ne doivent pas être vus comme un frein à l’innovation puisqu’ils suppriment les goulots d’étranglement et permettent de livrer plus rapidement des produits sécurisés. - Utiliser des outils dédiés et favoriser l’automatisation.
Les outils d’automatisation, par exemple, évitent les erreurs humaines dans les déploiements, car une manipulation involontaire ou des administrateurs qui ne s’appuient pas sur les mêmes standards peuvent engendrer des problèmes de sécurité. Parmi les autres outils dédiés, citons ceux qui reposent sur la découverte de vulnérabilités, comme les solutions de revue de code ou de scanners, et qui peuvent se greffer aux dispositifs existants.
L’association de ces solutions à un outil de suivi des bugs permet d’inscrire automatiquement les remédiations à effectuer dans la liste des corrections que les développeurs doivent accomplir.
Ces outils vont finalement contribuer à améliorer la rapidité d’exécution des tests de sécurité et leur suivi. Ils aident aussi à renforcer la robustesse et la fiabilité de la solution produite. Il est donc important de s’appuyer sur des technologies performantes, voir innovantes. Cela ne peut se faire qu’en se tenant informés sur les avancées technologiques dans le domaine.
Découvrir Code Patrol, la Revue de Code en mode SaaS
Faire appel à d’autres concepts, à une Red Team, ou encore aux chercheurs
Le modèle DevSecOps peut se conjuguer avec d’autres pratiques qui visent également à renforcer la sécurité sans nuire à l’agilité. Ainsi, la discipline dite de la défense en profondeur consiste à segmenter son application et son environnement en plusieurs couches, chacune dotée de contrôles de sécurité autonomes. Ainsi si une couche est compromise, cela permet de limiter la propagation de cette menace au sein de l’environnement.
Le Red Teaming (littéralement, constituer une équipe de « rouges ») consiste à confier à des collaborateurs la tâche de simuler des attaques sur les projets en cours afin de mettre en évidence ses faiblesses et ses vulnérabilités. L’enjeu des Red Teams est donc de mettre en avant les problèmes de sécurité mais surtout de proposer des solutions de corrections aux équipes. Ainsi, la démarche proactive prend le pas sur la démarche curative.
Enfin, une approche que Claranet considère innovante est celle du bug bounty. Contrairement aux prestations classiques de tests d’intrusion où une équipe de consultants est chargée de découvrir le maximum de vulnérabilités sur un temps imparti, il est question ici de faire appel à une communauté de chercheurs qui sera uniquement rémunérée pour chaque vulnérabilité remontée. À la clé, des économies substantielles sur les budgets de ses projets mais aussi une prestation qui ne sera pas limitée par le temps.
Deux règles conditionnent toutes ces bonnes pratiques :
- La première est de procéder par étape. Il est préférable d’introduire progressivement des petites mesures qui évolueront au cours du cycle de vie du projet, plutôt que de chercher à basculer soudainement en mode DevSecOps
- La seconde est que tous les collaborateurs soient impliqués, pour éviter des déséquilibres dans la sécurité, ce qui implique le soutien de la hiérarchie.