Module 110 - Analyser et représenter des données avec des outils

Traiter des données

partie 2

De quoi avons-nous parlé la semaine dernière ?

Temps à disposition : 5 minutes

Connectez-vous à : https://app.wooclap.com/EBFBDA

De quoi avons-nous parlé la semaine dernière ?

Des métriques
Des valeurs limites
Des alertes

Cas pratique

Correction Cas pratique 6 - Créer une alerte avec ELK Stack

Temps: 20 minutes

Objectifs du cours

Concevoir une surveillance SIEM
Etablir un rapport à l'aide d'indicateur

Les étapes de l'analyse de données

Nous allons voir dans les prochains slides le traitement des données et les alertes, donc l'étape 3 du processus de monitoring

Extension du périmètre de surveillance

Jusqu'à présent, nous nous sommes concentrés sur le monitoring applicatif. C'est indispensable, mais insuffisant. Dans un environnement de production réel, une panne ou une lenteur peut venir de trois autres sources invisibles pour l'application elle-même:

Le système d'exploitation
Le réseau
Les données métiers externes.

Surveillance Système et Sécurité (SIEM)

Une application fonctionne sur un OS (Windows/Linux).Si l'OS est compromis ou saturé, l'application le sera aussi.

De plus, les logs applicatifs ne voient pas les menaces de sécurité (ex: un pirate qui lance une commande PowerShell malveillante).

C'est ici qu'interviennent les agents de collecte système (comme « Winlogbeat » sous Windows ou « Auditbeat » sous Linux).

Surveillance Système et Sécurité (SIEM)

Pourquoi surveiller le système ?

Audit de sécurité : Détecter les tentatives de connexion échouées (Brute Force), la création de nouveaux utilisateurs suspects ou l'escalade de privilèges.
Intégrité : Savoir qui a modifié un fichier critique ou installé un logiciel non autorisé.
Sysmon (System Monitor) : Pour aller plus loin que les logs Windows standards, on utilise souvent Sysmon. Il enregistre des détails précis comme la ligne de commande exacte utilisée par un processus

Surveillance de la Performance Réseau (NPM)

Parfois, le serveur répond vite (l'application va bien), mais l'utilisateur trouve le site lent. Le coupable est souvent le réseau.

Le NPM (Network Performance Monitoring) consiste à analyser le trafic "sur le câble" pour mesurer la qualité des échanges. Le rôle de l'analyseur de paquets (Packetbeat) : Plutôt que d'installer un agent dans le code de l'application, on utilise une sonde passive (Sniffer) qui écoute le trafic réseau en temps réel.

Surveillance de la Performance Réseau (NPM)

Latence réseau vs Latence applicative : Permet de dire "C'est la base de données qui est lente à répondre" ou "C'est le transfert du fichier qui est lent".

Détection d'erreurs protocolaires : Repérer des erreurs DNS, des paquets perdus ou des certificats SSL expirés.

Cartographie des flux : Visualiser "qui parle à qui" pour détecter des connexions anormales (ex: le serveur Web qui tente de se connecter à un serveur suspect à l'étranger).

Intégration des Données

Dans une entreprise, tout n'est pas moderne. Il existe souvent des "vieux" logiciels (Legacy) qui ne savent pas envoyer de logs via une API ou un agent.

Ils génèrent souvent de simples fichiers plats (CSV, TXT, XML) déposés dans un dossier.

Intégration des Données

Pour surveiller ces systèmes, nous ne pouvons pas utiliser de simples agents. Nous devons utiliser un processus ETL (Extract, Transform, Load), souvent géré par l'outil « Logstash » dans la stack ELK.

Extract (Collecter) : Lire le fichier dès qu'il est modifié.
Transform (Transformer) : C'est l'étape critique. Il faut découper les lignes, nommer les colonnes et enrichir les données
Load (Charger) : Envoyer la donnée propre et structurée (JSON) dans Elasticsearch.