Collecte SIEM interrompue : détecter la panne et vérifier la reprise
Détectez les interruptions de collecte SIEM et vérifiez la reprise : retard, files d’attente, événements manquants et détections à rejouer.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un tableau de bord sans alerte peut correspondre à une période calme. Il peut aussi révéler une collecte interrompue. Le risque ne disparaît pas lorsque le collecteur redémarre : des événements peuvent encore attendre leur transmission ou avoir été perdus.
Superviser la reprise demande donc davantage qu’un voyant revenu au vert.
Le repère confirmé
Le NIST SP 800-92 aborde la gestion des journaux comme un ensemble de processus et d’infrastructures. Ce cadre aide à examiner une panne sur toute la chaîne de traitement. Source : NIST SP 800-92.
La méthode proposée par Seculogik
Pour les sources déjà exploitées, conservez un profil d’activité attendu. Il peut inclure les périodes normales de silence, les volumes usuels et la fréquence d’un signal de contrôle bénin.
Une baisse d’activité n’a pas le même sens sur un poste éteint le week-end et sur un service utilisé en permanence.
Lorsqu’une interruption est détectée, commencez par délimiter son périmètre. Une source manque-t-elle, ou plusieurs ? Toutes les catégories d’événements sont-elles absentes ? Les données continuent-elles d’arriver sans devenir interrogeables ?
Cette localisation évite de redémarrer au hasard des composants qui fonctionnent.
Ouvrez un incident de visibilité distinct d’une alerte de menace. Notez la dernière observation fiable, les services affectés, les responsables techniques et les détections potentiellement dégradées. Le SOC doit savoir où ses conclusions deviennent moins certaines pendant la panne.
Vérifier la reprise réelle
Après correction, produisez un événement de contrôle autorisé. Retrouvez-le à chaque étape utile, puis cherchez les événements plus anciens qui auraient dû arriver pendant l’interruption. Distinguez trois états : flux actuel rétabli, retard encore en résorption et intervalle définitivement incomplet.
Examinez les files d’attente et les mécanismes de conservation disponibles dans votre architecture. Ne présumez pas que toute donnée locale a été sauvegardée ou que tout événement retransmis déclenchera automatiquement les mêmes règles qu’en temps normal.
Dans Wazuh ou un autre SIEM, vérifiez le comportement de votre version avec les événements tardifs. Si des recherches doivent être rejouées sur la période affectée, attribuez cette tâche explicitement et conservez leurs résultats.
Fermer avec une preuve
La clôture doit préciser ce qui a été récupéré et ce qui reste inconnu. Ajoutez la cause, la correction et un contrôle capable de repérer sa réapparition.
Commencez par une panne simulée sur un environnement de test. L’objectif est une procédure de récupération vérifiable, qui empêche de confondre service redémarré, collecte restaurée et visibilité historique retrouvée.
Sources
- NIST SP 800-92, septembre 2006 : https://csrc.nist.gov/pubs/sp/800/92/final