Les équipes de sécurité rêvent de pouvoir disposer de véritables capacités d’automatisation. Ces dernières années, les options disponibles se sont nettement développées grâce au SOAR (Security Orchestration, Automation and Response) ainsi qu’à d’autres solutions de sécurité telles que le SIEM (Security Information and Event Management), l’IAM (Identity and Access Management), l’EDR (Endpoint Detection and Response), le XDR (Extended Detection and Response) et le CDR (Cloud Detection and Response) offrant ainsi une automatisation avec une capacité restreinte.
Avec toutes ces différentes options qui sont maintenant disponibles, il est essentiel, pour que les équipes puissent atteindre leurs objectifs, de bien comprendre les similitudes et les différences entre le SOAR et le DevSecOps. Bien qu’il existe des éléments d’automatisation au niveau des flux de travail dans le SOAR, ce qui distingue le DevSecOps du SOAR est une expérience collaborative entre les équipes Dev, Sec et Ops ; une hyper-dépendance à l’open source; une capacité en termes de proactivité et réactivité; et enfin une approche agile.
Qu’est-ce que le SOAR ?
Gartner® définit le SOAR comme un ensemble de “technologies permettant aux entreprises de collecter des entrées surveillées par l’équipe responsable des opérations de sécurité”. Les outils SOAR ingèrent les données des systèmes SIEM pour définir l’analyse des incidents et les procédures de réponse dans un format de flux de travail numérique.
Qu’est-ce que le DevSecOps ?
Le DevSecOps est une méthodologie appliquée aux processus modernes qui s’appuie sur une approche DevOps, à laquelle a été ajoutée, il y a plus de dix ans, une infrastructure agile au niveau du développement des logiciels, et enfin récemment, la notion de sécurité a été ajoutée au processus DevOps. Les objectifs du DevSecOps sont d’augmenter la vitesse de publication, d’éliminer les silos entre les équipes, de réduire la fréquence et l’impact des bugs dans les versions de production et de placer la sécurité plus en amont dans le processus de livraison des logiciels. Le DevSecOps va au-delà du développement d’applications, à mesure que les entreprises se modernisent et à une époque où tout l’univers IT repose sur du code, souvent désigné par IT-as-Code.
Les objectifs du DevSecOps sont atteints de deux manières différentes. Tout d’abord, via un changement culturel grâce auquel les équipes travaillent ensemble au sein d’une plateforme pour créer et itérer au niveau de la création de solutions reproductibles à partir de produits et d’outils provenant de plusieurs éditeurs, qui peut être désignée par le terme ‘usine logicielle ou DevSecOps’. Ensuite, l’utilisation de l’intégration continue et de la livraison continue (CI/CD). L’approche CI/CD comprend une catégorie d’outils logiciels qui intègrent et proposent fréquemment du code en mode push pour s’assurer que les nouvelles versions d’une application fonctionnent correctement. Le modèle CI/CD permet au code créé de tester et d’automatiser tous les aspects du pipeline, notamment la sécurité, et ce avant que le code ne soit mis en production.
Pourquoi le SOAR est différent du DevSecOps ?
On pourrait confondre la mécanique du SOAR avec celle du DevSecOps car les équipes de sécurité utilisant un outil SOAR adoptent le plus possible l’état d’esprit DevSecOps, qui consiste à utiliser une approche low code pour automatiser leur travail.
Mais c’est là que la similitude débute et s’arrête. Les trois différences fondamentales, décrites ci-dessous, permettent de différencier vraiment le DevSecOps du SOAR.
- Le SOAR a un support limité pour l’open source : les outils SOAR s’intègrent rarement aux outils open source car, par nature, ils s’intègrent principalement à des outils tiers tels que Cisco, Exabeam, Okta ou Splunk. Le manque d’intégration open source dissuade fortement les équipes DevOps qui s’appuient fortement sur des outils open source tels que Git, Ansible et Terraform pour mener à bien leurs missions. Cette contrainte isole les équipes de sécurité de la production et décourage les équipes DevOps de collaborer.
- Le SOAR n’adopte pas une approche agile pour déployer l’automatisation : lorsque les équipes de sécurité utilisant les outils SOAR parlent d’automatisation, c’est dans le contexte de l’ingestion de données SIEM, de la gestion de ces données, puis de l’automatisation des flux de travail en matière de réponse aux incidents. Cette approche est différente de l’utilisation du modèle CI/CD, comme dans le DevSecOps, qui permet aux développeurs d’intégrer leur nouveau code source, de le tester, de le pousser puis de le déployer le plus souvent en production.
- Le SOAR a été conçu comme un produit ponctuel pour les analystes en sécurité, et non pour la collaboration : le SOAR est un cas d’usage dans le DevSecOps qui peut prendre en charge de nombreux autres cas d’usage, y compris, mais sans s’y limiter, le SOAR, la conformité, la sécurité du Cloud, la sécurité des applications, l’automatisation du réseau, l’automatisation de l’infrastructure ainsi que les intégrations. L’objectif du DevSecOps est de permettre aux équipes de créer des solutions en tant que blocs de construction et de les associer via l’approche CI/CD au niveau de laquelle chaque équipe pourra se connecter à ses flux de travail existants avec les produits et outils qu’elle souhaite utiliser.
Concernant, plus particulièrement, les équipes de sécurité et celles responsables des opérations, l’approche CI/CD leur permet d’itérer via une approche agile avec divers cas d’usage, d’analyser le codebase ou l’application à la recherche de vulnérabilités de sécurité connues, ou d’exécuter l’infrastructure et les applications par rapport à des références de sécurité qui améliorent la protection des produits et la posture de sécurité de l’entreprise dans son ensemble.
Par conséquent, le DevSecOps adopte l’open source, avec une approche agile au niveau de l’automatisation et rend possible la collaboration alors que le SOAR ne le permet pas à tous les niveaux. Cependant, l’option de l’open source est en fait idéale pour les équipes de sécurité, qui apprécient le support et la responsabilité d’une grande communauté. De même, l’accès au CI/CD est bénéfique pour les équipes de sécurité, qui souhaitent depuis longtemps adopter une approche “shift-left“. En d’autres termes, faites en sorte d’intégrer les développeurs le plus tôt possible dans le processus de création du pipeline IT-as-Code afin qu’ils puissent résoudre les problèmes avant que le code n’arrive en production.
Atteindre l’agilité avec l’approche CI/CD : une priorité du DevSecOps
Le SOAR est exclusivement une plateforme de sécurité tandis que le DevSecOps répond de manière holistique aux besoins de toutes les équipes en adoptant le modèle CI/CD, des outils open source et la collaboration. Bien que le SOAR ne puisse pas remplacer le DevSecOps, ce dernier résout les problèmes inhérents au SOAR et le traite comme un cas d’usage tout en offrant une automatisation généraliste avec une expérience utilisateur qui renforce l’importance et l’impact de la sécurité.
Certaines équipes de sécurité et celles responsables des opérations peuvent être réticentes à l’idée d’utiliser une solution DevSecOps car l’approche CI/CD a la réputation d’être fortement liée au développement d’applications, mais ce n’est plus le cas maintenant. En effet, il existe aujourd’hui de nombreuses options en termes de plateforme low-code/no-code qui permettent à une entreprise d’atteindre ses objectifs en matière de DevSecOps. Idéalement, les équipes devraient se procurer une plateforme DevSecOps de type all-inclusive ; à savoir une plateforme qui inclurait une interface visuelle où tous les niveaux d’utilisateur pourraient collaborer, mais aussi une plateforme qui proposerait une base solide pour prendre en charge les développeurs et les exigences en matière de DevOps, comme un support pour les outils existants et du contenu d’automatisation dans sa forme native, par exemple, des configurations Terraform, des playbooks Ansible, des scripts, etc.
Le paysage des menaces est en constante évolution. Alors que les équipes de sécurité et celles responsables des opérations doivent faire toujours plus malgré une pénurie de talents, l’automatisation doit gagner du terrain pour permettre d’atténuer les pressions croissantes exercées dans leurs domaines. Les équipes de sécurité bénéficient grandement des pipelines CI/CD, qui non seulement reproduisent et accélèrent leurs capacités manuelles, mais consacrent également un temps précieux à la modernisation de leurs processus de travail quotidien qui correspondent à divers cas d’usage. En adoptant l’état d’esprit et les pratiques du DevSecOps, les équipes de sécurité et celles responsables des opérations peuvent devenir agiles avec leurs homologues Dev et DevOps grâce à une collaboration utilisant une technologie qui s’adresse à l’ensemble des talents techniques de chaque entreprise.
Billet inspiré de Automation in SOAR Goes Further with DevSecOps, sur le Blog Sophos.
