lassedesignen - Fotolia
DevSecOps et API : quand l’approche « Shift Left » ne suffit pas
Un éditeur de développement d’applications de banque en ligne a formé ses développeurs pour coder dans des environnements sécurisés, mais la protection des API a également nécessité un « virage à droite » pour renforcer les outils de surveillance et la formation des Ops.
D’abord, il y a eu l’approche DevOps. Puis il y a eu le mouvement DevSecOps et le « glissement vers la gauche » (Shift Left). Mais alors que la sécurité des API devient une préoccupation croissante, certaines entreprises reviennent à nouveau vers la droite.
Ce débat gauche - droite n’a rien à voir avec les conversations politiques houleuses entre la bûche de Noël et le café, mais fait référence au diagramme typique du cycle de vie de livraison des logiciels. Ce cycle est généralement décrit comme un processus linéaire de gauche à droite qui commence par les exigences de conception du produit applicatif, traverse le processus de développement et de génération de build, puis son déploiement sur l’infrastructure en production.
Idéalement, ce processus comprend aussi une boucle de rétroaction de la production vers les développeurs et les concepteurs afin d’orienter les futures mises à jour et de relier les parties gauche et droite du flux de travail. Mais dans la pratique, que ce soit lors de l’adoption de l’approche Agile et de la livraison continue ou de la tendance plus récente à injecter des principes de sécurité dans les premières étapes de la livraison des logiciels, les équipes et les éditeurs se sont souvent concentrés sur le côté gauche de ce diagramme, où les développeurs bâtissent es applications et écrivent le code, également connu sous le nom de « déplacement vers la gauche ».
Il n’y a pas que le développement dans la vie, il y a la production aussi
Entre-temps, l’infrastructure de production située à droite du schéma typique de livraison de logiciels, où les applications vivent en fin de compte, a subi ces dix dernières années des changements tout aussi telluriques que les approches Agile et DevOps. Ici, les applications monolithiques fonctionnant sur des serveurs virtuels ou bare-metal ont cédé la place aux microservices et à des niveaux toujours plus élevés d’abstraction logicielle entre les développeurs et le sous-jacent de l'environnement de production.
En parlant d’abstraction, les API sont désormais au cœur de la collaboration inter et intraorganisationnelle entre les équipes de développeurs à mesure que les stratégies DevOps et les microservices gagnent en maturité. Les API agissent comme une sorte de porte d’accès aux services numériques individuels, par laquelle d’autres services et développeurs d’applications peuvent accéder aux données. De nombreuses équipes DevOps travaillant dans des environnements cloud ont adopté des architectures « API-first » afin de suivre cette tendance, en orientant la conception des applications autour de la communication par API.
« En nous appuyant sur les API, nous permettons également aux partenaires et aux institutions financières de créer leurs propres expériences et leurs propres applications », avance David Biesack, responsable des API chez Apiture, un éditeur SaaS de solutions bancaires en ligne basé à Wilmington, en Caroline du Nord.
Les API constituent l’épine dorsale du portail interne des développeurs d’Apiture, et environ 25 API sont utilisées dans ses environnements en contact avec la clientèle. Dans certains cas, les API facilitent l’accès aux données des deux systèmes pour répondre aux questions des clients.
« Nous avons eu une demande de l’un de nos clients : il voulait savoir qui étaient tous les développeurs ou toutes les personnes de son organisation qui s’étaient inscrits sur le portail des développeurs, et lesquels d’entre eux avaient réclamés des clés d’API », témoigne David Biesack. « J’ai pu rapidement écrire un script qui se contente de consulter les API et de générer ces données directement. Je n’ai pas besoin d’aller dans la base de données back-end pour faire ce type de requêtes. »
La sécurité des API présente des défis uniques
La conception des API est relativement jeune, ce qui signifie qu’elle occasionne de nouvelles fragilités dans les architectes de la sécurité, dont les attaquants peuvent tirer parti. Son utilisation populaire explose également, ce qui attire également les acteurs malveillants – les analystes de Gartner ont signalé une hausse de 30 % des demandes de renseignements des clients concernant la sécurité des API cette année. Une analyse anonyme des données clients réalisée au cours des six premiers mois de 2021 par l’éditeur Salt Security, entend démontrer que le trafic global des API a augmenté de 141 % et que, dans le même temps, le trafic des attaques d’API a augmenté de 348 %.
Cet ajustement au développement axé sur les API a déplacé le projecteur de la sécurité chez Apiture loin du code logiciel, c’est-à-dire à droite : vers les environnements de production, selon David Biesack.
« Nous connaissons bien le Top 10 de l’OWASP et celui qu'il dédie à la sécurité des API – nous savons comment coder pour ce genre de choses, développer des solutions contre les attaques par injection de code, et divers autres types d’attaques qui sont assez bien connus », déclare David Biesack. « Ce que nous cherchions… c’était connaître quelles étaient les inconnues de la sécurité des API. Nous recherchions quelqu’un qui puisse aller au-delà des choses auxquelles nous pouvions nous préparer. »
Apiture a engagé Salt Security pour engager un POC à la fin de 2020, et a choisi d’acheter la plateforme de protection API de l’éditeur au début de 2021. Le produit recueille des données sur les API en dehors des chemins d’appels traditionnels, par le biais de mécanismes tels que la récolte de logs AWS CloudWatch et l’analyse du trafic réseau.
En arrière-plan, la plateforme reconstitue une copie du trafic d’API d’un client et l’analyse à la recherche d’un comportement inhabituel des utilisateurs d’API à l’aide d’algorithmes de machine learning. Les anomalies qui indiquent une vulnérabilité de la sécurité de l’API ou une attaque en cours déclencheront des alertes et des réponses de blocage des attaques de la part de l’outil Salt.
David Biesack explique qu’il a choisi Salt Security plutôt que ses concurrents, dont le spécialiste du WAF pour API Spherical Defense, parce que les membres du support de l’éditeur se sont bien entendus avec son équipe IT, mais aussi parce que Salt Security a rapidement découvert une vulnérabilité de sécurité dans un environnement de test.
« L’un des principaux arguments de vente était sa capacité à apprendre rapidement sur des échantillons de données », affirme David Biesack. « Nous avons activé Salt dans quelques environnements et il a collecté le trafic pendant une semaine, a commencé à l’analyser et a trouvé une vulnérabilité dans un cas critique, qui ne correspondait pas au modèle de sécurité de l’OWASP. »
Salt est en concurrence avec plusieurs éditeurs émergents dans le domaine en pleine expansion de la sécurité des API, notamment Traceable Inc, 42Crunch, CloudVector (racheté par Imperva en mai) et Imvision. Des acteurs IT établis, tels que Cisco, développent également de nouveaux produits de sécurité API.
Nombre de ces produits utilisent également le machine learning et l’intelligence artificielle pour identifier les comportements anormaux et potentiellement malveillants des utilisateurs d’API dès leur première apparition, plutôt que de s’appuyer sur les signatures d’attaques connues utilisées par les outils classiques de surveillance de la sécurité.
Trouver un équilibre entre Shift Left et formation des développeurs
L’accent renouvelé sur la surveillance de la sécurité des API en production ne signifie pas qu’Apiture a oublié ses pratiques DevSecOps « Shift Left », souligne M. Biesack. L’analyse de l’outil Salt Security informe également les premières étapes du flux de travail DevOps.
« Je travaille avec notre équipe produit… pour m’assurer que lorsqu’ils définissent une fonctionnalité du produit, [ils] incluent des éléments de sécurité logicielle », assure-t-il. « Savoir que Salt peut mettre en évidence les expositions possibles nous aide à comprendre où les données [sensibles] doivent être gérées, chiffrées et sécurisées. »
La formation des développeurs est une autre partie croissante du programme de sécurité des API conduit par M. Biesack, et il utilise également les données de Salt Security pour fournir un retour d’information aux développeurs lors des hackathons de sécurité internes.
« Au début de l’année 2021, nous avons institué un hackathon interne où nous disons à notre personnel d’ingénierie : “D’accord, nous ne développons pas de nouvelles fonctionnalités pour le moment, nous ne débugons pas – nous allons prendre 24 heures et simplement pirater le système” », explique-t-il. « “Mettez-vous dans la peau d’un pirate et essayez de voir si vous pouvez trouver d’autres vulnérabilités dans le logiciel” ».
David Biesack veut ajouter d’autres ressources de formation pour les développeurs autour de la cybersécurité en 2022.
« Nous évaluons des partenaires de formation externes pour faire une formation plus régulière avec notre personnel d’ingénierie sur la sécurité des API et les vulnérabilités de sécurité en général », dit-il. « J’ai réalisé des formations en interne… mais nous recherchons une manière un peu plus structurée de le faire ».