Webhook Configuration

Introduction

Data Security can push events to external systems using webhooks — an HTTP POST request sent to a URL you configure, with no polling required on the receiving end. Webhooks are the delivery mechanism behind most of the SIEM/SOAR/EDR integrations in this section (for example, CrowdStrike and Splunk Enterprise); this page documents the underlying webhook configuration itself, independent of any specific vendor.

There are two distinct webhook mechanisms in the product, covering two different event scopes:

• Data Security event webhooks — deliver Ransomware Defender and Active Auditor threat/security events (per-event detail: affected user, client IPs, shares, files, severity, and lifecycle state). This is the mechanism SIEM/SOAR/EDR integrations build on.
• Eyeglass alarm webhooks — deliver general Eyeglass and PowerScale operational alarms (DR events, node/service alarms) through Settings → Notifications, alongside Slack and Rocket.Chat notification options.

Data Security Event Webhooks

Setup Steps

1. In the Data Security web interface, navigate to Integrations → Webhooks.
2. Click + Add Webhook (top right).
3. Name and Define Target: enter a Name for the webhook, the target URL of the system that will receive the POST request, and the application type, then click Next.
4. Define Triggers: configure the event filter for this webhook (see Filtering Events).
5. Configure Headers: add the Content-Type header with value application/json (and any additional headers your receiving system requires, such as an authentication token — see Authentication below).
6. Click Create to commit the webhook configuration. There is no separate Save button — Create on the final step saves and creates the webhook.

Recommended configuration

Filter to Critical and Major severities, and to lifecycle states that represent an actual containment decision (LOCKED_OUT, DELAYED_LOCKOUT) rather than every event. The goal is to forward actionable findings to your SOC tooling, not a firehose of every alarm.

Filtering Events

Webhook filters are configured per webhook and typically include:

Filter	Values	Purpose
Severities	Warning, Major, Critical	Limit delivery to events at or above a chosen severity.
Event / lifecycle states	LOCKED_OUT, DELAYED_LOCKOUT, and others	Limit delivery to events that represent a specific response state, rather than every state transition.
Event types	THREAT_DETECTION and others	Limit delivery to a specific detection source.

note

Detection mode determines which severities can be raised at all — align your webhook filter to your mode to avoid missing events it does generate, or over-filtering for severities it never raises:

Mode	Severities raised
Monitor	Warning only
Enforcement	Warning and Major — no Critical
Critical	Warning, Major, and Critical

See Threat Detectors for what each mode does once a severity is raised.

Payload

The webhook payload for a Data Security event is a JSON object with the following top-level fields (based on the Zero Trust sample test payload Superna provides for validating SIEM/SOAR integrations):

Field	Type	Description
id	string	Internal event ID.
severity	string	Current severity: WARNING, MAJOR, or CRITICAL.
state	string	Current lifecycle state, for example WARNING, DELAYED_LOCKOUT, or LOCKED_OUT.
user	string	The affected user's SID.
userName	string	The affected user in DOMAIN\user format.
clientIPs	array of strings	Source IP address(es) the activity was observed from.
files	array of strings	Full UNC paths of files involved in the detection.
numFiles	integer	Count of files involved.
shares	array of objects	Every affected share, including name, zone, path, neName (cluster name), and its permission entries before/after lockout.
nes	array of strings	Network elements (cluster names) involved in the event.
detected / detectedTime	string / integer (epoch ms)	When the event was first detected.
firstSignalTimeStamp	integer (epoch ms)	Timestamp of the first contributing signal.
lockedOut / lockedOutTime	string / integer (epoch ms)	When the lockout was applied, if applicable.
expiry / expiryTime	string / integer (epoch ms)	When the event or its snapshots expire.
archivedTime	integer (epoch ms)	When the event was archived, if closed.
actions	array of objects	The event's action/comment history — each entry has action, dateInLong, resultState, admin, and comment.
possibleActions	array of strings	Actions currently available for this event, for example Comment, Restore User Access, Create Snapshot, Archive As Unsolved.
signalStrengths	object	Per-detector contribution to the event, keyed by detector ID (for example THREAT_DETECTOR_07) with its numeric score.
peakMonitor / peakWarning / peakMajor / peakCritical	integers	Peak signal-strength value reached at each severity tier over the life of the event.
isRoot	boolean	Whether the affected user resolved to a root/superuser account.
monitorOnly	boolean	Whether the event was raised while in Monitor mode (no lockout applied).
isRSW / isAudit	booleans	Whether the event originated from Ransomware Defender vs. an Active Auditor/audit trigger.
isNFSMonitorMode / isSMBSnapshotEnabled	booleans	Protocol-specific mode and snapshot-enablement flags in effect when the event fired.
protocol	string	Protocol the activity was observed over, for example SMB2.
eventSource	string	Source system type, for example ISILON_CLUSTER.
nfsProtocols	array of strings	NFS protocol versions in use, if applicable.
rswExtensions	array of strings	Ransomware-associated file extensions detected (for example *.locky).
snapshots / deletedSnapshots	object / array	Snapshots taken for the event, keyed by cluster, with name, path, created, expires, state, and size per snapshot.
isAPIEvent	boolean	Whether the event was created via the API rather than by a detector.
extraParams	object	Additional event-specific data — see extraParams fields below for the fields added in 2.15.0.

note

This schema reflects the full internal event object sent to a webhook receiver — not every field is relevant to every integration. Most SIEM/SOAR integrations in this section only consume a subset (severity, user, client IPs, shares/files, and state) — see Filtering Events to limit payload volume, and consult the specific vendor integration page for which fields it maps to native fields on the receiving side.

