Hi everyone! I've been lurking here for a bit, trying to learn about SIEM tools as we're evaluating them for our company. We recently got QRadar (I'm still very much a newbie with it), and my first real project was to build a dashboard focused on a specific worry our security team mentioned: suspicious logins across our main SaaS apps.
Since we use Okta for SSO and have apps like Salesforce, Google Workspace, and Dropbox, I wanted a single pane of glass for login events. I know this is probably basic stuff for you experts, but I was pretty proud of getting it to work!
My dashboard has a few key panels now:
* A table showing "Top Users by Failed Login Attempts" across all monitored apps, filtered for the last 24 hours.
* A graph tracking successful vs. failed logins per hour.
* A list of logins from unusual geolocations (based on our normal office locations).
* A specific panel that fires off if there's a successful login from a new country *and* a failed login for the same user within a 5-minute window.
The biggest hurdle for me was getting the log sources normalized correctly. I spent a good two days just making sure the Salesforce logs were parsing the username field the same way Okta was, so I could actually correlate events. It was a lightbulb moment when that finally worked!
I'd love any feedback or tips. Is this a sensible approach? Are there other key data points or correlations I should be looking at for SaaS login monitoring? Also, if anyone has built something similar, I'd be curious how you handled the geography rules – my "unusual locations" list is still pretty manual.
I admire the enthusiasm, but I'm always suspicious of the "single pane of glass" promise. You've built a dashboard for suspicious logins, but does your security team actually have a runbook for what to do with that list of unusual geolocations? Or is it just a prettier way to generate anxiety?
> The biggest hurdle for me was getting the log sources normalized correctly.
That hurdle never really goes away. Wait until your Salesforce admin changes a custom field name or Okta pushes a new event type. Your two days of parsing work will feel like a recurring subscription.
Show me the data
You're right about the runbook question - it's crucial. A dashboard without defined actions can just become noise. We had a similar phase with our marketing security alerts.
> Wait until your Salesforce admin changes a custom field
This hits home. We solved it by building our log parsing around the standard field set only, and flagging any deviation as its own alert. It means we miss some custom data, but the core login monitoring stays stable through changes. The trade-off is worth it for us.
automate everything
That's a really pragmatic approach. I've been staring at our own log parsing rules in Splunk, trying to decide how much custom Salesforce field data to include for audit purposes, and your comment clarifies the priority.
Focusing on the standard field set for the core monitoring logic makes total sense. But I'm curious, how do you handle the alert for a deviation itself? Is it a low-priority notification sent to an admin mailbox, or does it trigger a more formal process to review the change? I could see that becoming its own source of noise if your admins are constantly tweaking things.
The data mapping hurdle you described is the critical, unglamorous foundation for any dashboard like this. Your five-minute window correlation rule is a solid start for catching credential stuffing that succeeds after a few failures, but I'd caution against relying solely on the *same user* condition.
We've seen attackers rotate target usernames within the same source IP and user agent. A more resilient rule might look for that pattern of failure-then-success across a cluster of attributes, like a new source IP hitting multiple accounts from your company's domain within that short window. It adds complexity to your QRadar search, but it closes a blind spot.
On normalization, are you using separate log source types in QRadar for each app, or funneling everything through a single custom DSM? The latter can simplify field mapping but makes you more vulnerable to the schema changes others mentioned.