Comprendre les résultats souhaités : comment nous avons sélectionné l’ensemble de fonctionnalités de Cloud Defense Free

Lorsque nous avons décidé de lancer une version gratuite de FireMon Cloud Defense, nous savions que nous devrions concilier deux défis majeurs :

• Nous savions déjà que notre plateforme pouvait passer à l'échelle, mais pouvions-nous l'adapter pour qu'elle évolue de façon économiquement viable et prenne en charge de grandes entreprises sur le long terme ? Inutile de préciser que nous ne pouvions pas nous contenter de la publier en espérant que nos factures AWS ne nous conduisent pas au dépôt de bilan.
• Compte tenu de ces limites économiques, pouvions-nous proposer un ensemble de fonctionnalités apportant une valeur réelle aux utilisateurs ? En quoi consisterait cette valeur ? Quels problèmes résoudrait-elle ?

En réalité, « gratuit » n'est jamais totalement gratuit, puisque l'utilisation de quoi que ce soit demande du temps et des efforts. Nous ne considérons pas l'offre gratuite de Cloud Defense comme des miettes que nous laisserions tomber du bord de la table : nous savons que si nous demandons aux utilisateurs de s'inscrire, de déployer et d'utiliser la plateforme, ils ne le feront que si nous les aidons à accomplir leur travail.

(Qu'y gagnons-nous ? Nous savons qu'un certain pourcentage d'utilisateurs passera à nos formules payantes, mais la plateforme gratuite nous permettra surtout de recueillir des retours extrêmement précieux sur ce que les utilisateurs attendent de leur CSPM et sur la façon dont ils s'en servent, et de tester de nouvelles idées.)

Dans de prochains articles, nous aborderons la technologie plus en détail, mais aujourd'hui nous souhaitons vous présenter la démarche qui nous a permis de déterminer quelles fonctionnalités intégrer à l'offre gratuite. Comme nous considérons cette version de la plateforme comme un produit à part entière, nous avons décidé d'appliquer la même approche méthodologique que celle qui guide l'essentiel de notre stratégie.

Définir les résultats attendus

Chez FireMon, nous sommes de grands adeptes du cadre Jobs to be Done pour la stratégie produit. Le nom est assez explicite : ce cadre oriente les décisions produit en se concentrant sur la tâche que le client cherche à accomplir et sur les résultats précis qu'il en attend. Il s'agit là d'une simplification grossière du cadre JTBD, mais vous en saisissez l'idée. Plutôt que de vous concentrer sur les fonctionnalités, vous vous concentrez sur les résultats qu'un client potentiel attend d'un produit, puis vous vous en servez pour concevoir les fonctionnalités.

Au terme d'un processus approfondi mêlant recherche, expérience et entretiens, nous avons dégagé une première liste de résultats susceptibles d'être attendus par les professionnels de la sécurité du cloud :

• Améliorer ma connaissance et ma compréhension de notre posture cloud sur l'ensemble de notre empreinte cloud. (visibilité)
• Réduire au minimum la probabilité qu'une mauvaise configuration cloud soit appliquée sur notre empreinte cloud. (prévention)
• Réduire nos expositions en matière de sécurité et de conformité du cloud (en volume et en durée) sur l'ensemble de notre empreinte cloud, dans un environnement décentralisé. (remédiation)
• Améliorer notre capacité à communiquer les problèmes de sécurité du cloud à la direction et aux régulateurs.
• Réduire les risques de perte et d'utilisation abusive des accès IAM à nos déploiements cloud.
• Améliorer notre capacité à prévenir et détecter les attaques cloud et à y répondre
• Maintenir notre sécurité à jour face aux évolutions des services et plateformes cloud chez plusieurs fournisseurs.
• Réduire les frictions et la charge liées à la sécurité pour les équipes de développement et cloud, sans accroître nos risques de sécurité.
• Réduire le risque de violation de sécurité lors de nos déploiements en conteneurs.
• Réduire le temps que je consacre à intégrer la sécurité du cloud à mon programme grâce à des API et des structures de données standard.

