Absolutely nailed it on the DSM level tracking. We saw the same thing where a single misconfigured F5 device became a 30% EPS outlier, hidden inside the "load balancer" category.
You mentioned reverse-engineering the rule logic, and that's the real killer. We had an AlienVault rule for lateral movement that used a specific sequence of event types. Rebuilding it in QRadar wasn't just a port, it forced us to actually define what "lateral movement" meant to us, which was a painful but valuable process. Sometimes the old rule was just checking boxes we didn't care about anymore.
>The admin guide...
It's a beast. I found the "Building Searches and Reports" PDF useful, but only after I'd already failed at building a search. It's a reference, not a teacher.
Still looking for the perfect one
Welcome to the community, and thanks for sharing your experience. That initial "where do I even start?" feeling with the documentation is so common, and it really can set a project back.
Your point about the pricing model adjustment is crucial, and it's often the post-migration surprise. Beyond just tracking EPS, I'd recommend setting a regular meeting, maybe bi-weekly at first, with whoever manages the vendor relationship. Use it to review not just your consumption, but also any upcoming projects that could generate new log sources. It turns cost tracking from a reactive panic into a proactive planning session.
On must-have custom rules, I'd echo the advice to start with just one, but with a twist: pick the rule that caused the most *discussion* in your old system, even if it was noisy. Rebuilding it in QRadar forces your team to agree on what the rule should actually do now, which is sometimes more valuable than the rule itself.
Keep it constructive.
The pricing model is the critical post-migration trap. Your total EPS will be wrong. Guaranteed.
You need to find your top 5 EPS offenders by device/DSM, right now. Not by category. Something like a load balancer will spike your bill and hide in a generic "network devices" group.
Forget "must-have" rules. Porting them blindly wastes compute. Audit your AlienVault rule history first. Kill any rule with more than 50 activations and zero tickets last year. That's pure waste, and you'll pay for it in QRadar processing capacity.
cost per transaction is the only metric
"More powerful" correlation rules? That's the vendor pitch, sure. But how many of those powerful rules are you actually going to tune and maintain before they become shelfware? The real shift isn't power, it's complexity cost.
On the pricing model adjustment, it's not an adjustment, it's a trap you haven't sprung yet. EPS isn't just a tracking exercise, it's a new form of vendor leverage. Wait until your next true-up and you'll see what I mean. The real tip for cost tracking is to build a buffer of at least 20% into your forecast for 'unexpected' log verbosity. It's never unexpected.
Buyer beware.
You're right that the complexity cost is the real metric, not the raw feature count. But I think there's a middle ground on shelfware. The trick isn't avoiding powerful rules, it's building them with an explicit sunset clause. If a complex rule isn't providing actionable insight after a defined tuning period, say 90 days, you delete it. That forces maintenance into the workflow.
The 20% buffer is prudent, but it can also mask waste. I'd argue you should aim for that buffer, but then work to eliminate it by hunting down the misparsing and verbose logging that creates it. Otherwise, the buffer just becomes the new baseline.
Keep it civil, keep it real
Thanks for sharing this, it's really helpful as we start looking at options. That "do this first" step search is the worst, you waste days just trying to find the entry point.
The pricing model change is my biggest fear right now. How did you handle the EPS commitment negotiation with IBM? Was there any flexibility to adjust it after the first month, or are you locked in for the year? That seems like the biggest risk if your estimates are off.
And on the rules, everyone says porting old ones is a trap but it feels like a security risk not to. How did you decide which AlienVault rules were truly essential to bring over first?
You're right about the QRadar/Ariel internal events. That's a subtle point that can easily inflate your baseline EPS by 5-10% if you're not meticulous. To build on your report idea, we also created a scheduled report that breaks down EPS by DSM and highlights any source where the average event size exceeds a threshold. A verbose Windows security event, for instance, can consume several times the EPS unit cost of a simple firewall accept, so raw EPS can be misleading.
The default dashboards are indeed noisy. We found success by starting from a completely blank dashboard and adding only the most critical executive-level KPIs, like mean time to acknowledge and top attack vectors. Everything else was built as a separate, analyst-focused dashboard that prioritizes drill-down capability over at-a-glance views. This separation of concerns kept the noise level manageable.
Data doesn't lie, but folks sometimes do.
Your 3 month timeline is a victory, honestly. Most teams take that long just to admit their log source inventory is fictional.
>more powerful correlation rules
That's the early optimism talking. Wait until you try to recreate even a medium complexity AlienVault rule using QRadar's building blocks. The power is there, but the abstraction layer is brutal. You'll spend a week on what used to be a drag and drop.
My tip for cost tracking? Don't rely on QRadar's own EPS reports for billing. They often omit internal overhead. Set up a parallel calculation using raw data from your log collectors. The variance is enlightening, and sometimes the basis for a credit.
Data skeptic, not a data cynic.
Really appreciate you sharing this, it's the kind of real-world diary that helps everyone. I think you've already put your finger on the two biggest challenges for any migration: the initial setup friction and the mental shift in how you're billed.
On cost tracking, I'd add that beyond just watching EPS, you need to track what I call "event quality." One huge, verbose authentication failure can cost the same EPS as five clean firewall blocks, so your most expensive devices aren't always your noisiest. A regular audit of average event size per source can uncover some quick wins.
That "do this first" gap in the docs is a classic hurdle. I've found the best entry point is often the community use cases, not the admin guide, as they're built around actual problems.
Stay constructive
"Event quality" is a useful term for that. It's the first thing I audit when EPS spikes unexpectedly.
The community use cases are indeed the real admin guide. The official docs show you what a button does, but a use case shows you which button to press at 3AM when you're getting paged.
Congrats on getting through the migration! That initial setup phase is always a marathon, not a sprint.
>The QRadar docs are huge but finding the simple "do this first" steps was tricky.
This is so relatable. My team ended up creating a one-page "cheat sheet" with just the URLs for the five admin tasks we needed daily. The official docs are a forest; sometimes you just need a single trailhead.
On your dashboard point, I'd suggest starting with just one. Build a dashboard that directly answers a single question your boss asks every week, like "are we seeing more failed logins?" Get that one perfect and useful. The rest will follow naturally, and it keeps you from getting overwhelmed by all the options.
Automate all the things
Glad you posted this, and congrats on the migration. That initial log source mapping is always the beast.
The "powerful" correlation rules feeling is real early on, but the abstraction wall hits hard when you need to tweak them. For cost tracking, I'd validate your EPS with a separate stream, maybe a lightweight forwarder to a cheap S3 bucket, just to have an independent audit trail. QRadar's internal overhead can skew your numbers.
For dashboards, start stupid simple. A single line graph of your top 5 log sources by volume over 7 days. That's it. Once that's stable and you trust the data, then think about bells and whistles. Too many options too fast is a trap.
That initial setup phase really is a grind, but you made it through. Your point about finding the "do this first" steps is exactly right. My team kept a shared note of those breadcrumb links we finally found buried in forums, like the specific procedure for tuning a DSM before enabling it. It saved us during the second wave of onboarding.
On cost tracking, echoing what others said about internal overhead. We set a calendar reminder for a weekly check of the top 10 log sources by EPS, not just volume. You'd be surprised how often a single, chatty application server starts costing you more than your entire firewall cluster. It's a quick way to spot misconfigurations.
For dashboards, start with one that shows your rule execution count over the last week. It helps you see which of those powerful correlation rules are actually firing, versus just sitting there.
ship early, test often
The performance monitor tab in the rule wizard shows estimated EPS impact during test runs. It's a starting point.
But the real metric is watching your QRadar Console's system monitor after you enable a rule. If you see a consistent spike in CPU on the correlation node when the rule fires, that's your answer. For complex rules, the overhead comes from the join operations, not the event volume.
We built a script that polls the REST API for rule execution time during a quiet hour to profile each one. The built-in metrics are too high level.
That's a super practical tip, thanks! I haven't dived into the rule performance monitor yet.
>The overhead comes from the join operations
That explains a lot. We've got a few rules that trigger a lot but are simple, and they're fine. One complex rule with multiple criteria we built last week is what's been causing CPU grief. I was only watching EPS.
Could you share what API endpoints you used for that profiling script? I'm still learning the QRadar API but that sounds like a lifesaver.