> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ghostable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# SIEM Audit Webhook Templates

> Reference mappings for ingesting Ghostable audit webhooks into Datadog, Splunk, and Elastic.

Use these templates to normalize Ghostable audit webhook events in your SIEM.

## Event Contract (input)

Ghostable sends JSON payloads with signed headers:

* `X-Ghostable-Timestamp`
* `X-Ghostable-Signature`

Validate signature first, then parse JSON.

Common payload fields:

* `id` (event id)
* `type` (event type)
* `occurred_at` (timestamp)
* `organization.id`
* `actor.id` / `actor.email`
* `target.project_id` / `target.environment_id`
* `metadata` (event-specific context)

## Recommended Normalized Fields

Map payloads into a stable schema:

| Normalized field            | Source                              |
| :-------------------------- | :---------------------------------- |
| `event.id`                  | `id`                                |
| `event.action`              | `type`                              |
| `event.created`             | `occurred_at`                       |
| `organization.id`           | `organization.id`                   |
| `user.id`                   | `actor.id`                          |
| `user.email`                | `actor.email`                       |
| `ghostable.project_id`      | `target.project_id`                 |
| `ghostable.environment_id`  | `target.environment_id`             |
| `ghostable.force_overwrite` | `metadata.force_overwrite`          |
| `ghostable.conflicts`       | `metadata.conflicts` (if available) |

## Datadog Template

1. Create an HTTP intake endpoint (or intermediary worker).
2. Verify signature before forwarding to Datadog Logs intake.
3. Add pipeline remappers:
   * `type` -> `event.action`
   * `id` -> `event.id`
   * `organization.id` -> `organization.id`
   * `actor.email` -> `usr.email`
4. Create monitors:
   * high rate of `push_force_overwrite`
   * webhook delivery failures
   * repeated version conflicts

Example Datadog facets to enable:

* `event.action`
* `organization.id`
* `ghostable.environment_id`
* `usr.email`

## Splunk Template

Use `sourcetype=ghostable:audit` and JSON extraction.

Suggested field aliases:

* `event_id` = `id`
* `event_type` = `type`
* `org_id` = `organization.id`
* `actor_email` = `actor.email`

Example SPL alerts:

```spl theme={null}
index=security sourcetype=ghostable:audit type=push_force_overwrite
| stats count by organization.id, actor.email
| where count > 5
```

```spl theme={null}
index=security sourcetype=ghostable:audit type=version_conflict
| timechart span=15m count by organization.id
```

## Elastic Template

Map to ECS-compatible fields where possible:

* `id` -> `event.id`
* `type` -> `event.action`
* `occurred_at` -> `@timestamp`
* `actor.email` -> `user.email`
* `organization.id` -> `organization.id`

Recommended ingest pipeline processors:

1. `json` processor (if body wrapped as string)
2. `date` processor for `occurred_at`
3. `rename` processors for ECS fields
4. `set` processor for `event.dataset=ghostable.audit`

Example KQL:

```text theme={null}
event.dataset:"ghostable.audit" and event.action:"push_force_overwrite"
```

## Operational Checks

* Validate signatures and enforce timestamp drift checks before ingest.
* Deduplicate by `id` to reduce replay noise.
* Keep a dashboard for:
  * overwrite activity (`push_force_overwrite`)
  * conflict frequency (`version_conflict`)
  * webhook delivery reliability using Ghostable metrics endpoint.
