Rares sont les éditeurs à revenir sur leurs échecs, surtout lorsqu'ils touchent à la sécurité de leurs services. C'est pourtant l'exercice auquel s'est prêté Jay Thoden van Velzen, conseiller stratégique auprès du RSSI de SAP Sebastian Lange, qui est revenu dans un billet de blog sur la tentative de sécuriser les services cloud du groupe avec un EDR historique on premise. « Il existe des impératifs économiques et temporels pour migrer les systèmes et les applications vers les environnements cloud, cela ne signifie pas que vous devez également transférer votre pile d'outils de sécurité dans le cloud », prévient d'entrée Jay Thoden van Velzen. D'après son expérience, les trois principales exigences qui se sont posées avant même de considérer la valeur de sécurité d'une solution a été de savoir si l'outil était évolutif, déployable et abordable.

Sans se donner le fouet pour autant, le conseiller stratégique de SAP revient sur cette histoire plutôt sous un angle pédagogique qui pourrait bien servir de leçon pour des entreprises tentées de suivre ce même chemin. « Les outils de sécurité hérités des datacenters peuvent encore apporter de la valeur à un niveau supérieur. Mais en l'absence d'une surveillance et d'une détection adaptées au cloud, vous vous rendez vulnérable aux menaces courantes que les outils existants ne peuvent pas détecter », explique Jay Thoden van Velzen. « Les solutions de sécurité existantes peuvent donner un faux sentiment de protection tout en manquant de visibilité sur les événements liés au cloud et les mauvaises configurations de l'infrastructure. Aucun système historique ne prévient ou ne détecte un bucket de stockage ouvert ou un snapshot accidentellement public, sans parler de l'impact d'une fuite d'informations d'identification dans le cloud avant qu'il ne soit bien trop tard. Lorsque la solution est basée sur un agent (et de nombreuses solutions de point final le sont), que faites-vous des bases de données cloud ou des nœuds Kubernetes managés ? ».

Un remplacement complet en 2024

Dans ce contexte, l'éditeur a ainsi opté pour une plateforme de protection des applications cloud native (CNAPP) sans agent qui surveille l'infrastructure cloud native et les services managés, ainsi que les charges de travail basées sur les VM et les conteneurs. Elle contextualise les deux résultats en alertes basées sur les risques pour les mauvaises configurations, les vulnérabilités, les alertes IAM et les logiciels malveillants basés sur des fichiers qui facilitent la hiérarchisation au sein de l'organisation. A noter que cet outil supporte aussi la découverte des actifs, ce qui s'avère selon SAP important dans un environnement dynamique à croissance rapide.

« Comme la solution est déployée par l'intermédiaire des fournisseurs de cloud, tout comme les garde-fous, les employés ou les acteurs de la menace ne peuvent pas la contourner », fait savoir Jay Yhoden van Velzen ». En octobre 2023, le CNAPP a ainsi remplacé la solution CSPM développée en interne et remplacera début 2024 entièrement l'analyseur de vulnérabilités basé sur le réseau existant. Pour la sécurité d'exécution, plus particulièrement l'EDR et l'antivirus, SAP a rassemblé une variété de produits de sécurité différents sélectionnés par des acquisitions ou d'autres entités, en grande partie adossées aux datacenters du groupe. Ces produits ont ainsi été centralisés à l'aide d'une solution EDR de 2021, mais cette solution n'a finalement pas fonctionné à cause de son manque d'adoption. En 2023, SAP a alors commencé à déployer une deuxième solution pour la durée d'exécution, plus adaptée au cloud avec cette fois un certain succès selon Jay Thoden van Velzen.

Une logique de coûts en faveur d'une sécurité cloud

Le conseiller stratégique explique que les solutions legacy basées sur des agents se concentrent sur la sécurité de l'exécution et du réseau, deux aspects qui perdent de leur importance dans les cloud publics. En effet, de nombreux réseaux d'entreprises et de datacenters sont de grands réseaux ouverts, de sorte que leur surveillance contre les menaces est naturellement importante. Les comptes cloud apportent toutefois une isolation de l'instance où les ressources dans d'autres comptes cloud ne sont pas connectées à moins qu'elles ne soient explicitement configurées pour le faire, estime Jay Thoden van Velzen. « Ainsi, lorsque vous déployez un système par compte cloud, vous obtenez une microsegmentation des réseaux bien plus importante que dans le centre de données. Lorsque les systèmes doivent communiquer entre eux, ils le font de préférence par le biais d'appels API HTTPS, ce qui réduit la nécessité d'ouvrir des ports réseau au-delà de 443. L'administration du paysage, que ce soit par le biais de pipelines CI/CD ou de la console web d'administration du nuage, fonctionne via les interfaces de programmation d'applications (API) du fournisseur de cloud et les administrateurs ne se connectent pas directement au système dans des circonstances normales. Une grande partie du réseau reste donc un support d'appels d'API chiffrés », explique le conseiller.

Par ailleurs selon l'expert, les solutions de sécurité cloud native utilisent l'API des fournisseurs cloud, ce qui change radicalement la logique des coûts. « Notre solution CNAPP sans agent est environ cinq fois moins chère à exploiter qu'une solution endpoint basée sur un agent pour le même nombre de VM et d'hôtes de conteneurs. Ce calcul ne peut que s'améliorer au fur et à mesure que l'activité continue de se développer », prévient  Jay Thoden van Velzen. Et quant on sait que SAP fait tourner 30 000 VM toutes les 24h cela peut clairement commencer à chiffrer.

Déploiement et gestion opérationnelle à assurer

Mais ce n'est pas tout de s'équiper d'une solution de sécurité dédiée à ses services cloud, encore faut-il être en mesure de la déployer et de s'en servir avec la meilleure efficacité et facilité possible. Et dans ce cadre SAP a clairement vu un avantage pour le cloud. « Pour diverses raisons, les outils de sécurité des datacenters sont souvent constitués d'une collection de solutions ponctuelles de premier ordre. En outre, à la suite d'acquisitions, les organisations possèdent souvent une collection d'outils qui se chevauchent. Cela complique le travail de collecte des flux de données, leur enrichissement avec des métadonnées et leur mise en corrélation dans les plateformes SIEM. Chaque source de données supplémentaire ajoute à la complexité et à l'effort d'intégration avant d'aboutir à des détections efficaces », indique Jay Thoden van Velzen. Et de préciser : « les outils de sécurité cloud native peuvent être déployés par l'API cloud et peuvent être mis en œuvre au niveau de l'entreprise. Ainsi, l'onboarding peut être centralisé et appliqué à tous les comptes cloud de l'organisation sans aucun effort de la part des équipes de développeurs ».