Expertise 04 · Monitoring
Make sure your SOC sees an application attack while it happens
I have piped WAAP logs into a bank’s SIEM and fixed the backpressure that delayed them. I check what reaches your SOC, how fast, and who acts on it.
In short
Application security monitoring means collecting security events from the edge, applications, APIs (application programming interfaces) and mobile apps, delivering them reliably to a SIEM (security information and event management) platform, and turning them into detections someone owns. I assess log coverage, pipeline health under load, detections for application attacks, and whether the SOC (security operations centre) knows what to do when one fires.
What I check
- Security log coverage: edge, app, API and mobile
- SIEM pipeline health, lag and dropped events
- Field mapping agreed with the SOC
- Detections for application-layer attacks
- Alert ownership and escalation to app teams
- Log retention and where logs are stored
The threats
What this area has to stop.
The attacks I see most often in this area, and what they cost when they land.
Open the attack simulator- Threat 01Events delayed by backpressureDuring an attack, log volume spikes, the pipeline queues and events arrive too late to act on.Detection after the damage is done
- Threat 02Slow exfiltration nobody noticesValid API calls drain data over weeks, each one too ordinary to raise an alert.Breach found by a customer or regulatorSee which layer stops it
- Threat 03Stuffing seen only at the edgeBot traffic is logged by the WAAP but never correlated with logins and fraud cases.Account takeovers treated as one-offsSee which layer stops it
- Threat 04Hooking alerts never reviewedThe mobile app reports hooking and tampering, but the events stay in a vendor console.Fraud signals missed before a transferSee which layer stops it
- Threat 05Injection attempts without contextAttacks are logged without user, session or app context, so nobody can tell if one succeeded.Investigations that cannot concludeSee which layer stops it
The defences
How good looks, layer by layer.
- 01Edge telemetryWAAP, bot and CDN events show attacks probing your applications from the internet.WAF events, bot verdicts, DDoS alerts
- 02Application and auth logsLogins, privilege changes and business events show what an attacker did once inside.Auth events, transactions, admin actions
- 03Log pipelineCollects, parses and delivers events reliably, even at attack-day volumes.Shippers, persistent queues, parsers
- 04SIEM correlationJoins events across sources into detections tied to real attack paths.Correlation rules, use cases, enrichment
- 05SOC responseGives every alert an owner, a runbook and a route to the application team.Runbooks, escalation paths, tickets
Maturity
Where are you on the staircase?
Four levels I use to score this area. Most improvement plans aim one step up within a year.
- L0Dark
- WAF and app logs stay on the systems that made them
- Attacks found by customers, partners or auditors
- L1Collected, not used
- Logs reach the SIEM, but parsing is partial
- No detections written for application attacks
- L2Detecting
- Pipeline monitored; fields agreed with the SOC
- Detections for stuffing, injection and API abuse
- L3Correlated and owned
- Edge, app, mobile and fraud signals correlated
- Every alert has an owner, a runbook and a test
Measure it
Four numbers worth tracking.
- KPI 01Critical apps with logs in the SIEMShare of critical apps whose edge and application events arrive in the SIEM, parsed.
- KPI 02Pipeline lag at peakDelay between an event and its arrival in the SIEM when volume spikes, not on a quiet day.
- KPI 03Live app attack detectionsDetections in production for stuffing, injection, API abuse and other application threats.
- KPI 04Alerts with a named ownerAn alert without an owner is just a log entry. Track until every rule has one.
Frameworks I assess against
- NIST CSF 2.0
- MITRE ATT&CK
- OWASP Logging Cheat Sheet
Work with me
How I can help with this area.
- WAAP & 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.2–4 weeksFixed fee
- Application 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.1–3 weeksFixed fee
- AppSec maturity assessmentI score your application security practices against OWASP SAMM v2 using evidence, not opinion, then turn the gaps into a roadmap your board can fund.2–3 weeksFixed fee
- Application security logging checklistWhat applications should log, how events reach the SIEM reliably, and who acts on them.Free · interactive
Proof from delivery
- SIEMtelemetry pipelineWAAP security events arriving in the bank’s SIEM, reliablyBanking · A leading Sri Lankan private bankF5 → Logstash → Trellix SIEMRead the case
- 112applications migrated112 bank applications moved to cloud WAAP, wave by waveBanking · A leading Sri Lankan private bankF5 Distributed CloudRead the case
Why should WAF logs go to the SIEM?
A WAF (web application firewall) sees attacks on your applications before anything else does, but on its own it cannot connect them to logins, transactions or other systems. In the SIEM (security information and event management) platform those events can be correlated, so the SOC (security operations centre) sees a credential stuffing wave or an injection campaign as one incident, not scattered noise.
What is backpressure in a log pipeline?
Backpressure happens when the output side of a log pipeline, such as the SIEM (security information and event management) platform, cannot accept events as fast as they arrive. The pipeline slows, and events queue up, arrive late or are dropped. It tends to appear exactly when volume spikes, during an attack. Size for peak volume, use persistent queues and monitor the pipeline itself.
Which application events should be logged for security?
At minimum: logins and failures, password and MFA (multi-factor authentication) changes, privilege and role changes, access to sensitive records, high-value transactions, admin actions and input validation failures. Each event needs a timestamp, user, session, source address and outcome. Never log passwords, tokens or full card numbers. Agree the fields with the SOC (security operations centre) before go-live.
How can we tell if the SIEM would catch an application attack?
Test it. Run a controlled, agreed simulation, such as a burst of failed logins or a blocked injection attempt, and follow the events from source to SIEM (security information and event management) alert. Measure how long each step takes, check that the fields arrive parsed, and confirm someone in the SOC (security operations centre) picks it up. Gaps show up quickly.
Do you only work with Trellix SIEM?
No. Ravindu Fernando, a Colombo-based application security consultant, integrated F5 edge security logs into a bank’s Trellix SIEM (security information and event management) platform through Logstash, including fixing pipeline backpressure, and has deployed Datadog in production. The assessment is platform-neutral: coverage, pipeline health, detections and ownership matter the same way anywhere.