Advanced WAF Across 25 On-Premises and 35 SaaS Applications
A retail chain has 60 web applications in PCI scope: 25 hosted on-premises and 35 delivered as SaaS, including its storefront platform and payment pages. It has purchased BIG-IP Advanced WAF for all 60 applications and deployed it on a pair of appliances in the data center. Six weeks after go-live, the on-premises applications in blocking mode generate roughly 1,800 false positives per week, concentrated in an order-management app that sends JSON payloads with embedded HTML. The 35 SaaS applications show no WAF events at all. A legacy order-entry application breaks whenever blocking is enabled on one specific URL, and the business has said that application cannot be unavailable during the peak season. The security team wants a plan, and the compliance deadline is in 90 days.
1. Why do the 35 SaaS applications have no WAF events, and what are the realistic options for protecting them?
Read the worked answer
The 35 SaaS applications generate no events because their traffic never traverses the BIG-IP. Users reach the SaaS provider directly; on-premises WAF can only inspect traffic that flows through it. No amount of policy tuning will change that.
The realistic options, in order of preference:
- F5 Distributed Cloud WAF as an edge proxy, with the SaaS application's custom domain CNAMEd to the Distributed Cloud endpoint. This works only where the SaaS provider supports a custom domain and permits fronting; several providers do not, and some prohibit it contractually. Check provider by provider.
- Provider-native controls plus documentation. Where fronting is not possible, document the shared-responsibility boundary, verify the provider's WAF and PCI attestation, and record the compensating controls. That is an honest position for an auditor.
- API-level protection for any integration endpoints the retailer itself exposes.
The important step is the audit conversation: re-scope the Advanced WAF entitlement to the applications it can actually protect, and explain the SaaS boundary before the compliance deadline rather than after. Selling 60 apps of WAF and protecting 25 is the outcome to avoid.
2. Design a tuning process for the 1,800 weekly false positives, and say which policy settings you would change first.
Read the worked answer
Treat the false positives as a data problem before a configuration problem.
Process: pull the ASM event log for a full week, group by application, URL, parameter, and violation type, and rank by business impact rather than count. An order-management endpoint hit 400 times a week matters more than an admin page hit twice. Review weekly with the application owner, who is the only person who can say whether a payload is legitimate.
Settings, in order:
- Run the affected URLs in transparent mode while learning, then move to blocking URL by URL - not policy by policy.
- Enable learning and accept suggestions only after review; automatic acceptance is how exceptions become permanent holes.
- For the JSON order-management app, add targeted parameter-level exceptions for the specific parameters that legitimately carry HTML, rather than disabling the XSS signature globally.
- Check the violation rating threshold and consider a staged enforcement curve so a single low-confidence violation does not block a checkout.
Document every exception with a reason and an owner. An undocumented exception is indistinguishable from a disabled control at audit time.
3. The legacy order-entry application breaks under blocking. How do you phase in enforcement without accepting the peak-season risk?
Read the worked answer
Do not enable blocking on that application before peak season, and do not pretend the risk is eliminated. Reduce it and make it visible.
Phase 1 - visibility. Enable the policy in transparent mode on the specific URL and let it learn through a full business cycle, including month-end.
Phase 2 - narrow blocking. Enforce on the parameters and violation types you have evidence for, keeping the riskiest signatures in transparent mode. Isolate the URL with a dedicated policy so a change there cannot affect the other 24 applications.
Phase 3 - compensating controls. While blocking is partial, add rate limiting, bot defence, and network ACLs in front of that URL, and log every request so an incident can be reconstructed.
Governance. Put the residual decision in writing: the application owner accepts that this URL is protected in transparent mode through peak season, with the specific compensating controls listed and a date to revisit. Give the auditors the same document. That is a defensible position; switching blocking off silently is not.