Utilisation de la Suite Elastic dans les opérations de sécurité basées sur SaaS

Chez RS2, la sécurité est au cœur de nos actions. Notre produit principal, BankWORKS, est une solution intégrée de bout en bout dotée d’un ensemble complet de fonctionnalités. Il répond à tous les besoins en termes de traitement des paiements, depuis l’acquisition d’une transaction à partir d’un appareil jusqu’au règlement final et à l’inscription au grand livre. Ce logiciel sert aux banques, aux agents de traitement et aux fournisseurs de services de paiement du monde entier, quels que soient leur taille et le degré de complexité. Nous proposons également le produit sous forme de service géré hébergé.

Notre rôle, en tant qu’équipe, est de veiller à limiter les risques de corruption ou de fuite des données, dans tous les domaines de notre entreprise. Nous devons également respecter les différentes exigences de conformité, tout en évitant l’interruption des opérations quotidiennes.

En novembre 2017, nous avions pour objectif de renforcer notre équipe de sécurité. Toutefois, avant de demander à embaucher de nouvelles recrues, nous souhaitions nous attaquer à une autre problématique : réduire les interventions manuelles dans la gestion des incidents et des événements de sécurité. C’est là que notre périple avec la Suite Elastic a commencé.

De la proposition à la production

Étapes initiales

Je m’étais déjà servi de la Suite Elastic dans d’autres fonctions et dans le cadre de projets personnels. J’avais donc très envie de présenter le produit à l’équipe. J’avais le sentiment que ce produit répondrait à toutes nos exigences grâce à son ensemble complet de fonctionnalités et sa scalabilité.

