By Jonathan King, Cloud Security Engineer

Introduction 

Prisma Cloud allows you to create policies to ensure that your Cloud Security Posture Management is in compliance with best practices and the needs of your organization.  These policies create alerts which need to be evaluated and also indicate which cloud objects need to be updated for compliance. 

Managing these alerts is a task that many organizations find difficult as the number of alerts increases. Prisma Cloud allows you to define an auto-remediation to correct certain alerts.  However, oftentimes an organization requires much more customization and integration with other tools that they are using.

This article continues on from the previous article “Enhanced Alert Remediation” using XSOAR via CSPM, building on the concepts introduced in that article.  

This article will dive into post-integration of Prisma Cloud alerts to Cortex XSOAR incidents (where we discussed how to integrate Prisma Cloud to Cortex XSOAR), and how playbooks can be used to not only help remediate, but create an organized flow on how these violations should be delegated.

What are Cortex XSOAR Incidents?

Cortex XSOAR "incidents" refer to security events or alerts that the system identifies as needing attention or investigation. Incidents can be generated from various sources, such as security information and event management (SIEM) systems, threat intelligence platforms, cloud services, and other integrated tools.

Each incident in Cortex XSOAR includes relevant details about the security event, such as the source of the alert, the nature of the potential threat, timestamps, and other related information. XSOAR enables automated or manual workflows (playbooks) to respond to these incidents, reducing response times and improving the effectiveness of security operations.

Prisma Cloud alerts can be considered as a subset of Cortex XSOAR incidents. When a Prisma Cloud alert is generated, it can be sent to Cortex XSOAR, where it becomes an incident that can be managed using the XSOAR's orchestration and automation capabilities. The combination of Prisma Cloud and Cortex XSOAR can provide a more comprehensive and efficient response to security threats, especially in complex, multi-cloud environments. As an additional note, all Prisma alert policy types can be sent to Cortex XSOAR, but the methods beyond Config based alerts will depend on the policy and what the remediation is attempting to accomplish.

Breaking Down Incidents

When Prisma Cloud generates an alert and sends it to Cortex XSOAR, it typically includes the following key pieces of information:

1. Alert ID: A unique identifier for the alert.
2. Alert Status: The current status of the alert (e.g., Open, Dismissed, Resolved).
3. Alert Time: The timestamp when the alert was generated.
4. Policy Name: The name of the policy that triggered the alert.
5. Policy Severity: The severity level assigned to the policy (e.g., Low, Medium, High, Critical).
6. Resource Name/ID: The name or ID of the cloud resource that the alert pertains to.
7. Resource Type: The type of the cloud resource involved (e.g., Compute Instance, Storage Bucket).
8. Cloud Account ID/Name: The identifier or name of the cloud account where the resource is located.
9. Cloud Region: The geographical region of the cloud resource.
10. Alert Description: A detailed description of the alert, including the violation that occurred and the potential implications.

This information is utilized by Cortex XSOAR to provide context for the incident, facilitating the triage and response process. The specific information included can vary depending on the type of alert, the configuration of Prisma Cloud, and the specific integrations set up with Cortex XSOAR.

Figure 1: Prisma Cloud Alert as a Cortex XSOAR Incident_palo-alto-networks 

Playbooks

Playbooks are a key feature of Security Orchestration, Automation, and Response (SOAR) platforms like Cortex XSOAR. Playbooks are automated workflows that help security teams respond to incidents in a systematic and efficient way.

Here's a breakdown of what playbooks are and how they function:

• Definition: A playbook is a set of procedures or steps that are automatically executed in response to a specific type of security incident. These steps can include anything from sending emails and creating tickets, to running scripts, gathering data, making decisions based on conditions, and more.

• Automation: The primary purpose of a playbook is to automate repetitive or time-consuming tasks. For example, instead of manually gathering data about an incident from multiple sources, a playbook could automatically pull this information together. This helps reduce the time and effort required to respond to incidents.

• Standardization: Playbooks also help standardize the response to certain types of incidents. By defining a set of actions to take when a particular incident occurs, organizations can ensure a consistent response, regardless of who is on duty at the time. This can help prevent mistakes or oversights that might occur if each incident were handled individually.

