Send Cloudraw events to your SIEM

Overview: what Cloudraw sends

Cloudraw can stream its events to the tools your security team already uses. You add a destination, choose which streams it gets, and Cloudraw sends new events as they happen. You can have up to 10 destinations per workspace, of any mix of types.

What is sent

There are two streams. A new destination gets both unless you pick only one.

Record format

Every record has the same fields, whatever the destination:

• Audit records always have severity info. The message is <who>: <action>. data holds the audit entry's fields, the actor, and the entry's chain hash and sequence number, so your SOC can check that nothing is missing. Fields whose names look like secrets (token, secret, password, API key and similar) are replaced with [redacted].
• App-firewall records have severity warning (blocked) or info (would have been blocked). data holds the device, person, connection, program path, publisher, reason and whether the block was enforced.
• Each destination type wraps the record in the format the provider expects. The provider sections below show how.

Delivery and retries

• Events are sent in batches of up to 100, usually within a few seconds.
• Audit stream: nothing is lost. Cloudraw keeps a position for each destination. If the destination fails, Cloudraw holds the entries and retries (after 5 s, 30 s, 2 min, 10 min, then every 30 min) until it works. Entries arrive in order. After a failure a batch can arrive twice, so de-duplicate on the hash in data.
• If a destination keeps failing for 15 minutes, Cloudraw raises a security alert: "Log shipping to your <type> destination is failing since … Audit entries are held and will be delivered when it recovers." The alert clears itself when delivery works again.
• Alerts stream: best effort. A failed batch is retried with the same back-off, up to 6 attempts, and then dropped. Up to 2,000 alert records wait per destination. Beyond that the oldest are dropped. The destination's delivery status shows how many were delivered and dropped.
• Cloudraw always checks the TLS certificate and never follows redirects. Only ports 443, 8088, 8443 and 6514 are allowed. The destination must be reachable on a public address: private, loopback and link-local addresses, internal host names (localhost, *.local, *.internal, *.localdomain) and cloudraw.com hosts are refused. This is checked again every time Cloudraw connects.

Add a destination

1. Prepare the provider sideFollow the section for your provider below. Keep the values you collect at hand.
2. Open SIEM streamingIn the Cloudraw admin console go to Settings→Integrations→SIEM streaming and click Add destination.
3. Pick the type and fill in the fieldsUse the field table in your provider's section. Choose the streams: Audit, Alerts, or both.
4. SaveCloudraw checks the values right away and tells you what is wrong. After saving, secret fields show only ••••••••. They are stored encrypted and never shown again.
5. Send a test eventClick Test (see below).

You need the Owner or Security admin role to add, test or delete destinations. Auditors can see them.

Test a destination

Test sends one real record right away, with no retry, and shows the provider's answer. The record looks like this:

If it works, the destination status changes to streaming. If not, it changes to error and the error text is shown. You can run 10 tests per destination per hour.

Splunk (HTTP Event Collector)

Cloudraw sends to the Splunk HTTP Event Collector (HEC). Works with Splunk Enterprise and Splunk Cloud Platform.

In Splunk

1. Create an index (recommended)Go to Settings→Indexes→New Index. Name it, for example, cloudraw, and save.
2. Turn on HECGo to Settings→Data inputs→HTTP Event Collector. On Splunk Enterprise click Global Settings, set All Tokens to Enabled, keep Enable SSL on, and note the port (default 8088).
3. Create the tokenClick New Token. Name: Cloudraw. Leave Enable indexer acknowledgement off. Click Next.
4. Input settingsSource type: Automatic (Cloudraw sets it). Under Allowed Indexes add your cloudraw index and make it the Default Index. Click Review, then Submit.
5. Copy the token valueIt is a GUID. You need it in Cloudraw.

Your HEC URL is the event endpoint:

Cloudraw field → value

Each record becomes one HEC event with host and source set to cloudraw, time set from the record, and the full record as event.

Test it

Click Test in Cloudraw, then search in Splunk:

Troubleshooting

Microsoft Sentinel

Cloudraw sends to Microsoft Sentinel through the Azure Monitor Logs Ingestion API into a custom table in the Log Analytics workspace that Sentinel uses. (The older HTTP Data Collector API is retired and is not used.) This takes about 20 minutes.

In Microsoft Entra and Azure

1. Register an appIn the Microsoft Entra admin center go to Identity→Applications→App registrations→New registration. Name: Cloudraw log ingestion. Single tenant. No redirect URI. Click Register. On Overview copy the Application (client) ID and the Directory (tenant) ID.
2. Create a client secretGo to Certificates & secrets→Client secrets→New client secret, click Add and copy the secret's Value (not the Secret ID). No API permissions are needed.
3. Create a Data Collection EndpointIn the Azure portal go to Monitor→Settings→Data Collection Endpoints→Create. Use the same region as your Log Analytics workspace. When it is created, open it and copy the Logs Ingestion URL from Overview. It looks like https://<name>-abcd.westeurope-1.ingest.monitor.azure.com.
4. Save a sample fileSave this as cloudraw-sample.json on your computer. Azure uses it to build the table columns: [{"TimeGenerated":"2026-10-07T09:00:00.000Z","Tenant":"example","Kind":"audit","Action":"siem.test","Severity":"info","Message":"sample","Data":{"actor":"admin@example.com"}}]
5. Create the custom table and DCRGo to Log Analytics workspaces→your workspace→Settings→Tables→Create→New custom log (DCR-based).
   • Table name: for example Cloudraw. Azure adds _CL, so the table is Cloudraw_CL.
   • Data collection rule: Create a new data collection rule, for example cloudraw-dcr.
   • Data collection endpoint: the one from step 3.
   Click Next, upload cloudraw-sample.json, keep the default transformation (source), click Next, then Create.
