Beaucoup d’entreprises sont hésitantes à mettre en place des outils de contrôle de sécurité dans leurs projets d’innovation. Elles pensent que cela diminue leurs livraisons et nécessite aussi d’investir de gros moyens sur des fonctionnalités de sécurité. Aujourd’hui, le marché réclame constamment plus de rapidité et d’agilité, ce qui les rend frileuses pour investir dans ce domaine. Or, quand un projet manque de moyens de sécurité, il est fortement compromis. En effet, cela coûte d’autant plus cher de la corriger après sa mise en route et peut ternir l’image de marque.
Afin d’accorder sécurité et agilité, il y a une solution possible : réorganiser le projet et donc ajouter l’aspect sécurité au début même du projet. Le modèle du DevSecOps permet cette alliance parfaite.
Je ne vous ferai pas l’affront de vous expliquer ce que sont le DevSecOps et ses bénéfices. N’hésitez pas à consulter notre article précédent sur ce qu’est ce modèle.
DevSecOps : 3 points pour implanter le modèle dans son entreprise
Il y a trois étapes nécessaires à la mise en place du DevSecOps :
Premièrement,
Il est nécessaire de nourrir une culture de la sécurité au sein des équipes. Cela passe par des formations aux techniques adéquates et des incitations à se tenir informé des innovations dans ce secteur (veille technologique). Par exemple, il est possible de mettre en place des sessions de sensibilisation sur des thèmes d’actualité mais toujours sur la sécurité ! Également, il est possible de proposer des formations à ses collaborateurs, réalisables à distance en e-learning. Vous pouvez aussi responsabiliser davantage certains collaborateurs en désignant un référent dans les équipes qui contribuent au projet.
Deuxièmement,
Il faut mettre en œuvre des procédures et des processus inséparables de la sécurité, toujours en adéquation avec les méthodes agiles. Cela passe par l’intégration de la sécurité dès le début du projet. Cette approche nommée « Shift Security Left », permet aux entreprises de recourir à un flux de travail sécurisé à chaque étape d’un projet.
En complémentarité, il faut instaurer des dispositifs aptes à détecter et à alerter en cas d’éventuels problèmes de sécurité ou d’incidents. Ainsi, des moyens de contrôle doivent être mis en oeuvre pour s’assurer du maintien en conformité, détecter toute vulnérabilité ou encore alerter en cas de compromission.
La mise en place de processus et de procédures doit permettre de supprimer les goulots d’étranglement et de livrer de manière plus rapide des produits sécurisés.
Troisièmement,
Il est important d’utiliser des produits dédiés et de privilégier l’automatisation. Cette dernière permet par exemple de prévenir les possibles erreurs humaines dans les déploiements. Effectivement, une opération involontaire ou des administrateurs qui n’ont pas les mêmes modèles, peuvent créer des incidents de sécurité. Il est alors possible de s’appuyer sur des outils qui permettent :
- De scanner l’infrastructure et/ou le code
- De se greffer facilement à différents éléments de la pipeline d’automatisation
- D’alerter et bloquer le cas échéant une mise en production
L’ajout de ces outils à un dispositif de suivi des anomalies, offre la possibilité de centraliser les informations sur les vulnérabilités détectées et les correctifs à apporter. En conclusion, ces outils vont permettre d’améliorer la vitesse de suivi et d’exécution des tests de sécurité. De plus, ils augmentent la solidité et la fiabilité de la solution réalisée. Ceci montre l’importance de s’aider de technologies efficaces voire innovantes. Il est donc capital de rester en veille sur les innovations technologiques du secteur.
DevSecOps s’accorde à d’autres pratiques de sécurité
Ce modèle est compatible à d’autres pratiques qui servent aussi à augmenter la sécurité, sans desservir l’agilité.
De cette façon la discipline dite de la « défense en profondeur » scinde l’application et son environnement en différentes strates. Chacune bénéficie de contrôles de sécurité autonomes. Donc si une strate est touchée, cela permet de réduire la diffusion de l’éventuelle menace à l’ensemble de l’environnement.
Une autre pratique consiste à composer une équipe interne de « Red Team » avec pour mission la simulation d’attaques afin de découvrir des vulnérabilités sur les projets en cours. L’objectif de cette équipe est de mettre au premier plan les anomalies liées à la sécurité mais également d’apporter des solutions de sécurisation aux équipes.
Par ailleurs, une manière différente de procéder se démarque de plus en plus, elle s’intitule le « Bug Bounty ». A contrario des services classiques de tests d’intrusion, où une équipe doit détecter le plus possible de vulnérabilités sur un temps défini, il s’agit ici de recourir à une communauté de chercheurs uniquement rémunérée lors de la découverte d’une vulnérabilité. Ce qui signifie, des économies majeures sur le budget des projets mais également un service indéfini dans le temps.
Pour conclure,
Plusieurs conditions sont néanmoins nécessaires à l’application de ces techniques. Il est trop hâtif de basculer en mode DevSecOps du jour au lendemain. En effet, il est plus prudent d’amener étape par étape des mesures qui se développeront pendant le projet. Le DSI remplit un rôle primordial dans la mise en pratique de ce modèle. En tant que responsable hiérarchique, le DSI est la seule personne habilitée à entreprendre et à attirer l’attention des équipes sur les mécanismes de sécurité. Il fait office de clé de voute entre les différents collaborateurs du projet (exploitation, applications, architecture & sécurité).
Vous souhaitez plus d’informations sur la mise en place d’un modèle DevSecOps ?
