ASM False Positives on a JSON API While Keeping Checkout Blocking
A retail platform runs BIG-IP ASM 16.1.4 on the same instance as LTM. The security policy api-prod protects api.example.com (virtual server 10.20.5.10:443, pool of eight Node.js servers) and was built by Automatic Policy Builder from 21 days of staging traffic totaling 1.1 million requests. It is now in Blocking enforcement mode with Signature Accuracy set to Medium and Learning Mode set to Manual. Production volume is 2,400 requests per minute. In the first 24 hours, 6.2% of POST /api/v2/orders and 14% of PUT /api/v2/profile calls returned HTTP 403 with support IDs. The event log shows three violation families: an attack signature for SQL injection on the free-text JSON parameter delivery_note; a JSON schema violation because the mobile client sends an extra gift_wrap property; and an illegal meta-character violation on notes. Three other support IDs contain obvious ' OR 1=1-- payloads. PCI DSS requires blocking on /api/v2/checkout, and the only change window is 30 minutes tonight. There is no staging environment that carries production-like traffic.
1. How do you separate these 403s into false positives and true attacks using the support IDs, and what evidence do you require before changing the policy?
Read the worked answer
Start from the support ID, not from the violation name. In ASM event logs, open each support ID and record the violated parameter, signature ID and accuracy, violation rating, source IP, user agent, and whether the request matches a learning suggestion. A false positive usually has a benign payload that repeats across many users and often appears in the learning suggestions as a new parameter or value. A true attack tends to cluster on one source, use encoded or obfuscated payloads, and trigger multiple violations.
For delivery_note, inspect the actual value. If it contains ordinary delivery instructions and the SQL injection signature is the only hit, treat it as a candidate false positive and confirm that the parameter is documented free text. For gift_wrap, the mobile client is sending a legitimate new property; the learning suggestion should propose adding it, which is strong evidence of a schema false positive. For notes, the meta-character rule may be too strict if the field legitimately accepts punctuation. The three ' OR 1=1-- requests are true positives; do not weaken those signatures. Before editing, export the policy and preserve the exact request samples so the change can be justified and rolled back.
2. Within the 30-minute window, what exact policy changes would you make, and how do you keep `/api/v2/checkout` in blocking mode?
Read the worked answer
Make parameter-scoped changes, not global ones. For gift_wrap, accept the learning suggestion that adds the property to the JSON schema for POST /api/v2/orders rather than disabling JSON validation. For delivery_note, add an attack-signature exception for that parameter only, and only if the sample review confirms free text; keep the signature active on every other parameter. For notes, allow the required meta characters in the parameter's value definition, or add a narrow exception, rather than turning off the illegal-meta-character violation. Do not change Signature Accuracy from Medium to Low and do not move the whole policy to Transparent.
Keep /api/v2/checkout untouched: verify in the URL list that it has no parameter exceptions, and use Policy Diff after each change to confirm the checkout URL has zero differences. If per-URL enforcement mode is available in 16.1.4, keep checkout in Blocking while the API URLs remain in Blocking with the new exceptions; if not, the parameter-level exceptions are the safer mechanism. Apply changes one at a time and take a policy backup immediately before the first change.
3. What monitoring and rollback criteria would you set for the next 48 hours?
Read the worked answer
For 48 hours, monitor the 403 rate per URL, the count of each support ID, and the true-positive rate reported by the SOC. Set a rollback trigger: if the 403 rate on /api/v2/orders does not fall below 0.5% within two hours, or if any checkout request is allowed that previously triggered a high-accuracy SQL injection signature, revert to the backup policy. Send ASM events to the SIEM with request details so the SOC can mark false positives quickly. Use the Enforcement Readiness report and the Request Log to compare the blocked set before and after. Also watch pool member health and 5xx rates, because a policy change that removes a blocking rule can increase load on the Node.js tier.
Document each exception with the support IDs that justified it. After 48 hours, re-enable full blocking for any parameter whose exception was not used, and schedule a policy review so temporary exceptions do not become permanent.