6. Copy the DCR immutable ID and stream nameGo to Monitor→Settings→Data Collection Rules→cloudraw-dcr and click JSON View. Copy immutableId (starts with dcr-). Under streamDeclarations copy the stream name, for example Custom-Cloudraw_CL.
7. Give the app permission to sendIn the same DCR open Access control (IAM)→Add→Add role assignment. Choose the role Monitoring Metrics Publisher. Under Members choose User, group, or service principal, select Cloudraw log ingestion, then Review + assign. The role can take up to 30 minutes to work.

Cloudraw field → value

Test it

Click Test in Cloudraw. The first records can take 5 to 10 minutes to appear. Then run this in Microsoft Sentinel→Logs:

Troubleshooting

Datadog

Cloudraw sends to the Datadog Logs intake API (v2).

In Datadog

1. Create an API keyGo to Organization Settings→API Keys→New Key. Name it Cloudraw and copy the key. Use an API key, not an Application key.
2. Find your siteLook at the address bar when you are signed in to Datadog. app.datadoghq.com means site datadoghq.com. app.datadoghq.eu means datadoghq.eu. us3.datadoghq.com, us5.datadoghq.com, ap1.datadoghq.com and ap2.datadoghq.com are their own sites. US1-FED is ddog-gov.com.

Cloudraw field → value

Each record becomes one log with ddsource:cloudraw, hostname:cloudraw, status set to the severity, tags tenant:<id> and kind:<kind>, the message, and the full record under the cloudraw attribute.

Test it

Click Test in Cloudraw, then open Logs→Explorer and search:

Troubleshooting

Amazon S3

Cloudraw writes each batch as one NDJSON file (one JSON record per line) to your S3 bucket. Use this for long-term archive, or to feed a SIEM that reads from S3.

In AWS

1. Create the bucketIn the S3 console click Create bucket. The name may only use lowercase letters, digits and dashes. No dots. Note the AWS Region. Keep Block all public access on.
2. Create an IAM policyIn the IAM console go to Policies→Create policy→JSON and paste this, with your bucket name and prefix: { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::<your-bucket>/<your-prefix>/cloudraw/*" }] } Without a prefix, use arn:aws:s3:::<your-bucket>/cloudraw/*. Name the policy cloudraw-log-export.
3. Create an IAM userGo to Users→Create user. Name: cloudraw-log-export. No console access. Choose Attach policies directly and select cloudraw-log-export.
4. Create an access keyOpen the user, go to Security credentials→Create access key, choose Third-party service, and copy the Access key and Secret access key.

Cloudraw field → value

Files are named like this (time in UTC):

Test it

Click Test in Cloudraw. A new .ndjson file with one line appears under today's date folder.

Troubleshooting

Syslog over TLS

Cloudraw sends RFC 5424 syslog messages over TLS (RFC 5425) to your syslog server or SIEM collector, for example rsyslog, syslog-ng, QRadar or ArcSight. TLS is always on. Plain TCP and UDP are not supported.

On your syslog server

1. Open a TLS listenerSet up a TCP listener with TLS, normally on port 6514. Cloudraw uses octet-counting framing (RFC 5425), which rsyslog and syslog-ng accept on TLS inputs.
2. Install a server certificateThe certificate must match the host name Cloudraw connects to. If you connect by IPv4 address, the certificate needs that address in its Subject Alternative Names. It can come from a public CA, or from your own private CA (see ca_pem).
3. Make it reachableThe listener must have a public IP address that Cloudraw can reach. Allow it in your firewall.

Cloudraw field → value

Each record is one message. Facility is authpriv (10). Severity is critical (2), warning (4) or info (6). The header is cloudraw orchestrator as host name and app name, the message ID is the record's kind, and the message body is the full record as JSON:

Test it

Click Test in Cloudraw and look for a message with message ID alert and "action":"siem.test". A successful test means Cloudraw finished the TLS handshake and wrote the message. Syslog has no reply, so check that the message actually arrived.

Troubleshooting

Generic HTTPS endpoint

Use this for any collector that accepts JSON over HTTPS, for example a log pipeline (Vector, Fluent Bit, Logstash HTTP input, Cribl) or your own service.

On your endpoint

1. Accept a JSON POSTCloudraw sends POST with Content-Type: application/json and this body, with up to 100 records per request: { "source": "cloudraw", "events": [ { "at": "…", "tenant": "…", "kind": "…", "action": "…", "severity": "…", "message": "…", "data": { … } } ] }
2. Check the token (recommended)If you set a token, Cloudraw sends Authorization: Bearer <token>. Reject requests without it.
3. Answer quickly with 2xxAny 2xx status means delivered. Anything else, including a redirect, counts as a failure and is retried. Answer within 8 seconds.
4. Use a valid certificateThe endpoint needs a certificate from a public CA on port 443, 8088, 8443 or 6514.

Cloudraw field → value

Test it

Click Test in Cloudraw. Your endpoint gets one request with one record whose action is siem.test. Cloudraw shows the HTTP status your endpoint returned.

Troubleshooting

Troubleshooting (all destinations)