Ravindu FernandoApplication Security Consultant
Free scorecardBook a call

Case study · Banking

112 bank applications moved to cloud WAAP, wave by wave

I led the move of roughly 112 web applications and APIs at a leading Sri Lankan private bank to F5 Distributed Cloud WAAP, taking each one from monitoring to blocking.

A leading Sri Lankan private bank

Banking112applications migratedClient name under NDA

The setup

The architecture, simplified.

  • A leading Sri Lankan private bank moving its web applications and APIs to cloud WAAP.
  • Platform: F5 Distributed Cloud. Delivered by Innov8’s Application Security BU, which I head.
  • Scope: inventory, DNS cutover order, TLS, origin protection, false-positive tuning and rollback.
Customersweb, mobile and APIsBots & attacksSQLi, stuffing, floodsCloud WAAPF5 Distributed Cloud~112 apps, in wavesOriginslocked to the WAAPTuning loopmonitor, then block
Clean trafficBlocked at the edgeFalse-positive tuning

The challenge

What made this hard.

  • An estate nobody had fully listedHostnames, partner integrations and API calls had to be found and owned before any DNS record could change.
  • TLS on two legs, not oneClient to edge and edge to origin each fail in their own way. TLS compatibility needed real troubleshooting time.
  • Origins that could be bypassedAny origin still open to the internet lets an attacker skip the new edge. Lockdown had to be part of the migration.
  • Blocking without breaking bankingSwitching every application to blocking at once would risk outages on channels customers use every day.

The approach

How the work ran, step by step.

  1. 01

    Inventory and wave plan

    Every hostname, certificate, origin, client type and owner recorded, then applications grouped into waves from low to high business risk.

    • Hostnames, DNS zones and certificate owners
    • Client types, including partners and mobile
    • Waves ordered by business risk
  2. 02

    TLS and origin readiness

    Both TLS legs tested for each application before any DNS change, and origins restricted to accept traffic only from the WAAP.

    • Client-to-edge and edge-to-origin TLS tests
    • Origin firewall limited to provider ranges
    • Old direct DNS records retired
  3. 03

    Cutover in monitoring mode

    Each wave cut over on a lowered DNS TTL and went live in monitoring mode, with rollback steps written down and owned.

    • TTL lowered ahead of each cutover
    • Rollback runbook with a named owner
    • Owners test key functions via the edge
  4. 04

    Tuning against real traffic

    Every triggered signature classified as attack or false positive, with exceptions scoped to one signature, parameter and path.

    • A full business cycle observed per app
    • Narrow exceptions, no global disables
    • APIs seen in traffic added to inventory
  5. 05

    Staged blocking

    Each application switched to blocking once its exit criteria were met and its business owner approved the change window.

    • Security events confirmed in the SIEM
    • Business owner sign-off per application

The outcome

What changed.

Real numbers only where they exist. Everything else is stated plainly, without invented percentages.

  • 112Applications migratedRoughly 112 web applications and APIs onboarded to F5 Distributed Cloud WAAP.
  • Monitoring to blockingApplications moved from monitoring to blocking in waves, not in one big cutover.
  • Origin protection in scopeOrigin lockdown handled as part of the migration, so the new edge is not optional for an attacker.
  • A runbook that repeatsInventory, runbooks and rollback steps that double as change-control evidence for the bank.

Lessons

What I would tell the next team.

  1. Lesson 01

    The inventory is the migration plan

    If a column is empty, that application is not ready to cut over. Client types is the column most often blank, and it is where hidden APIs live.

  2. Lesson 02

    Lock the origin wave by wave

    An application behind the WAAP but still reachable directly has not really been migrated. Do origin lockdown per wave, not at the end.

  3. Lesson 03

    Earn blocking with evidence

    Monitor through a full business cycle, tune with narrow exceptions, confirm events reach the SIEM, then block. The runbook is what makes it fast.

Related

Where this experience shows up in my work.

FAQ

About this case

Ask me something else
How do you move 100+ applications to a cloud WAAP safely?

In waves, ordered from low to high business risk, so the runbook is proven before core channels move. For each application I complete the inventory, test Transport Layer Security (TLS) on both legs, lock down the origin and cut over the Domain Name System (DNS) record on a short time to live. It then runs in monitoring mode, and blocking follows only once real traffic has been reviewed and tuned.

What causes most problems in a cloud WAAP migration?

Rarely the web application firewall (WAF) engine itself. The problems come from what an organisation does not know about its estate: forgotten subdomains, partner integrations pinned to old addresses, undocumented application programming interfaces (APIs) and legacy clients that cannot negotiate modern Transport Layer Security (TLS). On this bank programme, TLS compatibility needed real troubleshooting time. A complete inventory and two-leg TLS testing prevent much of it.

Was this an assessment or a delivery project?

A delivery project. Innov8’s Application Security Business Unit carried it out, and I led it as head of that unit. That hands-on work is why my edge protection assessments look first at inventory, origin exposure and the path from monitoring to blocking. Execution is never assumed: if you need help after an assessment, it is scoped case by case with your own team, a partner or Innov8.

More case studies

Facing something similar?

Let’s look at your version of this problem.

A free 30-minute call to see whether an assessment would help, and what it would cover for your estate.

Book a callWhatsAppProfile PDF