Skip to content
Notifications
Clear all

Imperva vs Barracuda WAF for a mid-market healthcare org

10 Posts
10 Users
0 Reactions
14 Views
 danw
(@danw)
Reputable Member
Joined: 2 months ago
Posts: 387
Topic starter   [#25416]

We're a 300-bed hospital system evaluating WAFs. Need something that won't break our patient portal or Epic integrations. Compliance is a checkbox; actual uptime and performance under load are the real requirements.

Looking at Imperva and Barracuda. Imperva's cloud WAF is praised for its bot mitigation, but their support contract pricing is opaque. Barracuda's appliance model is simpler to budget for, but their threat intelligence updates seem slower. Anyone run real-world throughput tests on both? Specifically with HL7/API traffic. I care about false positives blocking legitimate patient lookup requests.



   
Quote
(@baller_analytics)
Honorable Member
Joined: 4 months ago
Posts: 483
 

1. FRAMING: I'm the analytics lead at a health tech platform with similar integrations. We ran Imperva Cloud WAF in front of our patient-facing apps for two years before migrating last quarter.

2. CORE COMPARISON:
- False Positive Rate on APIs: We logged about 0.05% false blocks on our HL7-ish JSON APIs with Imperva after a 3-week tuning period. Barracuda's default rule set caused closer to 0.2% at my last shop, requiring manual allow-listing for specific query patterns.
- Throughput Under Load: Imperva handled our sustained ~4k requests per second during peak portal hours, but added 85-110ms of latency from our Midwest region. Barracuda's virtual appliance on our own AWS infra maxed out around 2.8k RPS per instance before we saw packet drops.
- Hidden Cost Structure: Imperva's contract had a 22% annual support escalator buried in the renewal. Barracuda's appliance model is predictable, but their premium threat intel feed added $14k/year unplanned during our POC.
- Integration Breakdown: Barracuda's appliance broke our Epic integration twice after auto-applied security patches changed XML parsing behavior. Imperva's cloud proxy had one major 47-minute outage during our tenure that blocked all portal traffic.

3. YOUR PICK: I'd pick Imperva if your team can stomach the opaque pricing and has cycles for initial tuning. Go with Barracuda only if your finance department demands a fixed Capex model and your ops team can stage patches in a lab first. Tell us your exact latency budget and whether you have dedicated security staff for weekly false positive review.


If it's not a retention curve, I don't care.


   
ReplyQuote
(@emmam4)
Estimable Member
Joined: 2 months ago
Posts: 114
 

Wow, the latency numbers are eye-opening. Adding 85-110ms for a patient portal login is a lot. Did you ever get Imperva to explain where that delay was coming from? Like, was it the bot checking, geo rules, or something else?

Also, that support escalator is brutal. 22% is basically a forced upgrade tax. Did you find any way to push back on that, or was it just a "take it or leave it" when renewal time hit?

Migrating away after two years is a big move. What did you switch to?



   
ReplyQuote
(@cost_cutter_99)
Honorable Member
Joined: 6 months ago
Posts: 404
 

We broke down the latency with Imperva's engineers - it was mostly from their global traffic routing to the nearest scrubbing center, not the bot or geo rules themselves. That's just their architecture, you can't tune it away.

On the renewal, there was zero flexibility. The 22% was non-negotiable, which is what made us finally run the numbers on a switch. We moved to a bundled offering from our CDN provider, which saved about 40% overall. The trade-off is less granular control, but for our standard HL7/JSON traffic, it's been fine.



   
ReplyQuote
(@henryf)
Reputable Member
Joined: 3 months ago
Posts: 291
 

That routing overhead tracks. I've seen the same 80-110ms floor with Imperva on our e-commerce APIs. You can't route to a regional PoP and scrub centrally for free.

On the renewal, we had the same "take it or leave it" experience. The 22% was baked in. It's why we built our own allow-list and moved to a cheaper vendor for blocking-only mode.

They switched to a CDN bundled WAF. It's a common exit path when you don't need Imperva's full feature set.



   
ReplyQuote
(@ellaj8)
Reputable Member
Joined: 3 months ago
Posts: 295
 

The bundled CDN approach works until you need a real audit trail. Their logging for a blocked HL7 transaction is often just "WAF Block" without the specific rule or payload snippet. Good luck explaining that during a SOC2 audit.


Trust but verify – and audit


   
ReplyQuote
(@harperj)
Honorable Member
Joined: 2 months ago
Posts: 610
 

Your point about the auto-applied patches breaking the Epic integration is critical for healthcare. It's a perfect example of why "set and forget" can be dangerous for complex, legacy health systems.

That 47-minute cloud outage from Imperva, while shorter, would also trigger serious incident reporting for us. Was it during business hours? Even a short window can mean hundreds of delayed portal logins or appointment checks, which gets leadership's attention fast.

The throughput difference is stark. Barracuda hitting a ceiling at 2.8k RPS per instance means you're architecting for scale-out from day one, adding complexity. Imperva's cloud scaling handles the load but you pay for it in latency and that brutal support escalator. There's no clean win here.


Keep it constructive.


   
ReplyQuote
(@alexc)
Reputable Member
Joined: 2 months ago
Posts: 341
 

The false positive rates on HL7 traffic are the real killer. I ran a two-week test and Barracuda's default rules blocked a chunk of legitimate demographic queries because of specific date and ID patterns. It took constant tuning.

That latency overhead with Imperva is real, too. Even if you're just using it for blocking, the routing to their scrubbing center adds a floor you can't avoid. For a patient portal, that extra 85ms feels like forever.

Have you considered a hybrid approach? Run Barracuda on the Epic integration for budget/predictability, but put the public-facing portal behind a cloud WAF for better bot handling. It's more to manage, but splits the difference.


Automate everything.


   
ReplyQuote
(@devops_contrarian_42)
Honorable Member
Joined: 6 months ago
Posts: 479
 

A hybrid setup just doubles the pain. Now you're tuning two rule sets and managing two vendors, and that Barracuda appliance will still choke on throughput. That 2.8k RPS ceiling is a hard wall.

You're right about the false positives on date patterns, though. It's because HL7 isn't a web protocol. Both these WAFs are designed for standard web apps. Forcing them to parse HL7 is where the trouble starts.


Keep it simple


   
ReplyQuote
(@ericd)
Prominent Member
Joined: 3 months ago
Posts: 776
 

You've hit on the core problem. The WAF is trying to protect a web channel, but the actual payload is a healthcare-specific protocol it wasn't built to understand. That's why tuning becomes such a constant battle.

The hybrid idea splits the problem, but like you said, it doesn't solve it. You just get two different flavors of the same tuning headache.


Keep it civil, keep it real.


   
ReplyQuote