Transformer les indicateurs de menace de Cloudflare en règles WAF en temps réel

Dès qu’un indicateur de menace entre dans le système, les règles commencent à bloquer le trafic. Cette action semble très soignée. Le rythme est rapide, les retours sont rapides et les reportages sont magnifiques. Mais une fois ce truc mis en production, la vraie difficulté n’est plus de transformer l’indicateur en règle, mais de faire en sorte que cette règle résiste au trafic, aux faux positifs et aux rollbacks.

Lorsque j’ai lu Transformer les indicateurs de menace de Cloudflare en règles WAF en temps réel, ce qui m’est venu à l’esprit, ce ne sont pas les mots fantaisistes « automatisation de l’accès au renseignement », mais plusieurs images très pratiques : une adresse IP était marquée en rouge et a été interceptée dix minutes plus tard ; une ASN était considérée comme à haut risque et, par conséquent, une sortie entièrement partagée était impliquée ; un échantillon d’attaque de courte durée venait d’entrer dans la base de règles et le trafic d’attaque avait été supprimé, laissant une ancienne règle qui continue d’être en vigueur. Ici, le temps réel n’est pas seulement une question de vitesse : il compresse le cycle de vie des règles, la crédibilité des données et les responsabilités de disposition dans la même fenêtre.

Les règles peuvent être rapides, à condition qu’elles puissent être retirées

Lorsqu’un indicateur de menace entre dans un WAF, le premier à perdre patience n’est généralement pas l’attaquant, mais la personne en service. Parce qu’une fois qu’une règle entre en vigueur, ce qui suit n’est pas une « amélioration de la sécurité » abstraite, mais des blessures accidentelles spécifiques, des appels, des reculs et des audits. Les indicateurs au niveau IP sont les plus faciles à déléguer. Ils ont des frappes en un seul point, des temps de survie courts et de faibles coûts de récupération. Les indicateurs tels que l’ASN, le segment de réseau, l’empreinte digitale TLS et la combinaison de requêtes sont beaucoup plus prudents. Ils couvrent une plus grande surface et ont des effets secondaires plus difficiles lorsqu’ils sont frappés.

Ce qui est vraiment intéressant, c’est que les règles ne sont pas écrites une seule fois puis appliquées, mais apparaissent avec le TTL, la source, la plage d’accès et les conditions d’annulation. Sans ces champs, les règles en temps réel dégénéreront rapidement en un tas d’enregistrements d’interdiction expirés. Si vous bloquez une attaque aujourd’hui, vous commencerez à bloquer les utilisateurs normaux demain. La mauvaise odeur la plus courante dans la production est que la base de règles devient de plus en plus épaisse et que ce qui est retenu n’est pas un jugement efficace, mais des émotions historiques.

Un tampon doit être laissé entre la couche d’indicateur et la couche d’action.

La traduction des indicateurs de menace directement en règles de blocage est bien sûr la plus rapide, mais cette étape est également la plus simple pour amplifier les erreurs de renseignement en accidents en ligne. Une approche plus stable consiste généralement à laisser une couche de tampon entre l’indicateur et l’action, permettant au même signal de passer d’abord par l’observation, le défi et la limite de vitesse, puis de décider s’il doit réellement être bloqué. Une fois cette couche tampon manquante, plus les indicateurs sont mis à jour rapidement, plus vite les règles seront accidentellement endommagées.

Lorsqu’elle est effectivement mise en œuvre, il est préférable que la règle ne soit pas un simple interrupteur marche/arrêt, mais un ensemble d’états qui peuvent exprimer l’intensité de l’action : enregistrer d’abord, puis contester, puis limiter le courant et enfin passer à l’interception. L’avantage est simple : les règles peuvent être renforcées progressivement à mesure que les preuves deviennent plus solides, et peuvent être rapidement dégradées lorsque les preuves s’affaiblissent. Pour l’équipe de sécurité, cela peut mieux maintenir la crédibilité que de remplir toutes les règles en même temps ; du côté des entreprises, ils peuvent au moins constater des fluctuations anormales dès leur apparition, au lieu d’attendre que les tickets du service client s’accumulent pour savoir ce qui s’est passé.

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Cette structure semble simple, mais elle est en réalité très importante. Lorsque confidence est faible, la contestation en premier s’apparente davantage à un jugement technique qu’à une interception directe ; ttl expire automatiquement après expiration pour éviter que d’anciennes informations ne soient accrochées sur le côté ; scope est réduit à un chemin ou un segment de circulation afin que la zone de dommages accidentels ne soit pas infiniment agrandie.

Sans révision, les règles ne feront que s’allonger et ressembleront à un tas d’ordures.

La plus grande crainte du WAF en temps réel n’est pas le faible taux de réussite, mais le fait que personne ne sache ce qui s’est passé après la frappe. Une fois les règles publiées, vous devez être en mesure de vérifier trois choses : combien d’attaques réelles ont été bloquées, combien de requêtes normales ont été accidentellement tuées et s’il y a eu de nouvelles méthodes de contournement après les hits. Ce n’est qu’en reliant ces trois éléments que la règle peut être considérée comme applicable et maintenable ; sans aucun d’entre eux, cela finira par devenir une action inertielle consistant à “le bloquer d’abord de toute façon”.

C’est également la partie la plus sous-estimée de l’automatisation des indicateurs de menace. Il peut exister de nombreuses sources d’indicateurs et les mises à jour des renseignements peuvent être fréquentes, mais sans une boucle de rétroaction stable, les règles iront toujours de l’avant. Un système véritablement mature enregistrera le taux de réussite, le nombre d’annulations, le nombre de versions manuelles, les alarmes associées et les pertes commerciales de chaque règle. À ce stade, les règles ne sont plus simplement des configurations de sécurité, mais des enregistrements d’élimination avec une chaîne de preuves.

Cet ensemble d’outils ne convient qu’aux équipes disposant déjà de capacités d’élimination

Transformer les indicateurs de menace en règles WAF en temps réel ne convient pas à tous les scénarios. Pour les systèmes avec un faible trafic, une surface d’attaque étroite et une mise en service manuelle suffisamment rapide, il est souvent plus difficile de continuer à s’appuyer sur des règles statiques et des mises à jour manuelles. Ceux qui ont réellement besoin de cette fonctionnalité sont généralement des équipes avec un trafic important, une densité d’attaque élevée, des changements de règles fréquents et qui disposent déjà de journaux, de processus de révision et de tâches.

Une fois ce type de système mis en œuvre, la valeur ne se limite pas à « s’arrêter plus vite ». Ce qui est plus important est de transformer l’élimination de sécurité d’un jugement manuel ponctuel en une chaîne d’exécution révocable, révisable et gradable. L’avantage d’une plate-forme comme Cloudflare pour ce faire n’est pas seulement qu’elle peut recevoir davantage de signaux de menace, mais qu’elle a la capacité de transmettre les signaux à la couche de règles, puis de reconnecter la couche de règles à la surveillance, à la restauration et à l’audit. Sans cette chaîne, le temps réel ne fera que rendre les erreurs plus rapides ; avec cette chaîne, les règles peuvent véritablement entrer en production.