Per F5's guidance, a learning suggestion with a violation rating of 1 means the request is…

Correct: b. F5's exact wording: rating 1 = "most likely a false positive — if it is, consider accepting learning suggestions". Rating 5 is the attack end of the scale; 3 means examine.

Karthik wants to start protecting a production app but must guarantee no real user is blocked while he tunes. What's his first move?

Correct: a. Transparent detects, logs and learns while blocking nothing — the safe "meter off" phase. He tunes from the suggestions it posts, and flips to Blocking only when Readiness is clean. Blocking first (b) is the day-one mistake.

A suggestion shows violation rating 4 and learning score 88%. The junior engineer wants to accept it because the score is high. What do you tell them?

Correct: c. Rating drives accept/clear; score only tells you confidence/how-soon. A rating of 4 = "looks like a threat, examine it" — accepting would risk whitelisting an attack. Examine the request, and if it's an attack, clear it. High score is never a reason to accept a high-rating suggestion.

An engineer clears (Delete) a recurring rating-1 false-positive suggestion every morning to "keep the screen tidy", yet it's back the next day. What's actually happening?

Correct: b. Delete only removes the suggestion from the list; it doesn't add/relax the entity, so the recurring legit traffic re-creates it. For a genuine false positive you Accept (changes the policy) — or Ignore to hide it permanently. Delete is for clearing attacks, not fixing false positives.

A manager orders "go to Blocking today" for a customer-facing app, but Enforcement Readiness still shows 18 entities not ready. As the engineer, what's the right call?

Correct: c. Flipping with 18 not-ready entities risks blocking real customers on entities the WAF hasn't learned. You can enforce the ready items immediately (partial protection) and finish staging the rest. Deleting suggestions to fake a clean count (d) is dishonest tuning — the entities are still un-learned and will block legit traffic.

For an HDFC banking portal, an engineer proposes turning OFF staging for newly downloaded attack signatures "so every new signature blocks immediately". Sound design?

Correct: c. A new or updated signature can match legitimate banking traffic (a false positive). Per-signature staging lets it observe and post suggestions without blocking, so you enforce only the ones proven safe. Disabling staging on a customer-facing portal is exactly how a signature update strands real users. Option (d) contradicts itself — Transparent blocks nothing regardless.

Tuning ASM: False Positives, Suggestions & Going to Blocking

Q: You bring a brand-new Advanced WAF policy live for a production app. What Enforcement Mode should it run in first ?

Correct: b. Transparent is the "meter off" phase — the WAF learns the app's legitimate entities and posts suggestions without blocking anyone. Flip to Blocking only after tuning and a clean Enforcement Readiness. Going straight to Blocking (a) is exactly how a WAF gets disabled by an angry business unit on day one.

Q: A suggestion shows violation rating 5 and learning score 100%. What should you do?

