IBM QRadar

IBM QRadar is a mature, enterprise-grade security analytics platform deployed in data centers and private clouds. Founded as a product line within IBM Security, QRadar has been in production since 2009. It is the longest-running on-prem SIEM in this review alongside Splunk ES.

The critical fact: IBM has announced the End-of-Life (EOL) for QRadar On-Premises physical appliances. The EOL date is August 31, 2025. This is not End-of-Support. The appliances will continue to receive security patches and support under existing contracts. But no new features, no new hardware, no new versions. IBM is transitioning customers to QRadar SaaS (cloud-native) or IBM Security MaaS360 (unified cloud security platform). The dedicated-appliance SIEM business is ending.

For a CISO running QRadar on-prem today, this is not a hypothetical future risk. It is a deadline. The August 31 EOL means the organization must begin its migration planning now. The migration options are: (1) QRadar SaaS (same correlation engine, cloud delivery), (2) IBM Security MaaS360 (new platform, new architecture), or (3) a competitive cloud SIEM (Splunk, Sentinel, Chronicle, Elastic, Securonix). The migration is not a lift-and-shift. It is an architectural decision.

The QRadar on-prem platform remains technically capable. The correlation engine is mature. The Risk-Based Alerting (RBA) model is well-refined. The compliance DB is extensive. The AQL (QRadar Query Language) is functional. The platform is not broken. It is being sunset. The question for the CISO is not "is QRadar good?" The question is "what do I migrate to, and what does the migration cost in time, money, and operational disruption?"

The user's client has been running QRadar for over 10 years, replaced hardware appliances multiple times due to mandatory refresh cycles, and is now facing the EOL. The client uses Microsoft Sentinel in tandem with QRadar for Microsoft-native telemetry. The natural migration path is consolidation into Sentinel. The strategic question is whether that consolidation is the right decision or whether a competitive cloud SIEM (Elastic, Chronicle, Securonix) is a better fit for the non-Microsoft telemetry.

Top 10 per category. † marks QRadar-specific strengths.

A. Identity & Access Control: Login success/failure; account lockout/MFA rejection; password change/reset; role/permission change; privileged service account activation; OAuth/SAML token anomaly; conditional access bypass; MFA registration; privileged session initiation; † RBA: cumulative risk score elevation across identity events, asset criticality weighting, and user role sensitivity in a single risk-based alert

B. File, App & Cloud Storage: File create/modify/delete; API key rotation; cloud bucket policy change; DB query on restricted tables; PAM session; first-time object storage access; mass download; container image pull; Git permission elevation; † Compliance DB: file access to PII-classified storage, mapped to specific PCI-DSS/HIPAA/SOX controls, flagged as a control deviation if outside the user's approved scope

C. Network Flow: Src/Dst IP/port/protocol/duration/bytes; DNS query/response; TLS handshake; HTTP transaction; NDCM-collected NetFlow/IPFIX/sFlow; DNS tunneling; non-standard TLS ports; multi-connection fan-out; cross-region transfer; † NDCM: dedicated flow collection with protocol decoding (HTTP, DNS, TLS, SIP, SSL) at the flow level, asset enrichment via QRadar's Asset Inventory

D. Endpoint/Email/Gateway: Executable hash block; macro document; C2 beacon; fileless execution; sandbox rejection; new scheduled task; SUID binary creation; registry persistence; email gateway failure; † QRadar Winlogbeat/Sysmon integration: process creation, file access, registry modification, and network connection events correlated with the asset's criticality and the user's role

E. Exploit & Attack: Buffer overflow; SQLi/XSS (CRS 4.25); exploit kit hit; RCE via CVE; lateral movement; cloud metadata access; IAM privilege escalation; container escape; DNS exfiltration; † RBA: multi-vector attack chain (phishing + credential theft + lateral movement + data staging) correlated into a single risk score event with asset criticality and data classification weighting

