To uniquely identify the fields that you want to extract from a JSON object, your JSON expression must follow specific JSON keypath conventions.

This site provides free technical training for IBM Security products. You can explore the course catalog and build your own curriculum by enrolling in courses.

The content below includes a list of all technical notes published under QRadar by category and sorted by popularity. Users can expand or collapse each section below using the + / - buttons. As new documentation is released, this content will be updated and new articles added. Click Expand All before starting a CTRL-F search.

Use the IBM® QRadar® Threat Intelligence app to configure and manage threat intelligence feeds in QRadar.

When you install the app, a Threat Intelligence icon is added to the QRadar Admin tab. Click this icon to open the Threat Intelligence window.

Proofpoint on Demand customers can use this add-on to collect email security logs that can be stored and indexed in Splunk to search, report and investigate email delivery. This technology add-on maps the message and mail logs to Splunk Common Information Model (CIM) for email.

Security Information and Event Management (SIEM) solutions are used by many organizations to identify and correlate various security events occurring in their point products. Examples of SIEM products include HP's ArcSight, IBM's QRadar, and Splunk. 

When you create a log source extension, you might encounter some parsing issues. Use these XML examples to resolving specific parsing issues.

You create log source extensions (LSX) when log sources don't have a supported DSM, or to repair an event that has missing or incorrect information, or to parse an event when the associated DSM fails to produce a result.

Many users have had issues with incorrectly auto detected log sources.  In some extreme cases, incorrectly detected devices can have a major performance impact, which would lead to degradation on ecs-ec. The solution for this problem was to move this configuration into the database.

The DSM Editor is a new capability introduced in QRadar 7.2.8 that allows you to create a custom parser for getting your events into QRadar in a usable and user friendly way. This page will give an overview of how to use the editor and then create an extension to share your creation.

Application security is vitally important for every software project, especially so for security projects. This is why the validation process for QRadar app submissions go through a secure engineering review. As a member of the secure development team, this blog post will hopefully give you (the app developer) some insight regarding what to expect during our app validation process.

How does QRadar handle events or flows that temporarily exceed my license limit?

The QRadar Support team writes articles for users to assist with technical resolutions or common problems. This page includes a searchable list of all published articles. Users can filter the table by keyword to quickly locate support write-ups.

How do I modify an existing event format and using a routing rule to forward the data to another log server using Syslog?

What steps can administrators review before they attempt to update their QRadar deployment?

Hacker Factor Solutions provides whitepapers and journal articles. Most documents are created and provided privately to customers. The following list represents a sample of documents created by Hacker Factor Solutions and released publicly. The copyrights for these documents have been transfered to their respective owners.

The project SIEM Analytics is designed to assist professionals in choosing SIEM systems, to talk about the strengths and weaknesses of the most common SIEM systems, as well as to give a preliminary comparative analysis of SIEM systems.

Restoring a backup archive is useful if you want to restore previously archived configuration files, offense data, and asset data on your IBM® Security QRadar® system.

In this post my intention is just to give some quick points on QRadar High Availability (HA)

1.    HA Overview
    -    Uses Primary and Secondary HA hosts
    -    Uses Virtual IPs
    -    Network connectivity is tested via hearbeat (pings) to all managed hosts
    -    HA Can be configured for either  console or managed host
    -    Both devices must have the same versions of the software
    -    Both devices must support the same DSM, scanner and protocols RPMs
    -    Uses data synchronization or shared external storage 
    -    Consistency is maintained locally by using Distributed Replicated Block Device (DRDB)
    -    If using external storage data consistency is maintained through iSCSI or Fibre Channel
    -    Data is synchronized in real time
    -    Note: Asset profiler can impact DRDB speed
    -    "/store" partition on secondary is automatically replicated to the secondary host
    -    Ensure min 1 Gbps between primary and secondary HA hosts
    -    Initial synchronization can take greater than 24 hours
        This may be an understatement. I've seen initial synchronization take upwards of 72 hours.
    -    Secondary host goes into "standby" after synchronization
    -    Primary HA hosts status becomes "offline" when restored from a failover
    -    Primary needs to be placed "online" before it becomes active
    -    Disk replication is enabled while primary is "offline"
    -    Post disk failover synchronization is faster
    -    Basically uses deltas
    -     When the primary host is restored, only the data collected by the secondary during the period the primary was unavailable is synchronized
    -    Replacing or reformating the disk on the primary can result in longer synchronization time in the event of a failback

    IP Considerations
        -    Uses Virtual IPs
        -    Needs 3 IP address - VIP, Primary and Secondary
        -    The IP address initially configured on the primary host is automatically made the cluster VIP
        -    A new IP will need to be assigned to the primary once HA configuration is started
        -    Primary host can act as a standby for secondary 
        -    VIP is used by a host that has a status of active
        -    All IPs must be in the same subnet
        -    Latency must be less than 2ms for traffic crosing the WAN

    HA Wizard
        -    Used to configure Primary, Secondary and cluster VIP
        -    Verifies the secondary has a valid HA activation key
        -    Verifies the secondary is not part of an existing HA cluster
        -    Verifies software version is the same on both devices
        -    Verifies external storage (if configured) on primary and then secondary
        -    Verifies both support the same DSM, scanner and protocol RPMS

    Failover scenarios
        -    Power supply failure
        -    network failure (detected by connectivity tests)
        -    OS malfunction that delays or stops hearbeat tests
        -    RAID failure
        -    Manual failover
        -     Management interface failure on primary hosts

        -    Primary does not take back its role as primary in the case of a failover. 
        -    Secondary stays as primary while primary acts as standy
        -    Primary must be switched to "active" to take over its role

        -    No failover for software errors or disk capacity issues
        -    If both primary and secondary are unable to ping a managed hosts no failover occurs
        -    If primary cannot but secondary can ping a managed host, failover occurs

    HA Failover event sequence
        -    File systems are mounted
        -    Management interface alias is created eth0 is eth0:0
        -    VIP is assigned to the alias
        -    QRadar services are started
        -    Secondary connects to console and downloads configuration files

    Tips for manual synchronization
        -    Ensure primary and secondary hosts are sync'd
        -    Secondary must be in standby
        -    Secondary to offline and power off the primary
        -    DO NOT MANUALLY FORCE FAILOVER DURING PATCHES OR SOFTWARE UPGRADES

2.    HA Planning
    -    File systems on both devices much match - ext-3, etc
    -    Secondary's "/store" partion must be equal to or greater than the primary
    -    Both devices should have the same number of interfaces
    -    Both must use the same management interface
    -    Only 1 VIP
    -    Port 7789 is needed for Distributed Replicated Block Device (DRDB)
    -    DRBD traffic is bidirectional
    -    Disk replication ensures software updates are applied to the secondary
    -    Ensure the host has a valid activation key

3.    HA Management
    -    Uses System and License management window to:
        -    monitor HA
        -    Force failover
        -    Disconnect cluster
        -    Modify cluster settings
        -    Modify heartbeat interval
        -    Place the device in "offline" mode before maintenance

Syslog messages from transit network devices can provide insight into and context for security events that may not be available from other sources. This insight aids in determining the validity and extent of an incident. Within the context of a security incident, administrators can use syslog messages to understand communication relationships, timing, and, in some cases, the attacker's motives and/or tools. These events should be considered complementary and should be used in conjunction with other forms of network monitoring that may already be in place.