Correct: c. Rating drives the accept/clear decision; score only tells you how confident the WAF is that it has seen this enough. A rating of 5 = "most likely a threat — clear any learning suggestions associated with it" (F5's exact wording). A 100% learning score here just means the attacker has hit you a lot — never a reason to accept.

Q: You judge a suggestion as a genuine, recurring false positive on a legitimate parameter. Which button stops it coming back?

Correct: a. Accept changes the policy (adds the entity or relaxes the check), fixing the cause so the suggestion doesn't return. Delete (b) only clears it from the list — the same traffic re-creates it tomorrow. Blocking (c) would start enforcing the very false positive you're trying to silence.

Q: Hours after flipping to Blocking (Readiness was clean), one legitimate form starts throwing block pages and a rating-1 suggestion appears for that entity. Best response?

Correct: d. A rating-1 suggestion is a false positive on a legit entity — accept it to fix that one check without weakening the rest of the policy. Reverting the whole app to Transparent (a) throws away all your protection over a single parameter. Tuning is surgical, not all-or-nothing.

Most engineers think…

"The policy is built and the signatures are loaded — so I just flip it to Blocking and we're protected."

Wrong — and that one instinct is how Advanced WAF gets switched off in week one. Flip straight to Blocking and the WAF blocks the things it never learned were legitimate: a long base64 cookie, a JSON body with HTML in it, a parameter your devs added last sprint. Real customers hit a block page, the business escalates, and someone disables the policy "until it's fixed". Tuning is the job — not building. This capstone is the judgement layer on top of everything you already learned: read the Traffic Learning suggestions, separate false positives from attacks, accept the safe ones, and flip to Blocking only when it's safe.

① The tuning loop — and why you start in Transparent

Picture a new auto-rickshaw driver. Week one, he drives every route with the meter off — no charge, no risk. He learns which "wrong turns" were actually shortcuts. Only when he's driven every road does he switch the meter on. Your Advanced WAF policy does exactly this. It starts in Transparent mode: it watches real traffic, flags violations, but blocks nothing.

As traffic flows, the Policy Builder posts learning suggestions on Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning. Each one is the WAF saying "I saw this — do you want me to add it, relax it, or start enforcing it?" Your loop is simple and you repeat it daily: read suggestions → decide (accept / clear) → re-check Enforcement Readiness → repeat. When the screen goes quiet and Readiness is clean, you flip to Blocking. That is the whole capstone.

👉 So far: Transparent = meter off, learn the routes; Blocking = meter on. The Traffic Learning screen is where you read the routes. Next, see the full loop on the egress path.

Figure 1 — The Advanced WAF tuning loop (Transparent → tune → Blocking)

Build once, tune many times. The loop — read, decide, re-check — is the job. Blocking is the reward at the end, not the start.

Sneha at Infosys faces this

Sneha built a brand-new policy for an internal HR app on Friday and flipped it to Blocking before the weekend "to be safe". Monday morning, managers can't approve leave — the app throws block pages.

Likely cause

She skipped the loop. With zero learning time in Transparent, the WAF never learned the app's legitimate URLs, parameters and long session cookies — so in Blocking it treats them as violations.

Diagnosis

Read what's being blocked, then read the suggestions for those same entities.

Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning

Fix

Set Enforcement Mode = Transparent, let the Policy Builder learn for the Enforcement Readiness Period (default 7 days), accept the legitimate-entity suggestions, then flip back to Blocking.

Verify

Re-test the leave-approval flow in Transparent: it triggers a learning suggestion (not a block). After accepting, Enforcement Readiness drops to clean for those entities.

▶ Watch the tuning loop — then watch the day-one Blocking mistake

Rahul at TCS brings a new policy live. Press Play for the safe loop, then Break it to see what flipping to Blocking on day one does to real users.

① TRANSPARENTPolicy goes live in Transparent — it detects and logs, blocks nothing

▼

② LEARNPolicy Builder posts Traffic Learning suggestions for entities + violations it sees

▼

③ TUNERahul accepts false positives, clears attacks, re-checks Enforcement Readiness

▼

④ FLIPReadiness clean → flip Transparent → Blocking, attacks blocked, legit passes

Press Play to step through the safe tuning loop. Then press Break it.

Quick check · Q1 of 10

You bring a brand-new Advanced WAF policy live for a production app. What Enforcement Mode should it run in first?

a) Blocking — protect from the first request b) Transparent — detect, log and learn from real traffic while blocking nothing, then tune before you block c) It doesn't matter as long as signatures are loaded d) Disabled, until the next maintenance window

Correct: b. Transparent is the "meter off" phase — the WAF learns the app's legitimate entities and posts suggestions without blocking anyone. Flip to Blocking only after tuning and a clean Enforcement Readiness. Going straight to Blocking (a) is exactly how a WAF gets disabled by an angry business unit on day one.

Pause & Predict

Two suggestions appear. One says "a parameter order_notes contains HTML" with rating 1; another says "SQL injection in the id parameter" with rating 5. Which one do you accept and which do you clear — and why? Type your guess.

