A visualization of how data-ingestion works in SOAR

How Data Ingestion Works in SOAR

SOAR tools work as consolidation platforms for security alerts and incident response. Endpoint security tools, network security tools, email systems, and other tools collect logs, run detection rules and generate alerts. SOAR then ingests those alerts so teams can work out of a single platform for their incident response. One question first-time SOAR users often ask is, how do alerts go from their original data source into the SOAR platform? The most common method is a pull request from the SOAR tool to the original data source. The second method is having the original data source push the alerts to the SOAR tool via a webhook. Below, I will go into detail about each method.

Scheduled Pull Requests

The most common method for data ingestion in SOAR is to periodically send pull requests to the original data source. The frequency of these requests is set based on the organization’s needs.

At each scheduled interval, the SOAR tool queries the data sources for new or updated alerts. This is achieved by sending a GET or POST request to the API endpoints of these data sources. The requests are often designed to retrieve only new or updated information since the last check to maintain efficiency.

A screenshot showing scheduled data ingestion from D3 Smart SOAR to LogRhythm Axon, set to run every minute.

Scheduled data ingestion from D3 Smart SOAR to LogRhythm Axon, set to run every minute.

Once the data source responds, the SOAR tool ingests the alerts. This step involves parsing the received data (often in JSON format), extracting relevant information, and transforming it into a standardized format for consistent processing across different data types and sources.

A screenshot of Smart SOAR showing events returned from LogRhythm Axon.

Events returned from LogRhythm Axon.

Webhook

With this method, the original data sources push alerts directly to the SOAR platform using webhooks. This is usually preferred as data is only moving in one direction, making it a more reliable ingestion method. When a new alert is generated in the data source, it triggers the webhook and pushes it to the SOAR tool. Upon receiving the alert, the SOAR tool ingests, normalizes it, and stores it as an event. This process is similar to the pull request method, involving parsing, normalization, and initiating appropriate response workflows.

In Smart SOAR, each command can be turned into a public-facing API. When enabling this, the command can be triggered remotely from the original data source. When a new alert is generated, it can be automatically sent to Smart SOAR via this API.

A screenshot of Smart SOAR's integration tab highlighting where you can access the webhook authentication setup.

Screenshot: Webhook API key setup in Smart SOAR

The webhook method offers the advantage of faster response times, as alerts are pushed to the SOAR platform in real time. This is particularly beneficial for high-priority alerts that require immediate attention.

Key Takeaway

In summary, both the scheduled pull requests and push methods are effective in transferring alerts from various data sources into the SOAR platform. The choice between these methods depends on specific organizational needs and the capabilities of the original data source. Both methods can be used and when activated enhance the ability of SOAR tools to consolidate security alerts and provide a unified platform for incident response.

Powering the World’s Best SecOps Teams

Get Started with D3 Security