BLOG

Les six raisons pour lesquelles DevSecOps devrait s'attaquer à la gestion des robots

Vignette de Jim Downey
Jim Downey
Publié le 21 juillet 2022

À l’ère de la concurrence numérique, toutes les entreprises sont des entreprises technologiques et les innovations contemporaines ont bouleversé des secteurs allant de la finance à l’épicerie en passant par les transports. Pour réussir en tant qu’entreprise technologique moderne, il faut innover plus rapidement que la concurrence, et une innovation rapide nécessite DevOps. DevOps est une collaboration entre les développeurs et les opérations informatiques qui a permis des avancées majeures dans le rythme des sorties de produits en appliquant les principes Lean à la livraison de logiciels. Malgré les promesses de DevOps, les attaques de robots et autres problèmes de sécurité, s’ils ne sont pas correctement traités, peuvent empêcher les organisations d’en récolter les bénéfices. Heureusement, DevOps a donné naissance à DevSecOps, un rôle bien placé pour répondre aux problèmes de sécurité, et en particulier à la gestion des robots, dans le monde en évolution rapide de DevOps.

Dans une culture DevOps, DevSecOps assume la responsabilité d'intégrer la sécurité dans le pipeline d'intégration continue/développement continu (CI/CD), en garantissant un retour rapide aux développeurs sur les bogues de sécurité et en améliorant continuellement l'intégration de la sécurité dans le flux de valeur technologique.

S'appuyant sur les pratiques de fabrication Lean, DevOps met l'accent sur le déplacement des considérations de qualité plus tôt dans la chaîne de valeur afin de réduire les échecs en aval, où le coût des retouches est plus élevé ; il est préférable de concevoir la qualité dans un produit que de découvrir des défauts par l'inspection. La sécurité étant un élément essentiel de la qualité, DevSecOps s’engage également à déplacer la sécurité vers la gauche, en s’assurant que toutes les lacunes sont planifiées plus tôt dans le flux de travail. Plus les outils tels que les tests de sécurité d'analyse statique, les tests de sécurité d'analyse dynamique et les analyses de vulnérabilité sont exécutés tôt, plus les développeurs reçoivent des commentaires et plus les bugs peuvent être corrigés tôt.

Et plus la sécurité est prise en compte dans la collecte des exigences, la conception et le codage, plus les contrôles de sécurité seront efficaces. Bien qu'il s'agisse de concepts fondamentaux du codage sécurisé et du cycle de vie du développement logiciel (SDLC), ces pratiques deviennent de plus en plus importantes dans un environnement DevOps, car aborder la sécurité plus tard pourrait entraver les déploiements rapides ou entraîner des risques de sécurité.

Étant donné le rôle essentiel de DevSecOps dans la sécurisation de l’entreprise moderne, il s’ensuit que la gestion des robots doit être incluse parmi les responsabilités de cette discipline particulière. Non seulement la gestion des robots est essentielle à la sécurité et donc au cœur de la mission de DevSecOps, mais DevSecOps est également idéalement placé pour garantir que les organisations sont bien protégées contre les robots malveillants. Alors, comme promis, voici les six raisons pour lesquelles DevSecOps devrait s'attaquer à la gestion des robots :

1)   La protection contre les robots est essentielle à la sécurité et à la confidentialité des données

Les bots sont des scripts qui automatisent l'envoi de requêtes HTTP aux applications et aux API. Les criminels utilisent des robots pour attaquer les applications Web et mobiles dans plusieurs types d'attaques :

  • Credential stuffing: Les attaquants testent les informations d'identification volées par rapport aux identifiants de connexion pour prendre le contrôle des comptes.
  • Création de faux compte : Les criminels créent de faux comptes pour commettre des fraudes telles que l’influence sur les réseaux sociaux et le blanchiment d’argent. (Voir une analyse de F5 sur le problème des faux compte de Twitter .)
  • Cardage: Les criminels valident les données de cartes de crédit volées.
  • Craquage de cartes : Les criminels identifient les codes de sécurité et les dates de début et d’expiration manquantes des données de cartes de paiement volées en essayant différentes valeurs.
  • Vol de soldes de cartes-cadeaux et de points de fidélité : Les criminels volent les soldes des cartes-cadeaux et des points de fidélité , en s'appuyant sur le fait que les utilisateurs vérifient ces soldes peu fréquemment.
  • Achat/Revente : Les courtiers illicites achètent des biens dans le cadre d'offres à durée limitée pour les revendre à des prix plus élevés.
  • Stockage d'inventaire : Les robots réservent des biens et des services mais ne finalisent pas l'achat, donnant l'impression que l'inventaire n'est pas disponible et empêchant les achats légitimes.
  • Grattage: Les robots de scraping extraient les données des applications, provoquant un désavantage concurrentiel et ralentissant les performances du site.

