16 décembre 2015 Cas Utilisateur

WÜRTHPHOENIX NetEye : notre aventure avec la Suite Elastic

Par Georg Kostner

Wuerth-Phoenix_large.png

Exigences du marchés - Pourquoi la gestion de logs?

Tout a commencé avec la loi « informatique et libertés », Garante per la protezione dei dati personali, adoptée en 2008 par l'autorité italienne chargée de la protection des données. Cette loi stipule que toutes les entreprises doivent enregistrer l'ensemble des données relatives aux accès des administrateurs système et que ces données doivent être conservées pendant au moins six mois. Cela permet de faciliter et d'uniformiser la surveillance des activités des administrateurs système, mais surtout de protéger les données sensibles de l'entreprise. Mot-clé : audit de sécurité. (Cliquez ici pour consulter les textes officiels en italien et en anglais).

Une analyse détaillée des exigences de l'autorité chargée de la protection des données nous a permis d'identifier les quatre exigences suivantes :

  • Enregistrement et récolte d'événements (connexions, déconnexions, échecs d'authentification) dans un environnement hétérogène (Windows, Unix, Linux ; bases de données telles que Oracle, DB2, MySQL, Lotus Notes, SAP, pare-feu, etc.).
  • Archivage centralisé d'événements de tous les systèmes, bases de données et dispositifs du réseau.
  • Indexation des événements pour une recherche rapide et l'identification d'anomalies.
  • Recherche ciblée selon des critères précis (nom de l'hôte, utilisateur, heure, etc.) par les responsables de l'audit.

C'est donc un défi de taille qui nous attendait en 2010 : fournir à nos clients une solution qui répondait à ces 4 exigences au sein de NetEye, notre solution de gestion de système informatique.

Should we develop our own agent.png

Possibilités existantes - Que pouvait nous offrir le monde de l'open source ?

Étant donné que notre outil de surveillance NetEye était déjà basé sur plusieurs modules open source, il nous semblait évident de nous concentrer en premier lieu sur les possibilités que nous offrait l'open source. Quels outils étaient déjà disponibles pour récolter des logs ? Nos recherches ont démontré que Snare et Epilog constituaient des outils appropriés. Cependant l'association de ces deux outils présentait quelques limites :

  • Aucune garantie de communication fiable et sûre (problèmes au niveau des protocoles TLS-TCP, SYSLOG et RELP)  .
  • Impossible de mettre en place des filtres pour les outils (pour permettre d'accéder uniquement aux événements requis et ne pas surcharger le réseau et le système inutilement).
  • Aucun possibilité de configuration centralisée et simple des deux outils opérant sur des systèmes d'exploitation distincts.
  • La surveillance des outils eux-mêmes.
  • La détection automatique des rôles d'administrateur était impossible sous Windows.
  • L'installation des deux outils (Snare et Epilog) était inutilement laborieuse.

Après avoir identifié ces points faibles, nous avons décidé que nous ne voulions pas adopter une solution comportant de telles limites et avons conclu que nous devions développer notre propre outil : SAFED (Security Auditing ForwardEr Daemon) basé sur Snare et Epilog, afin de proposer une nouvelle solution de collecte des logs à la communauté [Github - Safed]. Nous avons donc décidé d'utiliser rsyslog pour créer des journaux sous Linuxs. Dans la première version de notre outil, Solr d'Apache se chargeait de l'indexation des logs, et nous avions développé notre propre interface de recherche via Solr. Nous étions donc bien équipés pour satisfaire aux exigences de 2010.

Entwicklung des neuen Safed Agent.png

Fig. 2 Agent SAFED

Valeur ajoutée - il fallait aller au-delà !

Notre solution se conformait certes aux directives des autorités, mais elle n'apportait aucun avantage particulier en termes de gestion informatique. Nous voulions impérativement continuer à la développer, afin qu'elle offre une plus-value à nos clients.

Nos clients nous ont fait part des exigences relatives à la gestion des logs et du Security Information and Event Management (SIEM). Soudain, il n'était plus « simplement » question de collecter et d'archiver les logs. Nous faisions face à de nouvelles demandes :

  • Agrégation des données : agrégation des données de diverses origines (réseau, sécurité, serveur, bases de données, applications)
  • Corrélation : reconnaissance des attributs communs en vue du regroupement des événements
  • Alertes : analyse automatique des événements connexes en vue de l'envoi de notifications
  • Tableaux de bord : représentation des données d'événement sous forme de tableaux de bord
  • Conformité : rapports dans les domaines de la sécurité, de la gouvernance et des audits
  • Sauvegarde : archivage longue durée des données historiques
  • Analyses forensiques : recherche de différents nœuds et périodes dans les logs, selon divers critères

La combinaison de SAFED, Rsyslog et Solr ne suffait plus. Nous sommes donc repartis à la recherche d'outils qui permettraient à NetEye de se conformer aux nouvelles exigences du marché. Nous sommes tombés sur la Suite Elastic en janvier 2014. Nos développeurs l'ont étudié scrupuleusement et ont trouvé la solution : transformer NetEye en une solution complète de gestion des logs grâce à la Suite Elastic.

Nous avons donc décidé d'intégrer la Suite Elastic à NetEye puisque cette solution présentait les avantages suivants :

  • Implémentation simple
  • Outil de parsage Logstash
  • Formation d'un cluster avec Elasticsearch
  • Évolutivité
  • Utilisation de Kibana comme tableau de bord interactif

[Pour être précis, nous avons utilisé Grok comme parseur en guise de solution intérimaire, procédé qui s'est avéré laborieux, mais dont l'utilisation a été simplifiée par son intégration à Logstash. Cela représente un autre facteur en faveur de l'intégration avec la Suite Elastic.]

Nous avons remplacé notre interface de recherche Web par Kibana. Solr a fait place à Elasticsearch. C'est à partir de ce moment là que nous avons commencé à utiliser Logstash comme parseur de logs. De plus, Elasticsearch nous permettait de faire une recherche par agrégation et indexation. 

Integrated Open Source Projects EN.png

Fig. 3 Intégration de la Suite Elastic

Un gestionnaire d'événements, c'est-à-dire un élément proactif qui déclenche une action précise lors de l'entrée d'un événement selon le résultat, était le seul élément essentiel des fonctions de SIEM qui nous faisait défaut. Nous avons donc développé NetEye Event Handler. Il recense les résultats de Syslog, les e-mails, les interruptions SNMP et les SMS et attribue les actions appropriées à l'aide d'un moteur de corrélation (vous trouverez des informations détaillées sur le NetEye Event Handler sur notre blog)

Résultat - Nous sommes fiers de ce que nous avons créé !

En 2014, au terme de nos développements et de l'intégration avec la Suite Elastic, nous avons lancé NetEye 3.5, doté d'un module de gestion complet des logs. Les événements sont collectés, indexés et agrégés. Il permet également une recherche individuelle et une réaction automatique à tous les événements. Nous sommes contents du résultat et heureux de pouvoir fournir une solution à nos clients permettant non seulement de se conformer aux directives en matière de protection des données mais en plus de bénéficier de tous les avantages d'un système de gestion complet des logs.

Drill Down EN.png

Fig. 4 Tableau de bord Kibana

Le futur - Nous n'allons pas en rester là !

Contrôle d'usage logiciel

Nous nous sommes rendu compte que nos solutions de base peuvent couvrir de nombreux autres domaines. Nos clients nous ont demandé de développer un contrôle d'usage des applications. Il s'agit concrètement d'un contrôle d'usage logiciel sur une ferme Citrix. Nous faisons appel à notre agent SAFED afin de collecter les événements (démarrage – fermeture de l'application par utilisateur). Les résultats sont ensuite consignés dans Elasticsearch et affichés dans le tableau de bord Kibana. Cet exemple souligne une fois de plus la flexibilité de la gestion des logs dans NetEye, basée sur la Suite Elastic.

Surveillance de la performance du réseau

Dans le domaine de la surveillance des performances du réseau, nous collectons des données Netflow à l'aide de notre solution nBox afin de mesurer l'utilisation du réseau. Là aussi, il est possible de transférer directement les données Netflow vers la Suite Elastic. Logstash peut recevoir des données NetFlow v5 et v9 (nous avons dû y apporter quelques améliorations pour v9, mais cela a été relativement facile à faire). Les tableaux de bord Netflow peuvent être affichés dans Kibana 4. Les tableaux Kibana sont très performants en ce qui concerne la navigation et l'agrégation. Ils offrent donc une multitude de possibilités.

Mais nous allons bientôt devoir faire face à un nouveau défi. Comment Elasticsearch fonctionne-t-il avec des millions de flux Netflow ? Nous avons déployé nos sondes réseau dans des réseaux 10G, qui représentent des millions de ces flux par seconde.

Données de performance au niveau I/O

Nous nous attellerons également à la collecte de données de performance dans un environnement VMWare ESX et sur les systèmes SAN au niveau I/O. Durant ce projet, nous trierons les données des MV par VMWare SDK, datastore et Lun et ainsi afficher les MV les plus actives. Ainsi, les administrateurs verront quelles MV génèrent énormément de capacité I/O sur le SAN. Ils conserveront une vue d'ensemble du réseau en cas de SAN multiples (de différents constructeurs) et trouveront une réponse à leur question dans un délai raisonnable.

Résumé

Nous ne faisons que commencer à exploiter les possibilités que représentent l'intégration la Suite Elastic dans NetEye. Nous nous réjouissons de découvrir quelles autres exigences du marché nous pourront satisfaire grâce à la Suite Elastic. La communauté voit elle aussi sans cesse apparaître de nouvelles opportunités et domaines d'utilisation pour une technologie aussi flexible.


Georg KostnerGeorg Kostner travaille depuis plus 17 ans au sein du Groupe Würth, dans les domaines de la gestion de système informatique et du développement de logiciels. Au début de sa carrière, il était responsable de la mise en place d'applications PRE et du développement d'infrastructures. Il s'implique toujours autant dans des projets de recherche innovants et techniques et conserve surtout un intérêt pour les logiciels en Open Source. En tant que directeur de la division System Integration, il est responsable des solutions WÜRTHPHOENIX NetEye et WÜRTHPHOENIX EriZone qui ont été développées en interne.