Answer: Accept the rating-1 one — a low violation rating means "most likely a false positive", so you teach the policy that order_notes legitimately carries markup. Clear the rating-5 one — a high rating means "most likely a real attack", and accepting it would whitelist the attacker's payload. Rating tells you attack-ness; that's exactly Path 2.

② Violation rating vs learning score — the two-axis decision

This is the single skill that separates a junior who panics at every suggestion from an engineer who clears a Traffic Learning screen in ten minutes. Every suggestion gives you two numbers. Read them together and the decision makes itself.

The violation rating answers "how attack-like is this?" It is a 1-to-5 score the WAF assigns to the whole transaction — not one violation — by weighing the combination of violations and their business impact. The learning score answers a different question: "how confident am I?" It is a percentage that rises as the WAF sees the same thing from more sources, more sessions, over more time. At 100% the Policy Builder is ready to recommend you accept.

Read the official guidance straight from F5: a violation rating of 1 means "most likely a false positive — consider accepting", 3 means "needs examination", and 5 means "most likely a threat — consider clearing any learning suggestions associated with it". So the two axes give you a grid: low rating + high score = accept (a real false positive, seen often); high rating = clear (don't whitelist an attacker, no matter how often you saw them).

Pro tip — rating is about the request, score is about you

Don't confuse the two. Violation rating grades the traffic (is this an attack?). Learning score grades the policy's confidence (have I seen enough to be sure?). A rating-5 request can hit 100% learning score and you should still clear it — high confidence that something is a real attack is the opposite of a reason to accept it. This is the row examiners love on the 303 — BIG-IP ASM Specialist exam.

👉 So far: rating = attack-ness (1–5), score = confidence (%). Low rating + high score = accept; high rating = clear. Next, see the grid that turns those two numbers into one decision.

Figure 2 — The decision grid: violation rating × learning score

Rating runs up the side, score runs along the bottom. Stay green for false positives, never accept anything in the red top row — that's the whole judgement.

Priya at Flipkart faces this

Priya sees 400 "Illegal meta character in parameter" suggestions on the checkout app, all rating 1, learning score climbing past 90%. The SOC wants her to clear them all "to be safe".

Likely cause

Legitimate behaviour. The delivery_note field accepts commas, apostrophes and ampersands — characters the WAF flags by default. Rating 1 + high score = a real false positive, seen widely.

DiagnosisSecurity ▸ Application Security ▸ Policy Building ▸ Traffic Learning → sort by Violation Rating ascending

Fix

Accept the suggestion — it relaxes the meta-character check for that parameter. Clearing them (the SOC's instinct) would just make the same false positives reappear tomorrow, never fixing the noise.

Verify

Re-run a real checkout: no new suggestion for delivery_note. Enforcement Readiness for that parameter goes clean. A genuine SQLi attempt still rates 5 and stays in the clear pile.

How the Security Policy Was Built (#2) Positive Security & Learning (#3)

Quick check · Q2 of 10

A suggestion shows violation rating 5 and learning score 100%. What should you do?

a) Accept it — 100% score means the policy is confident b) Accept it — high numbers are always good c) Clear it — rating 5 means "most likely a real attack"; accepting would whitelist the exploit. Score only measures how often it was seen d) Ignore it permanently and move on