• Customization: Playbooks in Cortex XSOAR are fully customizable. This means that organizations can tailor them to fit their specific needs and workflows. They can include steps to integrate with other systems, incorporate their own scripts, and adjust the flow of actions based on the details of the incident.

• Functioning: When an incident occurs, the appropriate playbook is triggered automatically. The playbook then executes its defined steps, which might include gathering data, performing analysis, making decisions based on defined conditions, and taking action. Actions can include things like blocking an IP address, quarantining a device, notifying stakeholders, creating a ticket in a ticketing system, etc. The playbook continues to run until all steps are completed or until it's manually stopped.

• Review and Improvement: After a playbook has been run, its performance can be reviewed to identify any areas for improvement. This could involve adjusting the steps in the playbook, adding new steps, or tweaking the conditions for decision-making. This iterative process helps organizations continuously improve their incident response capabilities.

Integrating a Playbook into an Incident

Integrating a playbook into an incident in Cortex XSOAR involves six steps:

1. Identify the Incident Type: Identify the type of incident for which you're creating the playbook. Cortex XSOAR allows you to define different types of incidents, each of which can have its own playbook.
2. Create or Select a Playbook: Either create a new playbook or select an existing playbook that matches the incident type. If you're creating a new playbook, you'll need to define the steps it should take, which can include automated tasks, manual tasks, and decision points based on conditions.
3. Configure the Playbook: Configure the playbook to work with your incident. This could involve setting up integrations with other systems, customizing the steps to match your workflows, and defining the conditions for decision points.
4. Test the Playbook: Before you integrate the playbook with an incident, it's a good idea to test it to make sure it works as expected. This can involve running it on a test incident and checking that all the steps are executed correctly.
5. Assign the Playbook to the Incident Type: Assign it to the relevant incident type. Whenever an incident of that type is created, your playbook will be automatically triggered.
6. Monitor and Refine: It is important to monitor your playbook’s performance and make any necessary adjustments. This could involve adding new steps, tweaking the conditions for decision points, or adjusting the integrations with other systems.

Example: Security Group Misconfiguration

Take the Prisma Cloud policy:

"AWS Security Group allows all traffic on SSH port (22)"

We want to use the "Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration" playbook as it is supported for this type of Prisma policy out of the box[1]:

Figure 2: Prisma Cloud Alerts Overview Dashboard on an AWS Security Group Alert Policy_palo-alto-networks 

1. Navigate to the Incident Types page: In the Cortex XSOAR interface, you should find an option in the menu for "Incident Types'' under Settings > Objects Setup. Click on “+ New Incident Type”.

2. Create a new Incident Type: Once on the Incident Types page, look for an option to create a "New Incident Type". Click on this to start creating a new incident type​​. Note that incidents are generated automatically from Prisma Cloud. Cortex XSOAR Incident types are defined by a grouping of Incidents. 

Figure 3: Cortex XSOAR Incident Type Creation/Modification_palo-alto-networks 

3. Fill in the parameters: Provide various parameters for your new incident type.

4. Name: Give your incident type a descriptive name that indicates it's associated with the "AWS Security Group allows all traffic on SSH port (22)" incident from Prisma Cloud.
5. Default playbook: In this field, select the "Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration" playbook. This will associate the playbook with your new incident type.
6. Run playbook automatically: Determine whether you want the playbook to run automatically when an event matching this incident type is ingested. If you want to manually initiate the playbook for each incident, leave this unchecked.
7. Auto extract incident indicators: This parameter determines how incident indicators are processed. Choose the option(s) that suit your use case.

Figure 4: Cortex XSOAR Incident Type Assignment_palo-alto-networks 

8. Post process using: Here, you can select a script to run on these incident types after they have been processed. You don't need to fill this in unless you have a specific post-processing script in mind.
9. SLA: Define the Service Level Agreement (SLA) for this incident type. This can be left as is unless you have specific SLA requirements​[2].
10. Save the new Incident Type: After you've filled in all the necessary parameters, click "Save". This will create your new incident type with the "Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration" playbook associated with it.
11. Assign the new Incident Type to the existing incident: Navigate to your existing "AWS Security Group allows all traffic on SSH port (22)" incident in Cortex XSOAR. There should be an option to modify or edit the incident's properties. Within this, you should be able to change the Incident Type to the one you just created.

Figure 5: Cortex XSOAR Incident Type Assignment_palo-alto-networks 