Il existe évidemment de nombreuses façons de traiter chacun de ces problèmes ; la question qui se posait à nous était donc de savoir lesquelles nous pouvions couvrir compte tenu des contraintes économiques liées à l'exploitation d'une plateforme hébergée gratuite. C'est très différent de la mise à disposition d'un logiciel open source que chacun doit déployer et exploiter lui-même. Nous voulions créer quelque chose d'aussi rapide et simple à utiliser qu'un produit commercial (disons, espérons-le, plus rapide et plus simple que bon nombre des produits que vous avez utilisés par le passé).

Traduire les résultats en fonctionnalités

Cette liste établie, il était temps de voir ce que nous pouvions adapter ou développer :

• Améliorer ma connaissance et ma compréhension de notre posture cloud sur l'ensemble de notre empreinte cloud. (visibilité)

La posture ne concerne pas nécessairement que la sécurité ; la posture, c'est la manière dont les choses sont configurées. Comme fournir une simple liste de mauvaises configurations ne rendrait pas compte de la posture, nous savions qu'il nous faudrait constituer un inventaire cloud, à l'échelle de l'entreprise, dans le respect de nos contraintes de coûts. Notre plateforme prenait déjà en charge un inventaire en temps réel, mais son passage à l'échelle n'était pas économiquement viable pour l'offre gratuite.

Nous avons conclu que nous pouvions maîtriser les coûts tout en apportant de la valeur avec des analyses quotidiennes et un historique d'inventaire de 30 jours avec suivi des changements. Vous remarquerez que nous ne parlons pas encore des mauvaises configurations de sécurité, mais nous y viendrons. Après quelques modélisations de coûts, nous avons constaté que nous pouvions faire fonctionner cela à l'échelle de l'entreprise (des milliers de comptes surveillés) dans les limites de notre budget : les deux cases étaient donc cochées, valeur apportée et coûts maîtrisés.

Cela a en réalité demandé un effort d'ingénierie considérable, car le produit commercial prenait principalement en charge des mises à jour d'inventaire en temps réel plutôt que des analyses périodiques. Nous avons toutefois regroupé ces évolutions avec d'autres changements que nous souhaitions apporter et qui amélioraient l'efficacité globale : l'ensemble s'accordait bien, ce qui a rendu la décision facile.

• Réduire au minimum la probabilité qu'une mauvaise configuration cloud soit appliquée sur notre empreinte cloud. (prévention)

Prévenir les mauvaises configurations cloud est un problème bien plus difficile que les détecter. Faut-il les bloquer dans le pipeline CI/CD lorsque l'infrastructure as code est utilisée ? Et les modifications manuelles ? Comment gérer les flux de travail sans ajouter trop de frictions ni casser des choses ?

Nous savions que nous ne pouvions pas mettre en œuvre une prévention complète dans un produit gratuit à ce stade. Notre plateforme actuelle gère cela par l'automatisation, dont l'exécution à grande échelle serait trop coûteuse en gratuit. Nous avons néanmoins quelques idées qui pourraient fonctionner et qui figurent désormais dans notre backlog de développement.

• Réduire nos expositions en matière de sécurité et de conformité du cloud (en volume et en durée) sur l'ensemble de notre empreinte cloud, dans un environnement décentralisé. (remédiation)

C'est le cœur de métier de Cloud Defense depuis les premières versions du produit. Si la remédiation automatisée ne convenait pas à notre offre gratuite (là encore, pour des raisons de coût et de complexité), rien ne nous empêchait d'exécuter l'intégralité de notre suite de contrôles de sécurité.

Mais recevoir une longue liste de problèmes de sécurité potentiels n'aide pas nécessairement à les corriger. L'une des autres capacités fondamentales de notre produit est une intégration ChatOps poussée. Nous prenions en charge Slack et Teams dès le départ, mais Teams exigerait davantage de support pour la raison suivante… eh bien… c'est Teams. Nous avons donc décidé d'activer pleinement nos notifications Slack granulaires (par compte ou par projet), puisque cela ne représentait aucun coût significatif pour nous et beaucoup de valeur pour les utilisateurs.

• Améliorer notre capacité à communiquer les problèmes de sécurité du cloud à la direction et aux régulateurs.