Correct: c. Rating drives the accept/clear decision; score only tells you how confident the WAF is that it has seen this enough. A rating of 5 = "most likely a threat — clear any learning suggestions associated with it" (F5's exact wording). A 100% learning score here just means the attacker has hit you a lot — never a reason to accept.

Pause & Predict

There are three buttons on a suggestion: Accept, Delete and Ignore. You clear (Delete) a false-positive suggestion to tidy the screen. Tomorrow the same suggestion is back. Why — and which button would have stopped it returning? Type your guess.

Answer: Delete only removes the suggestion now — if the same traffic recurs, the WAF generates it again. Accept changes the policy so the entity is learned and the suggestion stops. Ignore tells the Policy Builder to stop showing this specific suggestion permanently without changing the policy. For a genuine false positive you want Accept, not Delete. That's exactly Path 3.

③ Accept, Delete, Ignore — and per-entity vs per-signature

You've judged the suggestion. Now you act. The Traffic Learning screen gives you three buttons, and each does something different to the policy.

The three buttons (exact labels)

Accept Suggestion — changes the policy. The WAF adds the entity (a new URL/parameter/file type) or relaxes the check that caused the false positive. The suggestion stops recurring because you fixed the cause.
Delete Suggestion — removes it from the list for now. It does NOT change the policy, so if the same traffic appears again the Policy Builder re-creates the suggestion. Use it to clear a real attack out of the list, knowing it will only reappear if the attacker returns.
Ignore Suggestion — tells the Policy Builder to stop showing this specific suggestion permanently, without changing the policy. Use it for noise you've judged and don't want to see again.

Analogy: Accept is "fix the pothole". Delete is "drive around it today" (it's there tomorrow). Ignore is "stop reminding me about that pothole" — you've decided you'll live with it.

Per-entity vs per-signature staging

Suggestions and enforcement happen at two granularities, and the 303 exam loves the difference:

Per-entity — URLs, parameters, file types, cookies, headers. Each one sits in staging while the WAF learns it, then becomes enforced. You can enforce one URL while another keeps learning.
Per-signature — attack signatures stage independently. A newly added or newly updated signature stays in staging (generating suggestions, blocking nothing) until you enforce it — so a fresh signature update can't suddenly start blocking real users.

The Enforcement Readiness summary at the top of the screen counts exactly this: how many entities and signatures are still not ready. When everything has sat through its Enforcement Readiness Period (default 7 days) with no new suggestions, that count hits zero — your green light.

Pro tip — "Enforce Ready" entities are your safe wins

You don't have to wait for the whole policy. The screen lets you enforce just the entities and signatures that are ready while the rest keep learning. Enforcing the ready ones early shrinks your attack surface without risking the parts you haven't tuned. 17.5 even adds a one-click "Enforce and Enable all Attack Signatures with High Risk & High Accuracy in the Signature Set" option.

👉 So far: Accept fixes, Delete is temporary, Ignore silences. Entities and signatures stage separately; Enforcement Readiness counts what's not ready. Next, see exactly where these buttons live.

Figure 3 — Accept vs Delete vs Ignore — what each button does to the policy

Accept fixes the cause. Delete is a broom, not a fix. Ignore is "I've judged this, hide it." Pick by intent, not by which clears the list fastest.

🖥️ Recreated for clarity — your BIG-IP console matches this

https://10.10.10.5/tmui/ — Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning

Local Traffic

Security

Application Security

› Security Policies

› Policy Building

· Traffic Learning

› Attack Signatures

Network

System

Current edited policy: prod_shop_app · Enforcement Mode: Transparent · Enforcement Readiness: 3 entities, 1 signature not ready

SuggestionAdd valid parameter delivery_note (illegal meta char) Rating 1 Accept Suggestion 1

Learning score96% seen across 41 sources / 7 days 2

SuggestionSQL-Injection signature on parameter id Rating 5 Delete Suggestion 3

Enforce ready2 entities have passed staging — Enforce Ready available 4

① A low violation rating (1) → Accept teaches the policy this parameter is legit. ② The learning score (%) shows how often/widely it was seen. ③ A high rating (5) is a real attack → never Accept; Delete/Clear it. ④ Enforcement Readiness drives the green light to enforce.

Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning — the screen you live on while tuning. Pins mark the four fields this lesson changes.

▶ Watch one entity ride staging into enforcement — then watch a forced flip

Karthik at Wipro tunes a parameter on a TCS-built app. Play the safe staging path, then Break it to see what enforcing before Readiness is clean does.

① STAGINGNew parameter delivery_note enters staging — monitored, never blocks

▼

② SUGGESTIONMeta-char false positive posted, rating 1, learning score climbing

▼

③ ACCEPTKarthik accepts → check relaxed for that param → no new suggestion

▼

④ READY7-day Readiness Period passes clean → entity is Enforce Ready

Press Play for the safe staging-to-enforcement path. Then press Break it.

The four tuning verbs — tap each card

Each card front names the move; the back gives you the "so what" — when to reach for it during tuning.

✅

tap to flip

Changes the policy — adds the entity or relaxes the check. So what: the only button that fixes the cause. Use on a genuine false positive (low rating).

🧹

Delete / Clear

tap to flip

Removes the suggestion now, no policy change — it returns if the traffic recurs. So what: clear a real attack (high rating); don't use it on a recurring false positive.

🙈

Ignore

tap to flip

Hides this specific suggestion permanently, no policy change. So what: judged noise you don't want cluttering the screen again.

🚦

Enforce

tap to flip

Moves a staged entity/signature into active blocking. So what: do it only when Enforcement Readiness is clean — or you'll block what you never learned.

Quick check · Q3 of 10

You judge a suggestion as a genuine, recurring false positive on a legitimate parameter. Which button stops it coming back?

a) Accept Suggestion — it changes the policy to learn/relax the entity, so the suggestion stops recurring b) Delete Suggestion — removes it for good c) Switch the policy to Blocking d) Lower the Enforcement Readiness Period to 0 days

