# IBM QRadar

Forwards events to an IBM QRadar HTTP Receiver protocol log source. Each request carries a batch of events over HTTP or HTTPS, framed to match the log source's Event Parsing Method.

## Requirements

- A QRadar deployment (Console, Event Collector, or Event Processor) reachable from Monad on the port the HTTP Receiver listens on.
- Administrative access to create or edit a log source in QRadar.
- If using HTTPS with a self-signed certificate, the CA certificate that signed the receiver's server certificate.
- If using HTTPS with mutual TLS, a client certificate and matching private key trusted by the log source's trust store.

## Configure the HTTP Receiver log source

1. In QRadar, open **Admin > Data Sources > Log Sources > Add**.
2. Set **Log Source Type** to the vendor/type appropriate for your events (or a generic type such as `Universal DSM`) and **Protocol Configuration** to `HTTP Receiver`.
3. Configure the receiver:
    - **Listen Port**: any free port on the QRadar host. QRadar's default is `12469`. Whatever you pick here is what you'll enter as **Port** in Monad.
    - **Communication Type**: pick `HTTP`, `HTTPS`, or `HTTPS and Client Authentication (mTLS)`. This must match the **Communication Type** you select in Monad.
    - **Event Parsing Method**: pick `Event Per Line` for newline-delimited JSON, or `Event Per JSON Array` if you want one JSON array per request. Monad's **Event Parsing Method** must match.
    - (Optional) Turn on **Use HTTP Authentication Token Header** and set a header name + value if you want to require an auth header on every request. Monad satisfies this with the **Custom Header** authentication option.
4. Save and deploy the log source.

## Details

The QRadar output connector continuously batches processed events and posts them to the HTTP Receiver.

1. **Batch processing**: events are grouped and sent in batches, tuned via the batch config for record count, total size, and publish rate.
2. **Framing**: request bodies are either newline-delimited JSON (`Event Per Line`) or a single JSON array (`Event Per JSON Array`). Pick the one that matches your log source.
3. **Transport modes**: plain HTTP, HTTPS with server certificate verification, or HTTPS with mutual TLS. HTTPS is the default and recommended for production.
4. **Authentication**: optional HTTP Basic credentials or a custom header (e.g., `Authorization: Bearer <token>`) attached to every request.
5. **Error handling**: failed batches surface as pipeline errors and are retried according to standard connector retry behavior.

## Communication modes

- **HTTP** — plaintext. Use only on trusted networks; not recommended for production.
- **HTTPS** — TLS with server certificate verification. Supply the CA certificate that signed QRadar's HTTP Receiver server certificate. `Insecure Skip Verify` bypasses verification entirely and should not be combined with a CA certificate.
- **HTTPS with mTLS** — TLS plus a client certificate that Monad presents to QRadar. Supply the CA certificate (as above) plus a client certificate and matching private key in PEM format.

## Event parsing methods

- **Event Per Line** — request body is newline-delimited JSON: one event per line. Matches QRadar's default parsing behavior.
- **Event Per JSON Array** — request body is a single JSON array of events, e.g. `[{"a":1},{"b":2}]`. Use when the QRadar log source is configured for this parsing method.

## Configuration

The following configuration defines the input parameters. Each field's specifications, such as type, requirements, and descriptions, are detailed below.

#### Settings

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| Host | string | Yes | Hostname or IP address of the QRadar HTTP Receiver. Do not include a scheme (`http://` / `https://`). |
| Port | integer | Yes | TCP port the HTTP Receiver listens on. Default in QRadar is `12469`. |
| Communication Type | one-of | Yes | Transport mode: `http`, `https`, or `https_mtls`. Must match the log source's Communication Type. |
| Event Parsing Method | one-of | Yes | How events are framed on the wire: `line` (newline-delimited) or `array` (single JSON array). Must match the log source's Event Parsing Method. |
| Authentication | one-of | No | Optional authentication attached to every request. Omit for an unauthenticated log source. Options: `basic`, `header`. |
| Batch Config | object | No | Controls when a batch is sent by limiting record count, total size, and elapsed time. |

#### Communication Type — HTTPS

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| CA Certificate | secret (PEM) | Conditional | CA certificate used to verify QRadar's server certificate. Required unless `Insecure Skip Verify` is enabled. |
| Insecure Skip Verify | boolean | No | Skips TLS certificate verification. Not recommended for production. Cannot be combined with `CA Certificate`. |

#### Communication Type — HTTPS with mTLS

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| CA Certificate | secret (PEM) | Conditional | CA certificate used to verify QRadar's server certificate. Required unless `Insecure Skip Verify` is enabled. |
| Insecure Skip Verify | boolean | No | Skips TLS certificate verification. Not recommended for production. Cannot be combined with `CA Certificate`. |
| Client Certificate | secret (PEM) | Yes | Client certificate presented to QRadar for mutual TLS. |
| Client Key | secret (PEM) | Yes | Private key matching the Client Certificate. |

#### Authentication — HTTP Basic

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| Username | string | Yes | Username for HTTP Basic authentication. |
| Password | secret | Yes | Password for HTTP Basic authentication. |

#### Authentication — Custom Header

Use this to satisfy QRadar's "Use HTTP Authentication Token Header" server-side option, or to send a bearer token.

| Setting | Type | Required | Description |
|---------|------|----------|-------------|
| Header Name | string | Yes | Header name to send (e.g. `Authorization` or `X-Api-Key`). |
| Header Value | secret | Yes | Header value to send (e.g. `Bearer <token>`). |

## Limitations

- The connector honors QRadar's HTTP Receiver server-side settings but does not configure them. Server certificate provisioning (self-signed vs. QRadar cert store vs. PKCS12), trust stores, CN allowlists, issuer verification, certificate revocation checking, JSON path expressions, and gateway log source behavior must all be configured on the QRadar side.
- HTTP request timeout is 30 seconds. Batches that don't complete within this window are treated as failures and retried.

## Troubleshooting

- **Connection refused / timeouts**: verify `Host` and `Port` are correct and that firewalls between Monad and QRadar allow the listener port. Check the log source status in QRadar.
- **TLS verification failures**: ensure the `CA Certificate` matches the CA that signed QRadar's HTTP Receiver server certificate. As a diagnostic — not a production setting — enable `Insecure Skip Verify` to isolate whether the failure is verification-specific.
- **mTLS handshake failures**: confirm the client certificate is trusted by the log source's mutual authentication trust store, and that the Client Certificate and Client Key are a valid pair in PEM format.
- **Events not appearing in QRadar**: confirm the `Event Parsing Method` in Monad matches the log source's configuration. A mismatch (e.g., sending an array to a log source expecting one event per line) causes QRadar to parse the batch as a single event or drop it.
- **Authentication failures (`401`)**: if the log source uses `Use HTTP Authentication Token Header`, pick Monad's `Custom Header` authentication and set `Header Name` / `Header Value` to match. For HTTP Basic, verify the credentials configured on the log source.