Franchir le fossé culturel en adoptant le DevSecOps

Le DevSecOps accélère le rythme de la sécurité pour égaler celui du DevOps de manière à conserver sa souplesse tout en éliminant ses vulnérabilités.

L'adoption généralisée du Devops a finalement eu lieu en 2018, année au cours de laquelle la moitié des entreprises ont affirmé que leurs équipes avaient « entièrement intégré » ces pratiques. Le DevOps permet aux sociétés de coder et déployer leurs produits à une vitesse encore inégalée afin de surpasser la concurrence en publiant leurs logiciels de plus en plus rapidement.

Malgré tout et en dépit de ses avantages, le DevOps est devenu une sorte de point sensible pour les équipes SOC (Security Operation Center) : Google retourne plus de 31 millions d'articles pour les termes « DevOps sécurité ». Les services chargés de la sécurité jugent le DevOps dangereux en raison de sa rapidité et de l'absence de procédures de sécurité adéquates. Quant au service DevOps, il considère la sécurité comme un fardeau qui le ralentit, un obstacle qui l'empêche de répondre aux exigences de l'économie numérique comme des activités au sens large.

Cependant, le DevOps perdurera sans retourner sur ses pas ; c'est pourquoi les RSSI et les DSI doivent trouver le moyen de combler ce fossé. Étant donné qu'il est impossible de ralentir le DevOps, le DevSecOps constitue la seule solution. Le DevSecOps accélère le rythme de la sécurité pour égaler celui du DevOps de manière à conserver sa souplesse tout en éliminant ses vulnérabilités. Le DevSecOps est essentiel pour les entreprises désirant trouver l'équilibre en publiant rapidement de nouveaux produits et services sans risquer de subir de catastrophiques piratages.

Une question de priorités  

Les motivations et les risques assumés par les services DevOps et de sécurité sont de nature très différente. Les équipes DevOps sont incitées à raccourcir le cycle de développement, car elles estiment que le principal risque encouru par l'entreprise est de commercialiser ses produits plus lentement que ses concurrents. Une étude a conclu que les sociétés possédant des équipes DevOps performantes obtiennent 30 fois plus de déploiements que leurs concurrents, résolvent leurs problèmes 12 fois plus rapidement et sont plus susceptibles de dépasser leurs objectifs de rentabilité et de productivité. Si leurs concurrents ne souhaitent perdre de clients au profit de ces acteurs performants, ils doivent à leur tour adopter le DevOps sous peine de rester à la traîne en termes d'expérience client. C'est pourquoi le service DevOps se caractérise naturellement par sa propension à éliminer le plus grand nombre d'obstacles, car chaque processus représente un risque pour la productivité et les prestations de l'entreprise. 

En revanche, le service de sécurité doit traiter une série de risques très différents. Il s'attache à assurer la protection de l'entreprise face aux menaces internes et externes, et sa principale priorité consiste à interdire les accès non autorisés et les logiciels malveillants. C'est pourquoi il est bien plus prudent que l'équipe DevOps. Le service de sécurité désire prendre le temps nécessaire pour tester les services et les applications récemment déployés afin qu'aucune vulnérabilité ne puisse mettre la société en péril. Cette opposition directe au DevOps et le fossé culturel qui en résulte peuvent créer des tensions importantes.

Comme nous pouvons le voir, les deux équipes travaillent dans l'intérêt de l'entreprise, mais leurs risques et leurs motivations sont différents, ce qui les amène parfois à s'opposer. En dernier lieu, ces tensions peuvent cependant déboucher sur l'accroissement des risques encourus par ces deux acteurs.

La sécurité négligée

Dans ce contexte, il n'est pas surprenant qu'à peine un tiers (36 %) des équipes DevOps affirment intégrer la sécurité à la conception et au déploiement des nouvelles technologies. Il s'agit du scénario du pire, car les équipes DevOps adoptent des comportements risqués, mais également, car le service de sécurité n'a aucune idée de la situation pour parer à d'éventuelles menaces.