Nos coûts internes pour générer un rapport de conformité sont négligeables, même pour de grands environnements. En matière de conformité, des évaluations quotidiennes répondent généralement plus que largement à ce résultat attendu. Nous avons dû fournir un effort de développement supplémentaire pour prendre en charge de meilleurs rapports PDF sur les déploiements de grande taille (des centaines de comptes, par exemple), mais nous en avions de toute façon besoin pour nos clients commerciaux.

• Maintenir notre sécurité à jour face aux évolutions des services et plateformes cloud chez plusieurs fournisseurs.

Comme nos produits gratuit et commercial utilisent la même bibliothèque de contrôles, que nous mettons constamment à jour, cette capacité était disponible d'emblée. Notre effort d'ingénierie initial a porté sur l'optimisation des coûts pour AWS ; nous avons donc décidé de lancer le produit sans prise en charge d'Azure ni de GCP au départ. Azure est presque prêt, si bien que les utilisateurs bénéficieront à terme d'une prise en charge multicloud complète gratuitement.

• Réduire les risques de perte et d'utilisation abusive des accès IAM à nos déploiements cloud.

Nous disposons d'une fonctionnalité remarquable appelée Authorization Control, qui améliore sensiblement la sécurité IAM, mais l'équation économique ne permettait pas de l'inclure dans le produit gratuit.

• Améliorer notre capacité à prévenir et détecter les attaques cloud et à y répondre

Notre produit commercial prend en charge la détection des menaces en temps réel, mais il s'agit là encore d'une fonctionnalité dont l'équation économique ne permettait pas la prise en charge dans une plateforme gratuite, en raison du volume élevé d'activité à surveiller en temps réel.

• Réduire les frictions et la charge liées à la sécurité pour les équipes de développement et cloud, sans accroître nos risques de sécurité.
• Réduire le risque de violation de sécurité lors de nos déploiements en conteneurs.
• Réduire le temps que je consacre à intégrer la sécurité du cloud à mon programme grâce à des API et des structures de données standard.

Tous ces résultats ajoutaient des coûts et/ou de la complexité que nous n'estimions pas pouvoir absorber convenablement dans le produit gratuit, qu'il s'agisse de coûts d'infrastructure, de support ou de développement.

Composer l'ensemble de fonctionnalités

Les résultats attendus, combinés à notre analyse des coûts, nous ont aidés à décider quelles fonctionnalités inclure :

• Analyses une fois par jour
• Inventaire des ressources avec un historique de 30 jours
• La suite complète de contrôles de sécurité
• Rapports de conformité fondamentaux
• Intégration Slack
• AWS pour l'instant, Azure et GCP au fil des mises à jour de la plateforme

Ces décisions n'ont pas toujours été faciles. Par exemple, même un inventaire de 30 jours a un coût, mais nous estimions que livrer uniquement des rapports de mauvaises configurations ne répondrait pas correctement aux besoins de visibilité d'un utilisateur. Nous avons également considéré que limiter nos contrôles de sécurité ou obliger un utilisateur à passer au produit commercial pour obtenir des rapports de conformité aboutirait à un produit n'offrant pas réellement un résultat suffisant.

Cet ensemble répond aux principaux résultats attendus en matière de visibilité de sécurité, ainsi qu'aux résultats liés à la communication, afin d'améliorer le reporting et de réduire les délais de remédiation. Et nous savons que la valeur est là, puisque ce sont précisément les résultats attendus auxquels les premiers outils open source de sécurité du cloud entendaient répondre, et qui sont à l'origine de l'ensemble du marché du Cloud Security Posture Management.

Le cadre JTBD nous a réellement aidés à rester concentrés sur l’amélioration des résultats pour nos clients, plutôt que de simplement détacher quelques fonctionnalités qui, ensemble, n’aident vraiment personne. Nous estimons que le résultat final est une plateforme gratuite qui apporte une valeur concrète tout en étant si économique que nous pouvons la prendre en charge sur le long terme.

Découvrez-la et dites-nous ce que vous en pensez. FireMon Cloud Defense est en cours de développement et constitue pour nous un excellent moyen d’améliorer notre capacité à aider les professionnels de la sécurité cloud à accomplir leur travail.