Integrierte WAAP-Regeln sind wesentlich — aber keine zwei Anwendungen verhalten sich gleich.
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.
Unser Ansatz
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.
Benutzerdefinierte Signaturen werden per Wizard oder Raw-Regelmodell definiert
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 Regel- und Override-Flows werden getrennt gehalten
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.
Globale und Pool-Ebenen koexistieren ohne Konflikte
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.
Validierungs- und Hot-Load-Modell reduziert das Produktionsrisiko
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.
Fähigkeiten
Custom WAAP Rules führen benutzerdefinierte Sicherheitslogik auf demselben Niveau wie das kern-WAAP-Scoring-System aus.
Benutzerdefinierte WAAP-Regeln werden mit Regex, Scope, Score und Zustand erstellt
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.
Sieben Inspect-Scopes stellen sicher, dass die Regel im richtigen Traffic-Abschnitt läuft
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.
Vier Score-Stufen bringen Bedrohungsgewicht in das WAAP-Modell
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.
Monitor-Modus testet eine Regel in Produktionsverkehr ohne Blockierung
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.
Integrierte WAAP-Regeln können ohne Kopieren überschrieben werden
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 und Pool-benutzerdefinierte Regeln werden in separaten ID-Bereichen gehalten
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.
Nur der betroffene Signatur-Shard wird neu kompiliert — nicht die gesamte Engine
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 Regeln erscheinen in Logs und SIEM genau wie integrierte Regeln
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.
Operative Tiefe
Verwaltung benutzerdefinierter WAAP-Regeln wird zusammen mit Validierungs-, Konflikt-Kontroll-, Hot-Load-, Audit- und Rollback-Verfahren betrachtet.
Regelvalidierung
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.
Ebenenpräzedenz
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.
Regex-Sicherheit
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.
Übergang von monitor zu enabled
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.
Audit- und Änderungspfad
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.
Rollback-Management
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.
Anwendungsszenarien
Eine temporäre Zero-Day-Schutzregel hinzufügen
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.
Eine integrierte Regel, die Falsch-Positive erzeugt, eingrenzen
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.
Compliance-Format-Prüfungen am Edge durchsetzen
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.
Anwendungsspezifischen API-Missbrauch blockieren
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.
Häufig gestellte Fragen
Arbeitet eine benutzerdefinierte WAAP-Regel unabhängig von der integrierten Signatur-Engine?
Welche Eigenschaften einer bestehenden Regel können durch ein Override geändert werden?
Was ist der Zweck des monitor-Modus?
Wie verwalten die globale und die Pool-Ebene dieselbe benutzerdefinierte Regel?
Was sind die sieben Scope-Optionen und warum sind sie wichtig?
Startet eine Regeländerung die gesamte WAAP-Engine neu?
Die WAAP-Logik Ihrer Organisation an die kern-Signatur-Engine binden
Benutzerdefinierte Sicherheitsregeln mit Regex, Scope, Score und Override. Lassen Sie uns einen Live-Setup in Ihrer eigenen Umgebung durchführen.