Elastic sur Elastic : plongée au cœur de notre architecture SIEM
Elastic sur Elastic
L'équipe Elastic Infosec Detections and Analytics est responsable de la création, du réglage et de la maintenance des détections de sécurité utilisées pour protéger tous les systèmes Elastic. Chez Elastic, nous nous appelons Customer Zero et nous nous efforçons de toujours utiliser les versions les plus récentes de nos produits.
Dans cette série d’articles de blog, nous présenterons un aperçu de notre architecture, des données que nous envoyons à nos clusters, de la manière dont nous utilisons Cross Cluster Search (CCS) avec les applications Security et Machine Learning (ML), et des raisons pour lesquelles nous l’utilisons, ainsi que de la façon dont nous ajustons et gérons ces alertes et en informons les analystes.
Aperçu de l’environnement de sécurité informatique d’Elastic
De nombreux produits de cybersécurité et contrôles de sécurité sont conçus pour prendre en charge un "réseau d'entreprise" traditionnel, composé de postes de travail et de serveurs sur un réseau local, protégés par un pare-feu. Lorsqu'une alerte se déclenche et qu'une analyse forensique doit être menée sur une machine, il est d'usage de se rendre physiquement sur place pour effectuer un vidage de la mémoire et créer une image du disque dur. Chez Elastic, nous ne sommes pas une entreprise "traditionnelle" par nature ; notre équipe Infosec doit donc faire preuve d'innovation et de flexibilité pour protéger Elastic, sans chercher à faire entrer l'entreprise dans un moule "au nom de la sécurité". Heureusement, la Suite Elastic est la solution idéale pour cela.
Elastic est une entreprise mondiale qui est distribuée par conception, avec des clients et des employés dans plus de 80 pays à travers le monde. La plupart de nos employés travaillent exclusivement à distance, effectuant leurs tâches quotidiennes depuis un ordinateur portable appartenant à Elastic, connecté à Internet via des réseaux non fiables partout dans le monde. En tant qu'entreprise open source, notre code source se trouve sur GitHub et nos systèmes d'intégration continue et de compilation logicielle sont basés dans le cloud et sont visibles publiquement par les contributeurs. La surveillance efficace et la réalisation d'analyses forensiques sur ce réseau d'entreprise moderne et distribué nécessitent de recueillir les bonnes informations et de les mettre toutes à la disposition des analystes dans un seul emplacement.
En plus de nos postes de travail et de nos systèmes d'entreprise, nous monitorons et protégeons Elastic Cloud, qui fournit des services SaaS Elastic exécutant actuellement plus de 37 000 clusters Elastic dans plus de 40 régions cloud hébergées sur AWS, GCP, Azure et IBM. Elastic Cloud est un environnement distinct doté de privilèges élevés et géré par l'équipe Cloud, mais l'équipe Infosec d'Elastic est également chargée de créer des alertes dans cet environnement, de les monitorer et d'y répondre.
Zoom sur l’infrastructure de sécurité informatique d’Elastic
L'équipe d'ingénierie de la sécurité (SecEng) d'Infosec crée et assure la maintenance de notre ensemble de clusters à l'aide d'Elastic Cloud on Kubernetes et de Helm pour déployer l'infrastructure et assurer sa mise à jour. SecEng gère sept clusters différents ; six clusters de "données" avec différents rôles, et un septième cluster "search head" en tant que solution de gestion des informations et des événements de sécurité (SIEM) qui utilise CCS pour interroger les données et déclencher des alertes sur l'ensemble des autres clusters. Nous utilisons les versions les plus récentes de la Suite et des versions candidates avec des données réelles, de sorte que ses développeurs utilisent régulièrement nos clusters pour détecter et corriger les problèmes, mais aussi pour améliorer la Suite Elastic pour nos clients.
Pour pouvoir monitorer et protéger efficacement une organisation, il est essentiel de collecter les bonnes données et de les rendre exploitables en un seul endroit. Il n'existe pas de source de données unique regroupant toutes les informations nécessaires à la sécurité informatique. Un problème courant auquel de nombreuses organisations sont confrontées consiste à journaliser et à stocker les types de données appropriés, tout en les répartissant dans des emplacements distincts. Cette séparation peut être imposée par diverses exigences en termes de sensibilité ou de confidentialité, par exemple, des sources de données gérées par des équipes différentes ou les coûts liés au transfert des données vers un emplacement unique. Grâce à la puissance de CCS, nous pouvons conserver les données dans des clusters distincts, tout en étant en mesure d'effectuer des recherches et de générer des alertes depuis une interface Kibana unique, offrant ainsi aux analystes une vision globale et complète.
Grâce à une vue centralisée de toutes les informations, les analystes peuvent configurer leurs environnements de détection, de renseignement sur les menaces et de réponse aux incidents au sein de la Suite Elastic. Lors de l'analyse d'une alerte, nous pouvons utiliser les Timelines dans l'application Security pour mener des investigations en recherchant une valeur donnée dans l'ensemble des index. Outre ces timelines, nous utilisons également plusieurs tableaux de bord "Investigation" personnalisés, qui permettent d'afficher rapidement les informations nécessaires issues de divers index.
Scénario d’alerte critique
Imaginons que nous recevions une alerte critique indiquant que le compte Okta d'un employé pourrait être compromis. Nous constatons par ailleurs que, au cours du mois écoulé, le poste de travail de cet utilisateur a fait l'objet d'alertes comportementales à faible risque qui, considérées comme de fausses alertes, avaient été initialement écartées, mais qui méritent désormais un nouvel examen. Nous pouvons utiliser le tableau de bord User Investigation pour effectuer des recherches à l'aide de l'adresse e-mail de cet utilisateur et examiner rapidement toutes ses activités d'authentification Okta, les applications auxquelles il a accédé via l'authentification unique Okta, les fichiers Google Drive qu'il a consultés ou modifiés, son activité sur GitHub pendant cette période, ainsi que les accès aux fichiers Office 365 qui se sont produits au moment où son compte a potentiellement été compromis. Un panneau du tableau de bord affiche l'inventaire système JAMF concernant l'ordinateur portable professionnel attribué à cet utilisateur, ainsi que les coordonnées de celui-ci.
À l'aide des informations système, nous pouvons accéder au tableau de bord Host Investigation pour visualiser toute l'activité sur ce système et déterminer s'il a lui aussi été compromis ou si seul le compte Okta est concerné. Le fait de constater qu'aucun utilisateur n'était connecté au moment des alertes nous indique que le système est peut-être compromis et doit être isolé. Les événements Okta contiennent l'adresse IP utilisée pour se connecter. Nous pouvons également rechercher cette adresse IP pour voir si elle a été observée à ce moment-là dans l'un de nos autres ensembles de données comme les services cloud.
Des investigations de ce type peuvent prendre énormément de temps si vous ne disposez pas de tous les événements au même endroit. Sans collecte centralisée de vos événements, vous devrez vous connecter aux consoles d’administration de chacun des services hébergés afin de consulter les logs dans leur environnement.
La recherche inter-clusters, un choix gagnant
Nous avons décidé d'utiliser CCS pour deux raisons. Tout d'abord, nous disposions déjà de clusters contenant des données. Ensuite, nous souhaitions pouvoir effectuer des recherches sur l'ensemble de ces données depuis un cluster unique afin de simplifier la gestion des watchers, des tableaux de bord, des tâches de machine learning et des règles du moteur de détection. Plutôt que de migrer toutes les données vers un seul cluster, nous avons opté pour CCS. Avant l'adoption de cette solution, nous devions gérer ces objets et configurations sur plusieurs clusters, ce qui entraînait souvent une duplication des tâches.
Lors de l'analyse d'une alerte, nous devions auparavant ouvrir plusieurs onglets de navigateur pour consulter les différentes sources de données concernant l'événement. Désormais, lorsque nous examinons une alerte, nous pouvons créer un cas et une timeline dans l'application Security, qui regroupe tous les événements liés au cas. Par exemple, si nous détectons une alerte signalant une activité inhabituelle sur un serveur dans les données Auditbeat et que l'événement contient une adresse IP, nous pouvons interroger cette adresse IP dans une Timeline sur tous les index et voir rapidement si cette adresse IP a été observée dans l'un de nos autres services, tels que les données du proxy Nginx, Okta, GitHub, les logs du fournisseur cloud, les événements des postes de travail Endgame, etc. Grâce à ECS, les champs ont un format standard dans tous les modèles d'indexation, de sorte qu'une requête sur source.ip renvoie les documents de n'importe quel index avec une correspondance.
Outre ces raisons initiales, nous avons découvert bien d'autres avantages à cette configuration. Vous trouverez ci-dessous quelques-uns des nombreux bénéfices liés à l'utilisation de la recherche inter-clusters dans un contexte de sécurité.
- Stocker différents types de données dans des clusters distincts signifie que nous n’avons pas de point de défaillance unique pour l’ensemble de nos données. Lors de la mise à niveau d’un cluster, tous les autres clusters peuvent être utilisés.
- Nous pouvons accorder aux développeurs un accès pour tester et résoudre les problèmes sur un cluster de données spécifique sans leur accorder l’accès à toutes les données utilisées par Infosec.
- Les données des clusters Observability et APM sont souvent très utiles aux analystes de sécurité lors d’une enquête. Plutôt que de dupliquer toutes les données, nous pouvons ajouter les clusters distants à notre configuration CCS.
- Les analystes peuvent se voir accorder des privilèges élevés pour créer et gérer des alertes et des index sur le cluster SIEM, avec un accès en lecture seule aux données d’origine sur le cluster distant. Cela permet aux analystes de disposer de toutes les fonctionnalités de Kibana, tout en préservant l’intégrité des données d’origine à des fins d’audit et de conformité réglementaire.
- La mise à niveau du cluster Elastic "search-head" principal vers une nouvelle version vous donne accès à toutes les nouvelles fonctionnalités de Kibana, même si les autres clusters n'ont pas encore été mis à niveau. Cela allège considérablement la pression liée à la mise à niveau fréquente et anticipée de votre SIEM de production, car vous pouvez tester les dernières fonctionnalités sans risquer une interruption de service sur les clusters qui contiennent les données réelles.
- À partir de la version 7.13, les utilisateurs de Fleet doivent disposer de privilèges de superutilisateur sur le cluster. Il est possible de limiter au strict minimum le nombre d'administrateurs Fleet sur le cluster Fleet, tout en accordant aux autres utilisateurs des privilèges en lecture seule sur les événements collectés par ce cluster.
Customer Zero (suite)
Dans cet article, nous avons présenté un aperçu de la manière dont l’équipe Infosec d’Elastic utilise les nombreuses fonctionnalités d’Elastic Stack pour recueillir des données provenant de sources très diverses, afin d’offrir aux analystes une visibilité exceptionnelle sur les événements liés à la sécurité.
Assurez-vous de revenir consulter la deuxième partie de cette série, qui approfondira les types de données consultables dans Elastic SIEM et la façon dont vous pouvez aider vos équipes à simplifier et à rationaliser leurs efforts.