Case study · Banking
WAAP security events arriving in the bank’s SIEM, reliably
I led the integration of F5 WAAP security logs into a leading Sri Lankan private bank’s Trellix SIEM through Logstash, and fixed the pipeline backpressure that delayed events.
A leading Sri Lankan private bank
- F5 → Logstash → Trellix SIEM
- Monitoring & visibility
- Edge & WAAP
The setup
The architecture, simplified.
- A leading Sri Lankan private bank protecting its web applications with F5 WAAP.
- Goal: WAAP security events in the bank’s Trellix SIEM, so the SOC can see application attacks.
- Delivered by Innov8’s Application Security BU, which I head and led for this work.
The challenge
What made this hard.
- Backpressure, not parsingWhen the output side could not keep up, the pipeline slowed and events queued up or arrived late.
- Attack days are not average daysEdge log volume climbs when the bank is under attack, which is exactly when the SOC needs events fastest.
- Fields the SOC can useWAAP logs only help if their fields map to the detection use cases analysts actually run.
The approach
How the work ran, step by step.
- 01
Pipeline design
Designed the route from F5 through Logstash to the Trellix SIEM, with fields agreed against the SOC’s use cases.
- F5 security log export
- Logstash parsing and field mapping
- 02
Integration
Connected the F5 log stream through Logstash into the Trellix SIEM and checked that events arrived parsed.
- Trellix SIEM ingestion
- Test events checked end to end
- 03
Backpressure troubleshooting
Traced late and queued events to an output side that could not keep up, then resolved the backpressure.
- Bottleneck traced to the output stage
- Queueing and throughput adjusted
- 04
SOC visibility
Confirmed the SOC could see WAAP events in time to act, and that the pipeline itself is watched.
- Pipeline lag and queues monitored
- Events visible to SOC analysts
The outcome
What changed.
Real numbers only where they exist. Everything else is stated plainly, without invented percentages.
- Events arriving reliablyBackpressure resolved, so WAAP security events now arrive in the SIEM reliably.
- Edge attacks visible to the SOCWAAP security events now sit in the SIEM the SOC already works from, not only in the WAAP console.
- One pipeline, end to endF5 to Logstash to Trellix SIEM, designed as one route and tested from end to end.
Lessons
What I would tell the next team.
- Lesson 01
Size for attack-day peaks
Average volume is the wrong design target. The pipeline has to cope when the edge is under attack and logging hardest.
- Lesson 02
Monitor the pipeline itself
Use persistent queues where the design allows and alert on lag, so a silent backlog never looks like a quiet day.
- Lesson 03
Agree fields with the SOC first
Settle the fields and use cases with the SOC before go-live. Retrofitting them once events are flowing is slower and messier.
Related
Where this experience shows up in my work.
- Service · 2–4 weeksWAAP & API protection assessmentI review your WAF, WAAP, bot and API controls against your real estate and traffic, then show the gaps, the bypass paths and a safe route to blocking.
- Service · 1–3 weeksApplication architecture reviewI take one application or platform and trace every path from the internet to its data, then show which controls hold, which are missing and what to fix first.
What is backpressure in a SIEM log pipeline?
Backpressure builds when one stage of a log pipeline cannot accept data as fast as the stage before it sends it. In this bank’s pipeline, the output side could not keep up, so edge security events queued up or reached the security information and event management (SIEM) platform late. Sizing for attack-day peaks, using persistent queues where the design allows and monitoring the pipeline itself all help prevent it.
Why should WAAP logs reach the SIEM before blocking is switched on?
Blocking changes what customers experience, so the security operations centre (SOC) must be able to see what the edge platform is blocking and why. If the security information and event management (SIEM) platform is not receiving those events reliably, false positives and real attacks look the same: invisible. I treat a tested log pipeline as an exit criterion before any application moves to blocking.
Which edge security events does a SOC actually need?
The ones analysts can act on: attacks detected and blocked, the rule or signature that fired, the client address, the target host and path, and the policy mode at the time. Bot and application programming interface (API) events add context. Agree the fields and detection use cases with the security operations centre (SOC) before go-live, so analysts can act on events rather than just store them.
More case studies
- 112applications migrated112 bank applications moved to cloud WAAP, wave by waveBanking · A leading Sri Lankan private bankF5 Distributed CloudRead the case
- 120applications protectedAround 120 applications under WAAP, API and bot protectionManufacturing · A global apparel group headquartered in Sri LankaImpervaRead the case
- T1bank vulnerability programmeTier-1 bank scanning upgraded and extended to web applicationsBanking · A Tier-1 Sri Lankan commercial bankTenable Security CenterRead the case
- RASPin-app protection liveIn-app runtime protection live in a customer banking appBanking · A leading private bank’s mobile appZimperiumRead the case