Not in My Sandbox: Save Those Deployment Tears

Jun 28, 2023
6 minutes
74 views

Efficiency in a security operations center (SOC) is more than just ensuring security professionals are successfully responding to threats. A successful SOC works to maximize its operations, people, processes, and technologies in order to quickly and resource-effectively detect, respond to, and mitigate security incidents in an organization. While less dramatic than the latest APT rebuttal, the people and process side are foundational to a successful and efficient SOC.

Security orchestration automation and response (SOAR) is often the most associated with workflow efficiency. So, with the launch of Cortex XSIAM 1.5, we focused on SOAR functionality advances, including:

  • Playbook Playground: Allow easier playbook development without impacting production environments by running a playbook in a sandbox environment.
  • Playbook Incident Context: Enhance investigation and response process and improve incident management with cross-alert playbook decision-making. This new feature offers to run playbooks on alerts while accessing incident-level information.

Sandboxes Aren’t Just for the Kids

When the stress of messing up code in deployment is taken away, analysts can be much more creative with their ideas.

Analysts in XSIAM can now evaluate the efficacy of their response protocols by testing playbooks in a sandbox environment. Based on their observations and the lessons they learned from the simulated context, they can refine and enhance the response procedures and strengthen the organization's overall security posture.

Automation engineers need to simulate script and automation runs to ensure that it behaves as expected. Without a non-production area to do so, the engineer will need to use complex techniques to simulate automation runs.

The benefit of using the playground is that the actual actions and testing are done on a non-production instance of an alert providing a safe and manner area to:

  • Validate self-created content, such as integrations, commands, scripts, and playbooks.
  • Test out-of-the-box or downloaded content and learn how it can be used.
  • Run ad-hoc actions outside of an incident scope.

Let’s look at an example:

An analyst is asked about a specific suspicious URL. This activity isn't currently related to any existing incident. They want to run the rasterize command to get a representation of the URL and then perform a VirusTotal test, similar to what is in Figure 1. The analyst can now confirm that this is indeed phishing quickly and easily without "damaging" any production alert. This saves both the investigating analyst time, as well as the overall team. This information is now available in the playground, which can be used in the playbook debugger.

 

Figure 1: Rasterize command example to get a representation of a URL in question, and then VirusTotal test output on the same URL.
Figure 1: Rasterize command example to get a representation of a URL in question, and then VirusTotal test output on the same URL.

 

Analysts can evaluate the efficacy of their response protocols, spot any holes or weaknesses, and adjust the playbook as necessary by running it in a sandbox. Based on their observations and the lessons they learned from the sandbox environment, they can refine and enhance the response procedures, strengthening the organization's overall security posture.

What Could You Do with More Context?

Having all the information you need in a centralized, easily accessible place, when doing your work is ideal. By delivering this at the incident level, it aids analysts in comprehending and gathering proof of the adversary tactics, techniques, and procedures (TTPs).

To expand remediation capabilities during an investigation, an analyst can now gather insights at an incident context level from multiple alerts and use the data for automation purposes, such as CLI commands and playbooks. In addition, an analyst can modify the incident fields to easily reflect changes - making the process more efficient and increasing the accuracy of the data. The incident context, which is available for all child alerts, can also hold insights learned during an investigation, enrichment data or incident assignee list.

A real world application of this enriched incident context is when a playbook runs at the alert level and opens a ticket, say in Jira. Now, analysts will see a log in the incident context, so if there's another alert grouped into the incident it won’t run the same playbook with the same action - resulting in additional Jira tickets. This is something that customers have requested and now comes with XSIAM right out of the box.

Complementary to this workflow, alerts can also change their parent incident fields. So a full use case encompassing both incident context and field access could be - an analyst learns something interesting during the investigation at the alert level (e.g. that the server is an internal lab server and not a production server), so we can add that to the incident context (so other child alerts are aware) and also lower the severity of the incident (which is an incident field).

Figure 2: In this example, a Jira ticketing system is used to manage alerts.. This playbook checks existing endpoints and Incident IDs and decides whether to create a new ticket or whether to add to the existing ticket, rather than having duplicate tickets.
Figure 2: In this example, a Jira ticketing system is used to manage alerts.. This playbook checks existing endpoints and Incident IDs and decides whether to create a new ticket or whether to add to the existing ticket, rather than having duplicate tickets.

 

Incident context can now be viewed more simply by analysts, which gives them valuable information for a thorough investigation. This knowledge is essential for locating the source of the problem, estimating the size of the breach, and creating a workable remediation strategy.

Beyond the addition of the playbook incident context capabilities and the playbook playground, highlights of what else new in Cortex XSIAM 1.5 include:

  • Data Ingestion Health: Expanded data health offers security engineering instant visibility into significant health issues. The granular health metrics provide visibility into the data pipeline as well as out-of-the-box health alerting capabilities. Health alerts are currently in beta.
  • Broker VM High Availability (HA) Cluster: Safeguard your Broker VM deployment by creating HA Clusters that provide redundancy of specified Broker VM components in one or more clusters.
  • Multi-Tenancy: To address the unique requirements of distributed organizations with multiple Cortex XSIAM tenants, Cortex XSIAM can now support multi-tenancy through a new parent-child deployment option.

With the latest XSIAM release, we continue to advance our mission to help customers protect their organization and do so more efficiently. Connect with your account manager, or contact us, to set up a demo to see XSIAM in action.

Learn more about XSIAM at paloaltonetworks.com. To obtain a complete list along with details of these and all the other new capabilities, features, and enhancements, please refer to the Cortex XSIAM 1.5 release notes.


Subscribe to Security Operations Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.