Playbook Polling - Administrator Guide - 6.10 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Product
Cortex XSOAR
Version
6.10
Creation date
2022-10-13
Last date published
2023-09-13
Category
Administrator Guide

When working with third-party products (such as detonation, scan, search, etc.) you may need to wait for a process to finish on the remote host before continuing. In these cases, the playbook should stop and wait for the process to complete on the third-party product, and continue when it is done. You may not achieve this via integrations or automations due to hardware limitations.

To use polling, Cortex XSOAR comes out-of-the-box with the GenericPolling playbook, which periodically polls the status of a process being executed on a remote host, and when the host returns that the process execution is done, the playbook finishes execution.

The GenericPolling playbook is used as a sub-playbook to block the execution of the master playbook until the remote action is complete. There are a number of playbooks that use the GenericPolling playbook that come out-of-the box, or installed from a content pack such as:

Generally polling is used in the following circumstances:

  • File detonation in a sandbox

  • URL detonation

  • Queries that take a long time to complete

Polling prerequisites

You need to use the GenericPolling playbook as a sub-playbook in a master playbook. The main playbook should follow this structure:

  1. Start Command: The task contains a command that fetches the initial state of the process and saves it to context. This command starts the process that should be polled.

  2. Polling Command: The task contains the GenericPolling sub-playbook that polls for an answer.

  3. Results Task: Returns the results of the operation. The task contains the results that were polled, which are added to context.

For information about the GenericPolling playbook inputs, such as Ids, Interval, and dt, etc., see Playbook inputs.

Limitations of Generic Polling

  • Global Context is not supported.

  • Does not run from the Playground.

  • The GenericPolling playbook uses the ScheduleGenericPolling automation, which supports only a list argument.

    genericpolling-limitations.png

Troubleshoot Polling

  • The playbook is "stuck" on Waiting for polling to complete

    As generic polling schedules tasks are outside the context of the playbook (not visible in the playbook run), errors may appear only in the War Room. Go to the War Room of the incident and check for errors or warnings related to GenericPolling tasks.

  • The GenericPolling task completes but the status has still not "finished".

    If the timeout is reached, the playbook successfully finishes even if there are items that did not complete. Try increasing the timeout value for the GenericPolling task.

  • The integration returns an ID not found error when running from the GenericPolling sub-playbook, but when running manually, it finishes successfully

    Some products cannot handle consecutive requests to query an action status right after the request to perform the action. After you initiate the action, try adding a Sleep task before calling the GenericPolling sub-playbook.