F. Behavioral/UEBA: Impossible travel; egress spike; off-hours access; privilege escalation without ticket; service account interactive session; new API consumer; IAM role first-time assumption; authentication method change; data access breadth expansion; † QRadar baseline: per-user, per-asset, per-service behavioral baselines with RBA risk score elevation on deviation, weighted by asset criticality and data classification

Log Sources (syslog, WEF, SNMP), NDCM for flow, SIEM Connectors for cloud/SaaS. Source-level filtering via Event Parsing Rules and Normalize rules. No pre-ingest deduplication. Corrule-based aggregation and RBA handle repetition. Asset/Network Inventory contextualizes benign patterns.

Architecture: App Node (Console/Manager), Event Manager Nodes (correlation/parsing), NDCM (flow), Flow Storage Nodes. Manual scaling by adding hardware or VMs. No auto-scaling. Retention governed by local storage and Compliance DB archiving.

Scale: >10K EPS. Handled by the Event Manager Node cluster. Scaling is manual: add nodes, add storage, tune the correlation engine. At extreme scale, the appliance sizing (XG/XDR series) becomes the constraint. The manual capacity planning is the operational cost.

Failure Modes. The EOL is the primary failure mode. The hardware refresh cycle, the manual scaling, and the single-vendor appliance dependency create operational debt. The secondary failure mode is the correlation rule maintenance: hundreds of custom correlation rules, parsing rules, and compliance mappings must be validated after any platform update. A bad update can break a rule silently.

Schema, Search & Visualization

Event Parsing Rules (regex, JSON/XML, field splitters). Normalize Rules map to QRadar's internal model. Not CIM, not UDM, not OCSF by default. Custom field mapping via Custom Fields and Reference Data.

AQL query language. Timeline Inspector, Entity Builder, RBA views, Compliance Dashboard. Pre-built and custom widgets. Role-based templates. CSV/JSON export. ServiceNow/Jira integration. Tableau®/Power BI via middleware.

Detection is from the correlation rules (QRadar-authored), the Compliance DB, and upstream sources (WAF/CRS, EDR, identity). The RBA model aggregates multi-source events into a risk score. The correlation engine is mature and well-refined for enterprise SOC operations.

SOAR: Watson Orchestration. Functional for standard workflows. Less deep than Splunk SOAR or Cortex SOAR. The ITSM integration (ServiceNow, Jira) is mature.

The free-stack context applies. The detection primitives are commodity. QRadar's contribution is the correlation, the RBA model, the Compliance DB, and the 15+ years of enterprise deployment. For a 10-year QRadar customer, the institutional knowledge in the correlation rules, the compliance mappings, and the SOC workflows is the real asset. The migration must preserve that knowledge.

Architecture & Deployment Constraints

Historical: per-flow/per-event subscription or appliance-based licensing. Transitioning to cloud consumption.

Includes subscription, hardware maintenance, Compliance DB updates, support. Extended support post-EOL: +15–30% annually.

Search: unlimited within allocated storage. No per-query fees. Storage: manual tiering. No auto-ILM.

EOL Impact: August 31, 2025. End of feature development, hardware procurement, standard lifecycle. Extended support available. No new updates. Migration planning required.

Migration Options:

1. QRadar SaaS — Same engine, cloud delivery. Preserves correlation rules, Compliance DB, App Exchange. Lowest friction.
2. IBM Security MaaS360 — New platform. New architecture. Higher friction.
3. Competitive cloud SIEM — Splunk, Sentinel, Chronicle, Elastic, Securonix. Requires rule re-implementation, schema mapping, workflow redesign. Highest friction.
4. Hybrid/interim — Maintain on-prem under extended support. Run parallel cloud SIEM for new workloads. Migrate over 12–24 months.

Cloud, Ecosystem, Customers

On-prem/hybrid. SAML/OIDC. SOC 2 Type II, ISO 27001, FedRAMP Moderate (verify), GDPR/CCPA, HIPAA, PCI-DSS. App Exchange (parsers, compliance packs, automation). Watson Orchestration. X-Force threat intel. Professional services.

Named customers: Capital One, Ford, Visa, Disney, Warner Bros. Discovery, Intuit, ServiceNow, Atlassian, Discord, Shopify, Netflix, Spotify, VMware.