Pour une taxonomie complète des attaques de bots, consultez le manuel des menaces automatisées de l'OWASP ou ce résumé de Kyle Roberts.

De toutes les attaques de robots, le credential stuffing est particulièrement pernicieux. La Global Privacy Assembly (GPA) a déclaré que le « credential stuffing » constituait une menace mondiale pour la confidentialité des données. La GPA, qui représente plus de 130 régulateurs et responsables de la protection des données et de la confidentialité, insiste sur le fait que la gestion des robots est désormais une mesure nécessaire pour la confidentialité des données, et donc obligatoire pour toutes les entreprises B2C faisant des affaires en ligne.

Si DevSecOps veut remplir sa mission de sécurisation de l’organisation et de ses clients, il est essentiel de résoudre le problème des robots malveillants.

2)   Les robots corrompent la télémétrie dont dépend DevOps

Selon le manuel DevOps , la télémétrie est essentielle pour prédire, diagnostiquer et résoudre les problèmes dans les systèmes complexes, c'est-à-dire les systèmes trop grands et trop imbriqués pour qu'une seule personne puisse comprendre comment tous les éléments s'assemblent. Pour que DevOps réussisse, la télémétrie doit couvrir plusieurs couches, notamment les mesures commerciales, l'utilisation des fonctionnalités, les performances du réseau et la charge de l'infrastructure, afin qu'un problème dans une couche puisse être tracé sur l'ensemble de la pile pour une identification rapide des causes profondes.

Les robots déforment considérablement la télémétrie. De nombreux clients de F5 Distributed Cloud Bot Defense ont découvert que la plupart de leurs comptes utilisateurs étaient faux et que les bots représentaient plus de 95 % du trafic de connexion. Dans certains cas, la majeure partie de l’infrastructure d’une organisation ne faisait rien de plus que servir des robots de scraping.

Sans la capacité de distinguer un humain d’un robot, la télémétrie n’aurait plus de sens. Une fonctionnalité échoue-t-elle à cause d’utilisateurs réels ou de robots ? Pourquoi le taux de réussite de connexion est-il si variable ? Qu'est-ce qui a provoqué une augmentation soudaine du trafic vers un chemin application particulier ? Les robots noient le signal dans tout leur bruit.

Pour que DevOps réussisse, il a besoin d’une télémétrie significative, et pour rendre la télémétrie significative, il faut pouvoir détecter les robots. DevSecOps peut apporter une contribution significative au succès de DevOps en s'engageant dans la gestion des robots, garantissant l'intégrité des données si essentielles à DevOps.

3)   La protection contre les robots n'est pas une question de sécurité du code ni une tâche exclusivement réservée aux développeurs

Contrairement aux vulnérabilités traditionnelles que les développeurs peuvent résoudre grâce aux meilleures pratiques de codage et aux tests de vulnérabilité, les attaques de bots ciblent principalement les fonctionnalités légitimes qu'une application doit exposer, telles que la connexion, le mot de passe oublié, le paiement du produit et les informations sur les prix des produits. (Dan Woods de F5 fait référence à ces vulnérabilités inhérentes dans son interview sur Pirate Radio .) Bien que la protection contre les robots soit essentielle à la sécurité des applications, elle ne concerne pas le codage sécurisé et ne peut pas être résolue par les développeurs seuls. La protection des robots se situe dans cet espace entre les développeurs et InfoSec, précisément l'espace occupé par DevSecOps.

Étant donné que les organisations criminelles sont bien incitées à développer des robots qui contournent la détection, se protéger contre les robots malveillants est étonnamment difficile. Le CAPTCHA ne fonctionne plus. Les services de résolution de CAPTCHA utilisant le ML et les fermes de clics humaines rendent la résolution de CAPTCHA rapide et bon marché. (Voir Tales of a Human CAPTCHA Solver de Dan Wood.) Les robots exécutent JavaScript pour satisfaire aux preuves de travail, imiter le comportement humain réel, introduire un caractère aléatoire subtil et exploiter les réseaux proxy pour dissimuler leurs origines à travers des millions d'adresses IP résidentielles valides. Et les criminels rééquipent leurs robots quelques heures après leur détection. Cette sophistication et cette évolution rapide des robots signifient que l’époque où l’on pouvait arrêter les robots par des mises à jour manuelles des règles WAF est révolue depuis longtemps.

Imposer ce niveau d'effort au personnel de développement les empêcherait de proposer des fonctionnalités. Confier la tâche de mettre à jour les règles WAF à l'équipe d'exploitation brûlerait toutes ses ressources. Les organisations ont besoin de l’implication de DevSecOps pour intégrer une solution de gestion des robots dans le flux de valeur technologique.

