Comment Lacework s’attelle à l’observabilité et à la sécurité dans le cloud
La jeune pousse s’appuie à la fois sur les API et sur un agent déployable de manière industrialisée pour, notamment, offrir une visibilité complète sur les flux réseau et assurer la détection d’anomalies.
Lacework est une jeune pousse basée à San Jose, en Californie. L’entreprise a été fondée début 2015 par Mike Speiser, Sanjay Kalra et Vikram Kapoor. Le premier a été PDG de Snowflake entre 2012 et 2014 – la plateforme de Lacework s’appuie d’ailleurs sur Snowflake. Le second est notamment passé par Cisco et Juniper, tandis que Vikram Kapoor, directeur technique de Lacework, a été patron de l’ingénierie de Bromium durant plus de trois ans – un spécialiste de la microvirtualisation fondé par Simon Crosby (ancien directeur technique de Citrix), racheté par HP en 2019.
Philippe Van Hove, responsable Europe du Sud et Centrale pour Lacework, explique que la jeune pousse a développé une plateforme « qui vise à adresser la question de la sécurité dans le cloud », une question qu’il décrit comme « un problème de Big Data et d’analytique », mais surtout un sujet « très compliqué » pour les entreprises. Pourquoi ? Parce qu’il faut d’abord disposer des talents maîtrisant les technologies impliquées, mais aussi réussir à faire appliquer des politiques de sécurité dans des environnements où les volumes de données et les quantités de flux sont très importants.
Et c’est sans compter avec la nature profondément dynamique de ces environnements où, notamment, toute trace d’activité peut disparaître avec l’arrêt d’un conteneur : « l’agilité et l’accélération des activités rendent l’exploitabilité et l’observabilité de ces flux extrêmement difficile ». Du coup, constate-t-il, pour beaucoup d’entreprises, « la meilleure façon de faire, c’est souvent… de ne rien faire ».
Pour Philippe Van Hove, la première force de Lacework est le choix de Snowflake comme socle technologique, qui « permet de collecter des volumes de données considérables ». Et d’évoquer le chiffre de 7 milliards de data points par client et par mois. Le tout est enrichi de manière transparente par l’application d’algorithmes d’apprentissage automatique non supervisé pour établir des modèles comportementaux et, dès lors, détecter d’éventuelles anomalies.
De quoi réduire très significativement le volume d’alertes générées et, surtout, de produire des alertes déjà enrichies et contextualisées. En France, alors que l’activité de Lacework sur le Vieux Continent n’a démarré qu’il y a quelques trimestres, Philippe Van Hove revendique déjà IDemia et Vestiaire Collective comme clients.
En entrée, la plateforme, qui s’inscrit dans la catégorie des Cloud Workload Protection Platforms (CWPP), s’alimente auprès des API offertes par AWS, Azure, et GCP, ainsi que d’un agent, notamment pour assurer l’observabilité des conteneurs : l’agent assure la surveillance de « tout ce qui se passe à la suite d’une connexion réseau entrante ou sortante », explique Frédéric Breton, responsable technique Europe du Sud et Centrale de Lacework. Mais il surveille également les fichiers et leurs éventuelles modifications, ou encore inventorie les paquets utilisés.
Toutes ces données collectées sont consolidées dans plusieurs tableaux de bord accessibles via une interface Web pour fournir une vue d’ensemble sur la conformité de l’environnement ou encore sur les vulnérabilités présentes ainsi que les défauts de configuration – comme ceux susceptibles de rendre accessibles à n’importe qui des données stockées dans des buckets S3. Un classique, malheureusement.
Surtout, l’interface permet d’accélérer les investigations lorsque des anomalies sont détectées, ou encore de vérifier le risque d’exploitation de vulnérabilités – que ce soit en se penchant sur les chemins d’accès à l’hôte concerné ou sur le fait que le composant concerné soit véritablement actif ou simplement dormant.
La plateforme va également assez loin dans l’analyse des événements de sécurité, permettant notamment de remonter la trace de communications entre pods ou la chronologie d’une élévation de privilèges.
La configuration de l’interface n’est pas ajustée en fonction du profil de l’utilisateur et de son rôle dans l’organisation – et donc l’usage qu’il peut avoir de la plateforme –, mais ce rôle détermine les fonctionnalités auxquelles il aura accès.
