Cisco PSIRT openVuln

Cisco Secure Access

Cisco Secure Email Threat Defense

Cisco Secure Endpoint

Cisco Threat Response

Cisco Umbrella (v2)

Cisco Vulnerability Management

Cisco XDR: Analytics

Cisco XDR: Automate

Cisco XDR: Investigate

Ivanti Neurons for MDM

PagerDuty

The target has been provided by the Secure Endpoint Integration Module and does not require an Account Key selection.

Information about duplicate GUIDs will be listed and stored in the output variable Duplicate_GUIDs_Output. Also, listed in the output of the python execution. The output is in JSON format and can be easily copied and pasted into Microsoft Excel or Google Sheets for further analysis.

Cisco Secure Endpoint - Find Duplication GUIDs

This workflow appears in the pivot menu and allows you to add a mobile device to a static group in Jamf Pro. Supported observables: hostname, MAC address, serial number.

Target: Jamf Pro

Steps:
* Determine which observable type was provided (if none provided or unsupported, end the workflow)
* Search for a matching mobile device
* Check if the mobile device was found (if not, end the workflow)
* Extract the first mobile device ID
* Attempt to add the mobile device to the static group
* Check if adding to the group was successful:
  * If it wasn't, output an error

Jamf Pro - Add Mobile Device to Static Group

The name of the static mobile device group to add devices to

Group Name

This workflow appears in the pivot menu and allows you to enable a user in Microsoft Entra ID using their email or username. Supported observables: email, user. Note that a "user" observable can contain a SAM account name or user principal name

Target: Microsoft Entra ID

Steps:
* Determine which observable type was provided
* Search for a matching user
* Check if the user was found:
    * If not, end the workflow
* Extract the user ID
* Attempt to enable the user
* Check if enabling the user was successful:
    * If it wasn't, output an error

Microsoft Entra ID - Enable User

This incident response workflow allows you to create an incident ticket in ServiceNow from a playbook or using an automation rule. When using this workflow in a playbook, the user executes the workflow and a ticket is created. When using this workflow with an incident automation rule, the ticket is created as soon as the workflow is executed. The workflow will also set the XDR incident's status to Incident Reported.

Target: Conure APIs, Platform APIs, Private Intelligence API, ServiceNow

Steps:
* Get the incident summary
* Parse the incident's attributes
* Check if a ticket already exists for this incident:
    * If it does, update the workflow results and continue
    * If it doesn't:
        * Create the ticket and update the workflow result
        * Update the incident's external references
* Update the incident's status to Incident Reported

ServiceNow - Create Ticket for Incident

The user ID of the ServiceNow user to list in incidents as the caller (the person reporting the incident). This should be the username of a valid ServiceNow user

Caller User ID

An optional user to assign new incidents to in ServiceNow. This should be the user's ServiceNow username

Assignee

An optional group to assign new incidents to in ServiceNow

Assignment Group

### Step 1: Install the Workflow

- Ensure you have the Splunk Enterprise integration enabled in XDR.
- Install the workflow from the XDR automation Exchange.

### Step 2: Configure the input variables

**- Input - Splunk - Index** : Enter the Splunk Index to retrieve events.
To search all events, use "*". Note: This is not recommended for scalability.

**- Input - Splunk - Template X** : Set to true if you want to use the template for the search query. Only one template can be enable. To use the workflow on multiple template you need to link this workflow to a different trigger/schedule

Templates exist for : Corelight (Notice and Suricata), Endace, Cisco Secure Firewall (Intrusion and SI),  Palo Alto Firewall (Intrusion), Zscaler ZIA, Meraki MX, Cisco SNA, Sophos EPP, Symantec EPP, ThousandEyes Alerts.

**- Input - Splunk - Custom Search Query** : Set to true if you want to use a custom search query instead of an existing template and fill the input variable "Input - Splunk - Custom Search Query Content"

**- Input - Splunk - Custom Search Query Content** : Only if "Input - Splunk - Custom Search Query" is true and you don't want to use a predefined template. Replace X in the Search Query template with the correct value or fiedname or with the value "null" if the field doesn't exist.

