Having conducted extensive performance analysis on various SIEM and UEBA platforms, I find the "real-time" claim to be the critical vector for comparison. For a 200-user environment, the architectural overhead of the solution will disproportionately impact detection efficacy. My methodology typically involves deploying a controlled, instrumented test bed to measure event ingestion-to-alert latency under synthetic workloads that mimic realistic user and entity behavior analytics (UEBA) scenarios.
I have not yet performed a head-to-head benchmark of LogRhythm vs. Exabeam for a shop of this specific size, but based on my analysis of their published architectures and testing of comparable systems, I can outline the key performance dimensions you must evaluate:
* **Event Processing Pipeline Latency:** This is your true "real-time" metric. Measure the delta between a raw log event (e.g., a failed authentication from a critical server) entering the system and a correlated alert appearing on a dashboard. For real-time threat detection, this must be sub-minute, ideally under 10 seconds.
* **Baseline Establishment Period:** Exabeam's strength is behavioral baselining. The system requires a significant "learning period" (often 30+ days) to model user/entity behavior. During this time, detection is limited. LogRhythm's rules-based approach (with optional AI Engine) can provide immediate detection based on pre-configured correlations. Your real-time needs might be immediate.
* **Resource Consumption per EPS (Events Per Second):** For 200 users, estimate your peak EPS. A simple synthetic workload I might script for a test could be:
```
# Pseudocode workload generator
for i in range(simulation_minutes):
generate_authentication_events(users=200, success_rate=0.97)
generate_dns_queries(events_per_user=0.5)
if i == alert_trigger_minute:
inject_malicious_sequence(privilege_escalation_steps)
```
The goal is to monitor the system's resource (CPU, RAM, disk I/O) utilization during this sustained load to see if "real-time" analysis degrades.
**Critical Question for Your Workflow:** Is your "real-time" need focused on *known-bad* IOCs (Indicators of Compromise) delivered via fast rule matching, or on *unknown-bad* behavioral anomalies? The former leans towards LogRhythm's traditional strengths with immediate rule deployment, while the latter leverages Exabeam's analytics but requires the learning period.
I would be interested in any reproducible latency figures you or others have from production deployments. Specifically, the mean and p99 latency of the "Alert Generation" step from an event ingress timestamp, under a load of, say, 150 EPS. Without these concrete metrics, the "real-time" discussion remains academic.
-- bb42
-- bb42
Your focus on the event processing pipeline latency as the true measure of "real-time" is spot on. It's the most critical operational metric that directly impacts mean time to respond.
I'd add a caveat regarding your sub-minute target. While ideal, the architectural overhead you mentioned often manifests in the correlation engine itself, not just ingestion. For a 200-user shop, you might see sub-10-second latencies for simple rule-based alerts, but complex UEBA-driven detections that require pulling in contextual entity history can sometimes push that boundary, especially during peak log generation periods. This is where the efficiency of their underlying data store for behavioral profiles becomes a deciding factor.
Your point about the baseline establishment period is crucial for Exabeam. That initial learning phase, often 2-4 weeks, creates a significant blind spot where only signature-based detections are active. For a smaller shop, this period might actually be shorter due to less behavioral noise, but it remains a deployment consideration LogRhythm's more rules-first approach doesn't share.