# Bindplane Integration for Google SecOps
This repository contains the architecture, automation, and setup scripts for deploying an OpenTelemetry-based telemetry pipeline using Bindplane OP. The primary objective is to route logs to Google SecOps (filtered for cost-optimization) and Google Cloud Storage (GCS) for full raw retention, while providing an automated incident rehydration capability through Google SecOps.
# Code
https://github.com/Darrenswift/secops-incident-response
## Project Structure
- `setup_scripts/create_bindplane_pipeline.py`: Python script to programmatically create Bindplane pipelines via the REST API.
- `soar_integration/bindplane_soar_integration.py`: Custom Siemplify (Google SecOps SOAR) Python integration to automate incident log rehydration.
- `docs/architecture-design.md`: Overview of the primary routing and incident rehydration architectures.
- `docs/automation-guide.md`: Guide on automating the rehydration workflow via API and SOAR.
- `docs/incident-rehydration-runbook.md`: Standard operating procedure (SOP) for SOC analysts to invoke rehydration manually or via SOAR.
- `examples/routing.pipeline.json` & `examples/incident-rehydration-pipeline.json`: Example pipeline configurations.
## Pipeline Architectures
### 1. Standard Log Routing Pipeline
- **Goal:** Route telemetry data to Google SecOps (filtered) and GCS (unfiltered).
- **Reduction:** Uses filters to drop noisy events before sending to SecOps, significantly reducing ingestion costs.
- **Retention:** Sends 100% of raw logs to a GCS bucket for long-term compliance and future rehydration.
### 2. Incident Rehydration Pipeline
- **Goal:** Replay archived, unfiltered telemetry from GCS back into Google SecOps during an active investigation.
- **Process:** Configures a dedicated rehydration agent to pull logs for a specific time window. Overrides the namespace (e.g., `your-company-incident`) to easily identify rehydrated logs within SecOps.
## Setup Instructions
### 1. Bindplane Setup
Use the provided Python setup script to create your pipelines programmatically:
```bash
python3 setup_scripts/create_bindplane_pipeline.py \
--api-key "YOUR_BINDPLANE_API_KEY" \
--project-id "YOUR_BINDPLANE_ACCOUNT_ID" \
--customer-id "YOUR_SECOPS_CUSTOMER_ID" \
--gcs-bucket "YOUR_GCS_ARCHIVE_BUCKET" \
--gcp-project "YOUR_GCP_PROJECT_ID"
```
*Alternatively, you can manually import the provided `.json` files directly into the Bindplane UI or simply create this within the Bindplane UI without importing .json*
### 2. SOAR Integration Setup (Google SecOps SOAR)
To automate the rehydration process in response to alerts, import the custom action into Siemplify:
1. Open Google SecOps SOAR -> **Settings** -> **Integrations** -> **IDE**.
2. Click **Add Integration** named `BindplaneOP`.
3. Set the Environment Parameters: `API URL`, `API Key`, and `Account ID`.
4. Click **Add Action** named `Rehydrate Incident Logs`.
5. Under the **Parameters** tab for this Action, add the following parameters:
- `Pipeline Name` (String, Default: `incident-rehydration-pipeline`)
- `Rehydration Agent ID` (String, Mandatory)
- `Start Time (UTC)` (String, Mandatory) -> **Use Placeholder: `[Event.Start Time]`**
- `End Time (UTC)` (String, Mandatory) -> **Use Placeholder: `[Event.End Time]`**
6. Paste the contents of `soar_integration/bindplane_soar_integration.py` into the editor, then **Save**.
### 3. Setting Up the SOAR Request Form
To allow SOC analysts to easily trigger rehydration on-demand, you need to configure a Request Form in Google SecOps SOAR that captures the exact time window.
1. Navigate to **Settings** -> **Portal** -> **Request Forms** (or **Settings** -> **Requests** depending on your version).
2. Click **Add Request Form** and name it `Incident Response Log Rehydration`.
3. Add the following **Mandatory Custom Fields**:
- `Start Time` (Type: String)
- `End Time` (Type: String)
4. **Crucial Formatting:** It's best practice to add placeholder text or a description to these fields such as `[FORMAT] YYYY-MM-DDTHH:MM:SSZ` so analysts know how to input the time.
5. In the form's configuration, set it to automatically trigger your Rehydration Playbook upon submission.
> [!NOTE]
> **Timestamp Sanitization "Magic":** The Bindplane UI and API handle time windows differently. While the UI is flexible, passing seconds, milliseconds, or a trailing `Z` directly to the Bindplane API configuration can cause the agent to fail. To make this robust, the custom `bindplane_soar_integration.py` includes a `format_bindplane_time` function. It automatically parses common SOAR formats (Unix epoch ms/s, ISO 8601, standard strings) and rigidly truncates them down to the exact `YYYY-MM-DDTHH:MM` format required by the Bindplane source parameters. This ensures the integration rarely fails due to analyst typos.
### 4. Playbook Execution Workflow
Once the form is configured, the operational flow is completely hands-off:
1. A SOC analyst fills out the "Incident Response Log Rehydration" request form, providing the Environment, Start Time, End Time, and Priority.
2. SOAR automatically creates a Case and attaches your Bindplane playbook.
3. The playbook extracts the `Start Time` and `End Time` from the request form and passes them to the custom Bindplane Integration action.
4. The integration contacts the Bindplane API to dynamically update the time window on the GCS source.
5. The integration forcefully assigns the configuration to your dormant rehydration agent.
6. The agent wakes up, immediately pulls the requested logs from GCS, and pushes them into Google SecOps.
## Deep Dive: How the Python Integration Works
For technical users and engineers looking to understand or modify the SOAR automation, the `bindplane_soar_integration.py` script performs a highly specific sequence of API calls and data formatting to ensure a flawless rehydration process:
1. **Parameter Extraction & Dynamic Hunting:** The script extracts the API credentials and time windows. If the SOAR platform fails to resolve a placeholder (e.g., `[Alert.StartTime]`), the `get_dynamic_field` function actively hunts through the Case's Custom Fields, Alert Custom Fields, and Additional Properties to locate the requested data dynamically.
2. **Timestamp Sanitization:** As noted above, the `format_bindplane_time` function intercepts the raw timestamps. It normalizes various time formats (Epoch timestamps, ISO 8601 with milliseconds, standard strings) and rigidly formats them down to the strict `YYYY-MM-DDTHH:MM` string required by the Bindplane source parameters.
3. **Resource Fetching:** Bindplane OP requires all associated resources to be submitted together. The script performs `GET` requests against `/configurations/{pipeline_name}`, `/sources`, and `/destinations` to pull the live state of the pipeline, the GCS Source, and the Google SecOps Destination.
4. **Parameter Injection:**
- It strips any existing `starting_time` and `ending_time` from the GCS Source and injects the newly formatted time window.
- It injects the `your-company-incident` namespace into the Google SecOps Destination parameters to ensure the rehydrated logs are tagged correctly.
5. **Blueprint Application:** The script bundles the modified Configuration, Source, and Destination objects and submits a `POST` request to `/v1/apply` to update the Bindplane Control Plane.
6. **Rollout Execution:** It executes a `POST` to `/rollouts/{pipeline_name}/start` to ensure the new configuration is actively rolled out.
7. **Agent Deployment:** Finally, the script performs a `PATCH` request to `/agents/labels` using `"overwrite": True`. This forcefully assigns the target rehydration Agent ID to the updated configuration, instantly waking it up to pull the requested logs from GCS.
