Comment êtes-vous arrivé à cette solution ?
ALSID se place sur un marché très particulier et très précis car il concerne la sécurité des infrastructures AD.
Pourquoi ce marché ? Pourquoi aujourd’hui a-t-on la reconnaissance du marché sur cette thématique-là ? C’est relativement simple : si on considère la ‘kill chain’ de Lockheed Martin qui est standardisée et reconnue par le marché. C’est les 10/11 étapes que suivent typiquement un groupe d’attaquants pour prendre la main sur une infrastructure correcte. Généralement, cela passe par des phases de reconnaissance ensuite par la compromission d’un certain nombre de « endpoints » puis des mécanismes de propagation latérale, d’élévation de privilèges pour atteindre un niveau d’accès sur la cible qui est suffisant pour arriver à ses fins, piquer de l’information ou détruire une partie du SI.
La difficulté qu’ont ces acteurs, c’est qu’on a aujourd’hui une quantité de ‘devices’ très importante (on compte 3 ou 4 ‘devices’ en moyenne par employé). C’est probabiliste. On estime qu’au bout d’un moment, c’est irréaliste d’avoir l’ensemble de ces ‘devices’ parfaitement sécurisé, parfaitement à jour et parfaitement durcis de manière homogène sur des échelles qui sont importantes.
La question c’est : « qu’est-ce qu’il se passe si quelqu’un arrive à prendre la main sur ce ‘device’ là ? » Ce qu’on pense, c’est qu’il va pouvoir réaliser assez facilement de l’élévation de privilèges ou de la propagation latérale car la protection est beaucoup moins élevée une fois qu’on est à l’intérieur du réseau de l’entreprise.
Et c’est là où on va agir. On pense que l’AD arrive en seconde étape lors d’un scénario d’attaque avancée et sur lequel il y a beaucoup moins de protection. Les entreprises sont moins matures en termes de visibilité et sont un peu démunies en matière de capacité de détection des menaces sur ces infrastructures.
Le deuxième point qui nous fait dire qu’on est dans un positionnement intéressant, c’est qu’aujourd’hui, on est dans un basculement en termes de construction des SI. On part du château fort à l’ancienne où on protégeait nos bijoux à l’intérieur de notre réseau et où on construisait de grosses barrières périmétriques pour s’assurer que rien n’était franchissable.
Le problème, c’est l’arrivée du Cloud et l’explosion du nombre de ‘devices’ : les messageries sont décentralisées et beaucoup d’applicatifs sont en SaaS et donc les SI sont un peu ouverts aux quatre coins du vent. Maintenant, on a Azure AD accessible par API. L’AD est aussi exposé sur Internet ce qui le place en plein front sur les problématiques du moment. On a donc une menace qui s’intéresse à ces problématiques-là qui ne sont pas nouvelles.
On est arrivé sur un segment assez pointu, mais sur lequel il y a de la demande. Tout le monde est au courant des problèmes de sécurisation AD, mais comment est-ce qu’on l’adresse ? On intervient là.
Quel est le fonctionnement de votre solution ?
Historiquement, les solutions de sécurité sur AD étaient fabriquées avec les niveaux de connaissances de l’époque, c’est-à-dire avec une analyse des journaux d’authentification Windows ou une mise en place d’agents antiviraux sur les serveurs Windows. Le fait d’installer des agents logiciels sur des serveurs aussi sensibles que les serveurs AD qui contiennent tous les mots de passe de l’entreprise (aussi bien celui du PDG que celui du stagiaire) augmente considérablement la surface d’attaque.
Les antivirus ont quand même une chance d’avoir un ‘zero-day’. J’étais ancien pentester, et le grand jeu c’était de prendre la main sur l’AD en passant par un logiciel tiers. Chaque fois, on trouvait un moyen.
Après 10 ans de pentest, on s’est dit qu’il ne fallait pas d’agents tiers en place. Aujourd’hui, il y a des ‘forwarder’ de journaux. En termes de volumétrie, c’est lourd. On se retrouve avec des bandes passantes de 8 Gbits. Il y avait 50 logs inutiles pour la sécurité pour un log intéressant. Le ratio est ridicule et de nos jours, les attaques ne génèrent pas vraiment beaucoup de logs.
On s’est alors demandé comment avoir un outil qui n’installe pas d’agent, qui n’a pas de droits, qui n’utilise pas les journaux et qui ne change pas la configuration AD des clients. On veut accéder au contenu de la base AD. On veut voir l’activité de ce qui se passe sur l’AD, qui change de mot de passe, qui se connecte, qui se déconnecte, qui crée un compte, un groupe, qui obtient des droits, etc. On s’est rendu compte qu’un AD échangeait déjà ces informations entre tous les contrôleurs de domaines pour maintenir une cohérence des données. Les échanges sont réguliers, compressés, optimisés en termes de bande passante et nous n’avons pas grand-chose à faire pour les récupérer, c’est vraiment l’AD qui les envoie. On va donc s’abonner à ces flux de réplications. Quand l’AD envoie ses informations, il nous l’envoie également pour que nous l’analysions. Il y a derrière après toute une machinerie pour analyser les impacts des modifications, trouver les vulnérabilités, les tentatives d’attaques ou de faire de la réponse à incident.
Dans le cas d’un AD compromis, de DC shadow, etc… ALSID le détectera. Cependant, l’objectif d’ALSID n’est pas de détecter les attaques après, mais bien de détecter, via les signaux faibles, les attaquants avant qu’ils ne deviennent admin.
Quelles solutions de remédiation proposez-vous dans le cas d’une attaque ?
On ne peut pas corriger en live. Mais on peut y aller avec précaution et étape par étape. Mettre en quarantaine un AD de manière automatique, c’est trop dangereux.
ALSID garantit la bonne marche de l’AD du SI. Ils n’ont pas de droits. Comment automatiser les choses ?
On s’applique sur des briques complémentaires qu’on appelle des ‘playbooks’. Exemple : quelqu’un rentre dans le groupe d’administration de l’AD. On le détecte, on le remonte au SIEM qui va être orchestré par un orchestrateur lambda qui va recevoir l’information et qui va pouvoir lancer un playbook ALSID qui va requêter l’AD pour supprimer l’utilisateur du groupe. On va trouver une solution où l’on peut maîtriser l’impact. On définit ces playbooks avec le client.
On peut prendre des actions brutales, mais il faut prendre en compte de manière forte les contraintes de production.
Donc nous n’avons pas de droits et sommes non intrusifs mais nous laissons à nos clients des outils pour remédier de manière automatique.
Quelles sont les entreprises visées par votre produit ?
La question qui se soulève est sur la taille critique des clients qui utilisent les solutions ALSID. Généralement, les petites entreprises n’ont pas le niveau de maturité.
Nous nous intéressons aux entreprises plus structurées entre 500 et 1000 salariés qui commencent à avoir un réseau d’entreprise conséquent. C’est rare pour celles de moins de 200. La plus grande en date compte plus de 675 000 comptes sur l’AD.
Utilisez-vous de l’IA dans votre solution ?
L’IA répond à des problématiques très précises, mais je ne pense pas que ce soit adapté à l’AD. Pourquoi ne le faisons-nous pas ? L’IA est basée sur l’apprentissage et il y a une marge d’erreur. Il n’y a pas un cas de détection à 100 % par principe. Est-ce qu’il est possible d’accepter les faux positifs liés à l’apprentissage ?
On ne va pas faire de l’apprentissage, mais on va faire de l’analyse orientée graphe. On va représenter le modèle de sécurité des AD que l’on supervise sous la forme d’un hypergraphe c’est-à-dire un graphe connecté de manière multiplan et complète. Chaque nœud du graphe va être un objet AD. On va connecter les nœuds avec des relations de contrôle entre les objets. Si Alice peut changer le mot de passe de Bob, il y a une relation. Ensuite, on “mappe” le tout. Le produit fait de la recherche de chemin : à partir d’un nœud, est-ce qu’il est possible d’obtenir tous les droits ?
Avec cela, il nous faut beaucoup de puissance de calculs. Les graphes changent à chaque mise à jour de l’AD.
Par-dessus tout cela, il y aura une machine à état pour couvrir les comportements suspects pour prévenir les attaques.
Où est-ce que les hypergraphes sont stockés ?
Ils sont stockés dans le pays de l’entreprise. Ce sont des infrastructures qui sont dédiées aux clients. Cela nous rend une multitude de services. Il n’y a aucune mutualisation entre les clients. Il n’y aura pas de propagation en cas de compromission d’un client.
Personne n’y a accès. Tout est clusterisé avec Kubernetes. On peut y accéder, mais c’est très compliqué.
On prend nos conteneurs et on les met où on veut. Terraform nous permet d’être agnostiques au fournisseur de cloud sur lequel on se trouve. On a des clients du Canada, USA, Pays-Bas, France, Suisse, Italie, Hong Kong, Malaisie, Singapour, Australie, Japon sur des datacenters localisés dans chaque pays.
Que pensez-vous du ‘zero-trust’ et de la place de l’humain dans la cybersécurité ?
C’est l’évolution, et tout le monde va faire du zero-trust. On n’a pas vocation à être la ‘silver bullet’ qui va régler les problématiques de cybersécurité. L’idée c’est d’avoir une vision sur l’ensemble des niveaux logiques du SI, au niveau de la protection de la data, du réseau, de l’infra, des endpoints et d’avoir des mécanismes adaptés à chacun de ces enjeux. Chez ALSID, on est sur l’infrastructure. C’est pour cela qu’on est proche des fabricants de endpoints.
C’est extrêmement important d’avoir des humains dans la sécurité. Mais il faut surtout sensibiliser les administrateurs. Ils ont les clés du camion, il ne faut pas les oublier. Même s’il est bon en administration AD, il n’est pas forcément au courant des attaques sur l’AD. Le but est de les sensibiliser aux enjeux qu’il peut y avoir.
Typiquement, les admins qui se connectent en RDP sur une machine utilisateur, c’est du suicide.
Utilisez-vous ou produisez-vous de la threat intelligence ?
On n’en produit pas. On en consomme énormément pour avoir un produit à jour sur les attaques. Il faut que nous soyons informés sur ce qu’il passe. On travaille avec des sociétés de threat Intel qui sont confidentielles et qui nous transmettent leurs flux de threat Intel contre des analyses techniques sur l’AD et on met à jour nos capacités.
Le mot de la fin, parmi tous les thèmes que l’on vous a cité, pensez-vous qu’il en manque ?
J’ajouterai la notion d’orchestration : ‘comment automatiser la réponse à la menace ?’ Il y a un article dans ‘business insider’ qui montre comment le SOC croule sous les informations et que le but était de traiter automatiquement les données par les plateformes pour soulager l’analyste et se concentrer sur les menaces pour l’entreprise.
