Key takeaways
- A cloud WAAP migration succeeds or fails on application inventory and cutover sequencing, not on the WAF policy itself.
- Every application should go live behind a cloud WAAP in monitoring mode and move to blocking only after its own traffic has been reviewed and tuned.
- Origin servers must accept traffic only from the WAAP provider, otherwise attackers can bypass the new protection by connecting to the origin directly.
- TLS compatibility must be tested on both legs of a cloud WAAP deployment, from client to edge and from edge to origin, before any DNS change.
- WAAP security logs should be flowing into the SIEM through a tested pipeline before blocking is enabled, so the SOC can see what the platform is doing.
Moving from an on-premises WAF (web application firewall) to a cloud platform for web application and API (application programming interface) protection, known as a cloud WAAP, is mostly a migration project, and only partly a security policy project. After onboarding roughly 112 applications to F5 Distributed Cloud (XC) for a leading Sri Lankan private bank, my clearest lesson is that inventory, DNS (Domain Name System) sequencing, TLS (Transport Layer Security) compatibility and origin lockdown decide the outcome long before the first attack is blocked. Get those right, go live in monitoring mode, tune against real traffic, and only then switch to blocking.
Why do cloud WAAP migrations go wrong?
Most of the problems I have dealt with were not caused by the WAAP engine. They came from things the organisation did not know about its own estate: a forgotten subdomain, a partner integration pinned to an old IP address, an API that the mobile app calls but nobody listed, or a legacy client that can only negotiate an outdated TLS version.
I saw the same patterns while deploying Imperva WAAP, API security and Advanced Bot Protection across around 120 applications for a global apparel manufacturing group headquartered in Sri Lanka. Different platform, different industry, same lessons. Nothing below is unique to an F5 Distributed Cloud migration, which is why I treat it as platform-neutral.
What should a WAAP migration inventory include?
The inventory is the migration plan. If a column is empty, the cutover for that application is not ready. For each application I want:
- Every hostname it answers on, and who controls the DNS zone
- The current certificate, who renews it, and whether the private key can be moved
- Origin IP addresses and the network path from the internet
- Client types: browsers, mobile apps, partner systems, machine-to-machine calls
- Authentication method, including any mutual TLS (mTLS) with partners
- A business owner and a technical owner, by name
- Peak periods and approved change windows
- Existing WAF exceptions, and why each one exists
The column most often left blank is client types. That is exactly where hidden APIs and fragile legacy integrations live.
How should you sequence DNS cutovers?
I plan in waves, from low business risk to high, so the team builds a repeatable runbook before it touches the channels customers depend on most. Lower the DNS TTL (time to live) well before each cutover so that a rollback takes effect quickly. Check for apex domains early too: a bare domain usually cannot be a CNAME (canonical name) record, so it needs a different approach with your DNS provider.
| Wave | Typical applications | Why this order |
|---|---|---|
| 1 | Marketing and informational sites | Low transaction risk; proves the DNS, certificate and logging workflow |
| 2 | Internal and partner portals with known users | Users report problems quickly; exercises authentication flows |
| 3 | Customer portals and public APIs | Higher traffic; needs tuned policies and bot rules |
| 4 | Core transactional channels | Only once the runbook has been proven many times |
Why test TLS in both directions?
A cloud WAAP introduces two TLS connections where there used to be one: client to edge, and edge to origin. Each fails in its own way.
On the client side, the risk is older clients: partner systems on dated Java or .NET runtimes, older Android devices, or embedded systems that cannot negotiate the protocol versions and cipher suites the new edge offers. On the origin side, it is the reverse: origin servers with old cipher suites, incomplete certificate chains, expired or self-signed certificates, or an origin that requires SNI (Server Name Indication) values the edge has not been configured to send.
TLS compatibility was one of the areas that needed real troubleshooting time during the bank migration. My practice now is to test both legs for every application before any DNS change, and I ask partner teams directly which TLS versions their integrations use rather than assuming.
How do you stop attackers bypassing the WAAP to reach the origin?
If the origin still accepts traffic from anywhere, the WAAP is optional for an attacker. Historical DNS data and certificate transparency logs make forgotten hostnames and old origin addresses easy to find.
Origin protection has three parts:
- Restrict inbound traffic at the origin firewall to the WAAP provider’s published address ranges, or use private connectivity if the platform offers it.
- Add a second check an attacker cannot guess, such as mTLS between edge and origin or a secret header validated at the origin.
- Retire or repoint old DNS records that still resolve directly to the origin, including “dr”, “old” and “test” style hostnames.
Do this wave by wave, not at the end. An application that sits behind the WAAP but is still reachable directly has not really been migrated.
Why start in monitoring mode before blocking?
Every application should go live in monitoring mode. I do not set a fixed number of days for this. I wait until the application has seen a full business cycle, including month-end processing, salary dates, statement runs and any campaign traffic, because that is when unusual but legitimate requests appear.
When is an application ready for blocking mode?
These are the exit criteria I use for staged blocking:
- Its security events are reaching the SIEM (security information and event management) platform, and someone has reviewed them.
- Every triggered signature has been classified as an attack, a false positive, or needing input from the application owner.
- False positives are handled with narrowly scoped exceptions, not by disabling signatures globally.
- The application owner has tested key functions through the edge, including login, search, file upload and payments.
- API endpoints seen in traffic have been added to the inventory.
- Rollback steps are written down, and the person who can execute them at 2 a.m. knows it.
- The business owner has approved the change window.
How do you tune WAF false positives without weakening protection?
False positives cluster in predictable places: rich-text editors, JSON (JavaScript Object Notation) bodies containing code-like strings, Base64-encoded payloads, long cookies, and free-text fields where names and addresses include apostrophes. The fix is almost never to switch a protection off. Scope each exception to the specific signature, the specific parameter and the specific path, record why it exists, and review it whenever the application changes.
How do you find the APIs hiding inside web applications?
Many applications listed as “websites” are really front ends to JSON APIs, and the same back ends often serve the mobile app and partner integrations. Most WAAP platforms, including the ones I deploy, can discover API endpoints from live traffic. Use that discovery during the monitoring period, then compare it with what the development teams believe they have published.
The OWASP (Open Worldwide Application Security Project) API Security Top 10 2023 is a useful lens. Improper Inventory Management (API9:2023) is precisely the problem that discovery addresses. Broken Object Level Authorization (API1:2023), by contrast, is something a WAAP can rarely detect, because the malicious request looks valid. That one has to be fixed in the application.
How should bot rules be set up during a migration?
Bot mitigation works best when it is attached to business flows rather than individual paths: login, one-time password (OTP) requests, registration, password reset and application forms. Start in monitoring mode here too, and list the automation you want to keep, such as uptime monitoring, search engine crawlers on public pages, partner aggregators and your own test tooling. Browser-based challenges do not run inside a native mobile app, so mobile traffic usually needs the platform’s mobile SDK (software development kit) or a separate approach.
Why get WAAP logs into the SIEM first?
On one engagement I integrated F5 security logs into a Trellix SIEM through Logstash, and the issue that needed real troubleshooting was not parsing. It was backpressure: when the output side could not keep up, the pipeline slowed and events queued up or arrived late. The lessons from that troubleshooting are straightforward. Size the pipeline for attack-day peaks rather than average volume, use persistent queues where the design allows, monitor the pipeline itself, and agree the fields and use cases with the SOC (security operations centre) before go-live rather than after.
How do you plan rollback and ownership?
Rollback should be boring: revert DNS on a short TTL, keep the previous certificates valid, and keep the old WAF or load balancer configuration in place until the application has been stable for an agreed period. Just as important is a clear RACI (responsible, accountable, consulted, informed) for each step, covering the application owner, network team, security team, SOC, and the platform vendor or integrator.
For organisations considering web application and API protection in Sri Lanka, particularly banks, the migration also has a compliance side: regulators increasingly expect documented change control, third-party risk assessment for cloud services, and evidence of security monitoring. Good migration artefacts, such as the inventory, runbooks, approvals and log integration, double as that evidence. In Gulf Cooperation Council (GCC) markets and elsewhere, confirm early where TLS is terminated and where logs are stored, because data residency questions tend to arrive late if nobody raises them.
Where to start
Pick five applications from your first wave. Fill in every inventory column, test TLS on both legs, lock down their origins, put them into monitoring mode and confirm their events reach the SIEM. If any of those steps is hard for five applications, it will be much harder for a hundred.
Want a second opinion on your own environment? Book an assessment call or talk to the Innov8 AppSec team about implementation.