Looking at Imperva's Cloud WAF for a PCI DSS 4.0 audit. Their dashboard shows compliance "status," but our QSA wants raw evidence from logs for controls like 6.4.3 (public-facing web apps), 11.4 (IDS/IPS), and 11.6 (WAF). The pricing page mentions "advanced analytics," but it's vague on structured reporting.
Has anyone built a process to extract and format Imperva logs for a PCI audit report? I'm trying to avoid manual screenshots of the portal.
Specifically:
* Which log types (Security Events, Audit Logs, Incidents) are most critical for PCI?
* What's the best export method? SIEM integration, direct API pull to S3, or their built-in reports?
* Any gotchas with log field mapping to PCI requirements? For example, proving a blocked attack needs specific fields (timestamp, source IP, rule ID, threat signature).
I'm reverse-engineering the cost too. If we need to push logs to a SIEM for 365-day retention, does that blow up the data ingestion fees compared to using Imperva's own storage? My spreadsheet shows their extended retention add-on might be cheaper than Splunk ingest for high-volume apps, but the data schema matters for reporting.
I'm dealing with this exact pressure right now. For PCI 11.6, we had to show the WAF was actively blocking. Our QSA was strict about the fields too, like you said. We used the Security Events log, focusing on 'block' actions.
The API to S3 route was cheaper for us than their extended retention, but you have to build the formatting yourself. I scripted a daily pull using Terraform to trigger a Lambda that fetches via API and parses to JSON. The tricky part was mapping their 'security_rule_name' to a PCI control description for the report.
Did you run into schema changes breaking your process? I'm nervous about that.
Yeah, schema changes are a real headache. I'm pulling logs into Grafana via Loki and had a dashboard break when they added a new field. I set up a simple alert now that triggers if the log volume for the 'security_events' stream drops suddenly, which usually means the ingestion broke. Not perfect, but it's a start.
What do you use to test your Lambda parsing after an Imperva update?
You're already building a spreadsheet for cost. Good.
Why not just skip Imperva's logs entirely? Use a free WAF like Coraza with modsecurity audit logs. The logs are already structured for PCI reporting. No API fees, no surprise schema changes, and you own the data path.
For PCI 11.6, your evidence is just a log line showing a block. You can generate that for zero dollars. The real cost is engineering time to parse proprietary formats.
linux is free
Volume drop is a weak signal. It doesn't catch silent failures like schema changes that still produce logs.
You need to validate the log structure, not just count rows. Add a canary test. Ingest a known good log line with every pull and check if the parsed fields exist and match expected values. If the canary fails, your pipeline broke.
What's your validation step?
If it's not a retention curve, I don't care.