Tirer une vraie valeur du SIEM, du SOAR et de l’IA de sécurité

1Introduction

Le scénario est connu. On achète un SIEM, on y connecte toutes les sources de journaux disponibles, les coûts d’ingestion augmentent chaque mois et les analystes apprennent à ignorer une file d’alertes faite surtout de bruit. Puis quelqu’un propose d’ajouter de l’IA pour donner du sens à tout cela. L’automatisation et l’IA peuvent démultiplier le travail d’une équipe de sécurité, mais seulement sur de bonnes données et de bonnes détections. L’ordre de construction compte plus que les produits choisis.

2Commencez par les données, pas par la licence

Priorisez les sources de journaux selon leur valeur de détection, pas selon leur disponibilité. Pour la plupart des organisations, le premier niveau comprend le fournisseur d’identité, la détection et réponse sur les postes, les journaux du plan de contrôle cloud, la sécurité des e-mails, ainsi que la télémétrie DNS et pare-feu des systèmes exposés à Internet. Viennent ensuite les applications critiques. Les sources verbeuses à faible valeur de sécurité peuvent être filtrées, échantillonnées ou placées dans un stockage moins cher.

• Normalisez selon un schéma commun, comme OCSF ou Elastic Common Schema, pour qu’une même détection fonctionne chez tous les éditeurs.
• Stockez les horodatages en UTC et gardez les horloges synchronisées. La corrélation entre les sources en dépend.
• Surveillez l’état des sources de journaux. Une source qui cesse d’envoyer sans bruit est un angle mort qu’un attaquant exploitera volontiers.

3L’ingénierie de détection sous forme de code

Les détections méritent la même rigueur que le code applicatif. Gardez-les dans Git, relisez les changements, testez-les et déployez-les via un pipeline. Sigma, un format de règles indépendant des éditeurs, permet d’écrire une détection une fois et de la convertir dans le langage de requête de votre SIEM. Reliez chaque règle aux techniques MITRE ATT&CK pour rendre visibles les lacunes de couverture, et validez les règles par des simulations d’attaque sûres comme Atomic Red Team.

title: Shell Spawned by Web Server Process
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    ParentImage|endswith:
      - '/nginx'
      - '/httpd'
      - '/java'
    Image|endswith:
      - '/sh'
      - '/bash'
  condition: selection
level: high
tags:
  - attack.persistence
  - attack.t1505.003

Suivez le taux de vrais positifs de chaque règle. Une règle qui se déclenche chaque jour et qui est toujours classée sans suite apprend aux analystes à l’ignorer. Réglez-la, ajoutez du contexte ou retirez-la.

4La qualité des alertes avant leur volume

L’alerte fondée sur le risque change l’unité de travail : on passe des événements isolés aux entités. Les signaux de faible confiance ajoutent du risque à un utilisateur ou à un hôte au lieu d’ouvrir chacun un ticket, et une alerte ne se déclenche que lorsque le risque cumulé dépasse un seuil. Enrichissez automatiquement chaque alerte avec la criticité de l’actif, le rôle de l’utilisateur, l’historique récent d’authentification et le renseignement sur les menaces, pour que l’analyste parte du contexte et non d’une ligne de journal brute.

5SOAR : automatiser le répétitif, encadrer le dangereux

Les plateformes d’orchestration, d’automatisation et de réponse exécutent des playbooks entre vos outils. Commencez par le travail le plus volumineux et le moins risqué, où l’automatisation est rentable le plus vite.

• Enrichissement : vérifications de réputation, contexte de l’utilisateur et de l’actif, et alertes liées ajoutés avant qu’un humain n’ouvre le dossier.
• Tri du phishing : extraire les indicateurs de l’e-mail signalé, les vérifier, trouver le même message dans d’autres boîtes et le mettre en file pour suppression.
• Confinement avec approbation : l’isolation d’un hôte ou la désactivation d’un compte est préparée automatiquement et exécutée après un clic de l’analyste.
• Clôture : les faux positifs connus sont fermés avec un motif documenté, pour que les tendances restent mesurables.

Gardez un humain dans la boucle pour toute action destructrice ou visible par les clients. Un playbook qui désactive le compte du PDG à 2 h du matin à cause d’une règle mal configurée fera reculer le programme d’un an.

6Là où l’IA de sécurité aide vraiment

• Résumer une alerte ou un incident à partir de dizaines d’événements bruts en un récit lisible.
• Traduire la question d’un analyste en langage courant en une requête correcte, ce qui raccourcit la chasse pour les profils juniors.
• Regrouper les alertes similaires pour qu’une décision en règle plusieurs.
• Proposer les prochaines étapes d’enquête et rédiger des règles de détection à faire relire par un ingénieur.

Tout cela dépend des couches précédentes. Un modèle qui raisonne sur des noms de champs incohérents, des sources manquantes et des règles bruyantes produira des absurdités très assurées. Traitez les résultats de l’IA comme des pistes à vérifier, journalisez chaque action d’un composant d’IA, et ne le laissez pas exécuter de confinement sans les mêmes étapes d’approbation que vos playbooks.

7Gardez des coûts raisonnables

Les SIEM facturés à l’ingestion pénalisent la journalisation sans discernement. Faites passer les données par un pipeline de sécurité qui les filtre et les réduit avant le SIEM, gardez 30 à 90 jours en stockage à chaud pour les enquêtes et archivez le reste dans un data lake moins cher, consultable en cas d’incident. Mesurez le coût par cas d’usage de détection. Vous verrez vite quelles sources sont rentables et lesquelles ne font que gonfler la facture.

8Conclusion

Le SIEM, le SOAR et l’IA ne fonctionnent bien que s’ils sont construits dans le bon ordre : de bonnes données, puis de bonnes détections, puis l’automatisation, puis l’IA. Jugez chaque étape selon les attaques qu’elle aide à détecter, le temps d’analyste qu’elle économise et son coût par détection, et cessez de payer pour les données qui n’apportent rien de cela.