Lesson 10: Fix False Positives with Safe, Scoped Policy Tuning

F5 ASM CLASSROOM • LESSON 10

Level: Intermediate  |  Suggested study and lab time: 75 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP

Start Here / Course Guide · All lessons

---

Today you are the investigator

A valid customer search fails after policy enforcement. The search includes punctuation used in a book title. Your goal is to restore legitimate behavior while preserving the intended protection. A broad policy relaxation may appear successful while hiding a much larger problem.

A repeatable investigation method

Reproduce: capture the smallest synthetic request that shows the problem. Locate: find its event and exact input location. Validate: confirm with the application owner that this behavior is legitimate. Scope: identify the smallest policy change that represents the requirement. Verify: test valid and invalid cases before and after the change.

A violation is not a false positive merely because a user complains. The application might be receiving malformed input, a client might have a bug, or the behavior might be malicious. Investigation comes first.

Worked example

Suppose q on /search legitimately accepts a wider character set than an inventory identifier. The event identifies a parameter character restriction. A justified change might allow the required character for that URL-level search parameter. Widening every parameter would change the meaning of your policy far beyond this use case.

If the event instead identifies an attack signature, changing a character rule may not solve it. Tune the control that actually triggered. Multiple violations can remain after the first is resolved, so repeat the event review.

Guided lab

1. Export the current lab policy and record its applied revision.
2. Create a regression table with normal search, legitimate punctuation, maximum intended length, overlength text, and a documented security test case.
3. Run the tests and record both application behavior and WAF events.
4. Inspect the exact violation and obtain a written input requirement for the affected endpoint.
5. Make one scoped change. Document its entity, reason, owner, and review date.
6. Save, apply, and rerun the entire regression table.
7. Confirm that unrelated endpoints did not inherit an unintended relaxation.
8. Revert if the change allows an invalid case that the policy was meant to reject.

Expected result: valid behavior is restored, the intended negative cases still fail for understood reasons, and the change is explainable. “No more alerts” is not a sufficient success metric.

How to document an exception

Requirement: Search accepts the approved punctuation set.
Scope: /search, parameter q, specific affected check.
Evidence: Sanitized request and event reference.
Validation: Before/after positive and negative test results.
Owner and review date: Recorded in the change system.
Rollback: Restore the previous tested policy revision.

Common mistakes

Do not disable a whole signature category to fix one parameter. Do not trust an entire source network to silence a single client problem. Do not leave temporary exceptions without review. Avoid changing several unrelated settings together: you will not know which change caused the result.

Knowledge check

A legitimate request works after tuning. Are you finished?

Instructor answer

No. Confirm that relevant invalid requests remain controlled, other workflows still work, the intended policy is applied, and the exception has documented ownership and rollback.

---

Further reading

• F5 documentation: refining security policies with learning
• F5 documentation: adding entities to a security policy

Independent educational material. Menus, defaults, and feature availability vary by BIG-IP release and license. Use the documentation for your installed version. Perform exercises only in your authorized lab. Examples and expected results are instructional; these labs have not been executed on a BIG-IP device for this blog.

← Previous lesson · Course guide · Next lesson →