ASM Positive Security & Learning — Allow-list What's Good, Don't Chase Every Bad

① Positive security — allow-list the good, don't chase every bad

Picture a Big Fat Indian Wedding. A bouncer who tries to recognise every possible gatecrasher will fail — there are infinitely many. The smart bouncer instead learns the guest list: these relatives, this caterer, that decorator, entering through that gate. Anyone not on the learned list gets a second look. That is positive security.

In Advanced WAF, the two models work together. Negative security (attack signatures) blocks known-bad. Positive security allow-lists known-good — the legitimate entities your app actually serves. A request that asks for a URL your app never exposes, or sends a parameter the app never uses, sits outside the allow-list — a violation, even if no signature matches it. That is how positive security catches zero-days that signatures miss.

Quick history (state this the same way every time): ASM went End-of-Sale on 01-Apr-2021. Advanced WAF (launched 2018) = ASM + L7 Behavioral DoS + Bot Defense (Proactive Bot Defense) + credential-stuffing/brute-force + DataSafe. Existing ASM customers on BIG-IP ≥ 14.1 under support can reactivate to Advanced WAF free. The GUI module is still literally Security ▸ Application Security and many screens still say "ASM" — so we use "ASM" for the menu/legacy name and "Advanced WAF" in prose. The cert anchor for this whole series is the 303 — BIG-IP ASM Specialist exam (90 min, 80 questions, pass 245/350).

② Traffic Learning — how Policy Builder discovers your entities

You don't hand-write the allow-list. Policy Builder watches live traffic and builds it for you. The screen where you review what it found is Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning — the heart of this lesson.

As traffic flows, ASM generates learning suggestions for requests that don't yet match the policy. Each suggestion is "I keep seeing this file type / URL / parameter / cookie / redirection domain — should I add it as legitimate?" You Accept, Delete or Ignore each one. (Accepting how to go live / flip to blocking is a judgement call covered in the False-Positive Tuning lesson — here we learn what the entities and the workflow are.)

The two numbers that matter. Every suggestion carries a learning score and is shaped by the request's violation rating. Keep them straight:

• Learning score (0–100%) — how confident Policy Builder is that the suggestion is safe to accept. It climbs as the entity is seen more often, from more sources, over more time. At 100%, automatic Policy Builder accepts it for you; you can accept a valid one earlier.
• Violation rating (1–5) — how attack-like the triggering request looks. This drives the score: lower violation rating → higher learning score (looks benign, trust it), higher rating → the score stalls (looks like an attack, don't trust it).

③ Staging and the three learning modes

Learning an entity is only half the job. The other half is doing it safely, so a new entity never causes an outage. That's what staging and the per-entity learning modes are for.

Read the screen like a triage queue. Pins ① and ② are high-score, benign suggestions (low violation rating) — accept them. The id parameter at pin-area sits at 11% with violation rating 5 — ASM is warning you this looks like an attack, so you Delete it, not accept. Pin ③ is the Enforcement Readiness Summary, which we read in Path 4.

Entity staging — the safety window

Staging means an entity (or an attack signature) is in the policy but not enforced — ASM logs it and posts learning suggestions, but never blocks on it. New entities and new signatures go into staging automatically. The window is the enforcement readiness period (default 7 days). If no new learning suggestions appear for an entity across that period, it's considered ready to be enforced.

Analogy: staging is a new bouncer shadowing a senior for a week. He watches who comes in and notes faces, but he doesn't turn anyone away yet. Only after the week — once nothing new surprises him — does he start enforcing the guest list.

The three learning modes — per entity type

For file types, URLs and parameters you choose how aggressively Policy Builder learns, in Learning and Blocking Settings:

• Add All Entities — learn every explicit entity seen in traffic. Builds a comprehensive, granular allow-list (the strictest, but the policy gets large). Not available for cookies.
• Selective — start with a wildcard; when a wildcard match draws a false positive, add an explicit entity with relaxed settings. The balance of security, small policy size and low maintenance.
• Never (wildcard only) — keep a wildcard and only ever relax the wildcard on a false positive; never add explicit entities. Easiest to manage, least strict.

There's also a Compact flavour (top-level URLs like /abc/* enforced explicitly, the rest under a wildcard, with pre-populated disallowed file types) for very large apps.

The five entity types Policy Builder learns — tap each card

Positive security tracks five kinds of entity. The front names it; the back gives the "so what" — what the allow-list protects.

④ Tighten the policy and read the Enforcement Readiness Summary

You've learned entities and staged them safely. The last two moves are tightening the policy so it stays lean, and reading the summary that tells you what's ready to enforce.

Loosen vs tighten — the two stabilize directions

Policy Builder stabilizes a policy in two directions, each with its own requests-and-time threshold in Learning and Blocking Settings → Policy Building Process:

• Loosen Policy (add) — when traffic shows a legitimate entity is missing, add it / relax a setting so the app keeps working.
• Tighten Policy (stabilize) — tightening shrinks and hardens: it deletes redundant wildcard entities, removes stabilized entities from staging, and enforces violations that haven't occurred for the configured number of requests/time. This is how an auto-built policy stops sprawling.

Analogy: the wedding bouncer's week is over. Loosening is adding a late-confirmed cousin to the list. Tightening is striking off the "maybe" entries nobody used and locking the final list — fewer names, firmer door.

The Enforcement Readiness Summary — your go/no-go board

Open Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning and read the Enforcement Readiness Summary. For each entity type (File Types, URLs, Parameters, Cookies, Redirection) it shows a Not Enforced count. A number greater than zero means entities of that type are still in staging (or a wildcard is still learning explicit matches) — being learned and logged, but not yet able to block. When the staging period passes with no new suggestions, they become Ready to be Enforced, and you can enforce them. The summary is the single screen that answers "is this policy safe to enforce yet?".

Pin ① is the State column — your at-a-glance "is this blocking yet?". Pin ② is order_ref, the parameter Karthik just learned, still Staged with 4 days left in its window; it logs but can't block until it stabilizes. The wildcard and the older parameters are already Enforced.

The same moves at the command line

ASM is GUI-heavy, but tmsh and the iControl REST API expose the same state. Useful for audits and automation.

root@(bigip01)(cfg-sync)(Active)(/Common)(tmos)# list asm policy shop_app_policy parameters
# realistic mgmt IP 10.1.1.245 — run from the BIG-IP CLI
asm policy shop_app_policy {
    parameters {
        order_ref { perform-staging enabled }
        coupon    { perform-staging disabled }
    }
}

order_ref : perform-staging = enabled   (still in the 7-day readiness window)
coupon    : perform-staging = disabled  (enforced — now blocks bad input)
# perform-staging enabled  = entity is staged (logs, no block)
# perform-staging disabled = entity is enforced

curl -sk -u admin:****** \
  https://10.1.1.245/mgmt/tm/asm/policies//policy-builder \
  | python3 -m json.tool

{
  "enforcementReadinessPeriod": 7,
  "learningMode": "automatic",
  "trustAllIps": false
}
# enforcementReadinessPeriod = 7 days (the default staging window)
# If a never-seen URL still shows Not Enforced > 0 → it is still learning, not ready.