Correct: a. Accept changes the policy (adds the entity or relaxes the check), fixing the cause so the suggestion doesn't return. Delete (b) only clears it from the list — the same traffic re-creates it tomorrow. Blocking (c) would start enforcing the very false positive you're trying to silence.

Pause & Predict

You're about to flip a policy serving 5,000 users from Transparent to Blocking. Enforcement Readiness still shows "12 entities not ready". What's the one thing that could break, and what should you do first? Type your guess.

Answer: Those 12 not-ready entities are URLs/parameters the WAF is still learning — flip now and it can block legitimate requests to them, stranding real users. Do this first: let staging finish (or accept the legit-entity suggestions so Readiness drops to 0), then flip Enforcement Mode to Blocking. Readiness clean is the green light. That's exactly Path 4.

④ The final flip — Transparent → Blocking, the safe way

Everything so far has been preparation. This is the moment the meter goes on. The control lives at Security ▸ Application Security ▸ Security Policies ▸ <policy> ▸ Policy Properties, in the Enforcement Mode field — a toggle between Transparent and Blocking.

The don't-block-legit-customers playbook

Confirm Enforcement Readiness is clean. On Traffic Learning, the count of not-ready entities and signatures should be 0. If it isn't, you have learning left to do — finish it.
Enforce the ready entities/signatures. Move what's passed staging into enforcement (or use the 17.5 one-click high-risk/high-accuracy enforce) so the policy actually checks them.
Set Enforcement Mode = Blocking. Now an enforced violation returns the blocking response page instead of just logging.
Watch the first hours. Keep the Traffic Learning screen open. A surprise false positive will surface as a low-rating suggestion — accept it, and the block clears for that entity.

Why this order matters: Transparent learns, staging protects you from new entities and fresh signatures blocking too early, and Enforcement Readiness is the one number that says "I won't strand a real customer." Flip before it's clean and you're the rickshaw driver charging a passenger on a route you never drove.

The two GUI knobs you actually touch

Enforcement Mode (Policy Properties) — Transparent = detect + log only; Blocking = actively block enforced violations and serve the blocking page. This is the master switch.
Blocking settings per check — even in Blocking mode, each violation has Learn / Alarm / Block flags. A check only blocks if its Block flag is on AND the entity/signature is enforced (not staged). Violation Rating Based Enforcement adds a safety net: a transaction rated 4–5 can block even when individual violations have Block off.

🖥️ Recreated for clarity — your BIG-IP console matches this

https://10.10.10.5/tmui/ — Security ▸ Application Security ▸ Security Policies ▸ prod_shop_app ▸ Policy Properties

Local Traffic

Security

Application Security