**Template :** 
*index=X
| rename X as event_severity | eval event_severity=if(event_severity=*,"High","Unknown")))
| rename X as sighting_name
| rename X as indicator
| rename X as src_ip | eval src_ip=if(src_ip!="",'src_ip',"null")
| rename X as src_port | eval src_port=if(src_port!="",'src_port',"null")
| rename X as dest_ip | eval dest_ip=if(dest_ip!="",'dest_ip',"null")
| rename X as dest_port | eval dest_port=if(dest_port!="",'dest_port',"null")
| rename X as mitre_tactic | eval mitre_tactic=if(mitre_tactic!="",'mitre_tactic',"null")
| rename X as mitre_technique | eval mitre_technique=if(mitre_technique!="",'mitre_technique',"null")
| rename _time as splunk_time
| rename X as URL | eval URL=if(URL!="",'URL',"null")
| rename X as domain | eval domain=if(domain!="",'domain',"null")
| rename X as IngressInterface | eval IngressInterface=if(IngressInterface!="",'IngressInterface',"null")
| rename X as EgressInterface | eval EgressInterface=if(EgressInterface!="",'EgressInterface',"null")
| rename X as action | eval action=if(action!="",'action',"null")
| rename X as proto | eval proto=if(match(URL,":443"),"https",if(domain!="","http","null"))
| rename X as Various1 | eval Various1=if(Various1!="",'Various1',"null")
| rename X as Various2 | eval Various2=if(Various2!="",'Various2',"null")
| rename X as sha256 | eval sha256=if(sha256!="",'sha256',"null")
| rename X as user | eval user=if(user!="",'user',"null")
| rename X as filename | eval filename=if(filename!="",'filename',"null")
| rename X as hostname | eval hostname=if(hostname!="",'hostname',"null")
| table sourcetype event_severity sighting_name indicator src_ip dest_ip src_port dest_port mitre_tactic mitre_technique splunk_time URL domain IngressInterface action proto Various1 Various2 filename EgressInterface sha256 user hostname
| sort +sighting_time*

**- Input - Splunk - Custom SourceType** : Use this field if the Splunk SourceType is different than the one predefined in the template

**- Input - XDR - Default Mitre Tactic** : Set the default Mitre Tactic  ID to use in incident if not existing in the log or if the workflow can't deduce it from the indicator name

**- Input - Firewall Logs - Outside Interface Name** : Only for Secure Firewall and Palo Alto, set the name of the Outside interface (case sensitive)

**- Input - Firewall Logs - Span Interface Name** : Only for Secure Firewall and Palo Alto, set the name of the Span interface (case sensitive)

**- Input - Workflow Run Interval** : Set this value to reflect the schedule interval (in minutes) Ex : if you schedule the workglow to run every 5 minutes, set this value to 5, if you schedule the workglow to run every 1 hour , set this value to 60

**- Input - XDR - Update Closed Incident** : On new detections with similarity with an existing incident, define the behaviour if the existing incident has a status closed* If set to true : The incident will be updated with the new detection. If set to false : A new incident will be created (except for Closed FP and Closed Near Miss).
requiers the deployment and the configuration of the workflow : **"Splunk - Create XDR incident - Update History Table"**.

### Step 3: Automate the Workflow
When prompted to "Automate it," you can add a scheduled automation rule.
**For example, set the automation to run at a 5-minute **interval.****

Splunk Cloud - Create XDR Incident v2 - from Template

Template for Cisco Secure Firewall - Security Intelligence logs collected via Syslog - IP, DNS and URL (only one template can be set to true)

Input - Splunk - Template Secure Firewall Syslog - SI

Template for Corelight Notice logs (only one template can be set to true)

Input - Splunk - Template Corelight Notice

Template for Corelight Suricata logs (only one template can be set to true)

Input - Splunk - Template Corelight Suricata

Template for ThousandEyes (only one template can be set to true)

Input - Splunk - Template ThousandEyes

Template for Palo Alto Firewall Intrusion logs (only one template can be set to true)

Input - Splunk - Template Palo Alto - Intrusion

Template for Endace "Password found in clear text" logs (only one template can be set to true)

Input - Splunk - Template Endace Password Found

On new detections with similarity with an existing incident, define the behaviour if the existing incident has a status closed*
If set to true : The incident will be updated with the new detection. 

If set to false :A new incident will be created (except for Closed FP and Closed Near Miss). requiers the workflow : "Splunk - Create XDR incident - Update History Table" attached to an incident trigger with no filter

Input - XDR - Update Closed Incident

Template for Zscaler ZIA logs -  (only one template can be set to true)

Input - Splunk - Template Zscaler

Enter the name of the Outside Interface (firewall logs only)

Input - Firewall Logs - Outside Interface Name

Template for Endace Notice logs (only one template can be set to true)

Input - Splunk - Template Endace

Enter the Splunk index for the collected log or *

Input - Splunk - Index

Set the default mitre tactic ID to use if not found in log and unable to deduce from indicator (ex : TA0040)

Input - XDR - Default Mitre Tactic

Set to true if you want to use a custom search query instead of an existing template

Input - Splunk - Custom Search Query

Template for Cisco Secure Firewall Intrusion logs collected via Syslog -  (only one template can be set to true)

Input - Splunk - Template Secure Firewall Syslog - Intrusion

Template for Sophos Endpoint Web logs -  (only one template can be set to true)

Input - Splunk - Template Sophos Endpoint - Web

Use this field if the Splunk SourceType is different than the one defined in the template

Input - Splunk - Custom SourceType

Template for Cisco Secure Firewall Intrusion logs collected via Estreamer -  (only one template can be set to true)

Input - Splunk - Template Secure Firewall Estreamer - Intrusion

Template for Cisco Secure Network Analytics (only one template can be set to true)

Input - Splunk - Template Cisco SNA

Use only if you don't use any template. Respect the template and replace X with the correct value/field name

Input - Splunk - Custom Search Query Content

Set this value to reflect the schedule interval (in minutes)
Ex : if you schedule the workglow to run every 5 minutes, set this value to 5, if you schedule the workglow to run every 1 hour , set this value to 60