By following these previous 11 steps, you have integrated the "Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration" playbook into an existing Cortex XSOAR incident.

Next we will watch how the playbook takes the incident and performs the auto-remediation of this incident type.

1. Watching the Playbook Work Plan: When an incident is active/open, you can go to the Work Plan tab within the incident and look at the interactive playbook flow chart. From here you will see the actions it has successfully completed with a Green Checkmark, and for any Playbook paths that did not match the criteria for it will be grayed out.

2. Look for any Manual Steps to Playbook Completion: If your playbook contains any paths that require manual intervention, such as manually making changes to a cloud asset with appropriate credentials, then the Playbook cannot succeed by performing steps to automatically resolve the issue. When this occurs, you will need to follow the steps outlined in the portion of the Playbook to manually resolve the incident.
3. Closure of the Incident: When the playbook has reached the end for incident closure, specific steps will be taken automatically to close out the incident. After this has been performed, you can review the resolved status within Prisma Cloud.

Figure 6: Cortex XSOAR Incident Closure_palo-alto-networks 

4. Closure of the Prisma Cloud Alert: At this time you can now proceed to view the Alert that was seen in Cortex XSOAR within Prisma Cloud by going to the alerts overview page and selecting the Resolved Alert Status filter in the Alerts Overview. You will now be able to see the alert in question (Ex: The AWS Security Group Alert) and see that it is now in a resolved state.

Figure 7: Prisma Cloud Alert Remediation_palo-alto-networks 

*Note: The "Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration" playbook uses the following commands: 

• aws-ec2-revoke-security-group-ingress-rule
• aws-ec2-describe-security-groups

Ensure that you have the necessary permissions and configurations set up to allow these commands to run properly​[1]​. Also, you will need the Prisma Cloud policy ID as a required input for this playbook​[1]​.

Example # 2: GCP Instance Misconfiguration

Take the Prisma Cloud policy:

"GCP VM instances have block project-wide SSH keys feature disabled"

We want to use the "Prisma Cloud Remediation - GCP Compute Engine Misconfiguration v2" playbook as it is supported for this type of Prisma policy out of the box[1]:

Figure 8: Prisma Cloud Alerts Overview of a GCP Instance Misconfiguration Policy_palo-alto-networks 

1. Navigate to the Incident page: Use the default incident type associated with this incident. Go to the “Incidents” page and find any names with "GCP VM instances have block project-wide SSH keys feature disabled".
   
2. Assign a Playbook: We will look under “Case Details” and select the dropdown window for “Playbook” and search/select the playbook, "Prisma Cloud Remediation - GCP Compute Engine Misconfiguration v2".

Figure 9: Cortex XSOAR Incident Details Page_palo-alto-networks 

3. View Playbook Progression: Select the playbook and view its progress under the “Work Plan” tab. You will see how the playbook takes its approach to resolution. This type of playbook has another playbook nested within Nesting playbooks that creates a modular approach on resolving incidents effectively without overpopulating one individual playbook.

 Figure 10: Cortex XSOAR Work Plan Playbook Progression_palo-alto-networks 

4. Resolution: Once the Playbook has remediated the issue, the Incident will be closed, and the alert from Prisma Cloud will be resolved automatically by detecting that the resource in question no longer is in violation of the policy.

Conclusion

We have talked about how Cortex XSOAR and the incidents will be processed by playbooks. These Cortex XSOAR playbooks allow greater functionality in being able to manually and automatically remediate an incident from a Prisma Cloud alert, as well as provide the ability to route the alert information to other active applications or systems within your organization. 

Cortex XSOAR provides a mechanism for you and your team to customize the handling of alerts from Prisma Cloud and automate the response to more alerts leaving fewer alerts to be processed by your security team. 

There are many playbooks that are out-of-the-box and ready to be used for your alerts and remediations, the next article will cover how to create custom playbooks to tailor to all types of alerts that you receive in Prisma Cloud.

Reference: 

[1] Prisma Cloud Remediation - AWS EC2 Security Group Misconfiguration

[2] Incident Types 

About the Author:

Jonathan King is a Cloud Security Engineer on the Prisma Cloud CSPM team, specializing in supporting all non-compute solutions for Prisma Cloud  AWS, Azure, GCP, OCI, and Alibaba.