Positionner correctement les flux de menaces, IPS, EDR et SIEM

Un flux de menaces ne remplace pas les politiques IPS, EDR, de sécurité DNS, WAF, SIEM ou de pare-feu propre. Il accomplit une tâche différente : préparer l’infrastructure active connue afin que les fonctions de contrôle existantes puissent l’utiliser rapidement au niveau du périmètre.

L’intérêt n’est pas de détecter toutes les techniques d’attaque. L’intérêt réside dans la suppression plus précoce de l’infrastructure d’attaquants récurrente et déjà observée du flux de trafic normal.

Quel rôle joue un flux de menaces

Un flux de menaces de pare-feu est une couche de réputation et de pré-filtrage. Il fournit des adresses IP, des domaines ou des URL qui ont été évalués à partir de plusieurs signaux comme étant pertinents pour les politiques de production. Le pare-feu peut ensuite récupérer ces indicateurs grâce à des fonctions de liste natives et les utiliser dans des règles.

Les cas d’utilisation typiques incluent :

• réduire plus tôt les scanners connus et l’infrastructure des botnets
• bloquer ou enregistrer l’infrastructure de commande et de contrôle, de phishing ou de malware
• réduire les bruits périmétriques récurrents avant les contrôles en aval
• fournir aux politiques de pare-feu existantes des informations plus récentes sur les menaces

Cela ne transforme pas le pare-feu en un système de détection complet. Cela donne au pare-feu de meilleures données de décision mises à jour en permanence.

Ce que font encore IPS, EDR et SIEM

IPS, EDR et SIEM fonctionnent sur d’autres couches. Ils détectent les modèles d’exploitation, le comportement des processus, l’activité des points finaux, la corrélation des journaux, les anomalies ou les techniques d’attaque concrètes. Ces contrôles restent importants, en particulier pour les attaques nouvelles, ciblées ou non encore observées.

Cybora complète ces couches :

• IPS et WAF voient moins de hits répétés connus lorsqu’une partie du trafic est réduite plus tôt.
• EDR reste responsable du comportement, de l’exécution et des mouvements latéraux des points finaux.
• Le SIEM et la journalisation conservent leur rôle de corrélation, de traçabilité et de réponse aux incidents.
• Le DNS et la sécurité Web restent pertinents pour le contexte de l’utilisateur, du navigateur et de l’application.

Un flux de menaces n’est donc pas un concurrent de ces systèmes. Cela réduit l’infrastructure connue où le pare-feu peut déjà prendre des décisions.

À quoi ressemble une bonne mise en œuvre

Une bonne mise en œuvre est contrôlée et vérifiable. Les administrateurs ne doivent pas activer aveuglément une liste et espérer que tout convienne. Un déploiement étape par étape est utile :

1. Récupérez l’URL du flux et vérifiez l’état HTTP.
2. Vérifiez l’importation et la population de la liste sur le pare-feu.
3. Référencez d’abord le flux dans une politique clairement définie.
4. Observez la journalisation et les correspondances pendant une période significative.
5. Si des problèmes surviennent, faites la distinction entre le format, l’interrogation, la licence, la politique et les faux positifs.

Les détails de ce processus sont documentés dans Validation et dépannage.

Ce qui n’est délibérément pas promis

Aucun flux ne bloque chaque attaque. Les nouvelles infrastructures, les campagnes très ciblées ou les attaques sans activité auparavant observable ne peuvent être évaluées qu’une fois les signaux existants. Les infrastructures légitimes doivent également être traitées avec prudence, car l’hébergement partagé, les plateformes cloud, les CDN et les services SaaS peuvent causer des dommages collatéraux.

Cybora n’optimise donc pas pour la taille maximale de la liste, mais pour une conservation prête pour le pare-feu. Pour en savoir plus sur l’évaluation des risques opérationnels, consultez Policy Confidence.