Dans les jours qui ont suivi ma prise de fonctions dans un nouveau rôle chez RS2, j’ai déployé Elasticsearch et Kibana (version 6) sur une machine virtuelle dans mon ordinateur portable. J’ai installé quelques Beats directement sur la MV (packetbeat, auditbeat, metricbeat et filebeat) et j’ai envoyé toutes les données à Elasticsearch. Seule une heure a suffi pour que Kibana obtienne des données pertinentes (dont 40 minutes pour le téléchargement et l’installation de l’image ISO du système d'exploitation).

J’ai montré ce processus à mon collègue, et il a été presque immédiatement convaincu que c’était l’outil dont nous avions besoin pour avancer, que nous devrions créer une démo avec des données réelles pour présenter cette solution aux dirigeants et mettre en avant son efficacité. Nous avons décidé d’inclure quelques dispositifs réseau et quelques serveurs existants qui n’impliqueraient pas de changements au niveau de notre réseau de production (avec les Beats et Logstash), ainsi que quelques intégrations tierces.

Évaluation du cloud

Dans mes fonctions précédentes, j’ai hébergé de larges déploiements Elastic regroupant plusieurs serveurs. Toutefois, je ne m’étais pas réellement penché sur l’offre Elastic Cloud. RS2 s’est retrouvé en position de « gel au niveau de l’infrastructure » en raison de sa migration imminente vers le cloud. Cette situation, associée au fait que nous disposions de délais serrés et de ressources limitées, m’a amené à étudier Elastic Cloud. En tant que professionnel de la sécurité des infrastructures et des données, j’étais sceptique. Je voulais m’assurer que le service avait été conçu en gardant la sécurité à l’esprit.

Dès que j’ai eu mon cluster, j’ai effectué quelques tests rapides de sécurité pour voir si je détectais une vulnérabilité ou une faille flagrante. Voici ce que j’ai découvert :

• Elastic vous permet de choisir entre AWS et GCP comme fournisseur de cloud back-end. De ce fait, vous bénéficiez de toutes leurs fonctions de sécurité, ainsi que de leurs certifications de conformité.
• Des réseaux distincts sont utilisés pour chaque cluster, et non pas les sous-réseaux par défaut de chaque fournisseur.
• Des paramètres TLS et des messages cryptés modernes sont utilisés pour les URL d’Elasticsearch et de Kibana
• Les ports de transport d’Elasticsearch sont choisis de façon aléatoire
• Les URL de chaque instance sont également choisies de façon aléatoire, il n’est donc pas possible d’énumérer les noms de clients
• Il n’est pas possible d’avoir un accès IP direct sans ID de cluster
• Les dernières versions de la Suite Elastic sont utilisées, ainsi qu’une version récente de Java 8.

Mise en place

Je disposais donc de mon cluster cloud. Il me fallait désormais concevoir les flux de données. Le diagramme ci-dessous présente l’architecture pour la preuve de concept.

Comme nous disposions de X-Pack, nous nous sommes beaucoup servi de Watcher dans l’architecture d’alerting. Nous l’avons intégré avec un Slackbot personnalisé à l’aide des actions webhook de Watcher.

Préparation de la démo – Traitement des données

Première étape : analyser et enrichir nos logs le plus possible. En matière de sécurité, l’enrichissement joue un rôle fondamental pour résoudre les incidents rapidement. En effet, il permet de réduire drastiquement le temps d’investigation nécessaire aux analystes. Il aide également à filtrer les faux positifs. Pour réaliser cette première étape, je me suis servi de plusieurs plug-ins de filtre Logstash. Un vrai jeu d’enfant ! De plus, pour pourvoir aux besoins de notre outil existant d’archivage de logs, j’ai pu configurer plusieurs sorties Logstash pour envoyer des données simultanément à notre cluster Elastic et à l’outil d’archivage existant.

Voici une liste de quelques opérations d’enrichissement ajoutées à nos logs analysés :

• Données GeoIP (géolocalisation et ASN)
• Recherches d’IP malveillantes
• Recherches d’utilisateurs autorisés à se connecter
• Analyse d’agents
• Déchiffrement d’URL

Il s’agit d’une liste partielle des enrichissements configurés pour la preuve de concept. Nous en avons ajouté bien d’autres lorsque nous sommes passés à la production.

J’avais donc des données correctement analysées. Avec ces données, j’ai créé des tableaux de bord personnalisés, que j’ai utilisés en plus des tableaux de bord intégrés de base, pour mettre en avant certaines des fonctionnalités d’enrichissement évoquées précédemment. Voici quelques exemples de tableaux de bord Kibana personnalisés que nous avons élaborés pour la preuve de concept (toutes les données sensibles ont été supprimées) :

J’ai ajouté en plus d’autres intégrations astucieuses pour la démo afin de montrer à quel point il est facile d’ajouter des données à Elastic. Il s’agit en fin de compte d’un autre index. Parmi ces intégrations, citons celle au célèbre service "Have I been Pwned?" de Troy Hunt. Le service propose une API REST très pratique, qui vous permet de demander si une adresse e-mail est détectée dans les failles de données médiatisées. Un système de surveillance a été créé pour nous alerter en cas de nouvelles entrées dans notre domaine.

Alerting

L’idée sous-tendant l’architecture d’alerting de la preuve de concept (à appliquer ultérieurement dans la production) était que tout soit exploitable avec Slack. Voici quelques exemples de données manipulées dans Slackbot. Un analyste dispose de tout ce dont il a besoin pour démarrer une investigation. Les données utilisées ont été recueillies par différents Beats, et les logs analysés des dispositifs réseau, par Logstash.

Certains ensembles de données contenaient les éléments suivants :

• Logs de relais SMTP, logs d’authentification et logs de filtrage de paquets de nos pare-feux
• Requêtes DNS au niveau des paquets, à l’aide de Packetbeat
• Logs SSH/SFTP, utilisant Wazuh et Filebeat de façon combinée
• Une liste des processus et de leur statut, avec Metricbeat
• Monitoring du socket réseau sortant, avec Auditbeat sur systèmes *nix

Voici quelques exemples d’alertes Slackbot que nous avons élaborées pour la preuve de concept (toutes les données sensibles ont été supprimées) :

• Alerte de connexion TeamViewer
  
  
• Alerte de connexion au pare-feu
  
  
• Alerte de programme malveillant
  
  

Résultats

Il va sans dire que la preuve de concept a été un vrai succès et que nous avons eu l’autorisation de passer à la production. Comme évoqué précédemment, voici les principaux points qui nous ont permis de réaliser cette preuve de concept avec autant de fluidité :

• La facilité et la vitesse exceptionnelles avec lesquelles il est possible d’utiliser Elastic Cloud et de tout ce qu’elle comprend (sauvegardes intégrées prêtes à l’emploi, résilience et haute disponibilité, X-Pack packagé pour la taille de notre déploiement)
• La capacité à prélever des données et à les convertir en informations utiles et exploitables très rapidement (il nous a fallu trois jours complets pour mettre en œuvre la preuve de concept, du début à la fin, en réalisant notamment les tâches indiquées dans cet article – analyse, élaboration des tableaux de bord, enrichissement, mise en place de l’architecture d’alerting, etc.)
• Le fait que nous puissions réaliser toutes ces tâches en parallèle des processus existants, sans interruption

Gestion des mises à niveau

Après quelques semaines en production, Elastic a publié une mise à jour. Étant donné que j’avais déjà réalisé la mise à niveau de larges déploiements Elastic avec X-Pack, j’étais très curieux de voir comment cette mise à niveau serait gérée par la plate-forme cloud. En fait, c’était d’une extrême simplicité : on sélectionne la nouvelle version dans un menu déroulant, et tout se fait automatiquement, sans interruption.

Conclusion

Comme vous pouvez l’imaginer, notre aventure avec Elastic ne s’est pas arrêtée là. Nous ajoutons en permanence de nouvelles sources de données, nous renforçons l’enrichissement (p. ex. la corrélation avec nos systèmes RH pour obtenir les données sur les vacances des utilisateurs et les systèmes d’accès physique pour si quelqu’un se trouve ou devrait se trouver dans le bâtiment ou pas), et nous définissons des alertes immédiatement en fonction des menaces et des activités malveillantes découvertes. Nous travaillons également sur l’intégration à d’autres outils internes que nous utilisons.

L’avenir de la Security Analytics avec Elastic s’annonce prometteur... et nous avons hâte d’y être ! À chaque mise à jour, Elastic ajoute des composants supplémentaires qui simplifient le travail de nos analystes et suscitent leur enthousiasme. Autre grand événement que nous attendons aussi avec impatience : les mises à niveau d’Elastic Cloud. RS2 va continuer à tirer profit des ensembles complets de fonctionnalité, non seulement dans le cadre de la Security Analytics, mais pour toute l’organisation. Et ça, c’est une certitude !