Pourquoi suis-je ici ?

Pourquoi suis-je ici ?

Ulfar Erlingsson - Chief Architect

June 3, 2021

Remarque : cette publication est une version abrégée de l'article « Interview with Úlfar Erlingsson » sur l'entretien mené par l'équipe de recherche de Sutter Hill Ventures. Consultez la publication originale ici (en anglais).

Comme beaucoup de personnes qui travaillent dans la sécurité, je suis arrivé là par hasard. Au milieu des années 90, je faisais un doctorat quand Internet est arrivé, ou plutôt quand le monde entier a commencé à se servir d'Internet à partir d'un navigateur Web. 

Il est tout de suite apparu clair qu'Internet engendrait un nombre faramineux de problèmes de sécurité, au point où il semblait que cela n'allait jamais fonctionner. Pendant ce temps, je travaillais sur les traitements distribués fiables, le fondement de ce que l'on appelle aujourd'hui le cloud, où ces questions de sécurité étaient également soulevées. 

Bien que j'aie passé toute ma carrière dans la sécurité, l'approche réactive axée sur des règles qui a dominé le secteur depuis ses débuts ne m'a jamais intéressé. 

Il existe deux approches diamétralement opposées concernant la sécurité de l'activité des logiciels. La première consiste à définir des règles qui reconnaissent des activités malveillantes (de potentiels dangers) et signalent toute activité détectée de cette façon. C'est globalement de cette manière que le secteur de la sécurité fonctionne depuis les années 80. Les premiers fournisseurs d'antivirus ont créé un antivirus fondé sur un système de signatures et depuis, toutes les entreprises prospères de sécurité logicielles ont adopté la même approche.

L'approche opposée consiste à comprendre les workloads du client et à déterminer ce qu'elles devraient faire au lieu de définir ce qu'elles ne devraient pas être en train de faire. Au premier abord, cela semble être une tâche beaucoup plus simple. L'ensemble d'activités qu'un logiciel doit exécuter est beaucoup plus restreint que l'infinité (dénombrable) d'activités qu'il ne devrait jamais effectuer. On appelle cette approche la « détection d'anomalies comportementales ». Elle nous permet de garantir la sécurité en veillant à ce que seul se produise ce qui doit se produire. 

Le concept est simple, mais dans les faits, la détection des anomalies comportementales est très compliquée à mettre en œuvre. Pour de nombreuses raisons, déterminer ce qui est normal est extrêmement difficile et ne peut pas être mis à l'échelle. Dans le monde des centres de données d'entreprises, les organisations disposaient d'un ensemble unique de logiciels et de matériel entremêlés, généralement sur plusieurs dizaines d'années. Déterminer ce qui fonctionnait pour une entreprise n'avait presque aucune incidence sur ce qui fonctionnerait pour une autre. Il en devenait impossible de trouver une solution réutilisable.

Le cloud change la donne. La plupart des entreprises cloud-native sont assez similaires. Nous pouvons collaborer avec elles pour nous améliorer en permanence, obtenir de meilleures données sur ce que nous faisons et contrôler nos résultats. Nous échouons moins que la concurrence et chaque fois que cela arrive, c'est l'occasion pour nous de changer de point de vue et d'aborder d'autres types de problèmes similaires qui pourraient se produire. Pour nos concurrents, maintenir une liste exhaustive de règles personnalisées est une tâche sans fin digne de Sisyphe.

Chez Lacework, nous avons vraiment réussi à créer un produit de sécurité de niveau supérieur qui consiste à comprendre ce qui est normal dans l'environnement de notre client et à signaler les écarts par rapport à cette notion de normalité. C'est un tournant majeur dans la mise en œuvre de la sécurité. Cette méthode nous rend uniques, non seulement dans notre approche pratique de la Cloud Security, mais aussi concernant notre définition des valeurs et des paramètres de la sécurité.

Derrière l'offre unique de Lacework, il y a notre outil Polygraph. Il s'agit d'un aperçu virtuel et abstrait de ce qui se passe dans le cloud du client. 

Concrètement, les activités qui s'exécutent dans le cloud recouvrent le lancement de processus, des employés effectuant leur travail et des éléments passant d'une machine à l'autre, par exemple. Il y a un flux important ici. Les adresses IP ne sont pas statiques. Les noms DNS ne sont pas statiques. Même les processus et les missions ne le sont pas. Beaucoup d'entreprises ont migré vers des microservices, qui peuvent s'exécuter pendant quelques secondes ou minutes. À l'inverse, dans les entreprises, vous aviez auparavant des composants d'infrastructure tels qu'un environnement serveur/client, où tout le travail de l'équipe d'assistance informatique consistait à essayer de faire fonctionner ces éléments pendant des mois sans interruption. Désormais, dans le cloud, vous avez une abstraction qui peut être un ensemble éphémère de microservices dont aucun ne vit plus de 30 secondes. Cependant, cet ensemble éphémère est en fait un composant, et c'est une partie essentielle de ce que fait le client.

Cet ensemble éphémère de services présente également des comportements particuliers. Même s'il ne vit que pendant une courte durée, il obtient des données à partir d'une certaine source et il répond à des questions qui proviennent de quelque part. C'est en déterminant qu'un ensemble éphémère particulier d'activités est en fait un composant, en répétant la même démarche pour les composants avec lequel il communique (qui peuvent aussi être virtuels ou éphémères) et enfin en définissant le comportement correct de ces éléments que nous pouvons créer notre Polygraph. 

Ainsi, lorsque l'un de ces processus ouvre soudainement un port TFTP ou commence à lire des données issues d'un compartiment S3 très différent (actions typiques d'un comportement malveillant), nous pouvons le repérer. C'est ce que fait Polygraph. Il élabore ces abstractions ou entités abstraites virtuelles qui représentent de nombreuses activités, processus et machines, y compris des machines qui apparaissent et disparaissent en raison de la mise à l'échelle élastique. Le Polygraph reconnaît cela comme une abstraction unique qu'il relie à d'autres abstractions pour former un graphique qui représente la manière dont les abstractions doivent communiquer et interagir entre elles, et la façon dont elles dépendent les unes des autres. C'est notre technologie principale. 

J'ai rejoint Lacework parce que j'essaye depuis plus de dix ans de suivre l'approche de détection des anomalies. Et c'est très compliqué. C'est extraordinaire que Lacework y soit parvenu. Je suis donc là parce que j'étais fasciné et que je voulais faire partie du processus visant à changer fondamentalement et à améliorer la manière dont la sécurité est atteinte dans le cloud.