--- title: SOC - Alert Ingestion (Webhook) - Template Playbook Overview slug: solutions/soc-alert-ingestion-webhook-template-playbook-overview docTags: createdAt: 2025-08-11T11:13:45.686Z --- This document provides detailed information about the **SOC - Alert Ingestion (Webhook) - Template** playbook, which ingests alerts via webhook events, processes them, and handles actions such as enrichment, correlation, and case creation. Users need to configure only the following components: - **Placeholder - Create TEDS Alert (Webhook)** - **Custom Alert Data Extension (Webhook)** - **Correlate (Webhook)** **Note:** These playbooks can and should be **duplicated** and the **Placeholder - Create TEDS Alert (Webhook)** component swapped out to match the technology stack in your organization. This ensures the playbook works seamlessly with your chosen vendor's tools. ## Overview - **Objective:** Automate webhook-based alert ingestion using Turbine logic to process alerts and transform them into actionable items. - **Key Workflow Steps:** 1. Alerts are ingested through webhook events. 2. Fetched alerts are standardized into TEDS objects. 3. Each alert undergoes deduplication, enrichment, and correlation. 4. Enriched and correlated alerts are used to create cases for investigation. ## Accessing the Playbook To access the playbook: 1. Navigate to **Orchestration** in the Swimlane platform. 2. Click on **Playbooks**. 3. Select **SOC - Alert Ingestion (Webhook) - Template**. ## Loop-Based Alert Processing in the Playbook The playbook processes alerts triggered by incoming webhook events. Here's how it works: 1. **Alert Ingestion:** A webhook endpoint captures incoming alerts and passes them to the playbook. 2. **Data Standardization:** The raw webhook data is transformed into TEDS-compliant objects using the **Placeholder - Create TEDS Alert (Webhook)** component. 3. **Deduplication:** Alerts are evaluated for uniqueness using the **Duplicate Alert Discovered (Webhook)** component to avoid redundant processing. 4. **Enrichment:** - The **Link Knowledge Base Articles (Webhook)** component associates relevant KBAs with the alert. - The **Enrich Observables (Webhook)** component adds Threat Intelligence data to the alert's observables. 5. **Correlation:** Enriched alerts are correlated with existing data using the **Correlate (Webhook)** component. 6. **Case Creation:** Based on predefined criteria, alerts are escalated into cases for further investigation. ## Configuring the Key Components of SOC - Alert Ingestion (Webhook) ### Placeholder - Create TEDS Alert (Webhook) **Purpose:** Converts raw webhook alert payloads into TEDS (Turbine Extendable Data Schema) objects for further processing. **Details:** This is a placeholder component that can be replaced with vendor-specific integration components (VICs) that output TEDS data. **Configuration:** - Open the **Placeholder - Create TEDS Alert (Webhook)** component. - Configure the component to receive webhook payload data: - The component receives the webhook payload automatically when a webhook event is triggered - Map fields from the webhook payload structure to the corresponding TEDS alert fields - Configure any required transformations or data mappings - Ensure all required TEDS fields are populated correctly for downstream processing. **Inputs:** - **Webhook Payload:** Raw JSON data from the webhook containing alert information. The webhook payload structure depends on your source system. Common fields in webhook payloads include: - Alert ID or unique identifier - Alert title or name - Alert description - Severity or priority level - Timestamp information - Source system information - Affected entities (IPs, hosts, users) - Additional vendor-specific fields **Note:** The webhook payload is automatically passed to the component when a webhook event is triggered. You need to configure field mappings within the component to extract data from the payload and map it to TEDS fields. **Outputs:** - `alert`: Standardized TEDS alert object containing the alert data, with fields such as: - `alert_uid`: Unique identifier for the alert - `alert_title`: Title or summary of the alert - `alert_description`: Detailed description of the alert - `alert_category`: Type of alert (e.g., phishing, malware, suspicious activity) - `alert_severity`: Severity level of the alert - `alert_risk_score`: Risk score associated with the alert - `alert_created_timestamp`: Timestamp when the alert was created - `alert_start_timestamp`: Alert start time - `alert_end_timestamp`: Alert end time (if applicable) - `alert_provider`: Source system or tool that generated the alert - `alert_organization`: Organization identifier - `alert_impacted_ip_addresses`: Array of affected IP addresses - `alert_impacted_hostnames`: Array of affected hostnames - `alert_impacted_usernames`: Array of affected usernames - `alert_mitre_attack_tactic_technique`: MITRE ATT\&CK mappings - `observables`: Array of observable entities extracted from the alert - `raw_alert`: Raw alert data from the webhook payload **Important Notes:** - The component automatically receives the webhook payload when an event is triggered - You must configure field mappings to extract data from your specific webhook payload format - The webhook payload structure varies by vendor - consult your source system's webhook documentation - Ensure the webhook endpoint is properly configured and secured - The component transforms the webhook payload into TEDS format according to the Alert schema **Example Webhook Payload Mapping:** If your webhook payload looks like: You would map: - `id` → `alert_uid` - `title` → `alert_title` - `severity` → `alert_severity` - `timestamp` → `alert_created_timestamp` - `source` → `alert_provider` ### Custom Alert Data Extension (Webhook) **Purpose:** Takes the raw JSON payload of the incoming alert and adds new fields to the alert TEDS object. **Configuration:** - Open the **Custom Alert Data Extension (Webhook)** component. - Define custom fields required for your organization's workflows. For example: - **Custom\_Alert\_ID:** A unique identifier for alerts in your system. - **Enriched\_Severity:** A recalculated severity score based on internal logic. - Map additional fields from the fetched alert data to these custom fields. - Ensure the output object is updated to include the new fields for correlation. **Inputs:** - **Raw Alert Data**: JSON payload of the incoming alert (from webhook payload or previous component output). **Outputs:** - **Enriched Alert TEDS**: Object containing the enriched alert fields, including: - **Custom\_Alert\_ID** - **Enriched\_Severity** - All standard TEDS alert fields - Any additional custom fields you've configured ### Correlate (Webhook) **Purpose:** Correlates the ingested and enriched alert data with existing data for better context and prioritization. **Configuration:** - Open the **Correlate (Webhook)** component. - Map fields from the enriched TEDS object to the correlation logic. Key fields include: - **Alert TEDS:** Object containing standardized alert data. - **Custom Data:** Object containing additional enriched fields. - Define correlation rules and logic. - Ensure the output object includes: - **CIM\_Tracking\_IDs:** An array of tracking IDs for correlation. - **Correlation\_Context:** Additional context generated during correlation. - Add correlation logic to the parallel node, followed by **Append Variable** and **Update Variable** nodes. **Inputs:** - **Enriched Alert TEDS**: Object containing enriched alert fields. - **Custom Data**: Object containing additional custom fields. **Outputs:** - **CIM\_Tracking\_IDs**: Array of tracking IDs for correlation. - **Correlation\_Context**: Additional contextual data. ## Testing and Validation 1. Simulate webhook events to test the playbook's behavior. 2. Validate that: - The webhook payload is correctly received and parsed. - The fetched alerts are correctly converted into TEDS objects. - Custom fields are populated as expected. - Correlation rules are applied correctly, and relevant data is matched. 3. Review the playbook's output to ensure the processed alerts are accurate and ready for case creation. 4. Debug and refine mappings as needed. **Testing Tips:** - Use the webhook trigger's test functionality to send sample payloads - Verify that your webhook endpoint is accessible and properly secured - Check that field mappings correctly extract data from your webhook payload format - Validate that the output alert objects contain all required TEDS fields - Test with various alert types and payload structures ## Deployment 1. Activate the playbook after testing. 2. Configure the webhook endpoint URL in your source system to point to the Turbine webhook trigger. 3. Monitor execution logs to ensure smooth operation. 4. Adjust configurations in the **Placeholder - Create TEDS Alert (Webhook)**, **Custom Alert Data Extension (Webhook)**, and **Correlate (Webhook)** components as requirements evolve. **Deployment Considerations:** - Ensure the webhook endpoint is properly secured (authentication, HTTPS) - Configure rate limiting if your source system sends high volumes of alerts - Set up proper error handling and alerting for failed webhook processing - Monitor webhook delivery and processing to ensure alerts are being received correctly - Consider implementing webhook signature verification for security This documentation outlines the configuration and usage of the **SOC - Alert Ingestion (Webhook)** playbook, focusing on the key components users need to configure.