Les signatures WAAP intégrées fournissent une protection de base contre SQL injection, XSS, path traversal, SSRF, les CVE connus et les techniques d'attaque courantes. Dans les environnements de production réels cependant, chaque application est différente. Certaines API nécessitent des formats de headers spécifiques, certaines applications s'appuient sur des structures de paramètres legacy, et du trafic parfaitement normal pour un service peut sembler suspect à l'ensemble de signatures intégré.
Deux exigences en découlent. Premièrement, ajouter des règles WAAP spécifiques à l'application sans casser l'ensemble de règles intégré. Deuxièmement, modifier le comportement d'une règle intégrée existante pour un service spécifique : la désactiver, la mettre en mode monitor, abaisser son score ou la restreindre à une section de trafic particulière.
Dans les approches traditionnelles, la rédaction de règles personnalisées est souvent un travail lourd. L'opérateur doit apprendre un langage de scripting propriétaire, la syntaxe des règles devient complexe, un regex mal rédigé peut couper le trafic de production, et le déploiement d'une règle peut créer un risque d'interruption de service. Par conséquent, les équipes rédigent soit des règles trop larges soit ignorent temporairement le trafic risqué.
La gestion des identifiants, le traitement des remplacements et l'isolation des couches ajoutent une autre dimension. Lorsque les règles intégrées, les règles personnalisées à l'échelle de l'organisation et les règles spécifiques à l'application partagent le même espace de noms, la maintenance devient difficile. Si la même règle doit se comporter différemment selon les applications, une approche copier-et-modifier devient rapidement non viable.
Le modèle TR7 Règles WAAP personnalisées simplifie cette complexité : les règles personnalisées sont définies avec regex, portée, score et état ; les règles existantes sont ajustées avec des remplacements ; les couches global et pool sont gérées via des plages d'identifiants non conflictuelles.
TR7 transforme la rédaction de règles WAAP personnalisées d'une tâche de codage séparée en un flux de politique vérifiable et en couches, natif au moteur WAAP central.
L'opérateur définit une règle WAAP personnalisée avec les champs nom, description, regex, portée de correspondance, score et état. Le mode assistant est suffisant pour un usage quotidien ; les équipes souhaitant un contrôle plus fin peuvent gérer la même structure en JSON brut.
De nouveaux patterns regex peuvent être ajoutés pour des besoins spécifiques à l'organisation ou à l'application. Pour les règles intégrées existantes, seul le comportement spécifique à modifier — état, score ou portée de correspondance — est remplacé ; l'ensemble de règles intégré n'est jamais dupliqué.
La couche globale fournit une base à l'échelle de l'organisation pour tous les services ; la couche pool applique des paramètres plus restreints pour des applications ou services spécifiques. Parce que les plages d'identifiants sont partitionnées, les règles intégrées, les règles personnalisées globales et les règles spécifiques au service n'entrent jamais en collision.
Avant qu'une règle entre en vigueur, les champs nom, score, portée et regex sont validés. Si la règle est valide, le shard de signature ciblé est recompilé ; les parties inchangées du moteur ne sont pas affectées.
Les Règles WAAP personnalisées exécutent une logique de sécurité personnalisée au même niveau que le système de scoring WAAP central.
Chaque règle personnalisée est définie avec nom, description, regex, portée de correspondance, score et état. Le regex spécifie le pattern d'attaque ou le format non autorisé ; la portée détermine si ce pattern est recherché dans path, query, header, form, json, xml ou contenu raw. La valeur de score porte le poids de la menace dans le modèle de scoring WAAP. Le champ état contrôle si la règle est enabled, monitor ou disabled.
Une règle personnalisée n'est pas appliquée aveuglément à l'intégralité de la requête. La section de trafic exacte à rechercher est sélectionnée explicitement. Les options de portée path, query, header, form, json, xml et raw limitent l'endroit où la règle opère. Cela réduit le risque de faux positifs et garantit que le regex ne s'exécute que là où c'est pertinent. Le même pattern peut être utilisé sur différentes portées avec des effets différents.
Les règles personnalisées se voient assigner l'un des quatre niveaux de score : 2, 4, 6 ou 8. Les scores plus bas sont appropriés pour la surveillance ou les signaux faibles ; les scores plus élevés indiquent de forts indicateurs d'attaque. Le score rejoint le mécanisme de décision WAAP central et est évalué aux côtés des autres signatures. La règle personnalisée n'est pas un interrupteur de blocage isolé — elle fait partie d'un calcul de risque composite.
Une nouvelle règle personnalisée n'a pas besoin d'aller directement en mode blocage. En mode monitor, les correspondances de règles sont journalisées mais le trafic n'est pas interrompu. L'équipe opérationnelle observe le taux de faux positifs sur le trafic réel, affine le regex et la portée, et déplace ensuite la règle en mode enabled avec confiance. Ce modèle fournit un déploiement contrôlé en production.
Si une règle intégrée existante génère trop de bruit dans une application spécifique, il n'est pas nécessaire de copier et modifier l'ensemble de règles. Un remplacement modifie l'état, le score ou le comportement de portée de correspondance. La même règle intégrée peut rester active globalement tout en étant placée en mode monitor ou restreinte à une portée plus petite pour un pool spécifique. Cela réduit la charge de maintenance et évite la dérive par rapport à l'ensemble de signatures actuel.
Les identifiants de règles personnalisées globales sont générés dans la plage 1 000 000–4 999 999 ; les identifiants de règles personnalisées pool dans 5 000 000–9 999 999. Cette séparation évite les conflits entre les règles intégrées, les règles à l'échelle de l'organisation et les règles spécifiques à l'application. L'équipe opérationnelle peut identifier la portée d'une règle rien qu'avec son identifiant. La gestion de l'inventaire des règles devient plus ordonnée dans les grands environnements.
Lorsqu'une règle personnalisée est modifiée, seul le shard de signature ciblé est recompilé. L'approche consistant à arrêter et redémarrer l'ensemble des règles inchangées n'est pas utilisée. Cela rend les opérations sur les règles plus rapides et moins risquées. Le comportement est particulièrement précieux pour les règles de protection temporaire changeant fréquemment.
Les correspondances de règles personnalisées ne sont pas stockées dans un format de log séparé et déconnecté. L'identifiant de règle, le nom, l'état, la valeur de score et la portée correspondante sont inclus dans le flux principal d'événements WAAP. Côté SIEM, les règles personnalisées et intégrées peuvent être examinées via le même modèle d'événement. Cette visibilité fournit une cohérence pour la réponse aux incidents et le reporting de conformité.
La gestion des règles WAAP personnalisées est considérée conjointement avec la validation, le contrôle des conflits, le hot-load, l'audit et les procédures de rollback.
Avant qu'une règle entre en vigueur, des contrôles confirment que le regex n'est pas vide, que le score est l'une des valeurs autorisées et que la liste de portées est valide. L'unicité du nom et la plage d'identifiants font également partie du processus de validation. Une règle invalide n'est pas admise dans le moteur WAAP.
La couche globale fournit une base à l'échelle de l'organisation ; la couche pool définit un comportement plus spécifique pour un service ou une application particulière. Lorsque la même logique a besoin de résultats différents à différentes couches, le mécanisme de remplacement est utilisé. Ce modèle fournit des exceptions gérables et délimitées au lieu de règles dupliquées.
Des patterns regex rédigés sans précaution peuvent créer des risques de performance. Des patterns trop larges, fortement rétrogradés ou appliqués à des portées inutilement grandes peuvent générer des coûts dans le trafic de production. Le regex doit donc être défini avec la portée la plus étroite et le pattern le plus précis possible.
Le workflow sécurisé pour une nouvelle règle personnalisée est d'observer le trafic réel en mode monitor d'abord. Les résultats des logs sont examinés et les chemins, headers ou paramètres produisant des faux positifs sont évalués. Une fois le comportement de la règle clarifié, la règle est déplacée en mode enabled.
L'ajout, la mise à jour, la désactivation et le remplacement de règles personnalisées doivent être liés aux enregistrements d'audit. Qui a modifié le score, la portée ou l'état de quelle règle, et quand, est une information critique pour l'examen post-incident. L'historique des modifications est particulièrement important pour la sécurité opérationnelle sur les règles ayant un effet de blocage.
Si une règle personnalisée produit des effets inattendus, elle peut rapidement être déplacée en état monitor ou disabled. Les modifications de remplacement peuvent également être annulées pour restaurer le comportement de la règle intégrée. Cela rend les opérations sur les règles possibles sans interrompre le trafic de production.
L'équipe sécurité peut ajouter une règle temporaire basée sur regex pour une vulnérabilité nouvellement divulguée sans attendre une mise à jour officielle des signatures. La règle est d'abord testée en mode monitor et déplacée en mode enabled une fois le pattern d'attaque confirmé.
Si une règle WAAP intégrée affecte le trafic normal dans une application spécifique, elle est remplacée plutôt que complètement désactivée. La portée est restreinte, le score est abaissé, ou la règle est placée en mode monitor uniquement pour le pool concerné.
Les applications financières ou de santé peuvent utiliser des règles personnalisées pour valider les formats attendus dans des headers, champs de formulaire ou champs JSON spécifiques. Les requêtes non conformes sont scorées ou bloquées avant d'atteindre le code applicatif.
Les équipes SaaS peuvent capturer les patterns d'abus spécifiques à leur propre comportement API dans la portée path, query, header ou JSON. Les violations de logique métier non couvertes par l'ensemble de signatures intégré sont gérées comme règles personnalisées à l'intérieur de TR7 WAAP.
Règles de sécurité personnalisées avec regex, portée, score et remplacement. Laissez-nous vous présenter une configuration en direct dans votre propre environnement.