F5 ASM Attack Signatures — Signature Sets, Staging & Enforcement

① What an attack signature is — the wanted-poster wall

Think of a police station's wanted-poster wall. Each poster is one known offender: a face, a name, a description. Every person walking past is compared to every poster. A match raises a flag. An attack signature is exactly that — a rule or pattern that identifies a known attack on a web application. When F5 BIG-IP Advanced WAF (formerly ASM) receives a request or response, it compares the content against the signatures associated with the policy and raises a violation on a match.

This is the negative-security half of a WAF policy: block what is known-bad. (The positive-security half — allow only known-good URLs and parameters — is lesson 4.) The GUI module is still literally labelled Security ▸ Application Security, and many screens and profiles still say "ASM" — that legacy module name lives on inside Advanced WAF.

You never manage thousands of signatures one by one. They are organised into signature sets, and you assign sets to a policy. F5 ships the signatures in a pool and pushes updates roughly every six weeks.

② Signature sets — the unit you actually assign

You don't hang every wanted poster individually. You hang boards — "violent offenders", "fraud", "shoplifters" — and the right boards go up at the right station. In Advanced WAF a signature set is that board: a named group of attack signatures. You assign sets to a policy, not single signatures. Sets keep the policy maintainable and let an F5 signature update drop new members straight into the set you already trust.

System-supplied signature sets

F5 ships many predefined sets. The ones you meet first:

• Generic Detection Signatures — broad coverage of well-known web and application attacks. This is the all-rounder set most policies start with.
• SQL Injection Signatures — attempts to inject SQL statements (the ' OR 1=1-- family).
• Cross Site Scripting Signatures — forcing a site to echo attacker-supplied executable script (<script>…).
• Command Execution Signatures and Path Traversal Signatures — OS command injection and ../-style attempts to reach files outside the web root.

Sets can be filter-based (membership is defined by attributes like attack type, system, or risk, so new signatures auto-join) or manual (you hand-pick members). You can also build a user-defined set for your own apps.

Assigning a set to a policy

When you attach a set you also choose its default blocking actions — Learn, Alarm and Block — which take effect when you associate the set with a new policy. Learn surfaces the match on the Traffic Learning screen, Alarm logs it, Block drops it (only when the policy is in Blocking mode). We unpack Alarm vs Block in Path 4.

③ Staging & enforcement — the rookie-cop period

Here is the analogy that makes this lesson stick. A new attack signature is a rookie cop. For the first stretch of duty the rookie can only observe and write reports — never make an arrest. That probation exists so a rookie who'd wrongly cuff your own staff is caught before any real damage. That probation is staging.

What staging does

Staging means the system applies the attack signatures to live traffic but does not apply the blocking policy action to requests that trigger them. A staged signature still sees every match — it just records the request as a learning suggestion instead of dropping it. Its whole purpose is to reduce the violations caused by false-positive matches before any signature can block a real user.

The Enforcement Readiness Period (default 7 days)

How long is probation? It's the Enforcement Readiness Period, set in the policy's properties — default 7 days. New and updated signatures stay in staging for this window. Each day, signatures that have passed the period with no problems become Enforcement Ready and appear in the Enforcement Readiness Summary.

Staging → enforced (this never happens by itself)

This is the #1 trap. "Enforcement Ready" does not mean "now blocking". It means "the period elapsed — it's safe for you to enforce." You still take the action:

• Review the staged hits / learning suggestions. A signature matching only your legitimate traffic is a false positive → disable it. A signature matching real attacks → enforce it.
• Enforce — clicking Enforce (or Enforce Ready Entities) removes the signature from staging and puts the blocking policy into effect for it.
• Apply Policy. Like everything in Advanced WAF, the change is staged in the editor until you Apply.

Until you enforce and apply, a signature past its readiness period still only logs. Many "the WAF won't block" tickets are exactly this — staged signatures nobody enforced.

The four states a signature lives in — tap each card

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

④ Alarm vs Block flags & signature updates

Two things decide whether a matched signature actually stops a request: its state (Path 3 — enforced, not staging) and its flags (this section). Get either wrong and the WAF "doesn't block".

Alarm vs Block — two independent flags

In the Attack Signatures list each signature carries two checkboxes:

• Alarm — the policy logs the request data if a request matches the signature. You get a violation entry and a support ID — but the request still goes through.
• Block — the policy blocks all requests that match the signature. You can only enable Block when the policy enforcement mode is Blocking — and the signature must be enforced (not staging) for it to bite.

So the chain to an actual drop is: policy in Blocking mode → signature enforced → Block flag ticked. Miss any link and you only Alarm. (Whether the policy as a whole should go Blocking is the global go-live decision — that's lesson 10.)

Signature updates — and why they re-stage

F5 ships signature updates roughly every six weeks. Two modes:

• Scheduled — pick an Update Interval and the box pulls updates automatically (needs external network access and a current service-check date).
• Manual — choose a Delivery Mode: Automatic (fetch directly from F5) or Manual (upload a signature-update file from F5 — for air-gapped systems). On 14.1.x and later this is the Live Update workflow.

The catch every junior misses: when staging is on, updated signatures go back into staging for the Enforcement Readiness Period — the new logic is vetted before it blocks. So right after an update, some previously-blocking signatures briefly only log again. That's intended; review the new suggestions, then re-enforce.

root@(bigip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify asm policy /Common/app_pol \
  signature-staging enabled \
  signature-settings { signature-staging enabled }
# Assign the system-supplied sets in the GUI (Attack Signatures Configuration), then:
list asm policy /Common/app_pol enforcement-readiness-period

asm policy /Common/app_pol {
    enforcement-readiness-period 7
    signature-staging enabled
}
# 7-day readiness window confirmed; new/updated signatures will stage before they block.

root@(bigip01)(tmos)# show asm policy /Common/app_pol signatures staged
# (read the staged list + their learning suggestions in the GUI Readiness Summary)

root@(bigip01)(tmos)# modify asm policy /Common/app_pol signatures enforce-readiness
root@(bigip01)(tmos)# modify asm policy /Common/app_pol apply

Enforcement readiness applied: 412 signatures enforced, 3 left disabled (false positives).
Policy /Common/app_pol applied. Active.
# Enforced signatures with Block ticked now drop matches; the 3 disabled ones never block your app.

root@(bigip01)(tmos)# show asm policy /Common/app_pol signatures \
  signature-id 200002001
# then read the request in the Event Log by support ID

2026-06-02 14:22  src 203.0.113.7  vs 10.10.20.5:443
  Signature: SQL-INJ "OR 1=1" (200002001)  Set: SQL Injection Signatures
  State: enforced   Alarm: yes   Block: yes   Mode: Blocking
  Result: BLOCKED   Support ID: 18007244126553882151
# If Result = Alarmed → Block flag is off. If State = staging → enforce it first.