· Security Policies

· Policy Properties

› Policy Building

Network

System

Policy: prod_shop_app · Properties

Policy Nameprod_shop_app

Enforcement Mode ◉ Transparent ◯ Blocking 1

Enforcement Readiness Period7 days 2

Enforcement Readiness0 entities / 0 signatures not ready 3

Save → flip to Blocking

① Enforcement Mode toggle — flip from Transparent to Blocking only here. ② The Enforcement Readiness Period (default 7 days) — the staging window. ③ Enforcement Readiness = 0 not ready is your green light to flip safely.

Security ▸ Application Security ▸ Security Policies ▸ <policy> ▸ Policy Properties — the Enforcement Mode toggle. Flip only when pin ③ reads zero.

tmsh — read Enforcement Readiness, then flip the policy to Blocking

# BIG-IP >= 14.1 · Advanced WAF · self IP 10.10.10.5
tmsh list asm policy prod_shop_app enforcement-mode
# check what is still staged before you flip:
tmsh show asm policy prod_shop_app | grep -i ready
# only when clean, flip Transparent -> Blocking:
tmsh modify asm policy prod_shop_app enforcement-mode blocking
tmsh save sys config

Expected output

enforcement-mode transparent
Enforcement Readiness : 0 entities, 0 signatures not ready
Policy prod_shop_app : enforcement-mode now blocking
Saving running configuration...  /config/bigip.conf  [  OK  ]
# If "not ready" > 0, do NOT flip — finish staging/accept legit suggestions first.

iControl REST — same flip via the management API (10.10.10.5)

curl -sku admin:****** -X PATCH \
  https://10.10.10.5/mgmt/tm/asm/policies/<policyId> \
  -H 'Content-Type: application/json' \
  -d '{"enforcementMode":"blocking"}'

Expected output

{
  "name": "prod_shop_app",
  "enforcementMode": "blocking",
  "isModified": true
}
# 200 OK — the policy is now Blocking. Watch Traffic Learning for any day-one false positives.

The trap behind a "finished" policy

Don't flip to Blocking because a date arrived or a manager asked. Flip because Enforcement Readiness = 0 not ready. Flipping with entities still staged is how Advanced WAF blocks the leave-approval button on Monday morning — and how the business unit asks you to "just turn it off". The clean Readiness count is the only green light that matters.

👉 So far: confirm Readiness = 0, enforce the ready items, flip Enforcement Mode to Blocking, then watch. Next, prove the flip was safe.

▶ Watch the flip get validated — then watch the day-one false positive

Priya at HDFC flips the policy to Blocking after a clean Readiness. Play the safe validated flip, then Break it to see a missed false positive surface.

① READINESSTraffic Learning shows 0 not ready — the green light

▼

② FLIPPolicy Properties → Enforcement Mode = Blocking, saved

▼

③ ATTACKA real SQLi (rating 5) hits → enforced signature blocks it, returns block page

▼

④ LEGITA normal checkout passes untouched — the meter is on, the real passenger rides

Press Play for the safe validated flip. Then press Break it.

Aditya at TCS faces this

Aditya flipped to Blocking with a clean Readiness, but hours later one customer-facing form starts throwing block pages. Real users are affected. The team panics and wants to revert to Transparent for the whole app.

Likely cause

A low-volume legitimate flow the WAF saw too rarely to fully learn — so it surfaced only once real traffic hit it in Blocking. A rating-1 suggestion is already on the Traffic Learning screen for that exact entity.

DiagnosisSecurity ▸ Application Security ▸ Policy Building ▸ Traffic Learning → filter Violation Rating = 1

Fix

Accept the rating-1 suggestion for that entity — no need to revert the whole app. The check relaxes for that one parameter and the block clears, while every other enforced check keeps protecting.

Verify

Re-test the form: it submits cleanly. The Event Log shows the request now passes; a genuine attack on the same form still blocks. Don't revert — tune the one entity.

Verify it worked — the log that ends the argument

