Un SIEM ?

Un SIEM est un système de collecte, d’analyse, de corrélation des logs avec des remontées d’alertes pour les évènements de sécurité.

Il en existe de nombreux sur le marché et qui vont peut-être plus loin que la définition que je viens d’en faire mais mon besoin - et certainement celui de la plupart des structures de tailles moyennes - est de pouvoir centraliser les logs, être alerté des évènements de sécurité et avoir un tableau de bord de ces alertes.

Dans le monde du logiciel libre, le stack ELK est souvent cité comme un bon candidat, mais de mon point de vue c’est très lourd et fastidieux à mettre en place.

Collecte des logs : Rsyslog (Windows, Linux)

Pour centraliser les logs, on peut faire dans le classique : Rsyslog s’installe sur les principaux OS du marché, et est simple à déployer et configurer.

Profitons-en.

Analyse et remontée d’alertes : OSSEC (Windows, Linux)

OSSEC est un HIDS (host-based intrusion detection system). Il analyse les logs et vérifie l’intégrité des fichiers des clients et présente ça côté serveur avec une remontée d’alertes.

Il est relativement simple à mettre en place et le niveau des alertes et facile à affiner.

Dans un premier temps installer un client OSSEC sur le collecteur de logs vous donne une vue d’ensemble de votre parc.

Dans un deuxième temps, il est plus intéressant d’installer OSSEC sur chaque machine pour profiter de la vérification d’intégrité des fichiers et être sûr que les logs sont bien analysés (même si le client pour une raison ou une autre n’envoie plus ses logs au collecteur).

Et maintenant qu’est-ce qu’on fait ?

Bon, si vous n’avez jamais eu de remontées d’alertes de logs auparavant, les premiers jours vont être bien remplis. Tout ce qui n’allait pas va refaire surface et vous allez devoir corriger pas mal de problèmes - de la même manière que quand on met en place un système de supervision.

D’ici quelques jours/semaines, vous aurez traité la plupart des évènements récurrents et il ne restera plus que des alertes “intéressantes”.