Les identités de machine font ici figure d'exemples parfaits. Une étude a mis en évidence que les équipes DevOps adoptent régulièrement des pratiques imprudentes, par exemple en utilisant des certificats autosignés ou en ne remplaçant pas les certificats de test lors de la mise en production. Ces faux-pas génèrent d'importants risques de sécurité. Si des pirates parviennent à déceler ces points faibles, ils peuvent les employer pour infiltrer l'entreprise à l'aide de programmes malveillants, effectuer une attaque MitM (man in the middle) ou extraire des données sensibles. Ces problèmes surviennent, car les équipes DevOps, pressées de mettre en production les nouvelles versions le plus rapidement possible, n'ont simplement pas toujours le temps d'effectuer la procédure de demande auprès d'une autorité de certification. Pourtant, en raison des vulnérabilités, l'omission de ces opérations crée des besoins de sécurité à traiter sans ralentir le DevOps. Les services de sécurité ne doivent plus refuser l'approche DevOps, mais trouver le moyen qu'elle puisse se concrétiser en toute sécurité.

Une réponse automatique

L'adoption d'une approche plus coopérative permet au DevOps de fonctionner à son rythme tout en adaptant celui des procédures de sécurité et en impliquant le service de sécurité via le DevSecOps. Le dialogue engagé ne se caractérise plus par sa confrontation, mais par une collaboration dont le but est de maintenir la sécurité sans ralentir les opérations. La clé de ce processus est l'automatisation, qui peut répondre aux besoins des services DevOps comme des services de sécurité, car elle est rapide, fiable et simple à vérifier. L'automatisation des processus invariablement appliqués dans les domaines clés tels que le test et le déploiement permet aux collaborateurs de dédier bien plus de temps à l'amélioration continue ainsi qu'à la détection et à la résolution des erreurs. Cette opération élimine les obstacles du service DevOps afin de ne pas le ralentir, tandis qu'elle garantit au service de sécurité le contrôle permanent des processus clés ainsi que la consultation des journaux système pour accéder si besoin à un dossier ou des données (potentiellement par le biais de l'automatisation). 

Si nous réfléchissons à l'exemple précédent des identités de machine, il apparaît évident que l'automatisation du processus de provisionnement des certificats éliminera facilement les conditions propices aux erreurs de sécurité. Désormais, dès que le code est prêt à être mis en production, le certificat adéquat est demandé et appliqué en toute simplicité pour le développeur. Nous assurons ainsi les opérations de sécurité sans ralentir le moins du monde les pipelines DevOps. Le service DevOps est libre de coder et livrer rapidement, tandis que le service de sécurité évite de le ralentir : tous deux savent que les procédures de sécurité sont observées automatiquement et continuellement.

Le DevSecOps ou rien

Après avoir largement adopté le DevOps, il est crucial que les sociétés comprennent et adoptent le DevSecOps dès que possible. Le DevOps ne doit pas être craint en raison des risques de sécurité, car il s'agit de l'avenir du code axé sur le développement et le déploiement continus : les entreprises qui ne l'adopteront pas ne pourront pas tenir le rythme. Néanmoins, en l'absence de supervision et d'intervention du service de sécurité, les équipes DevOps libèreront une horde de vulnérabilités dans leur empressement à déployer.

Pour les sociétés, la seule solution consiste à adapter le rythme de la sécurité à celui du DevOps afin que les deux entités travaillent harmonieusement du point de vue culturel et technologique. Elles répondent ainsi aux principales préoccupations des deux équipes en garantissant vitesse et sécurité. Seule l'harmonisation des motivations des équipes de DevOps et de sécurité (en leur fournissant les outils nécessaires pour y parvenir) permettra d'éviter une série d'accidents graves survenant en vitesse de croisière et à grande échelle.