Integrierte WAAP-Signaturen bieten Basisschutz gegen SQL Injection, XSS, Path Traversal, SSRF, bekannte CVEs und gängige Angriffstechniken. In realen Produktionsumgebungen ist jedoch jede Anwendung anders. Einige APIs erfordern spezifische Header-Formate, einige Anwendungen verlassen sich auf Legacy-Parameter-Strukturen, und Traffic, der für einen Service völlig normal ist, kann dem integrierten Signaturset verdächtig vorkommen.
Daraus ergeben sich zwei Anforderungen. Erstens, anwendungsspezifische WAAP-Regeln hinzufügen, ohne das integrierte Regelset zu beschädigen. Zweitens, das Verhalten einer bestehenden integrierten Regel für einen bestimmten Service zu ändern: sie zu deaktivieren, in den monitor-Modus zu versetzen, ihren Score zu senken oder sie auf einen bestimmten Traffic-Abschnitt zu beschränken.
In traditionellen Ansätzen ist das Schreiben benutzerdefinierter Regeln oft schwere Arbeit. Der Operator muss eine proprietäre Skriptsprache erlernen, die Regel-Syntax wird komplex, ein schlecht geschriebener Regex kann den Produktionsverkehr unterbrechen, und das Deployen einer Regel kann ein Risiko der Service-Unterbrechung schaffen. Als Ergebnis schreiben Teams entweder Regeln, die zu breit sind, oder ignorieren vorübergehend riskanten Traffic.
ID-Verwaltung, Override-Handling und Ebenenisolierung fügen eine weitere Dimension hinzu. Wenn integrierte Regeln, organisationsweite benutzerdefinierte Regeln und anwendungsspezifische Regeln denselben Namespace teilen, wird die Wartung schwierig. Wenn sich dieselbe Regel in verschiedenen Anwendungen unterschiedlich verhalten muss, wird ein Duplikat-und-Bearbeiten-Ansatz schnell nicht nachhaltig.
Das TR7 Custom WAAP Rules Modell vereinfacht diese Komplexität: benutzerdefinierte Regeln werden mit Regex, Scope, Score und Zustand definiert; bestehende Regeln werden mit Overrides angepasst; globale und Pool-Ebenen werden durch nicht-konfliktäre ID-Bereiche verwaltet.
TR7 macht das Erstellen benutzerdefinierter WAAP-Regeln von einer separaten Coding-Aufgabe zu einem verifizierbaren, mehrschichtigen Richtlinienfluss, der nativ in der kern-WAAP-Engine ist.
Der Operator definiert eine benutzerdefinierte WAAP-Regel mit Name, Beschreibung, Regex, Match-Scope, Score und Zustandsfeldern. Der Wizard-Modus ist für den täglichen Einsatz ausreichend; Teams, die eine engere Kontrolle wünschen, können dieselbe Struktur als Raw-JSON verwalten.
Neue Regex-Muster können für organisations- oder anwendungsspezifische Bedürfnisse hinzugefügt werden. Für bestehende integrierte Regeln wird nur das spezifische Verhalten, das geändert werden muss — Zustand, Score oder Match-Scope — überschrieben; das integrierte Regelset wird nie geforkt.
Die globale Ebene bietet eine organisationsweite Basislinie für alle Services; die Pool-Ebene wendet engere Einstellungen für spezifische Anwendungen oder Services an. Da ID-Bereiche partitioniert sind, kollidieren integrierte Regeln, globale benutzerdefinierte Regeln und servicespezifische Regeln nie.
Bevor eine Regel live geht, werden Name-, Score-, Scope- und Regex-Felder validiert. Wenn die Regel gültig ist, wird der anvisierte Signatur-Shard neu kompiliert; unveränderte Teile der Engine werden nicht beeinflusst.
Custom WAAP Rules führen benutzerdefinierte Sicherheitslogik auf demselben Niveau wie das kern-WAAP-Scoring-System aus.
Jede benutzerdefinierte Regel wird mit Name, Beschreibung, Regex, Match-Scope, Score und Zustand definiert. Der Regex spezifiziert das Angriffsmuster oder das nicht erlaubte Format; der Scope bestimmt, ob dieses Muster in path, query, header, form, json, xml oder raw-Inhalt gesucht wird. Der Score-Wert bringt das Bedrohungsgewicht in das WAAP-Scoring-Modell. Das Zustandsfeld steuert, ob die Regel enabled, monitor oder disabled ist.
Eine benutzerdefinierte Regel wird nicht blind auf die gesamte Anfrage angewendet. Der genaue Traffic-Abschnitt, der durchsucht werden soll, wird explizit ausgewählt. Path-, query-, header-, form-, json-, xml- und raw-Scope-Optionen schränken ein, wo die Regel arbeitet. Dies reduziert das Falsch-Positiv-Risiko und stellt sicher, dass der Regex nur dort läuft, wo er sinnvoll ist. Dasselbe Muster kann in verschiedenen Scopes mit unterschiedlichen Effekten verwendet werden.
Benutzerdefinierten Regeln wird eine von vier Score-Stufen zugewiesen: 2, 4, 6 oder 8. Niedrigere Scores sind für Monitoring oder schwache Signale geeignet; höhere Scores weisen auf starke Angriffsindikatoren hin. Der Score tritt dem kern-WAAP-Entscheidungsmechanismus bei und wird zusammen mit anderen Signaturen ausgewertet. Die benutzerdefinierte Regel ist kein isolierter Blockierungsschalter — sie ist Teil einer zusammengesetzten Risikoberechnung.
Eine neue benutzerdefinierte Regel muss nicht direkt in den Blockierungsmodus gehen. Im monitor-Modus werden Regel-Übereinstimmungen protokolliert, aber der Traffic wird nicht unterbrochen. Das Betriebsteam beobachtet die Falsch-Positiv-Rate auf echtem Traffic, verfeinert den Regex und Scope, und versetzt die Regel dann zuversichtlich in enabled. Dieses Modell bietet kontrolliertes Rollout in der Produktion.
Wenn eine vorhandene integrierte Regel zu viel Rauschen in einer bestimmten Anwendung erzeugt, muss das Regelset nicht kopiert und modifiziert werden. Ein Override ändert den Zustand, Score oder Match-Scope-Verhalten. Dieselbe integrierte Regel kann global aktiv bleiben, während sie für einen bestimmten Pool in den monitor-Modus versetzt oder auf einen kleineren Scope eingeschränkt wird. Dies reduziert den Wartungsaufwand und verhindert Drift vom aktuellen Signaturset.
Globale benutzerdefinierte Regel-IDs werden im Bereich 1.000.000–4.999.999 generiert; Pool-benutzerdefinierte Regel-IDs in 5.000.000–9.999.999. Diese Trennung verhindert Konflikte zwischen integrierten Regeln, organisationsweiten Regeln und anwendungsspezifischen Regeln. Das Betriebsteam kann den Scope einer Regel allein aus ihrer ID identifizieren. Regelinventar-Management wird in großen Umgebungen geordneter.
Wenn eine benutzerdefinierte Regel geändert wird, wird nur der anvisierte Signatur-Shard neu kompiliert. Der Ansatz, das gesamte unveränderte Regelset anzuhalten und neu zu starten, wird nicht verwendet. Dies macht Regeloperationen schneller und risikoärmer. Das Verhalten ist besonders wertvoll für häufig wechselnde temporäre Schutzregeln.
Benutzerdefinierte Regel-Übereinstimmungen werden nicht in einem separaten, getrennten Log-Format gespeichert. Regel-ID, Name, Zustand, Score-Wert und übereinstimmender Scope sind im Haupt-WAAP-Event-Stream enthalten. Auf der SIEM-Seite können benutzerdefinierte und integrierte Regeln durch dasselbe Event-Modell untersucht werden. Diese Sichtbarkeit bietet Konsistenz für Incident-Response und Compliance-Berichterstellung.
Verwaltung benutzerdefinierter WAAP-Regeln wird zusammen mit Validierungs-, Konflikt-Kontroll-, Hot-Load-, Audit- und Rollback-Verfahren betrachtet.
Bevor eine Regel live geht, bestätigen Prüfungen, dass der Regex nicht leer ist, der Score einer der erlaubten Werte ist und die Scope-Liste gültig ist. Namens-Einzigartigkeit und ID-Bereich sind ebenfalls Teil des Validierungsprozesses. Eine ungültige Regel wird nicht in die WAAP-Engine zugelassen.
Die globale Ebene bietet eine organisationsweite Basislinie; die Pool-Ebene definiert spezifischeres Verhalten für einen bestimmten Service oder eine Anwendung. Wenn dieselbe Logik an verschiedenen Ebenen unterschiedliche Ergebnisse braucht, wird der Override-Mechanismus verwendet. Dieses Modell bietet verwaltbare, eingegrenzte Ausnahmen anstatt duplizierter Regeln.
Unvorsichtig geschriebene Regex-Muster können Leistungsrisiken schaffen. Zu breite, backtracking-intensive oder auf unnötig große Scopes angewendete Muster können Kosten in Produktionsverkehr erzeugen. Regex sollte daher mit so engem Scope und so präzisem Muster wie möglich definiert werden.
Der sichere Workflow für eine neue benutzerdefinierte Regel ist es, echten Traffic zunächst im monitor-Modus zu beobachten. Log-Ergebnisse werden überprüft und Pfade, Header oder Parameter, die Falsch-Positive erzeugen, werden bewertet. Sobald das Regelverhalten klar ist, wird die Regel in den enabled-Modus versetzt.
Hinzufügen, Aktualisieren, Deaktivieren und Überschreiben benutzerdefinierter Regeln sollte an Audit-Datensätze gebunden sein. Wer den Score, Scope oder Zustand welcher Regel wann geändert hat, ist kritische Information für die Post-Incident-Überprüfung. Änderungshistorie ist besonders für die operative Sicherheit bei Regeln wichtig, die einen Blockierungseffekt haben.
Wenn eine benutzerdefinierte Regel unerwartete Effekte erzeugt, kann sie schnell in den monitor- oder disabled-Zustand versetzt werden. Override-Änderungen können auch rückgängig gemacht werden, um das Verhalten integrierter Regeln wiederherzustellen. Dies macht Regeloperationen möglich, ohne den Produktionsverkehr zu unterbrechen.
Das Sicherheitsteam kann eine temporäre Regex-basierte Regel für eine neu offengelegte Schwachstelle hinzufügen, ohne auf ein offizielles Signatur-Update zu warten. Die Regel wird zunächst im monitor-Modus getestet und in enabled versetzt, sobald das Angriffsmuster bestätigt ist.
Wenn eine integrierte WAAP-Regel normalen Traffic in einer bestimmten Anwendung beeinträchtigt, wird sie überschrieben statt vollständig deaktiviert. Der Scope wird eingeengt, der Score gesenkt, oder die Regel wird nur für den relevanten Pool in den monitor-Modus versetzt.
Finanz- oder Gesundheitsanwendungen können benutzerdefinierte Regeln verwenden, um erwartete Formate in bestimmten Headern, Form-Feldern oder JSON-Feldern zu validieren. Nicht konforme Anfragen werden bewertet oder blockiert, bevor sie den Anwendungscode erreichen.
SaaS-Teams können Missbrauchsmuster, die spezifisch für ihr eigenes API-Verhalten sind, in path-, query-, header- oder JSON-Scope erfassen. Geschäftslogik-Verletzungen, die nicht vom integrierten Signaturset abgedeckt werden, werden als benutzerdefinierte Regeln innerhalb von TR7 WAAP verwaltet.
Benutzerdefinierte Sicherheitsregeln mit Regex, Scope, Score und Override. Lassen Sie uns einen Live-Setup in Ihrer eigenen Umgebung durchführen.