Webhooks Explained: What Are Webhooks? How Do They Work?

Combine the power of Webhooks and APIs to supercharge your security automation engine.

What are Webhooks?

Webhooks: you may have heard of this ubiquitous term in the world of web applications and modern technologies, but what are they and how do they help solve problems in security? If you’re not already using webhooks in your security automation, you may want to check out what solutions support this useful data strategy.

But before we get into the weeds of webhooks, it’s worth taking a moment to talk about two ways to integrate capabilities of various applications into your security stack.

APIs and Webhooks

Both of these technologies allow for you to get information from a software application, but the funnel of information is essentially inverted with the other.

With APIs (application programming interfaces), the receiver requests information from the application and gets a response. These requests can be scheduled or even automated based on custom logic through solutions like Swimlane Turbine. This communication methodology is often referred to as polling, and is quite common. APIs are an incredibly useful way to get information when you want it, or to take action with an application’s security response capabilities.

Webhooks, on the other hand, start with the source of the event. When something occurs in an application that supports webhooks, a request can be sent to a defined destination using an HTTP request. This allows you to receive this data as soon as the event occurs and the application sends the request.

For security automation, this is a game changer. Webhooks are the automation of the application interface world.

API Polling vs Webhooks in Security

When your security automation is structured to be triggered by events as they occur in your applications, you place your automation closer to the point of inception, which drastically improves your security posture. This is what the Active Sensing Fabric in Swimlane Turbine is all about. Viewed on a timeline (below), this is much more apparent.

With API polling, there are potential gaps where events can occur, but the destination application doesn’t know about them. Risk in these cases should be mitigated by increasing the frequency of the requests from the destination system, but will never be entirely eliminated.

For example, if your endpoint detection and response (EDR) solution detects malicious activity on an endpoint, security teams need to know about this as soon as possible. With API polling, we may miss an event that occurred immediately after a request, only to find that more events occurred after that when we request the next batch of events from the EDR solution or SIEM.

With Webhooks, the overhead of managing a request schedule isn’t necessary, since events will be sent to the destination as soon as the source emits the event as a webhook message.

In our endpoint detection example, as soon as the malicious activity is detected and logged, an event is then sent to the configured destination. This closes the gap between requests and eliminates the batching of events that can lead to missed or delayed detections.

Gap closure means quicker response times, which improves your key security metrics such as MTTD and MTTR. Put simply: The faster you can get the bad where it needs to go, the sooner you can address it.

(If you’d like to learn more about webhooks and their origins, Jeff Lindsey originally coined the term in 2007. Check out the archived version of their original article.)

Introducing: Turbine Webhook Triggers

Turbine makes implementing webhooks into your playbooks a breeze. As a built-in feature of playbooks, it only takes a few clicks and a description to create an active webhook trigger that will listen for events – no additional connectors or set up required. See it in action below.

Once you create your webhook trigger, you can send any data through a standard HTTP POST request to trigger your playbook and even map the data from the request itself to playbook actions. You can then take the automatically-generated webhook URL to your source application and configure it to begin sending events to Turbine as they happen.

Webhooks in Turbine playbooks also support authentication. You can ensure compatibility and compliance with your entire security application stack without sacrificing the convenience that Turbine’s webhooks offer.

APIs and Webhooks: The Security Automation Power-Duo

So, what is the right path for you? Fortunately, the answer is easy: Both APIs and Webhooks are powerful (and necessary) tools that should be utilized in your security automation toolset.

When crafting your automation, consider whether your automation should be triggered based on real-time events, as they occur. If so, triggering automation based on a stream of events using simple tools such as webhooks is a great strategy and should be favored over API polling strategies. When you don’t need real-time updates, the technology doesn’t support it, or would rather schedule the fetch of data, API polling is favorable.

Ultimately, when you pair the detection improvements enabled by webhooks and the powerful response capabilities offered by APIs through Turbine connectors, you can build a truly responsive event detection and remediation system and dramatically improve your security posture – with Turbine as your force multiplier for XDR.

Swimlane Turbine: Your XDR Force Multiplier

Download our whitepaper to learn more about how Swimlane Turbine is your force multiplier.

Download