Never claim "we're safely in Blocking" from the Policy Properties screen alone. Do a safe synthetic attack (e.g. a harmless test payload that trips a signature), then open Security ▸ Event Logs ▸ Application ▸ Requests, filter on your test source + last hour, and read the Violation, Attack Type and Request Status columns. Request Status = blocked with the support ID proves the policy is enforcing. If a real request shows blocked instead, that's your day-one false positive — go accept its suggestion.

Event Logs filter — confirm the policy is enforcing after the flip

Security ▸ Event Logs ▸ Application ▸ Requests
  Filter:  Policy = prod_shop_app  AND  Request Status = Blocked  AND  last 1 hour
  Columns: Source IP · Violation · Attack Type · Violation Rating · Support ID

Expected output

2026-06-02 14:22  src 203.0.113.7    Status: BLOCKED
  Violation: Attack signature detected   Attack Type: SQL-Injection
  Violation Rating: 5   Support ID: 8847120053361902
2026-06-02 14:23  src 172.16.40.18   Status: PASSED   (legit checkout, internal LAN)
# If a real user (e.g. 192.168.10.x) shows BLOCKED → accept that entity's rating-1 suggestion.

Quick check · Q4 of 10

Hours after flipping to Blocking (Readiness was clean), one legitimate form starts throwing block pages and a rating-1 suggestion appears for that entity. Best response?

a) Revert the whole policy to Transparent — disable protection for everyone b) Delete the policy and rebuild from scratch c) Lower the Enforcement Readiness Period to 0 d) Accept the rating-1 suggestion for that entity — it relaxes that one check while every other enforced check keeps blocking attacks

Correct: d. A rating-1 suggestion is a false positive on a legit entity — accept it to fix that one check without weakening the rest of the policy. Reverting the whole app to Transparent (a) throws away all your protection over a single parameter. Tuning is surgical, not all-or-nothing.

Figure 4 — Transparent vs Blocking: what the same attack does (control OFF vs ON)

Same SQL injection, two modes. Transparent (OFF) lets it through on purpose while learning; Blocking (ON) stops the attack and still serves the real customer. That gap is the whole point of the flip.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from F5 techdocs + DevCentral, scoped to Advanced WAF (ASM) tuning. For a live prod issue, paste your Event-Log export into chat.techclick.in.

🧠 In your own words

Type one line: why is it safe to flip a policy from Transparent to Blocking only when Enforcement Readiness shows 0 not ready? Then compare to the expert version.

Expert version: In Transparent mode the WAF only detects and logs while it learns the app's legitimate entities (URLs, parameters, file types) and stages new/updated signatures. An entity or signature that's still "not ready" hasn't finished its Enforcement Readiness Period — the WAF hasn't confirmed it's legitimate. Flip to Blocking with not-ready items and the WAF can block those legitimate requests, stranding real customers. When the count is 0, everything enforced has been learned or tuned, so Blocking stops attacks without breaking legit traffic. If your answer mentioned "not-ready entities aren't learned yet, so they'd block real users", you've got it.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on ASM tuning at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Advanced WAF (formerly ASM): F5 BIG-IP Advanced WAF — ASM + L7 Behavioral DoS + Bot Defense + credential-stuffing/brute-force protection + DataSafe. ASM went End-of-Sale 01-Apr-2021; existing ASM customers on BIG-IP ≥14.1 under support can reactivate to Advanced WAF free. The TMUI module is still labelled "Application Security".
Transparent mode: Enforcement Mode where the policy detects and logs violations and learns from traffic but blocks nothing — the safe tuning phase.
Blocking mode: Enforcement Mode where the WAF actively blocks enforced violations and returns the blocking response page.
Traffic Learning: The Policy Building screen (Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning) where the Policy Builder posts learning suggestions and the Enforcement Readiness summary.
Learning suggestion: A recommendation to add an entity, relax a check, or enforce a signature, based on observed traffic. Acted on with Accept, Delete, or Ignore.
Violation rating: A 1–5 score for the whole transaction. 1–2 = likely false positive (accept), 3 = examine, 4–5 = likely attack (clear). It grades the traffic.
Learning score: A percentage showing how confident the Policy Builder is, based on how often/widely the entity was seen. It grades the WAF's confidence, not whether the traffic is safe.
Staging: A state where a new entity or signature is monitored and generates suggestions but is not enforced — it cannot block yet. Entities and signatures stage independently.
Enforcement Readiness: The Traffic Learning summary counting how many entities/signatures are still not ready. 0 = everything has passed staging with no new suggestions — the green light to enforce.
Enforcement Readiness Period: The window (default 7 days) a staged entity/signature must collect no new suggestions before it's considered ready to enforce.
Enforcement Mode: The policy-level switch (Policy Properties) between Transparent and Blocking. The master "meter off / meter on" toggle.
Violation Rating Based Enforcement: A safety net where a transaction rated 4–5 can block even if individual violations have their Block flag off.