MSSP/Big-4 excluded. Many are 10+ year QRadar customers facing the EOL migration. Order does not indicate scale.

Strengths: 15+ years of enterprise deployment. Mature correlation engine. Extensive Compliance DB. RBA model. NDCM flow collection. Institutional knowledge in correlation rules and compliance mappings.

Weaknesses: EOL August 31, 2025. The platform is being sunset. The migration is mandatory, not optional. Manual scaling. Smaller connector ecosystem. SOAR less deep than Splunk or Cortex. AQL less expressive than SPL or KQL. The 10-year investment in correlation rules, compliance mappings, and SOC workflows must be preserved or rebuilt during migration.

IBM QRadar on-prem is a technically capable platform being sunset. The EOL date (August 31, 2025) is the defining fact. The CISO's decision is not "is QRadar good?" The decision is "what do I migrate to, what does it cost, and how do I preserve the 10 years of institutional knowledge in the correlation rules, compliance mappings, and SOC workflows?"

The migration options have different friction levels. QRadar SaaS is the lowest friction (same engine, cloud delivery). A competitive cloud SIEM is the highest friction (new engine, new schema, new query language, new SOAR). The hybrid/interim path (parallel deployment, 12–24 month migration) is the most operationally safe but the most expensive (running two platforms simultaneously).

Ideal buyer: Organizations that are already running QRadar on-prem and must migrate. The question is where to, not whether to.

Key RFP (for the migration decision):

1. What is the total migration cost (labor, tools, dual-running, training) for each of the four migration options?
2. What is the correlation rule migration path? Can the rules be exported and re-implemented, or must they be rebuilt?
3. What is the Compliance DB migration path? Are the control mappings portable?
4. What is the SOC workflow migration path? Are the ITSM integrations, SOAR playbooks, and escalation paths portable?
5. What is the training requirement for the SOC team? New query language, new schema, new dashboard?
6. What is the dual-running period? How long can the organization run QRadar + the new platform simultaneously?
7. What is the contractual exit from the QRadar extended support contract?

Red flags: A migration plan that does not explicitly address the correlation rule, Compliance DB, and SOC workflow preservation. A TCO model that omits the dual-running period cost. A timeline that does not include a rollback procedure.

Wazuh

Wazuh is a free, open-source security platform (MIT licensed) that unifies log analysis, vulnerability detection, file integrity monitoring (FIM), incident response, cloud security posture, and compliance automation into a single self-managed ecosystem. It is not a SaaS product. It is not a vendor platform. It is a community-driven open-source project that the user installs, configures, and operates on their own infrastructure.

The user running Wazuh alongside Falco, ClamAV, Chkrootkit, CrowdSec, Coraza/CRS 4.25, Fail2ban, and Lynis on an Ubuntu web server and Stalwart mail server is the canonical deployment. The stack is free. The stack is functional. The stack covers detection, prevention, monitoring, compliance, and hardening. The operational cost is the engineer's time.

For a CISO evaluating Wazuh, the question is not "is Wazuh a good SIEM?" Wazuh is a good open-source SIEM. The question is "can my organization operate a self-managed security platform with the depth and rigor that a production SOC requires, without a vendor support contract, without a vendor SLA, and without a vendor to call at 3 AM when the indexer cluster is down?"

The answer depends on the organization's engineering capacity. A 200-person tech company with a 5-person security team and a DevOps culture can run Wazuh effectively. A 50,000-person enterprise with a 50-person SOC and no dedicated SRE for security infrastructure should not run Wazuh as their primary SIEM. The platform is capable. The operational model is the constraint.

The Wazuh manager, the OpenSearch/Elasticsearch indexer cluster, the Wazuh agents, the dashboard, the FIM baselines, the vulnerability scanner, the compliance rules, and the integration pipelines are all the organization's responsibility. There is no vendor to patch, no vendor to scale, no vendor to call. The MIT license means the software is free. The infrastructure, the engineering time, and the operational overhead are not.