Input - Workflow Run Interval

Template for Cisco Secure Firewall - Security Intelligence logs collected via Estreamer - IP, DNS and URL (only one template can be set to true)

Input - Splunk - Template Secure Firewall Estreamer - SI

Template for Meraki MX Intrusion logs (only one template can be set to true)

Input - Splunk - Template Meraki Intrusion

Enter the name of the SPAN Interface (firewall logs only)

Input - Firewall Logs - Span Interface Name

Template for Sophos Endpoint Threats logs -  (only one template can be set to true)

Input - Splunk - Template Sophos Endpoint - Threats

Timestamp to date

Calculate Timestamp 

Firewall Logs - Identify Asset Ip , Observable IP, Direction

XDR Incidents - Update Mitre TTP

Splunk - Generate Query

Cisco XDR - Create Incidents - Update History V2 Table

Cisco XDR - Extract data from Incident

Splunk - Get Search Results - Custom

This workflow is designed to be executed when an incident is resolved and ready to be closed. The workflow will export the incident summary to a supported product and then mark the incident as closed. Currently supported products include: Elastic Cloud, Google SecOps, Microsoft Sentinel, Splunk Cloud, and Splunk Enterprise.

Targets: Automation APIs, Conure APIs, Platform APIs, Elastic Cloud, Google SecOps Ingestion API, Microsoft Sentinel Ingestion, Splunk Cloud, Splunk Enterprise

Steps:
- Check how the workflow was started (if not playbook, end the workflow)
- Get a list of XDR automation targets and extract the supported integrations
- Check if there are supported integrations available (if not, end the workflow)
- Fetch the incident summary (if this fails, end the workflow)
- For each integration:
  - Attempt to export the incident summary to the integration
- Set the incident's status to closed

XDR - Close and Export Incident

prod-nam

prod-eu

prod-apjc

This workflow consumes one or more hostnames and attempts to isolate matching endpoints in all supported products. Currently supported products include: Cisco Secure Endpoint, CrowdStrike, SentinelOne, Microsoft Defender for Endpoint (Commercial or GCC), Trend Vision One, Cybereason, Palo Alto Cortex, and Darktrace /NETWORK.

Targets: Automation APIs, Cisco Secure Endpoint, CrowdStrike, SentinelOne, Microsoft Defender for Endpoint (Commercial or GCC), Trend Vision One, Cybereason, Palo Alto Cortex, Darktrace /NETWORK

Steps:
- Check how the workflow was started (if not a playbook task, end the workflow)
- Get a list of XDR automation targets and extract the supported integrations
- Check if there are supported integrations available (if not, end the workflow)
- For each hostname:
  - For each integration:
    - Attempt to isolate the host in the given integration
  - Check if the host was isolated in at least one product (if not, update the workflow results)

XDR - Contain Incident: Assets

This workflow consumes one or more URLs and attempts to block them in all supported products. Currently supported products include: Cisco Secure Access, Cisco Umbrella, Cisco XDR (intelligence feeds).

Cisco XDR intelligence feeds can be used by other products, such as firewalls, to fetch lists of observables from XDR for use in policies.

Targets: Automation APIs, Platform APIs, Private Intelligence API, Cisco Secure Access, Umbrella

Steps:
- Check how the workflow was started (if not a playbook task, end the workflow)
- Get a list of targets and extract the supported integrations
- Check if there are supported integrations (if not, end the workflow)
- For each integration:
  - Complete setup as needed depending on the integration
- For each URL:
  - For each integration:
    - Attempt to block the URL in the given integration
    - If the new Cisco Umbrella module is not available, try the legacy one
  - Check if the URL was blocked in at least one product (if not, update the workflow results)

XDR - Contain Incident: URLs

This workflow consumes one or more usernames or email addresses and attempts to restore matching users in all supported products. Currently supported products include: Cisco Duo, Microsoft Entra ID.

Targets: Automation APIs, Cisco Duo, Microsoft Entra ID

Steps:
- Check how the workflow was started (if not a playbook task, end the workflow)
- Get a list of XDR automation targets and extract the supported integrations
- Check if there are supported integrations available (if not, end the workflow)
- For each observable:
  - For each integration:
    - Attempt to re-enable the user in the given integration
  - Check if the user was re-enabled in at least one product (if not, update the workflow results)

XDR - Restore Users

This workflow validates the configuration of Cisco XDR intelligence feeds and their associated indicators. If the objects requested don't exist, they will be created. If they do exist, their IDs and URLs will be returned.

Targets: Private Intelligence API

Steps:
[] Search for indicators
[] Check if a matching indicator was found:
[]> If it was, extract the ID and set the output variable
[]> If it wasn't, create the indicator and set the output variable
[] Search for feeds
[] Check if a matching feed was found:
[]> If it was, extract the ID and view URL and set the output variables
[]> If it wasn't, create the feed and set the output variables

Automation

A powerful low-to-no-code approach that allows your SOC to start automating complex tasks on day one.

Installable workflows

Built-in workflows

Built-in actions