is a Security Orchestration, Automation, and Response (SOAR) system. The platform combines security infrastructure orchestration, playbook automation, and case management capabilities to integrate your team, processes, and tools to help you orchestrate security workflows, automate repetitive security tasks, and quickly respond to threats.
See Also
Start with Investigation in Splunk SOAR (Cloud)Managing cases in SOARSplunk SOAR (Cloud) introduction - Splunk DocumentationWhat’s Splunk Doing With AI? | SplunkUse this manual if you're a Security Operations Center (SOC) staff member, analyst, or manager who is not primarily a administrator.
The following diagram shows the end-to-end flow of security automation in .
In this example, there are three apps in a environment. Each app provides at least one action.
- The MaxMind app provides an action to find the geographical location of an IP address.
- The PhishTank app provides an action to find the reputation of a URL.
- The Palo Alto Networks (PAN) Firewall app provides several actions, such as blocking and unblocking access to IP addresses, applications, and URLs.
There is one MaxMind asset, one PhishTank asset, and two PAN Firewall assets. There are two PAN Firewall assets because they each have a different version number. Two playbooks run actions from the app assets.
- Playbook 1 runs actions from the MaxMind and PAN Firewall version 2.7 assets whenever a new container is created in .
- Playbook 2 runs actions from the PhishTank and PAN Firewall version 3.0 assets whenever a specific workbook is used in a case.
This table provides information on each component in the diagram and terminology:
| Component | Description | More information |
|---|---|---|
| App | A connection to third-party security technologies. The connection allows to access and run actions provided by the third-party technologies. Some apps also provide a visual component such as widgets that can be used to render data produced by the app. | See Add and configure apps and assets to provide actions in in the Administer manual. |
| Asset | A specific instance of an app. Each asset represents a physical or virtual device within your organization such as a server, endpoint, router, or firewall. For example, you might have a Palo Alto Network (PAN) Firewall app that connects the firewall to . You can configure an asset with the specific connection details for this firewall. If your environment has multiple firewalls, you can configure one asset for each firewall. | See Add and configure apps and assets to provide actions in in the Administer manual. |
| Container | A security event that is ingested into . Containers have the default label of Events. Labels are used to group related containers together. For example, containers from the same asset can all have the same label. You can then run a playbook against all containers with the same label. You can create custom labels in as needed. | See Configure labels to apply to containers in the Administer manual. |
| Case | A special kind of container that can hold other containers. For example, if you have several closely related containers for a security incident, you can promote one of those containers to a case and then add the other related containers to the case. Doing this lets you consolidate your investigation rather than having to investigate each container individually. | See Overview of cases. |
| Artifact | A piece of information added to a container, such as a file hash, IP address, or email header. | n/a |
| Indicator or Indicator of Compromise (IOC) | A piece of data such as an IP address, host name, or file hash that populates the Common Event Format (CEF) fields in an artifact. Indicators are the smallest unit of data that can be acted upon in . | n/a |
| Playbook | A series of automation tasks that act on new data entering . For example, you can configure a playbook to run actions against all new containers with a specific label. Or you can configure running a playbook as part of the workflow in a workbook. | See Use playbooks to automate analyst workflows in in the Build Playbooks with the Playbook Editor manual. |
| Workbook | A template providing a list of standard tasks that analysts can follow when evaluating containers or cases. | See Define a workflow in a case using workbooks in . |
| Action | A high level primitive used throughout the platform, such as get process dump, block ip, suspend vm, or terminate process. Actions are run in playbooks or manually from the web interface. Actions are made available to by apps. | See Add and configure apps and assets to provide actions in in the Administer manual. |
| Owner | The person responsible for managing assets in your organization. Owners receive approvals, which are requests to run a particular action on an asset. Approvals are sent to the asset owners and contain a service level agreement (SLA) dictating the expected response time. SLAs can be set on events, phases, and tasks. | See Configure approval settings for a asset in the Administer manual. See Configure the response times for service level agreements in the Administer manual for more information about configuring SLAs. |
