# IBM QRadar (Early Access)

!!! info "Early access"
    The IBM QRadar integration is available as an early-access feature and is actively evolving. Your feedback helps shape it; contact [sales@wallarm.com](mailto:sales@wallarm.com) with questions or suggestions.

[IBM QRadar](https://www.ibm.com/products/qradar-siem) is a security information and event management (SIEM) platform. You can set up Wallarm to send detected attacks to a QRadar [HTTP Receiver](https://www.ibm.com/docs/en/dsm?topic=options-http-receiver-protocol-configuration) log source. Wallarm Cloud delivers events over HTTPS, authenticated with a token header.

## Requirements

* A QRadar HTTP Receiver endpoint that is publicly reachable from Wallarm Cloud
* An HTTPS server certificate signed by a certificate authority (CA) — self-signed certificates are not accepted

## Setting up integration

1. In QRadar, open **Admin** → **Log Sources** and create a log source with the **HTTP Receiver** protocol:

    | Parameter | Value |
    | --- | --- |
    | **Log Source Type** | Universal DSM, or a custom DSM for Wallarm |
    | **Listen Port** | A free port, for example `12469`. Wallarm Cloud must be able to reach it. |
    | **Communication Type** | **HTTPs** with a CA-signed server certificate |
    | **Use HTTP Authentication Token Header** | Enabled |
    | **Authentication Token Header Name** | `Authorization` |
    | **Authentication Token Value** | A secret string that you generate. You enter the same value in Wallarm Console. |
    | **Event Parsing Method** | **Event Per Line** |
    | **Max Payload Length (Byte)** | `32767` (advanced option) |
    | **Max POST method Request Length (MB)** | `5` or higher |

    QRadar compares the `Authorization` header value as is. Do not add a prefix such as `Basic` or `Bearer` unless it is part of the token value you configured.

1. Open Wallarm Console → **Integrations** and proceed to the **IBM QRadar** integration setup.
1. Enter an integration name.
1. Enter the HTTP Receiver URL with the listen port, for example `https://qradar.example.com:12469`. The URL must use `https://`.
1. Paste the **Authentication Token Value** configured in the log source. The value must not contain line breaks.
1. Choose event types to trigger notifications.

    Details on available events:

    * [Hits](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#hit) detected except for:

        * Experimental hits detected based on the [custom regular expression](https://docs.wallarm.com/user-guides/rules/regex-rule.md). Non-experimental hits trigger notifications.
        * Hits not saved in the [sample](https://docs.wallarm.com/user-guides/events/grouping-sampling.md).

        Optionally include the `headers` object with hit headers in hit logs. If disabled, headers are not included in the logs.

    * System related:
        * [User](https://docs.wallarm.com/user-guides/settings/users.md) changes (newly created, deleted, role change)
        * [Integration](https://docs.wallarm.com/user-guides/settings/integrations/integrations-intro.md) changes (disabled, deleted)
        * [Application](https://docs.wallarm.com/user-guides/settings/applications.md) changes (newly created, deleted, name change)
        * Errors during regular update of specifications used for [rogue API detection](https://docs.wallarm.com/api-discovery/rogue-api.md) or [API specification enforcement](https://docs.wallarm.com/api-specification-enforcement/setup.md#step-1-upload-specification)
    * [Rules](https://docs.wallarm.com/user-guides/rules/rules.md) and [triggers](https://docs.wallarm.com/user-guides/triggers/triggers.md) changed (creating, updating, or deleting the rule or trigger)
    * [Security issues](https://docs.wallarm.com/user-guides/vulnerabilities.md) detected by [all methods](https://docs.wallarm.com/about-wallarm/detecting-vulnerabilities.md#detection-methods), all or only for the selected risk levels:    
        * Critical risk
        * High risk
        * Medium risk
        * Low risk
        * Info risk
    * On an hourly basis, you can get a notification with the number of requests processed during the previous hour
1. Click **Test integration** to check configuration correctness, availability of the target system, and the notification format. Wallarm sends a sample attack to QRadar.
1. Click **Add integration**.

!!! info "Wallarm Cloud IP addresses"
    To provide Wallarm Cloud access to your system, you may need a list of its public IP addresses:

    **US Cloud:**

    ```
    34.102.90.100
    34.94.156.115
    35.235.115.105
    34.94.85.217
    34.94.51.234
    34.102.59.122
    34.94.238.72
    35.235.100.79
    34.102.45.38
    34.94.241.21
    34.94.203.193
    34.94.238.221
    34.94.9.235
    34.94.118.150
    34.94.193.9
    ```

    **EU Cloud:**

    ```
    34.141.230.156
    34.91.138.113
    34.90.114.134
    35.204.127.78
    34.90.24.155
    34.7.147.149
    ```

## Event format

Wallarm sends attacks (hits) as newline-delimited JSON (NDJSON): one JSON event per line, in the body of a `POST` request with the `Content-Type: application/x-ndjson` header and the token in the `Authorization` header.

Example of an event:

```json
{"vendor":"Wallarm","product":"WAF","event_id":"sqli","time":"2026-10-12T10:15:30Z","src_ip":"203.0.113.5","src_port":0,"dst_ip":null,"dst_port":null,"domain":"api.example.com","method":"POST","url":"/api/v1/login","severity":5,"action":"blocked","request_id":"abc123","payload":"' OR 1=1--"}
```

All fields are always present:

| Field | Description |
| --- | --- |
| `vendor` | Always `Wallarm`. |
| `product` | Always `WAF`. |
| `event_id` | Attack type, for example `sqli`, `xss`, `rce`, `ptrav`. Map it to QRadar event IDs (QIDs) in QRadar. |
| `time` | Request time in ISO 8601 format, UTC. |
| `src_ip` | Attacker IP address: IPv4, or IPv6 when IPv4 is not available. |
| `src_port` | Attacker port. Can be `0`. |
| `dst_ip` | Always `null`. |
| `dst_port` | Always `null`. |
| `domain` | Requested host. |
| `method` | HTTP method. |
| `url` | Request path. |
| `severity` | Always `5`. |
| `action` | Action taken on the request, for example `blocked` or `monitored`. |
| `request_id` | Wallarm request ID. |
| `payload` | Malicious payloads, separated by line breaks. Can contain sensitive request data. |

Each line is limited to 32767 bytes. If an event is longer, Wallarm truncates `payload`, then `url`, then `domain`, and adds the `...` suffix to the truncated value. Each request is limited to 5,000,000 bytes. Wallarm splits larger batches into several requests.

## Disabling and deleting an integration

You can delete or temporarily disable the integration. While deleting stops sending notifications and completely deletes all configuration, disabling just stops sending notifications, which you can re-enable at any moment with the same settings.

If the **System related** events are selected to trigger notifications for the integration, Wallarm will notify you about both of these actions.
## System unavailability and incorrect integration parameters

If QRadar responds with `401` or `403`, Wallarm treats the token as rejected and the integration as misconfigured. Other non-2xx responses and network errors are retried.

Notifications to the system are sent via requests. If the system is unavailable or integration parameters are configured incorrectly, the error code is returned in the response to the request.

If the system responds to the Wallarm request with any code other than `2xx`, Wallarm resends the request at intervals until the `2xx` code is received:

* The first cycle intervals: 1, 3, 5, 10, 10 seconds
* The second cycle intervals: 0, 1, 3, 5, 30 seconds
* The third cycle intervals:  1, 1, 3, 5, 10, 30 minutes

If the percentage of unsuccessful requests reaches 60% in 12 hours, the integration is automatically disabled. If you receive system notifications, you will get a message about the automatically disabled integration.