Shipping RASP Events to Your SIEM Using OCSF Format

Runtime security events are only useful if your SOC team can see them in the same interface they use for everything else. An alert sitting in a vendor's private dashboard that requires context-switching away from the primary SIEM is an alert that gets missed. This is why Raven.io's event format is built on OCSF — the Open Cybersecurity Schema Framework — and why the first SIEM integration question we ask new customers is "What are you already using?"

OCSF is a schema standard developed by Amazon Security Lake and partners including IBM Security, CrowdStrike, and Splunk. It defines a common JSON schema for security events across categories: network activity, file activity, process activity, database activity, and more. An OCSF-formatted event from Raven.io uses the same field names and event types as OCSF-formatted events from your network security tools, which means one set of SIEM correlation rules covers both.

What Raven.io Events Look Like in OCSF

Each Raven.io runtime event maps to an OCSF event class. A SQL injection attempt maps to OCSF class 1001 (Database Activity) with activity type "Query" and the detection details in the unmapped extension field. A path traversal attempt maps to OCSF class 1001 (File System Activity) with activity type "Read" and the blocked path in file.path. A subprocess execution from a web handler maps to OCSF class 1007 (Process Activity) with full call stack in the process.parent chain.

A full Raven.io SQL injection event in OCSF format:

{
  "class_uid": 1001,
  "class_name": "Database Activity",
  "activity_id": 1,
  "activity_name": "Query",
  "time": 1705123456789,
  "severity_id": 4,
  "severity": "High",
  "status_id": 2,
  "status": "Blocked",
  "app": {
    "name": "payment-service",
    "version": "2.1.4"
  },
  "actor": {
    "user": { "uid": "req-session-abc123" },
    "session": { "uid": "web-req-xyz789" }
  },
  "database": {
    "type": "PostgreSQL",
    "instance": "prod-db-1"
  },
  "query": {
    "sanitized": "SELECT id FROM users WHERE id = ?",
    "anomaly": "UNION SELECT clause injected"
  },
  "unmapped": {
    "ravenio_rule": "SQL_INJECTION_UNION",
    "call_stack": ["UserController.getUser", "QueryBuilder.build"],
    "original_query_hash": "sha256:abc..."
  }
}

The sanitized query field contains the query template with values replaced by ? — Raven.io never logs actual query values (which may contain PII). The anomaly field describes the deviation. The full original query hash allows correlation with other log sources without exposing the query content.

SIEM Integration Patterns

Splunk. Raven.io ships events to a Splunk HTTP Event Collector (HEC) endpoint. OCSF events index as structured JSON. A pre-built Splunk app (available in Splunkbase) includes dashboard panels for blocked events by type, anomaly trends by application, and correlation alerts for multi-stage attack patterns. Raven.io event type maps to Splunk CIM (Common Information Model) fields for compatibility with Splunk Enterprise Security correlation searches.

Elastic Security. Raven.io events ship to an Elasticsearch ingest pipeline via Logstash or the Elastic Agent data shipper. The OCSF event schema maps to Elastic Common Schema (ECS) fields through a published mapping table. The ingest pipeline applies the mapping automatically. Kibana dashboards using ECS field names work with Raven.io events without modification.

Datadog Security. Raven.io ships events to the Datadog Agent's API via the Logs API or directly through the Raven.io-Datadog integration. Events appear in Datadog Security Signals and in Log Management. Datadog's CSPM (Cloud Security Posture Management) rules can reference Raven.io events for runtime context in posture findings.

Microsoft Sentinel. Events ship via Azure Event Hub to the Sentinel workspace. A published Azure Function handles the OCSF-to-Sentinel schema mapping. Sentinel analytics rules can join Raven.io events with Azure AD audit logs and Azure Defender alerts for cross-signal correlation.

Writing Correlation Rules Against RASP Events

The value of runtime events in a SIEM goes beyond individual alerts. Correlation rules that join RASP events with other security data sources identify attack patterns that neither source catches alone.

Example correlation: a Raven.io event showing a blocked SQL injection attempt from IP X, followed within 10 minutes by a successful login from IP X through a different endpoint. The injection failed, but the attacker found another path. In isolation, the failed injection is a low-priority blocked event, and the login is a normal event. Together, they indicate an active attacker testing the application perimeter.

A Splunk SPL rule for this pattern:

index=ravenio status=Blocked
| stats count AS blocked_attempts BY src_ip, _time
| join src_ip [
    search index=auth_logs action=login result=success
  ]
| where _time - auth_time < 600
| table src_ip, blocked_attempts, user, auth_time

This kind of multi-source correlation is what makes SIEM-integrated runtime telemetry more valuable than a standalone RASP dashboard. The signal is not just "this attack was blocked" — it is "this blocked attacker subsequently succeeded somewhere else."

Alert Tuning and Suppression

A common concern about RASP SIEM integration is alert volume. An application under heavy scanner traffic can generate thousands of blocked events per hour from automated SQLi and path traversal probes. Flooding the SIEM with automated scanner noise creates the alert fatigue that makes the SIEM useless for detecting real attacks.

Raven.io addresses this through two mechanisms. First, automated scanner suppression: the agent detects scanner traffic patterns (sequential probe requests, known scanner User-Agent strings, IP addresses with high request volume to blocked paths) and tags those events as scanner_probe: true. SIEM ingest pipelines can filter or downgrade these events to a separate index. Second, event deduplication: multiple blocked events from the same source IP against the same attack vector within a configurable time window are collapsed into a single aggregated event with a count field.

For most production deployments, the relevant events that require SOC attention number in the single digits per day after scanner suppression and deduplication. The volume is manageable. The signal-to-noise ratio is high enough to make runtime SIEM integration genuinely useful rather than a source of alert fatigue.

Incident Response with RASP Forensics

When an incident is being investigated, Raven.io events provide forensic detail that application logs typically do not include. For each blocked or allowed anomalous event, the agent records: the full code call stack at the time of the operation, the source IP and session token, the exact SQL/file/network operation that was intercepted, and the baseline deviation score that triggered the alert.

This detail answers the questions that matter in incident response: which code path was exploited, which user session was involved, exactly what data was accessed, and whether similar events occurred before the blocking rule was triggered. RASP forensics turn post-incident investigation from evidence reconstruction into evidence retrieval.