F5 ASM Building a Security Policy — Templates, Building Blocks & Learning

① Templates — where a new policy starts

Think of buying a house. You don't pour the foundation, frame the walls, and run every pipe yourself from scratch — you start from a builder's standard plan and customise. A deployment template is that standard plan for an Advanced WAF policy. When you create a policy under Security ▸ Application Security ▸ Security Policies, you pick a template instead of starting from an empty page.

The two you meet first:

• Rapid Deployment — the fast baseline. It gives you generic protection (attack signatures + common building blocks) with minimal manual config, so you can go live in Transparent quickly and let learning do the rest. Most new policies start here.
• Application-ready / Comprehensive — a tighter, more application-specific positive-security model. It produces stronger protection but needs a longer learning and tuning window before you enforce.

The template only sets your starting point and how aggressively ASM learns. Whatever you pick, the real policy comes from tuning it against your actual traffic. The GUI module is still labelled Security ▸ Application Security, and many screens say "ASM" — that legacy module name lives on inside Advanced WAF.

② Building blocks — the entities a policy allows

Now look inside the policy. Think of a strict reception desk: the receptionist has a list of who's expected today, which rooms they may enter, and what they may carry. Anyone or anything not on the list is flagged. In Advanced WAF that list is the policy's building blocks — the entities the policy knows about and allows.

The four entities you meet first

• File types — which extensions the app legitimately serves (html, js, png…). A request for an unexpected type is flagged.
• URLs — the app's real paths (/login, /api/cart). A request to an unknown URL can raise an Illegal URL violation.
• Parameters — the input fields and their rules (type, length, allowed characters). This is the most security-relevant entity — most attacks ride in a parameter value.
• Headers — the HTTP headers the policy expects, plus rules on them (mandatory Host, cookie handling, etc.).

Together these entities are the positive-security model — allow only what you know is good. The attack-signature engine (the negative model — that's the Attack Signatures lesson) runs alongside it. Building a policy is mostly about getting these entities right for your app.

③ Policy building & learning — let ASM do the typing

Here is the analogy that makes this lesson stick. Automatic policy building is like an apprentice receptionist who shadows the front desk for a week, noting who actually shows up and what they carry. By the end they've drafted the "expected visitors" list for you — you just review it and sign off. That apprentice is the ASM learning engine.

What policy building does

Automatic policy building watches your live traffic and proposes learning suggestions — new file types, URLs and parameters it has seen, plus rules to relax. You review them on the Traffic Learning screen and accept the legitimate ones. The whole point is to build a tight, accurate positive-security model without hand-typing thousands of entities, and to keep it current as the app changes.

The learning runway (deploy Transparent first)

Learning needs real traffic and a safety window. So you deploy the new policy in Transparent mode and let it run for a while. New or learned entities also go through a staging / enforcement readiness period (default 7 days) — they're observed, suggested, but not enforced — so a wrong guess never blocks a real user before you've reviewed it.

Accepted ≠ enforced (this never happens by itself)

This is the #1 trap. Accepting a suggestion in the editor does not put it live. You still take the action:

• Review the learning suggestions. A suggestion that matches your legitimate traffic → accept it into the policy. A suggestion that looks like an attack → leave it (it'll be a violation once enforced).
• Enforce ready entities — once the readiness period elapses, enforce the entities that are ready so the policy starts acting on them.
• Apply Policy. Like everything in Advanced WAF, the change is staged in the editor until you Apply.

Until you enforce and apply, accepted entities still only log. Many "the WAF won't enforce my changes" tickets are exactly this — suggestions accepted but never applied.

The four stages of a policy entity — tap each card

The front names the stage; the back gives you the "so what" — what the entity is doing to traffic right then.

④ Review & enforce — from learning to live

You've learned the entities. The last stretch turns suggestions into a live, protective policy without breaking the app. Two things decide whether the policy actually protects: the entities you accepted (Path 3) and the enforcement mode (this section). Get either wrong and the WAF either lets attacks through or blocks real users.

Review the learning suggestions

On Security ▸ Application Security ▸ Policy Building ▸ Traffic Learning, each suggestion tells you what ASM saw and how often. Your job is to sort them:

• Legitimate? A real URL, a real parameter, a normal file type → accept it into the policy.
• Attack-shaped? A suspicious value, an odd path, a probing parameter → leave it. Don't widen the policy to fit an attacker; once enforced, that request becomes a violation.

The volume drops fast — most of an app's entities are learned in the first day or two of real traffic.

Enforce, then go Blocking

Accepting a suggestion adds it to the policy but doesn't make the policy act. Two final flips:

• Enforce ready entities — once the readiness period elapses, enforce the entities so the policy treats out-of-bounds requests as violations.
• Switch the enforcement mode to Blocking and Apply Policy — now the policy actually drops violations instead of just logging them.

So the chain to a protective policy is: learn entities → accept the legit ones → enforce → mode = Blocking + Apply. Miss the last flip and the policy only logs. (Whether to go Blocking, and when, is the global go-live decision covered deeper in the deployment lesson.)

root@(bigip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# list asm policy /Common/app_pol \
  enforcement-mode enforcement-readiness-period
# review the learned/suggested entities in the GUI Traffic Learning screen, then enforce

asm policy /Common/app_pol {
    enforcement-mode transparent
    enforcement-readiness-period 7
}
# Policy is learning in Transparent; 7-day readiness window confirmed before entities enforce.

root@(bigip01)(tmos)# modify asm policy /Common/app_pol entities enforce-readiness
root@(bigip01)(tmos)# modify asm policy /Common/app_pol enforcement-mode blocking
root@(bigip01)(tmos)# modify asm policy /Common/app_pol apply

Ready entities enforced: 318 URLs, 642 parameters, 14 file types.
asm policy /Common/app_pol { enforcement-mode blocking }
Policy /Common/app_pol applied. Active.
# The learned entities now enforce; in Blocking mode, requests outside them are dropped with a support ID.

root@(bigip01)(tmos)# show asm policy /Common/app_pol
# then read a test request in the Event Log by support ID

asm policy /Common/app_pol   Enforcement Mode: blocking
2026-06-02 14:22  src 203.0.113.7  vs 10.10.20.5:443
  Violation: Illegal parameter value (q=' OR 1=1--)   Result: BLOCKED
  Support ID: 18007244126553882151
# If Mode = transparent → only Alarmed. If a legit URL is BLOCKED → accept its learning suggestion.