4)   DevSecOps connaît la logique de l'application, ce qui est essentiel pour une protection efficace contre les robots

Bien que la protection contre les robots ne soit pas une tâche purement de développement, ce n'est pas non plus une tâche purement opérationnelle au sens traditionnel du terme. La configuration de la protection contre les robots nécessite une connaissance détaillée de l' application, de ses exigences, de sa conception et de sa mise en œuvre.

En regardant les types d’attaques de robots répertoriés ci-dessus, lesquels d’entre eux s’appliquent à votre application? Pour chacun de ces types d’attaque, quel chemin ou quelle API les robots suivront-ils ? Pour chacun de ces chemins, où est-il possible d’instrumenter la collecte de signaux pour recueillir les données nécessaires pour distinguer les robots des humains ?

Lors de la configuration de la protection contre les robots pour le Web, chez F5, nous désignons les chemins protégés comme des points de terminaison et les pages qui nécessitent une instrumentation comme des points d'entrée. Imaginez une connexion. Une page Web peut héberger le formulaire de connexion, que nous appellerions le point d’entrée. Et ce formulaire peut être publié sur un chemin particulier, que nous appellerions le point de terminaison. Bien sûr, ce n’est pas toujours aussi simple. Le formulaire de connexion peut exister sur plusieurs pages, et ces formulaires peuvent être publiés sur différents chemins.

C’est une histoire similaire pour le mobile. La protection des applications mobiles contre les robots nécessite généralement l'intégration d'un SDK pour l'instrumentation de télémétrie. Déterminer quelles demandes réseau doivent inclure cette télémétrie nécessite une connaissance de l'application.

Compte tenu de ces connaissances en matière d'applications requises pour la configuration, la gestion des robots est une bonne solution pour DevSecOps, d'autant plus qu'il est logique de déplacer cette étape vers la gauche, en considérant la gestion des robots pendant les phases d'exigences et de conception.

5)   DevOps connaît l'infrastructure

La protection contre les robots nécessite également une compréhension de infrastructure réseau. En règle générale, la protection contre les robots sera fournie via une API appelée à partir d'une couche du réseau, peut-être un CDN, un équilibreur de charge, une passerelle API, un contrôleur d'entrée ou une plate-forme application . L’une de ces couches sera configurée pour envoyer le trafic pertinent à l’API de gestion des robots afin de déterminer si une demande provient d’un humain ou d’un robot.

En collaboration avec les équipes de développement et d'exploitation, l'équipe DevSecOps disposera de la perspective la plus large sur la manière de décider où implémenter ces appels d'API d'une manière qui peut être entièrement automatisée (dans le cadre du pipeline CI/CD) et qui offre des performances optimales.

6)   DevSecOps sait où la gestion des robots doit s'intégrer dans le pipeline CI/CD

À mesure que les organisations publient de nouvelles fonctionnalités via le flux de valeur technologique, les défenses contre les robots nécessiteront des mises à jour de configuration, tout comme d'autres composants de sécurité tels que le WAF. L’équipe DevSecOps est bien placée pour déterminer à quel endroit du pipeline CI/CD cette mise à jour de configuration automatisée doit avoir lieu.

C'est plus complexe qu'il n'y paraît au premier abord, car la protection contre les robots pourrait interférer avec les tests d'assurance qualité automatisés, qui seraient alors détectés comme un robot. Il existe plusieurs façons de résoudre le problème, comme autoriser les outils de test via des en-têtes ou des adresses IP ou mettre en place des protections contre les robots uniquement une fois les tests d'assurance qualité automatisés terminés.

Plus important encore, DevSecOps doit travailler avec Dev et InfoSec pour déterminer où la protection contre les robots est nécessaire et fournir un moyen de s’assurer qu’elle est en place à mesure que les fonctionnalités pertinentes sont publiées.

Pour conclure

Les organisations qui fournissent des applications grand public doivent assurer la sécurité de leurs clients en ligne, en protégeant la confidentialité de leurs données et leur sécurité financière. Dans toute organisation recherchant un avantage compétitif grâce à l'innovation rapide rendue possible par DevOps, la protection des clients nécessite DevSecOps afin que la sécurité suive le rythme des versions. Parmi les responsabilités de DevSecOps, la gestion des bots est essentielle. Les attaques de robots mettent gravement en danger la sécurité des clients, et DevSecOps apporte des compétences très précieuses pour se défendre contre les robots malveillants et permettre aux organisations d'adopter en toute sécurité une innovation rapide.

Pour plus d’informations sur le retour sur investissement de la protection contre les robots, consultez le rapport Forrester Total Economic Impact . Apprenez-en davantage et planifiez une conversation avec un expert en bot F5 sur f5.com/bot-defense .