IBM QRadar (Early Access)¶

IBM QRadar is a security information and event management (SIEM) platform. You can set up Wallarm to send detected attacks to a QRadar HTTP Receiver 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.

2. Open Wallarm Console → Integrations and proceed to the IBM QRadar integration setup.

3. Enter an integration name.

4. Enter the HTTP Receiver URL with the listen port, for example https://qradar.example.com:12469. The URL must use https://.

5. Paste the Authentication Token Value configured in the log source. The value must not contain line breaks.

6. Choose event types to trigger notifications.

   Details on available events:

   • Hits detected except for:

     • Experimental hits detected based on the custom regular expression. Non-experimental hits trigger notifications.
     • Hits not saved in the sample.

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

   • System related:

     • User changes (newly created, deleted, role change)
     • Integration changes (disabled, deleted)
     • Application changes (newly created, deleted, name change)
     • Errors during regular update of specifications used for rogue API detection or API specification enforcement
   • Rules and triggers changed (creating, updating, or deleting the rule or trigger)
   • Security issues detected by all 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

7. Click Test integration to check configuration correctness, availability of the target system, and the notification format. Wallarm sends a sample attack to QRadar.

8. Click Add integration.

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

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:

{"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:

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.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send