How do I fix the same false positive on several vServices at once (global layer)?

Short answer

There are two different ways. If the signature matches the same legitimate content in most of the applications on the device, the global layer is used: on the Signature & Rule Library screen, the signature is selected and with Change State it is first set to Monitor, and if the records show that the signature is unnecessary, to Disabled. The change is applied to all the WAF-protected vServices; a vService can still change the state of the signature for itself on its own OWASP Rules screen (rule layers). If the false positive is only on specific pages of a few vServices, Global WAF Event Log is used: the signature is selected on the Signature tab of the filter strip, the rows belonging to different vServices are checked together and the teaching button on the toolbar is clicked; the name of the button becomes Allow, Teach or Allow / Teach according to the selection. The teaching is grouped per vService and applied in order; a separate Are you sure? confirmation is asked for every vService, and every vService writes the exclusion to its own page type rule. There is no device-wide OWASP exclusion list; the exclusions always belong to the host group and the page type rule of a vService. Making a change in the global layer requires full permission in the WAF area.

Problem: The Same Signature Produces False Positives on Many vServices

The same signature matches the same legitimate content on different vServices (e.g. a common rich text editor that many applications use); making a separate fix on every vService takes time.

Solution: 2 Methods

Your situation	Suitable method
The signature matches the same content in most of the applications on the device	Method 1: Signature & Rule Library
The false positive is on specific pages of a few vServices	Method 2: Global WAF Event Log

Method 1: Signature & Rule Library Recommended

• How it works The state of the signature is changed in the global layer and applied to all the WAF-protected vServices. A change in the vService layer overrides the global layer only for that vService.
• Where it is opened The TR7 logo at the bottom left → Configuration Menu → WAF → Signature & Rule Library
• Requirement Full permission in the WAF area; an account that has only modify permission cannot change the state
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the library

The Configuration Menu is opened with the TR7 logo at the bottom left; WAF → Signature & Rule Library is selected (how to access).

2

Adım 2 Find the signature

The Attack ID in the Event Logs record or the name of the signature is written in the search box (What are the rule layers (built-in library, global layer, vService layer); which one takes precedence?).

3

Adım 3 Open the Change State window

The row of the signature is selected and Change State on the toolbar is clicked.

4

Adım 4 Select the new state

New State = Monitor is selected. The field comes with Enabled every time it is opened.

5

Adım 5 Save

Accept is clicked; a separate confirmation window is not displayed. The change is applied to all the vServices.

6

Adım 6 Observe and turn it off if needed

For a while, the records of the signature are monitored in Global WAF Event Log with the Signature tab of the filter strip. If the records come only from legitimate requests, steps 3–5 are repeated with New State = Disabled. If the signature causes a problem only in one request section, instead of turning it off, that section is removed from the scanning with Inspection Scopes in the Edit window.

Verification

1vService viewTR7 side

On the OWASP Rules screen of any vService, the row and the preview of the signature are checked.

ExpectedState: Monitor · a single column in the preview (global layer)

If the signature appears in a different state on a vService, there is a change in that vService's own layer; Restore to Default deletes that vService's change.

2Global WAF Event LogTR7 side

The decision of the new records in which the signature is triggered on its own is checked.

ExpectedNot blocked — Below the blocking threshold

If the host group is in the Monitor mode, the decision is written as Not blocked — Monitor mode in every case.

Method 2: Global WAF Event Log

• How it works The records belonging to different vServices are selected on a single screen and taught together; the teaching is grouped per vService, and every vService writes to its own rule set (Can I see the WAF logs of all vServices on one screen (Global WAF Event Log)?).
• Where it is opened The TR7 logo at the bottom left → Configuration Menu → WAF → Global WAF Event Log
• Requirement Modify permission in the WAF area and an unrestricted vService scope
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the screen

The Configuration Menu is opened with the TR7 logo at the bottom left; WAF → Global WAF Event Log is selected.

2

Adım 2 Determine the scanning scope

Date Range is selected in the server filter; if the affected vServices are known, these vServices are selected with Pick vServices in the vService field.

3

Adım 3 Pull the logs

Save & Get Logs is clicked.

4

Adım 4 Select the signature

The related signature is selected on the Signature tab of the filter strip. Since it is an attack-based selection, the rows remain only with the attacks of this signature, and only this signature is taught.

5

Adım 5 Select the rows

The records are examined (Description on the Attacks tab of the preview); the rows confirmed to be false positives are checked. The vService column shows the vService the row belongs to.

6

Adım 6 Teach

The teaching button on the toolbar is clicked; the name of the button changes according to the selection: Allow if only blocked records are selected, Teach if only monitored or Teacher records are selected, and Allow / Teach if the two are selected together. Yes is selected in the Are you sure? window that opens for every vService.

Verification

1Attacks columnTR7 side

The Attacks column of the taught rows is checked.

Expected0 / N · row pale green

Common Mistakes

• Setting it directly to Disabled in the global layer. Disabled removes the protection of the signature on all the vServices; it is first observed with Monitor (Is it better to disable a signature entirely or to add an OWASP exclusion?).
• Not reviewing the selection in the global teaching. Every selected row writes an exclusion to the rule set of its own vService; if a record that is a real attack on a vService was also selected, it is taught as well.
• Thinking that all the records were taught in a scan that the row limit cut. Only the pulled rows are taught; if Line Limit (default 5,000) is filled, the operation is repeated by narrowing the vService field or Date Range.
• Using the global layer for a small number of vServices. If the signature is problematic only on a few vServices, the state is changed on the OWASP Rules screen of each of them (Can I disable a signature on a single vService only, rather than device-wide?); a global change also affects the protection of the other vServices.
• Looking for WEB-CLI for the signature state. There is no WEB-CLI command that changes the state of the signature library.

How it is done in the documentation

• Signature & Rule Library · The Rule Layers
• Global WAF Event Log · Operations
• OWASP Rules · The Rule Layers and the Place of This Screen

Related questions

• What are the rule layers (built-in library, global layer, vService layer); which one takes precedence?
• Can I disable a signature on a single vService only, rather than device-wide?
• Can I see the WAF logs of all vServices on one screen (Global WAF Event Log)?