📚 Sources

F5 BIG-IP Documentation — Refining Security Policies with Learning (Traffic Learning, learning suggestions, learning score, Accept/Delete/Ignore Suggestion, Enforcement Readiness Period, unlearnable violations). techdocs.f5.com/en-us/bigip-15-0-0/big-ip-asm-implementations/refining-security-policies-with-learning.html
F5 BIG-IP Documentation — Working with Violations (violation rating 1–5 scale, rating assigned to the whole transaction, separating false positives from attacks). techdocs.f5.com/en-us/bigip-17-5-0/big-ip-asm-implementations/working-with-violations.html
F5 Knowledge — Violation Rating Based Enforcement (K000137152) — a 4–5 transaction blocks even when individual violations have Block off; per-entity vs per-signature enforcement. my.f5.com
F5 DevCentral / community.f5.com — threads "ASM staging in Transparent and Blocking — what is difference", "ASM Learning and Enforcement readiness period, can we change?", "ASM transparent mode" (staging behaviour, readiness period, Transparent→Blocking false positives). community.f5.com
F5 BIG-IP 17.5.0 Release Notes — New Features (Base64 semantic auto-detection to reduce false positives; new "Enforce and Enable all Attack Signatures with High Risk & High Accuracy in the Signature Set" GUI option; JWT validation). techdocs.f5.com/en-us/bigip-17-5-0/big-ip-release-notes/big-ip-new-features.html
F5 Certification — 303 — BIG-IP ASM Specialist Exam Blueprint (90 minutes, 80 questions, pass 245 of 100–350; policy building, learning, enforcement objectives). education.f5.com/exams/big-ip-asm-specialist-303
Reddit r/f5networks — practitioner discussion on tuning ASM in Transparent before going to Blocking and reading violation rating vs learning score. reddit.com/r/f5networks

What's next?

That's the series. You can now run the full Advanced WAF tuning loop — read suggestions, judge with rating + score, accept or clear, watch Enforcement Readiness, and flip to Blocking without stranding a customer. Loop back to the foundations any time, then prove it on the simulator and the 303 mock.

Try the F5 WAF Simulator → Practice the 303 on exam.techclick.in →

Tuning ASM: False Positives, Suggestions & Going to Blocking

🎯 By the end you will be able to

Pick where you want to start

The Tuning Loop

Rating vs Score

Accept / Clear / Ignore

The Final Flip

① The tuning loop — and why you start in Transparent

▶ Watch the tuning loop — then watch the day-one Blocking mistake

② Violation rating vs learning score — the two-axis decision

③ Accept, Delete, Ignore — and per-entity vs per-signature

The three buttons (exact labels)

Per-entity vs per-signature staging

▶ Watch one entity ride staging into enforcement — then watch a forced flip

The four tuning verbs — tap each card

④ The final flip — Transparent → Blocking, the safe way

The don't-block-legit-customers playbook

The two GUI knobs you actually touch

▶ Watch the flip get validated — then watch the day-one false positive

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?