extraParams fields

Starting in 2.15.0, extraParams includes the following fields. These are appended to the existing payload and do not affect existing integrations:

Field	Type	Description
alertType	string	The category of alert that raised the event: Threat Detection (Ransomware Defender or Active Auditor) or Threat Hunting (Threat Hunting anomaly detection).
threatCategory	string	The threat category name for the event (for example, Suspicious Extension).
threatDescription	string	A description of the behavior that triggered the event, so security teams can understand what happened without cross-referencing internal threat-category documentation.
source	string	Always Superna.
sourceType	string	Always JSON.

note

alertType also defines a Data Attack value, reserved for future integration with Data Attack Surface Manager (DASM). This value is not produced by any detector in the current release.

Authentication

Webhook delivery itself does not require an API token — the receiving endpoint is authenticated using whatever headers you configure in the + Headers section (for example, a bearer token or API key header required by your SIEM/SOAR ingestion endpoint). This is separate from the Zero Trust API, which uses its own api_key token for applications that poll or call Data Security directly, rather than receive pushed events.

Testing a Webhook

For Data Security 2.13 and later:

1. Navigate to Integrations → Webhooks.
2. Locate the webhook entry you configured.
3. Click Test Webhook (or Test, depending on release).
4. Verify the receiving system returns an HTTP response code of 200 or 201. Any other response code indicates a configuration issue on either side of the integration.

Manual testing (versions earlier than 2.13)

Send a sample payload manually using a curl command against your webhook URL, replicating the payload fields above. Confirm the current sample command with Superna Support if the built-in Test Webhook button is not available on your release.

Eyeglass Alarm Webhooks

In addition to Data Security event webhooks, Eyeglass has a separate, more general webhook mechanism used for Eyeglass DR events and PowerScale operational alarms. It uses a simpler, fully-documented alarm payload and can run alongside Slack and Rocket.Chat notification channels. The legacy path was Notification Center → Webhooks; in 2.15.0 this moved to Settings → Notifications → Webhooks.

Setup Steps

1. Open Settings (gear icon, top-right of any page) → Notifications.
2. Click the Webhooks tab.
3. Enter the URL of the target system that will receive the POST request.
4. Click + Headers to add any key-value header pairs required by the receiving system (for example, Content-Type: application/json, or a custom authentication header).
5. Click Test to verify the target system received a test event.

Once saved, all Eyeglass and PowerScale alarms matching your configuration are sent to the configured URL as webhooks.

Endpoint requirements

All webhook options in Settings → Notifications require the Eyeglass VM to reach the target URL over the network — outbound access to the Internet if the target is a hosted service. There is no support for routing through an OS-level proxy for these notification channels.

Payload Schema

Eyeglass alarm webhooks deliver a JSON object with the following structure:

{
  "Alarm": {
    "type": "object",
    "properties": {
      "source": { "description": "the source of the alarm", "type": "string" },
      "timestamp": { "description": "The timestamp when alarm was raised", "type": "integer", "format": "int64" },
      "severity": { "description": "severity of the alarm", "type": "string" },
      "sync_key": { "description": "sync_key", "type": "string" },
      "sync_group": { "description": "sync_group", "type": "string" },
      "message": { "description": "message", "type": "string" },
      "code": { "description": "code", "type": "string" },
      "extra_data": { "description": "alarm extra data", "type": "string" }
    }
  }
}

Example payload:

{
  "source": "Sample Source",
  "timestamp": 1667995921023,
  "severity": "INFORMATIONAL",
  "sync_key": "sbeca3_3",
  "message": "Actual Message",
  "code": "RSW0010",
  "extra_data": "{\"reason\":\"Node sbeca3_3 version does not correspond to eyeglass version\"}"
}

severity values follow the standard Eyeglass alarm levels: Critical, Error, Warning, and Informational.

Troubleshooting

Issue	Likely cause	Resolution
Webhook returns a non-200/201 response	The receiving endpoint is unreachable, misconfigured, or rejecting the request	Confirm the URL is correct and reachable from the Eyeglass VM, and that any required headers (Content-Type, auth token) match what the receiving system expects.
No events arriving despite a successful test	Event filter (severity/state/type) excludes the events you expect	Review the webhook's filter configuration — Monitor mode only raises Warning; Enforcement mode raises Warning and Major, never Critical; Critical mode raises all three. A filter set to Critical-and-above will see nothing in Enforcement mode.
Webhook works for alarms but not Data Security events (or vice versa)	The two webhook mechanisms are configured independently	Confirm you're configuring the correct one: Integrations → Webhooks for Data Security threat/security events, Settings → Notifications → Webhooks for general Eyeglass/PowerScale alarms.
Cannot reach target URL	Outbound network/firewall restriction, or reliance on an OS-level proxy	Verify outbound connectivity from the Eyeglass VM to the target URL. OS-level proxy routing is not supported for these notification channels.

See also

• API Guide — The Zero Trust API used for polling and direct action calls, as opposed to pushed webhook events.
• CrowdStrike Falcon Endpoint Security — Example SIEM/EDR integration built on Data Security event webhooks.
• Splunk Enterprise — Example SIEM integration built on Data Security event webhooks, including a working HTTP Event Collector setup.
• Integrations with Slack, Rocket.Chat, and Webhook for Notifications — Full setup and payload schema for Eyeglass alarm webhooks.