About RPrasadi

By Richard Vega, Senior Customer Success Engineer     Dashboarding In Prisma Cloud The Prisma Cloud Darwin release enables you to utilize out of the box dashboards as well as custom dashboards. With the capabilities to track and monitor your cloud security posture ranging from vulnerabilities to compliance. In this article,  we will discuss the existing OOTB dashboards and the capability of creating custom dashboards in Prisma Cloud.   I.  Out of the box Dashboards   Prerequisites   To view the code to cloud dashboard, complete the following tasks:   Onboard your cloud accounts Create an alert rule with incident and attack path policies to detect issues Enable applications security specifically infrastructure as code (IaC) scanning Enable agent-based or agentless security for cloud workload scanning A.  Code to Cloud Dashboard         Figure 1: CodetoCloudDashboard_palo-alto-networks   A.  Code to Cloud Dashboard   Latest Events Tracker   The Dashboards > Code to Cloud > Latest Events Tracker provides a stream of updates to track changes across key metrics such as Threats Detected, Alerts Remediated, Critical Alerts etc., to help you assess the strength of your security posture in real time.   Use the Latest Events live stream to quickly assess the potential threat activity taking place in your cloud environment. You can also double-click on any event to investigate critical vulnerabilities and build-time issues detected. Select See All Events to see a list of the latest security events across your cloud estate. Select any event to navigate to the specific alert and investigate further.   Cloud Inventory and Graph Figure 2: Cloud Inventory_palo-alto-networks   Code to Cloud Inventory provides a panoramic view of your entire cloud estate, helping you understand how well your organization is embracing security best practices across your cloud environment, from individual resources to the entire code pipeline.   Graph data is sourced from Incidents, Attack Paths, Vulnerability Explorer data and IaC scans. Percentages are calculated by taking the latest snapshot and comparing it against data for the last 30 days, to derive the percentage difference. Metrics do not include data from non-onboarded accounts. Cloud accounts must be fully onboarded on the platform to view metrics.   Code/Build Inventory Figure 3: Code&Build_palo-alto-networks   The Code/Build Inventory widget surfaces metrics derived from the monitoring and scanning of hundreds of code repositories across the three repository systems secured by Prisma Cloud scanners including IaC/SCA, and Secrets. Historical developer data for code issues and pull requests are also surfaced.   The Code Issues in Repositories graph captures code errors in the default branch of all onboarded repositories over the last thirty days. Use this graph to track your team’s progress in resolving code errors before they affect your production systems. Code and Build Inventory provides you with a quick rundown of your protected repositories. Select any metric such as Repositories Systems to see a full catalog of all the Code & Build Providers with flags for Code Issues.   Deploy Inventory Figure 4: DeployInventory_palo-alto-networks   The Deploy Inventory graph visualizes the critical and high severity alerts triggered by vulnerabilities detected in container images and registries in the last 30 days. Here you can monitor trends in the rate of vulnerabilities identified across your workloads.   Select any metric in the Deploy Inventory table to further investigate the following: Container Registries: View all the registries that currently scanned for vulnerabilities Container Images: View details on container images with detected vulnerabilities Trusted Images: View all the running images in your environment and their trust status   Runtime Inventory Figure 5: Runtime Inventory_palo-alto-networks   Runtime Inventory helps you quantify and demonstrate your progress in securing your workloads. The Runtime graph captures the top critical and high severity incidents and alerts triggered by attack path policies in the last 30 days. Review the trendline to track your team’s progress in the remediation and the burn down of urgent incidents.   Select any metric on the Runtime Inventory table to view the total number of cloud providers and assets, and workloads protected by agents. For instance, you can select the Workloads Protected by Agents metric to view potentially compromised workloads that may be infected with malware.   The Inventory data above is sourced from Prisma Cloud Incidents, Attack Paths, Vulnerability Explorer, and IaC scanning data. Percentages are calculated by tabulating the difference between the latest snapshot and data points for the last 30 days.   Top Issues by Collection   The Code to Cloud dashboard, also provides you with the option to define your applications or teams and assign owners to track and monitor progress. You can compare key metrics such as Code Issues in Repositories or Urgent Vulnerabilities in Images across teams, business units and applications to benchmark security standards.   The first row of the table captures the aggregate of all issues across the tenants in your onboarded accounts. Use the Sort By drop-down to categorize your business unit view across Code/Build, Deploy and Run phases of the application lifecycle.   Add Row also allows you to create your own custom collection of accounts, application owners or business units to obtain more granular results on risks by individual applications and stakeholders.   The following caveats apply to Collections: Only System Administrators can create or add Collections. The Code to Cloud Row trendline is initiated after at least one row is added. Trendline data is populated only after regularly scheduled Prisma Cloud system updates. Trendlines may display a no data available message prior to system update. You can add Repositories to Collections. If a Repository is deleted at the source, it may still appear in a Collection  B.  Command Center Dashboard        Figure 6: Command Center Dashboard_palo-alto-networks   B.  Command Center Dashboard    The Command Center dashboard provides you with a unified view of the top cloud security incidents and risks uncovered across the assets monitored by Prisma Cloud. It provides security teams with a picture of the highest priority incidents and risks that require attention across the following attack vectors:   Incidents Attack Paths Misconfigurations Vulnerabilities Exposures Identity Risks Data Risks   The Command Center dashboard is only available to users with a System Admin role. Total Urgent Alerts   The Total Urgent Alerts bar provides a tally of alerts grouped by Incidents, Misconfigurations, Exposures, Identity, and Data Risks. The Filter controls above the Alerts bar allowing you to narrow your investigation to a specific Time Range or Account Group.    You can select multiple account groups at once to view data from multiple account sources. Filter data retrieved is updated across all the alert visualizations on the dashboard. The revert icon on the right above the Total Urgent Alerts bar allows you to revert back to default filter settings.     Figure 7: Urgent Issues_palo-alto-networks   Alerts Visualization   Actionable alert data is further grouped into the following areas by risk type:   Incidents: Retrieves data for critical and high severity alerts, generated by policies that detect potential security issues from misconfiguration or exposure, across your cloud infrastructure. Attack Paths: Provides the total number of critical and high severity alerts, triggered by policies covering issues that when taken together indicate a heightened risk of attack. Misconfigurations: Captures data for alerts generated by policies with configuration errors. Vulnerabilities: Provides insight into potentially compromised assets in your cloud environment, capturing the top five assets with vulnerabilities that triggered the most number of Critical and High alerts. Click on any listed image or asset to access the Assets Explorer to investigate further and take remedial action, if necessary. Exposures: Retrieves data for alerts generated by violations in network policies; in addition to the policy subtype config. Identity Risks: Lists alerts generated by violations in Identity and Access Management policies. This view is only available by subscription. Data Risks: Retrieves data for alerts generated by exceptions in the policy type Data. This view is only enabled by subscription.   Alerts Actions   Each alerts visualization allows you to further drill down and view the source of the alert by the policy name or the asset it originated from:   Figure 8: Incidents Widgets_palo-alto-networks The Incidents widget above for instance, provides three visualizations of urgent alerts activity:   Urgent Incidents: Provides a donut chart visualization of Critical and High severity Incidents. Select any alert for an in depth look at alerts generated by policies that detect potential security issues from misconfiguration or exposure. Top Incidents by Policy: Lists the top five policies that triggered an alert. Select a policy or an alert total for a detailed view of policy coverage incidents. You can also investigate alerts within individual policies. Top Attack Path by Policy: Lists top five attack paths by policy, type, severity, and number of alerts. Learn more about responding to alerts generated for a specific attack path. Top Incidents by Asset: Lists top five incidents by asset name, number of alerts, service, and account name. Learn more about responding to alerts generated in a specific asset. C.  Vulnerability Dashboard           Figure 9: Vulnerability Dashboard_palo-alto-networks   C.  Vulnerability Dashboard Prisma Cloud Vulnerabilities Dashboard gives you a holistic graphical view of all the vulnerabilities across your Code to Cloud environment. An overview of the top impacting CVEs enables you to prioritize vulnerabilities based on existing risks and trace them from runtime back to the source.    This risk assessment capability helps you to make informed decisions with findings and fix the vulnerable package or base image in code. This capability will allow you to remediate the root cause and resolve the issue when the build is next executed.   The dashboard helps you answer:   What are all the vulnerable assets across my entire application lifecycle? Where should I focus to find and fix the vulnerabilities? What are the critical and urgent ones, and the ones that are patchable? What actions can I take to remediate or mitigate the vulnerabilities in Code or Cloud? Discover Vulnerabilities Figure 10: PrioritizedVulnerabilities_palo-alto-networks   On Dashboard > Vulnerabilities you can discover all the vulnerabilities across your environment. Let’s say, there are 25K vulnerabilities in your environment out of which only 20,637 are critical and high, 7,470 are exploitable, out of which 7,400 are patchable meaning these vulnerabilities are actionable for you to fix them.    The funnel in the Prioritized Vulnerabilities further narrows down to just 35 vulnerable packages that are in use in the runtime that you can focus on.   Prerequisites   Onboard cloud accounts Onboard code repositories Configure registry scans Enable Workload Incident and Workload Vulnerability policies   The following visualizations are available for you to help contextualize risks from vulnerabilities:   Vulnerabilities Overview - Provides a summarized view of the total vulnerabilities in your environment further divided into Vulnerabilities by Asset and Vulnerabilities that have already been remediated.  Allowing you to track and share your progress in securing your environment. Visualize the trends with Total Vulnerable Assets, and their metadata, Total Vulnerabilities Remediated, and Total Vulnerabilities count in the current snapshot. Prioritized Vulnerabilities - Discover all the vulnerabilities across your workloads and identify the top-priority vulnerabilities (aggregated vulnerabilities that are urgent, exploitable, patchable, and vulnerable packages in use). The vulnerabilities sourced from Compute and CAS (Cloud App Sec) are prioritized and aggregated based on the most urgent, exploitable, patchable, and vulnerable packages in use. This prioritization helps you to identify the top-priority vulnerabilities to focus on. The aggregation is based on vulnerabilities that are: Urgent: Critical, High Exploitable: Exploit in the Wild and Exploit in POC Patchable: Vulnerabilities that are actionable and have a patch to fix or mitigate. Vulnerable packages in use. Top Impacting Vulnerabilities - Provides a ranked list of the most critical vulnerabilities in your environment based on the risk score. The ranked list consists of CVEs affecting the environment. Each CVE includes data about its risk factors, severity, CVSS, risk factors, and assets impacted. Review the top-impacting vulnerabilities based on the CVE severity, CVSS score, Risk Factors, and the assets impacted across your CI/CD pipeline. Vulnerability Impact by Stage - Visualize the sources of the vulnerabilities and the impact of the vulnerability across app stages of your application lifecycle. Trace vulnerabilities from runtime back to the repositories they originate from. At each stage, you can select and investigate any of the impacted assets such as Packages, Images in IaC Files, Host VM Images, Registry Images, Deployed Images, Serverless Functions, and Hosts.  This makes it easier for you to trace back the packages and images that were used to build a workload that is now vulnerable in the deploy stage, or runtime. D.  Compliance Dashboard           Figure 11: Compliance Dashboard_palo-alto-networks   D.  Compliance Dashboard Prisma Cloud’s Compliance dashboard provides a snapshot view of your overall compliance posture across multiple compliance standards. The dashboard provides you with an interactive look at how your compliance coverage maps to the established compliance frameworks available within Prisma Cloud. Use the Compliance dashboard as a tool for risk oversight across all the supported cloud platforms and quickly evaluate your compliance posture using real-time data. Use the provided Filters to hone in on the time period, cloud account, or account group you would like to focus on.    By default, the dashboard shows your compliance state for the last 24 hour period. The Compliance dashboard is available to users with the System Administrator role on all stacks, with the exception of app.gov  and app.cn.   Compliance Overview Figure 12: Compliance Overview_palo-alto-networks   The compliance score presents data on the total unique resources that are passing or failing the policy checks that match compliance standards. Use this score to audit how many unique resources are failing compliance checks and get a quick count on the severity of these failures.    The links allow you to view the list of all resources on the Inventory page, and the View Alerts link enables you to view all the open alerts of Low, Medium, or High severity. Compliance Trend   The compliance trendline is a line chart that shows you how the compliance posture of your monitored resources have changed over time (on the horizontal X axis). You can view the total number of resources monitored (in blue), and the number of resources that passed (in green) and failed (in red) over that time period.   Compliance Coverage   The Compliance coverage bar graph highlights the passed and failed resource count across all compliance standards for easy comparison. Select any given compliance standard to view the total number of failed assets for that standard. Click on the compliance standard to view policy details. E. Code Security Dashboard            Figure 13: Code Security Dashboard_palo-alto-networks   E. Code Security Dashboard    As a part of Application Security, the Code Security dashboard provides you with a contextual view of the top code security vulnerabilities and misconfigurations identified in scans across the code and build integrations on Prisma Cloud.   It gives you a contextual understanding of high priority errors that require attention across these vectors: High-risk code errors by severity Historical data for code issues and pull requests Common policy errors Licensing errors in non-compliant packages IaC errors in code categories Vulnerabilities seen in CVE from CVSS score   You can view the dashboard on Dashboards > Code Security. The Code Security dashboard is only available if you have subscribed to Application Security on Prisma Cloud. To know more on user role permissions see Prisma Cloud Administrator Permissions.   The Code Security dashboard is available to users with the System Administrator role on all stacks, with the exception of app.gov and app.cn.   Errors by Severity   The Total Errors bar provides a summary of code errors across severity of Critical, High, Medium, Low, and Info. You can see custom results for all Code Security errors using filters that allow you to narrow your investigation to a specific Repository, Code Category, or Severity .    You can select multiple repositories, code categories, and severities at once to narrow your investigation to find critical errors that may need immediate remediation. Filtering the data updates all visualizations on the dashboard. The reset filters allow you to revert back to default filter settings.    You can also see contextual results for code errors by severity when selecting the number corresponding to the severity giving you access to the results from Prisma Cloud switcher Application Security Projects > Overview. On Projects, you can execute remedial actions, if necessary.   Code Errors Visualization   The code errors are actionable and are grouped in these areas:   High-risk code errors by severity: The Top Repositories by High Risk Code Error Count provides a bar graph visualization of the top trending repositories to have a maximum number of Critical or High severity errors. The representing data is periodically updated, and you can verify the accuracy of the last scan by hovering on the timestamp.     Figure 14: Code Errors_palo-alto-networks Historical data for code issues and pull requests: View the trend for code errors and pull requests for repositories that are scanned using Prisma Cloud. Code Issues over time: Visualizes the trendline of code errors from the last 30 days of a default branch in an integrated repository. The data also gives you an understanding of when the errors occurred by monitoring data on Opened Earlier, Fix Pending, and Suppressed. You can also see if any remedial actions were taken on the same day by monitoring data on Fixed Today and Opened Today.   Figure 15: Code Issues_palo-alto-networks   Pull Requests over time: Visualizes a trendline of pull requests created on specific branches of integrated repositories from the last 30 days. Monitor the vulnerability status of the PR across Failed Earlier, Failed Today, Resolved, and Passed.   Figure 16: Pull Requests_palo-alto-networks   Common policy errors: The Common Errors by Policy provides a view of policies that have the highest error count. The data contextualized here is after periodic scans with timestamp available for you to see. With the high count of errors within a policy, you can also have information of the type of policy by Labels, and the Severity.  Selecting the policy directs you to Policies for more actionable information. While selecting the error count directs you to Application Security > Projects > Overview to execute a remedial action, if necessary.   Figure 17: Common Errors _palo-alto-networks   Licensing errors in non-compliant packages: The Top Non-compliant Package licenses provides insight into non-compliant package licenses that are being used in the repositories. The data shows the number of repositories that are potentially exposed due to usage of non-compliant package licenses.  The count shows the total number of instances the non-compliant package is used. Selecting the count directs you to Application Security > Projects > Overview with the non-compliant package already filtered. You can choose to execute a manual remedial action on Overview, if necessary. IaC errors in code categories: The IaC Errors by Category provides a summarized view for misconfigurations seen in IaC category. The count in each category is the number of misconfigurations identified and on selecting the count directs you to Application Security > Projects > IaC Misconfiguration where you can choose to execute a remedial action on Resource Explorer. Vulnerabilities seen in CVE from CVSS score: The Top CVSS Score Code Vulnerabilities lists the highest CVSS score identified across vulnerability scans. You also see the Risk Factors, the potentially compromised CVE with Severity, and Count. Selecting the count directs you to Application Security > Projects > Vulnerabilities with the CVE errors preselected. F.  Custom Dashboards     Figure 18: Manage Dashboards_palo-alto-networks   F.  Custom Dashboards Custom Dashboards are an option you have in Prisma Cloud to create your own customized views for the different personas in your organization. You can use a combination of the functionality discussed above as well as customize for your organization’s desired result. You can add and manage dashboards enable, disable, share, and clone as seen above. You can also add a new custom dashboard from scratch to fit your specific needs: Figure 19: Add Dashboard_palo-alto-networks From here, you can add widgets to customize your dashboard view and share your dashboard with other Prisma Cloud users. Figure 20: Custom Dashboard_palo-alto-networks   Prisma Cloud has a number of widgets that can be used to customize your dashboard and slice and dice data as you see fit. Each of these widgets has their own settings as well so you can include things like account groups or edit existing widgets to only contain certain data points - you can be as granular as need be. To enable shareability of your custom dashboards you will need to make sure the access permissions are set to public: Figure 21: Access Settings_palo-alto-networks   II.  Summary   In this article we talked about the Code To Cloud, Command Center, Vulnerability, Compliance, Code Security, And Custom dashboards that allow you to track, visualize, and share the metrics that matter most to you and your team. Widgets with visual representations in various formats such as line and bar graphs and pie charts are available to track key metrics such as assets with the most urgent alerts and vulnerabilities, resource compliance trend charts, and top risks to remediate. Share dashboard visualizations with your management team to quantify your progress in hardening your security posture. III.  References   Code to Cloud Dashboard Command Center Dashboard Vulnerabilities Dashboard Compliance Dashboard Code Security Dashboard Create and Manage Dashboards IV.  About the Author   Richard Vega is a Senior Customer Success Engineer at Palo Alto Networks specializing in securing Multi-Cloud infrastructure and being a trusted advisor to large and strategic customers. Rich is no stranger to wearing many hats and has worked in Sales, Product, Engineering and Customer Success in his career so he brings a unique perspective to the table when it comes to working with customers on securing their cloud assets.  ... View more

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:   Alert ID: A unique identifier for the alert. Alert Status: The current status of the alert (e.g., Open, Dismissed, Resolved). Alert Time: The timestamp when the alert was generated. Policy Name: The name of the policy that triggered the alert. Policy Severity: The severity level assigned to the policy (e.g., Low, Medium, High, Critical). Resource Name/ID: The name or ID of the cloud resource that the alert pertains to. Resource Type: The type of the cloud resource involved (e.g., Compute Instance, Storage Bucket). Cloud Account ID/Name: The identifier or name of the cloud account where the resource is located. Cloud Region: The geographical region of the cloud resource. 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.   Fig 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:   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. 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. 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. 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. 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. 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]:   Fig 2: Prisma Cloud Alerts Overview Dashboard on an AWS Security Group Alert Policy_palo-alto-networks  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”. 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.    Fig 3: Cortex XSOAR Incident Type Creation/Modification_palo-alto-networks    Fill in the parameters: Provide various parameters for your new incident type. 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. 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. 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. Auto extract incident indicators: This parameter determines how incident indicators are processed. Choose the option(s) that suit your use case.   Fig 4: Cortex XSOAR Incident Type Assignment_palo-alto-networks    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. SLA: Define the Service Level Agreement (SLA) for this incident type. This can be left as is unless you have specific SLA requirements​[2]. 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. 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.   Fig 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. Fig 6: Cortex XSOAR Incident Closure_palo-alto-networks    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.   Fig 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]: Fig 8: Prisma Cloud Alerts Overview of a GCP Instance Misconfiguration Policy_palo-alto-networks    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". 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".   Fig 9: Cortex XSOAR Incident Details Page_palo-alto-networks    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.    Fig 9: Cortex XSOAR Work Plan Playbook Progression_palo-alto-networks    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. ... View more

  Our experts will explain the possible risks across the entire application lifecycle and discuss how to use code-to-cloud intelligence to prioritize, remediate, and mitigate these risks efficiently, at scale, and before they become breaches. After, take the opportunity to implement these best practices with a hands-on lab using Prisma® Cloud and experience how the 2023 Cloud-Native Application Protection Platform (CNAPP) of the Year helps you protect applications from code to cloud.   We’ve got an action-packed agenda, including expert-led keynote sessions, be sure to stick around for cocktail hour and live demos after the day’s events.   Agenda:   11–11:30 AM | Registration 11:30 AM–12 PM | ​​A Radically New Approach to Cloud Security 12–12:45 PM | Lunch 12:45–1:15 PM | Recipe for Success: Cloud Use Cases 1:15–1:45 PM | Prisma Cloud and HashiCorp: Securing Cloud Operations 1:45–2 PM | Break 2–3:30 PM | Capture The Flag Hands-on Lab 3:30–5 PM | Drinks and Demos Sign up today, don’t miss out on these exciting events taking place in TYSONS CORNER, ATLANTA,  and MIAMI.      Cloud Native Application Platform,Cloud Security,CNAPP,Prisma Cloud,Roadshow ... View more

    Discover how to implement Data and AI Security across the enterprise with our recent acquisition of Dig Security. Data Security Posture Management (DSPM) puts data at the heart of Prisma Cloud's Code-to-Cloud intelligence. ... View more

By Ben Nicholson, Global Practice Lead   Ensure Your Cloud Applications are Secure from Code to Cloud   To stay relevant, organizations must be nimble, offering new services, and capabilities that transform their customers' experiences while managing the volatile world of cyber attackers.    In this dynamic environment, application development has accelerated. Forty percent (40%) of customers are updating their code daily, and 77% perform weekly updates, opening holes in security vulnerabilities and necessitating a shift in how they are managed. Forget integrating security at the end, leaving exposed risks and increased costs! “Shift left” places security management directly at each application development phase from code to runtime— reducing security risks and costs.   Migrating applications to the cloud can increase agility and scalability. What about securing the data, applications, and tools to ensure that you’re delivering secure cloud applications?    A recent survey with 2,500 respondents highlighted 5 top challenges and 5 top risks corporations encounter as they move toward the cloud. Security challenges that benefit from visibility, prevention, and protection.   Moving to the cloud-5 top challenges    Managing holistic security across teams   As organizations acquire new security tools there is shared responsibility between development, operations, security teams, and every stakeholder along the application lifecycle.    Embedding security across the application lifecycle   On average, organizations rely on 30+ tools with 6 to 10 ten tools dedicated to cloud security to solve top-of-mind issues and achieve the desired security posture.   Training staff to use security tools   Cloud-native application development requires securing exponentially more cloud assets across code, workloads, identities, data, etc.. Managing multiple execution environments, such as containers, serverless, and PaaS requires proficient staff with each tool.   Lack of visibility into security vulnerabilities across cloud resources   The holy grail of application security is vulnerability management — prioritizing and addressing alerts as they arise, mirroring the scale, speed, and agility of the cloud itself.    Finding the correct tools to address security needs   Not all organizations are at the same stage in their cloud adoption journey, nor do all embrace the same methodologies. Whether you develop applications exclusively in the cloud or use a lift-and-shift approach, the ideal cloud security tools allow organizations to scale, adding use cases as their cloud maturity increases. Future-proofing cloud security requires adopting a platform designed with flexibility and choice in its architecture.   Shift Left Secures Applications Downstream    We've found that the five challenges not only slow down your application development process. Moving vulnerabilities and misconfigurations upstream, five commonly experienced application-level risks are emerging.    In the survey mentioned above, 30% of respondents said the lack of visibility into vulnerabilities across their cloud resources introduced risks, blocking their ability to achieve comprehensive security. Lacking the ability to detect, contain, and resolve threats within an hour leaves applications vulnerable to attacks.    Five security risks that can impact your security posture are often encountered in:   Early stages of application development  Workload images with vulnerabilities or malware  Vulnerable web applications and APIs  Unrestricted network access between workloads  Downtime due to misconfiguration   Shipping insecure code and exposed credentials cause 82% of cloud breaches   Shift Left – Gain Visibility and Control, Exercise Prevention, and Embed Protection   How do you mitigate the five challenges while minimizing the five risks? Look for a security product specifically designed to continuously build in cloud security. Automating manual processes, securing cloud applications, amplifying visibility and control of security vulnerabilities, exercising prevention, and embedding protection are accomplished at every step of the CI/CD pipeline.  Visibility and control help find and mitigate vulnerabilities in the early stages of application development. Alerts allow you to apply prevention to workload images, web applications, APIs, unrestricted network access, and misconfigurations, ensuring protection at each CI/CD pipeline step. Embed security in the coding,  building, developing and runtime mitigates potential risks—reducing remediation costs, the number of exposures, and most importantly potential breaches.   “Shifting left” in your application life cycle requires managing security across teams and embedding a holistic security plan across your organization. For example, automating manual tasks and reducing human error can’t be done in a silo. Sharing expertise on the tools’ capabilities and features builds trust and increases security expertise credibility across the organization.   Step 1- Secure the Infrastructure   Cloud security solutions that provide continuous and near real-time detection of misconfigurations, vulnerabilities, and threats from code to runtime allow organizations to respond quickly and effectively to detect a breach or vulnerability.   Continuous visibility and control enable rapid and continuous developments, updates, maintenance, and securing of cloud-based applications across dynamic engineering ecosystems and cloud environments.     Right security tools such as Palo Alto Networks Prisma Cloud scanning capabilities help build security starting with writing the code. Identifying vulnerabilities, risks, and compliance violations ensures that code is free from security holes before progressing to the “deploy phase” of the application's lifecycle.   Step 2 – Secure the Source   With modern automation and the need for speed, cloud applications are in a continuous development, testing, and release cycle. Developers often rely on untested open-source code to accelerate development, introducing additional hidden risks.    From the source, a single vulnerability can easily grow exponentially through the pipeline, making it harder to eliminate. Identifying application vulnerabilities and compliance issues prevents weaknesses that bad actors might abuse. Prisma Cloud helps enforce your policies to ensure trusted applications only are deployed in the cloud runtime environment. For example, Prisma Cloud’s Defender automatically protects workloads in runtime, scans registries, and API Security. Other capabilities auto-correct misconfigurations and secure cloud storage.     Step 3 – Monitoring and Tracking for Ongoing Protection   Regardless of where it’s deployed (IaaS, PaaS, SaaS, etc.), an application’s runtime actions should be monitored for abnormal behaviors, preventing risks from occurring during this phase. Using predictive and threat-based protections, Prisma Cloud quickly identifies expected behaviors and prevents anomalous behavior.     With built-in scanning capabilities, policy enforcement, and predictive and threat-based protection, Prisma Cloud easily shifts your security left, ensuring that your cloud applications are secured from the start.   Prisma Cloud Field Guide e-book helps you learn to maximize application security by leveraging Prisma Cloud’s full capabilities at each stage of your cloud application development cycle.    The Prisma Cloud Security Guide provides a complete guide on how Prisma Cloud establishes the pillars of security for your cloud journey. Need help configuring, provisioning, and deploying Prisma Cloud for the maximum benefit? We recommend Prisma Cloud CBDR Adoption Workshop or QuickStart Service for Prisma Cloud Code Security. Shift left for optimum cloud application security. Learn more read The State of Cloud Native Security Report 2023 About the Author           ... View more

    In this session we will display how Prisma Cloud provides Code-to-Cloud protection to prevent application risks and breaches. See how you can leverage the workflows that enable a superior user experience for security and development teams to work together. ... View more

By Terri Chen, Program Manager     Introducing Our New Prisma Cloud TechDocs Site       What's new in Techdocs    Discover collections, use cases, release notes, and more in the improved left navigation.    New content collections that include conceptual and workflow details.    In-page anchors, light/dark mode, and enhanced web layout for better reading.   4 New Sections Use cases in Operationalize   Enterprise Edition Documentation   Compute Edition Documentation   Enterprise Edition—Classic Documentation         Use Cases in Operationalize   3 Phases to Operationalized   Secure the Source   Secure the Infrastructure   Secure the Runtime         Enterprise Edition Documentation   Access all the Enterprise Edition documentation   Expand the arrow to view content in each category         See Runtime Security for Compute content   Select Classic Releases to see all previous release notes         Compute Edition Documentation   Select the arrow for the list of supported Compute versions             Enterprise Edition—Classic Documentation   Select Classic Releases to see all previous release notes         Feel free to file a Support Ticket or reach out to your Customer Success Team for additional assistance.         ... View more

By Yaron Avital, Senior Staff Researcher    GitHub Actions, for good reason, is the go-to choice for countless developers. Despite its convenience, though, potential security risks accompany third-party actions. In this post, we share how the world’s most popular repositories fail to manage their build permissions and walk you through the why and the how of proper permissions management in GitHub Actions.   GitHub Actions has gained immense popularity in recent years as a powerful and flexible automation platform for software development workflows. With its intuitive user interface, extensive library of prebuilt actions and seamless integration with GitHub repositories, it has become a go-to choice for many developers and organizations seeking to streamline their CI/CD pipelines, automate routine tasks, and improve collaboration across teams.   But convenience and accelerated development aside, using third-party actions comes with security risks. GitHub cautions organizations by plainly stating, "There is significant risk in sourcing actions from third-party repositories on GitHub." The statement underscores the importance of ensuring the security of workflows on the platform.   In this blog post, we cover the all-important reasons AppSec engineers need to properly manage permissions in GitHub Actions — while also showing how the vast majority of GitHub organizations fail to correctly handle these permissions.   Action’s Permissions   When a workflow runs, GitHub issues a short-lived GITHUB_TOKEN for the workflow to interact with the repository. This token has since become a target for attackers who succeed in executing code in a workflow, as it provides them with the same level of permission as the token. Command injection in the CI, compromised dependencies or actions — all allow attackers to access the token and use it against the repository.   Tokens in each workflow are set by the repository administrators and maintainers with read or write access to a list of scopes. If not specifically set in the workflow configuration file, the default setting of the repository will determine permissions. In February 2023, applicable to new organizations, GitHub changed the default permissions granted to this token from “write-all”, granting write permissions on all available scopes, to read-only for the contents, packages and metadata scopes.   Developers who want to limit the permissions to the minimum can explicitly grant permissions to each workflow or a job, which is a smart move. Know the caveats, though. GitHub Actions supports the "write-all" and “read-all” scopes, granting all permissions. Also, even if granular permissions are set, they should match against the permissions the action requires to fulfill its purpose.   Let’s review why it’s a bad practice to allow broader scopes than required.   Permissions Worth Taking a Closer Look   Granting higher permissions to workflows that aren’t required, like “write-all”, “read-all” or actions in figure 1, fuels post exploitation techniques and allows attackers to inflict serious damage to the organization.   Figure 1: Actions commonly granted overly permissive actions can result in damaging exploitation.     Granting Tailored Permissions   GitHub allows setting granular permissions per a workflow’s job, and we can use an action inside a job, isolated from the rest of the workflow.   Let’s grant the third-party action the exact permissions it needs to operate.   Unlike the installation of GitHub apps where you authorize each permission used by the app beforehand, when making use of a GitHub action, there’s no permissions approval process. What’s more, there’s no central location, GitHub or otherwise, to find what permissions a third-party action requires. This makes it difficult for developers to maintain the important principle of least privilege. From good will, the maintainers occasionally mention the recommended permissions, like in actions/stale. But this isn’t enforced or standardized by GitHub, and in general, it’s rare to see guidelines on required permissions provided by maintainers.    Figure 2: The Close Stale Issues action by GitHub provides recommended permissions. [Source]   Creating Action Permissions Database   We’ve created PiPER (a portmanteau of pipeline and permissions), an internal tool that calculates the minimal required permissions for a given action. It works by performing static code analysis on the actions’ code, identifying any action made against the repository, and mapping usage to a permission. Achieving good coverage isn’t so straightforward, as the GitHub API can be accessed in various ways, such as interacting with it directly through HTTP or by using various libraries that wrap it. Additionally, both the REST API and the GraphQL endpoints can be used.   We used PiPER to analyze the top 1000 popular actions on the GitHub marketplace.   We've learned that about 50% of the actions don’t perform any interaction against the repository and, therefore, don’t require the GitHub token to fulfill its purpose.   Figure 3: Fifty percent of the analyzed actions require no permission.     In fact, 94% of actions require only 2-3 of the 13 available scopes — contents, issues and pull-requests being the popular ones. For example, the rtCamp/action-slack-notify action doesn't have any interaction with the GitHub API, so the GitHub token accessible by this action shouldn’t be granted permissions against the repository. You can achieve this by explicitly declaring it inside the job/workflow, as follows:   Figure 4: Disable permissions for all the available scopes.     How Major Projects Manage Permissions   We began to wonder how popular open-source projects manage their workflows’ permissions. Do they limit each action to the minimum required?  Do they manage cases where several actions are used in one workflow and each requires a different level of permissions?   To answer these questions, we created a list of the top starred 2000 public projects on GitHub using GitHub actions. As workflows triggered by pull requests originating from forks are set with read-only permissions by default, we analyzed build logs triggered by “push” events, extracted the third-party actions in use in each workflow, and calculated their effective permissions against the repository.   We now have the following:   Database of actions and their required permissions, created by PiPER List of workflows used by the top 2,000 GitHub public repositories using GitHub Actions, as well as the third-party actions they use and their permissions granted through the GitHub token.   We learned that the top 2,000 repositories are configured with approximately 6,000 workflows, all of which use 1,045 unique actions. Key observations we made include:   1. A staggering 93% of the 2,000 GitHub repositories that use GitHub Actions have at least one overly permissive workflow.   Figure 5: 93% of the analyzed repositories have at least one workflow with excessive permissions, as calculated by comparing granted permissions to required permissions using PiPER.   2. The vast majority of the open-source projects, 80%, doesn’t specify permissions in their workflow yaml, leaving the problematic default permissions in effect. That’s a lot of projects! But, most of them probably set minimal default permissions in the repository level, right? Well, far from it — 86% of the projects that didn’t specify permissions in their workflows were found overly permissive. 3. What happens when the repository maintainers do set granular permissions? In 36% of the open-source projects that invested time limiting the permissions of their GitHub token, their workflows were still overly permissive. It happens because permissions granted don’t match the actions’ requirements, or they’re specified for the entire workflow and not tailored per each job’s requirements.   Major Projects Using Low-Reputation Actions   Additionally, we encountered many cases where low-reputation actions with a low number of stars and forks maintained by private users — not having a GitHub “Verified Creator” badge, GitHub own vetting process — are effectively granted write-all permissions. As we can see in the following examples, first by taking a peak in the build logs, this is how we can tell the effective permissions of a job is “write-all”:   Figure 6: The effective permissions of a job are printed to the build logs when it starts.     A few examples of low-reputation actions used by workflows of highly popular GitHub repositories — unpinned and granted with highly excessive permissions to the repository through the GitHub token — include re-actors/alls-green used by Microsoft and FastAPI, bwoodsend/setup-winlibs-action used by Cloudflare, and ljharb/actions used by Airbnb. This is a serious security risk. Any action compromised could potentially be used to attack your GitHub organization all the way to the production environment.   Remediation   GitHub Actions is a powerful tool that can help developers automate their workflows. But it’s important to stay on top of the security risks associated with using this tool.   Attackers could leverage a malicious action to compromise a repository. To mitigate this risk, use job isolation, running each job in a separate container. Then, if one job is compromised, the others won’t be affected.   Another important security measure is to use tailored permissions, meaning to grant only the permissions necessary for an action to complete its task. For example, if an action needs to access pull requests, it should only be granted the pull-request:read permission. Implementing job isolation and splitting third-party actions into separate jobs opens up the option to grant tailored permissions, which reduces granted permissions and mitigates the security risks associated with using GitHub Actions. It’s important to remember, though, that no security measure is perfect. You must remain vigilant and continuously evaluate the security of workflows to protect against potential security breaches.   Figure 7: Workflow with excessive permissions     Figure 8: Breaking down the workflow to separate jobs with granular permissions for each job   Additional Tips for Securing GitHub Actions Workflows   Use actions listed on the GitHub Marketplace that have the "verified creator" badge. Prefer known vendors you can trust over unknown actions maintained by private developers. Conduct a vetting process that includes reviewing the code of the third-party action and set the permissions accordingly. Pin actions to full commit hashes. This ensures that you always use a known-good version of an action, even if an attacker compromises an action and makes changes to the code.   By following these practices, you can help to protect your organization from the security risks associated with GitHub Actions workflow permissions.   Learn More   If you’re interested in learning practical tips to get started with CI/CD security, read the CI/CD Security Checklist. You’ll find six best practices to help you embrace CI/CD security and harden your pipelines over time. ... View more

By Jonathan Bregman, Senior Product Marketing Manager     With the rise in attacks on continuous integration and continuous delivery (CI/CD) environments, it’s no surprise that the U.S. Government recently released guidance to help organizations understand their risks and defend their pipelines. CI/CD pipelines are critical to cloud-native software development and host highly sensitive data and credentials. But they often exist outside the purview of traditional AppSec teams. To help AppSec practitioners secure their pipelines, we’re excited to announce CI/CD Security by Prisma Cloud. With graph-based CI/CD security in the industry’s most comprehensive code-to-cloud cloud-native application protection platform (CNAPP), Prisma Cloud gives you:   Unmatched visibility into your engineering ecosystem Protection from the OWASP Top 10 CI/CD Risks Pipeline Posture Management Attack Path Analysis via the Cloud Application Graph™   Let’s dive into the details.   Unmatched Visibility into the Engineering Ecosystem   As developers commit code to source control, most organizations have deployed various types of code scanners to detect misconfigurations in templates, vulnerabilities in open-source packages, exposed secrets and other issues. The best tools provide granular fix guidance directly for developers, but given the diversity of code and supporting scanners, AppSec teams are left with a fragmented view of risk spread across multiple siloed tools. What’s more, most organizations lack visibility into developers contributing to trusted artifact registries, which technologies and frameworks are in use, and how to export a software bill of materials (SBOM) of the environment. Prisma Cloud’s new Application Security dashboard unifies visibility across the engineering ecosystem. From a single pane, AppSec teams gain visibility across code repositories, contributors, technologies used and pipelines connected, along with specific code risks. By understanding which repositories and pipelines connect to production, teams can easily prioritize risk with full infrastructure context.   Figure 1: The Application Security dashboard provides a centralized view of your entire engineering ecosystem_palo-alto-networks.     Defending Against the OWASP Top 10 CI/CD Risks   ]Attacks that seek to breach delivery pipelines are far too common, and up until recently no industry-recognized framework was available. To provide guidance on attack vectors and best practices to mitigate them, Prisma Cloud’s world-class AppSec researchers developed and published a formally recognized industry benchmark — the OWASP Top 10 CI/CD Security Risks project. Organizations can benefit from the project at any stage in their CI/CD security journey. For example, it’s easy for teams to use the project’s guidance to help identify misconfigurations for version control systems (VCS) and CI/CD pipelines. Those misconfigurations could easily lead to code tampering, credential theft and ultimately a runtime breach.     Figure 2: The OWASP Top 10 CI/CD Security Risks_palo-alto-networks     Pipeline Posture Management   To embrace DevSecOps, it’s essential to observe the posture of your delivery pipeline, ensure it’s protected against the Top 10 CI/CD risks and then report your findings to leadership. Prisma Cloud’s new dashboard provides continuous visibility across the critical pipeline issues with added context like system risks and both the number and frequency of events to accurately measure and alert on criticality.   Figure 3: Prisma Cloud provides continuous pipeline posture management against the OWASP Top 10 CI/CD Risks_palo-alto-networks     Attack Path Analysis via the Cloud Application Graph™   The power that graph databases bring to contextualizing security insights can’t be overstated. The ability to correlate multiple risk signals simultaneously to map an attacker's pathway to a breach is critical to delivering high fidelity alerts for AppSec teams. The Prisma Cloud Application Graph™ provides a dynamic visualization of your engineering ecosystem that allows you to better understand and analyze the environment and relationships between all artifacts from code to deployment. By effectively modeling every asset, you can map attack paths. This is critical as you protect your delivery pipelines from today’s sophisticated attacks. For example, cross-platform misconfigurations like poisoned pipeline execution (PPE) are only discoverable with graph-based analysis, which is why Prisma Cloud’s CI/CD Security is built off of the world’s first Application Graph.    Figure 4: The Prisma Cloud Application Graph™ helps customers uncover breach paths_palo-alto-networks   CI/CD Security and AppSec: Looking to the Future   In this modern threat landscape, protecting the delivery pipeline is more important than ever. Going forward, security and risk leaders must prioritize hardening CI/CD systems and processes as they begin to rearchitect their AppSec programs to account for the evolving threat landscape. Since its inception, Prisma Cloud has been at the forefront of delivering solutions for the most pressing cloud security challenges. With the industry’s only code-to-cloud CNAPP, customers can now protect their delivery pipeline with graph-based CI/CD security. To watch a live demo of CI/CD Security by Prisma Cloud, visit us at booth #1332 at BlackHat USA 2023. We’ll also highlight our research with related talks at BSidesLV and DEFCON this year:   Actions Have Consequences: The Overlooked Security Risks in Third-Party GitHub Actions Wednesday, August 9 at 2:30pm PDT, BSidesLV The GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree Tuesday, August 8 at 5:00pm PDT, BSidesLV Saturday, August 12 at 1:30pm PDT, DEFCON   And if you want to learn which attack vectors you should prioritize at the start of your CI/CD security journey, read this technical guide on the Top 10 CI/CD Security Risks. ... View more

In this session we will discuss what the top trends are in cloud security and how breach response looks like in the current cloud landscape. What are the actions a company should take ahead of time, and what issues arise after a breach occurs. This talk will also focus on vulnerability MGMT, and the best practices for avoiding incidents. ... View more

By William Gamazo, Principal Researcher and Nathaniel Quist, Manager   Executive Summary   On July 11, 2023, Unit 42 cloud researchers discovered a new peer-to-peer (P2P) worm we call P2PInfect. Written in Rust, a highly scalable and cloud-friendly programming language, this worm is capable of cross-platform infections and targets Redis, a popular open-source database application that is heavily used within cloud environments. Redis instances can be run on both Linux and Windows operating systems. Unit 42 researchers have identified over 307,000 unique Redis systems communicating publicly over the last two weeks, of which 934 may be vulnerable to this P2P worm variant. While not all of the 307,000 Redis instances will be vulnerable, the worm will still target these systems and attempt the compromise.   The P2PInfect worm infects vulnerable Redis instances by exploiting the Lua sandbox escape vulnerability, CVE-2022-0543. While the vulnerability was disclosed in 2022, its scope is not fully known at this point. However, it is rated in the NIST National Vulnerability Database with a Critical CVSS score of 10.0. Additionally, the fact that P2PInfect exploits Redis servers running on both Linux and Windows operating systems makes it more scalable and potent than other worms. The P2P worm observed by Unit 42 researchers serves as an example of a serious attack threat actors could conduct using this vulnerability.   P2PInfect exploits CVE-2022-0543 for initial access and then drops an initial payload that establishes P2P communication to a larger P2P network. Once the P2P connection is established, the worm pulls down additional malicious binaries such as OS-specific scripts and scanning software. The infected instance then joins the P2P network to provide access to the other payloads to future compromised Redis instances.   Exploiting CVE-2022-0543 in this way makes the P2PInfect worm more effective at operating and propagating in cloud container environments. This is where Unit 42 researchers discovered the worm by it compromising a Redis container instance within our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.   Unit 42 believes this P2PInfect campaign is the first stage of a potentially more capable attack that leverages this robust P2P command and control (C2) network. There are instances of the word “miner” within the malicious toolkit of P2PInfect. However, researchers did not find any definitive evidence that cryptomining operations ever occurred. Additionally, the P2P network appears to possess multiple C2 features such as “Auto-updating” that would allow the controllers of the P2P network to push new payloads into the network that could alter and enhance the performance of any of the malicious operations. Unit 42 researchers will continue to monitor for changes and update accordingly.   Palo Alto Networks customers receive protections against the types of threats discussed in this article through products including:   Prisma Cloud Advanced WildFire Cloud-Delivered Security Services for the Next-Generation Firewall, including Advanced URL Filtering and Advanced Threat Prevention.   If you believe you have been compromised by P2PInfect, the Unit 42 Incident Response team can provide a personalized response.   Self-replicating Peer-to-Peer Worm   Unit 42 discovered the first known instance of P2PInfect on July 11, 2023, using our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.   The P2PInfect worm uses a P2P network to support and facilitate the transmission of malicious binaries. We chose the name because the term P2PInfect appears in the leaked symbols reflecting the malware author project structure, as shown in Figure 1.      Figure 1. Artifacts of the Windows version, names and Redis module_palo-alto-networks.   All collected samples of the P2P worm are written in Rust, a highly scalable and cloud-friendly programming language. This allows the worm to be capable of cross-platform infections that target Redis instances on both Linux and Windows operating systems (please note that Redis does not officially support the Windows OS).   The worm infects vulnerable Redis instances using the Lua sandbox escape vulnerability, CVE-2022-0543. The first exploit for this particular vulnerability was published in March 2022, which resulted in the connection of the infected Redis instance to the Muhstik botnet. However, the P2PInfect worm appears to be associated with a different malicious network, not known to be related to the Muhstik botnet.   After initial infection through the exploitation of the Lua vulnerability, an initial payload is executed that establishes a P2P communication to the larger C2 botnet, which serves as a P2P network for delivering other payloads to future compromised Redis instances. Once the P2P connection is established, the worm pulls down additional payloads, such as a scanner. The newly infected instance then joins the ranks of the P2P network to provide scanning payloads to future compromised Redis instances. Exploiting CVE-2022-0543 makes P2PInfect effective in cloud container environments. Containers have a reduced set of functionalities – for example, they do not have “cron” services. Many of the most active worms exploiting Redis use a technique to achieve remote code execution (RCE) using cron services. This technique does not work in containers. P2PInfect incorporates the exploit for CVE-2022-0543 with the intention of covering as many vulnerable scenarios as possible, including cloud container environments.   The following sections will cover details about the exploitation payloads, the behavior of P2PInfect, and some of the details of the P2P network protocol.   Since the P2PInfect worm is newly discovered, we have focused here on providing an overview of its behavior and the P2P architecture it supports, as well as basic sample analysis. However, additional analysis and study is warranted in future research.   Exploitation of CVE-2022-0543   P2PInfect currently exploits the Lua sandbox escape vulnerability CVE-2022-0543 for initial access. This vulnerability has been used in previous attacks such as Muhstik and Redigo, both of which resulted in the compromised Redis instances participating in denial-of-service (DoS), flooding and brute-forcing attacks against other systems.   This exploit vector follows a similar pattern to what has been seen previously. However, the post-exploit operations of P2PInfect are significantly different from the previous uses of the vulnerability. It is important to note that this vulnerability is not a Redis application vulnerability — it is specifically a Lua sandbox vulnerability.   While this campaign does target vulnerable Redis instances and perform worm-like operations, there are no known links to other threat actor groups known for targeting Redis and deploying worms, such as Automated Libra (aka PurpleUrchin), Adept Libra (aka TeamTNT), Thief Libra (aka WatchDog), Money Libra (aka Kinsing), Aged Libra (aka Rocke) or Returned Libra (aka 8220).   How P2PInfect Leverages CVE-2022-0543 to Infect Vulnerable Redis Instances   The P2PInfect worm’s initial infection vector – exploiting Redis through CVE-2022-0543 – is not common among other cryptojacking-focused worms known to target Redis instances, such as those created by Adept Libra (aka TeamTnT), Thief Libra (aka WatchDog) threat actors or the ones delivering Money Libra (aka Kinsing) variants. These groups use alternative Redis vulnerabilities or misconfigurations in order to operate.   CVE-2022-0543 is a vulnerability with the Lua library related to the way Redis is packaged and delivered by Debian Linux package management. As such, it only affects users of Redis who use the Debian or derived (Ubuntu and others) distributions. Due to the focus on the OS and leveraging a subcomponent of Redis to compromise, P2PInfect’s exploitation efforts are therefore complex. Figure 2 shows an example of a captured exploit for CVE-2022-0543.     Figure 2. Example of the P2PInfect exploit on the Debian OS_palo-alto-networks.   .     Within the above image, one can see how the vulnerability is being weaponized. By using network requests through /dev/tcp, as seen on line four, the threat actor connects to a C2 IP address, written as ip-cnc over port 60100. Port 60100 is one of the P2P communication ports used by P2PInfect to maintain C2 communication. The initial payload, also seen on line four, sets the GET request to the directory /linux, which is the main dropper maintaining the core functionality of the P2PInfect worm. Other binaries are distributed within the P2P network, as we are going to see later in the article.   Network Communication Behavior   P2PInfect uses its P2P network to distribute follow-up malware to newly infected systems or cloud instances. When a system is first compromised, it will make a network connection to the P2P network and download the samples for the custom protocol to be used. As Figure 3 illustrates, the command: GET /linux, is followed by the image download of the core P2PInfect functionality.     Figure 3. Network communication protocol displaying the download of P2PInfect. Both Linux and Windows OS P2PInfect samples communicate in the same manner. The following samples were downloaded from the P2P network in plaintext: linux, miner, winminer and windows (see Figure 4).     Figure 4. List of the malware samples pulled from the P2P network_palo-alto-networks.      .   Once the core P2PInfect sample finishes execution, the payload will start scanning for additional hosts to compromise. The scanning operation focuses on exposed Redis hosts. However, researchers also found that compromised Redis instances also perform scanning attempts over port 22, SSH. While it is not clear why this scanning operation is taking place, as there are no known exploitation attempts by P2PInfect to compromise SSH, it is not altogether uncommon for port 22 to be scanned post-compromise by other known worms. Please see the Scanning Behavior section for additional details.   Node Communications   The main dropper communicates with any other listening P2P members on the current list of configured nodes using TLS 1.3. The C2 infrastructure is updated when the compromised node sends a json request with all known nodes to the P2P network. Updates to the C2 infrastructure will automatically be downloaded. The following image, Figure 5, shows an example of the nodes update.     Figure 5. P2P nodes update_palo-alto-networks.     The values with x.x.x.x are the current node IP, or the new learned nodes.   Scanning Behavior   Figure 6 illustrates the network scanning behavior of an infected host scanning for exposed SSH instances. These scanning operations occur across a random netrange selected by the P2PInfect functionality. Figure 6. Scanning traffic for SSH instances_palo-alto-networks.   . Figure 7 illustrates the P2PInfect scanning operations for exposed Redis instances.     Figure 7. Scanning traffic for Redis instances_palo-alto-networks.     Other Observations of P2PInfect   Some of the initial payload P2PInfect samples deliver ed to exploited systems were packed with UPX, while the second-stage malware samples, miner and winminer, were not UPX packed.   After the first dropper runs, it starts decrypting the configuration received from a command line, with information about other nodes in the P2P network. We found that the P2P port was variable – a design choice that allows the attack to be resilient to blocking and network firewall mitigation techniques (see Figure 8).     Figure 8. Example of the variable port usage of P2PInfect_palo-alto-networks.   All samples identified by Unit 42 researchers have been written in Rust, and some have “symbols leaked” inside, which gives indicators about the malware authors’ project structure. For example, the windows sample main execution thread leaks the name of the project as well as the file directory usage of the threat actor (see Figure 9).     Figure 9. Analysis pulled from the core Windows P2PInfect sample_palo-alto-networks.   We also identified a PowerShell script designed to establish and maintain communication between the compromised host and the P2P network. The PowerShell script leveraged the encode command to obfuscate the communication initiation (see Figure 10).     Figure 10. Obfuscated PowerShell command to establish P2P network connection_palo-alto-networks.   One of the first operations performed by the PowerShell command is to configure the local system firewall to block legitimate access to or from the compromised Redis application (see line five of Figure 11). Then (starting on line 17 in Figure 11), the script opens a communication port for the threat actor to access the compromised instance. This is a form of persistence, allowing the threat actors to maintain access to the infected host and keep it operable.       Figure 11. Modifying the network traffic rules of a compromised Windows instance_palo-alto-networks.     Of note from the decoded PowerShell, shown in Figure 11, are the following firewall configuration settings: Peer-to-peer port is 60102 – this port is variable, as not all nodes use the same port Redis port 6379 is only allowed to connect known C2 IPs The firewall rule is named Microsoft Sync   The Monitor Process   Another interesting feature of the initial P2PInfect payload when running in Windows OS is a process called the Monitor. The Monitor process fulfills the role of maintaining the functionality of the P2PInfect running processes on the infected host. The Monitor is dumped to C:\Users\username\AppData\Local\Temp\cmd.exe (see Figure 12 for an example of the Monitor (cmd.exe) enumerating system running processes).     Figure 12. The P2PInfect Monitor sample, cmd.exe process tree_palo-alto-networks.   After launching the Monitor (cmd.exe), the initial P2PInfect payload downloads new versions of itself from the P2P network and persists them with random names into the same original folder and an encrypted configuration is dropped (.conf) (see Figure 13).     Figure 13. Example of the random file names_palo-alto-networks.     The new P2PInfect download versions are executed, and the scanning operations to locate additional vulnerable Redis instances starts. The initial P2PInfect dropper will attempt to delete itself (see Figure 14).     Figure 14. Deletion of the core P2PInfect payload_palo-alto-networks.       Conclusion   The P2PInfect worm appears to be well designed with several modern development choices. Key among these is the use of the Rust language, which provides resilient capabilities and the flexibility to allow the worm to rapidly spread across multiple operating systems.   The design and building of a P2P network to perform the auto-propagation of malware is not something commonly seen within the cloud targeting or cryptojacking threat landscape. At the same time, we believe it was purpose-built to compromise and support as many Redis vulnerable instances as possible across multiple platforms.   We have caught several samples within our HoneyCloud platform, across multiple geographic regions, and we strongly believe the number of P2P nodes is growing. This is due to the volume of potential targets – over 307,000 Redis instances communicating publicly over the last two weeks – and since the worm was able to compromise multiple of our Redis honeypots across disparate regions. However, we don't have an estimate yet of how many nodes exist or how fast the malicious network associated with P2PInfect is growing.   We recommend that organizations monitor all Redis applications, both on-premises and within cloud environments, to ensure they do not contain random filenames within the /tmp directory. Additionally, DevOps personnel should continually monitor their Redis instances to ensure they maintain legitimate operations and maintain network access. All Redis instances should also be updated to their latest versions or anything newer than redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2.   Palo Alto Networks customers receive protections against the types of threats in the following ways:   Prisma Cloud is capable of identifying the runtime environment of any cloud Redis instance to ensure it detects and prevents the unknown and malicious execution of the P2PInfect worm. Cloud-Delivered Security Services for the Next-Generation Firewall include a variety of protections. Advanced URL Filtering blocks malicious IoCs related to this worm. Advanced Threat Prevention can block the attacks with Best Practices via Threat Prevention signatures 92349 and 93004. The Advanced WildFire cloud-delivered malware analysis service accurately identifies known samples as malicious.   If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:   North America Toll-Free: 866.486.4842 (866.4.UNIT42) EMEA: +31.20.299.3130 APAC: +65.6983.8730 Japan: +81.50.1790.0200   Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.   Indicators of Compromise   SHA256 Samples   Linux: 88601359222a47671ea6f010a670a35347214d8592bceaf9d2e8d1b303fe26d7 Miner: b1fab9d92a29ca7e8c0b0c4c45f759adf69b7387da9aebb1d1e90ea9ab7de76c Windows: 68eaccf15a96fdc9a4961daffec5e42878b5924c3c72d6e7d7a9b143ba2bbfa9 WinMiner: 89be7d1d2526c22f127c9351c0b9eafccd811e617939e029b757db66dadc8f93   IPs   35.183.81[.]182 66.154.127[.]38 66.154.127[.]39 8.218.44[.]75 97.107.96[.]14   CNC Requests   GET /linux GET /linux_sign GET /miner GET /miner_sigg GET /winminer GET /winminer_sign GET /windows_sign GET /windows Updated July 20, 2023, at 1:08 p.m. PT.  ... View more

    Discuss the new Network Investigate Graph and how it simplifies and enhances investigation. ... View more

By Shashank Chandramohan, Senior Customer Success Engineer    In the past, application teams would be required to code from scratch, from building an application to releasing a new version, at best, every one or two years using standard shipping distribution methods. Today, application teams often use third-party open-source resource libraries and the cloud to get their products into the hands of users. These methods have sped up development to the point where application teams can release much faster, such as once a month or once a week.    Information security has had to adopt a new model to span the application lifecycle to keep up with the development speed, new technologies, and infrastructure changes.    At Palo Alto Networks, we use the Code & Build, Deploy, Run (CBDR) framework. With this approach, you have four phases to prevent misconfigurations that can lead to vulnerabilities.    The phases are   Code - Writing the code to create the resource. Build - Compiling the resource and its configuration. Deploy - Deploying the resource to where it is housed. Run - Running the resource and the live environment in which it is hosted.   This article focuses on the CBDR framework's final phase, the Run phase. If you want to start from the first phase, you can read about the Code & Build or Deploy lifecycle phases by clicking the blog links above.   Even though most successful exploits and breaches result from misconfigurations and vulnerabilities introduced in the Code & Build or Deploy phases, maintaining security is still crucial in the Run phase because vulnerabilities and exploits can be introduced in any phase of the application lifecycle. Run focuses on securing your workloads in the cloud with your security infrastructure, maintaining network security, and keeping an eye out for breaches, given that assets have already been deployed and are now externally facing. Figure 1 - use cases of Prisma Cloud during the Run Phase   In the Run Phase, you're preventing and detecting breaches trying to access your production assets, network workloads, identities, and data. Prisma Cloud can help your organization’s security professionals detect, analyze, and remediate the common issues that appear in live environments, which range from crypto-jacking, where someone uses your Cloud resources to do crypto mining, to ransomware.    The Run phase’s security should not depend on only daily and infrequent scans. Daily scans can miss costly breaches and malware that is gone by the time abnormal behavior is detected. In a modern production environment, ephemeral cloud resources might only exist for minutes or hours, so it's essential to have a solution that continuously monitors and looks for vulnerabilities and attacks while the resources are active.   Prisma Cloud secures your runtime environment using predictive and threat-based protections. It can run and deliver results in near real-time, 24/7/365, eliminating the missed spots from when your resources were checked only once or twice a day. Your security personnel can be notified and start working on threats within minutes, saving time and money at scale.   By continuously monitoring your runtime environments, Prisma Cloud goes beyond protecting you from known vulnerabilities and can detect the suspicious behavior of a zero-day vulnerability. Using our machine-learning models based on what is normal for your resources - if behavior deviates from the norm and is malicious, you will be alerted and able to act quickly.    Prisma Cloud uses Palo Alto Wildfire to detect previously unseen targeted malware and advanced persistent threats. And best of all, we bring the resources and research from our world-renowned Unit 42 Security Group to help protect your runtime environment.   Drilling Down Prisma Cloud can identify and remediate issues to secure your assets with the following capabilities:   Compliance and Governance Misconfiguration and Threat Detection  Vulnerability Management Runtime Security Web App and API Security  Integrated Access Management Security Data Security Network Security.      Compliance and Governance  Cloud compliance comprises the procedures that ensure that your cloud environment complies with your governance rule. When you build a compliant cloud environment, your environment conforms to one or more specific sets of security and privacy standards. Some common compliance frameworks include PCI DSS, GDPR, FedRAMP, and various versions of NIST. Prisma Cloud has you covered and comes with over 20 of the most commonly used compliance frameworks for use out-of-the-box, and you can tailor and create your own rules and policies for your organization’s specific needs, making it simple to set up and maintain compliance. You can also view, assess, report, monitor, and create reports that contain summary and detailed findings of security and compliance risks in your cloud environment on one or more cloud accounts and review your cloud infrastructure's health and compliance posture.    Figure 2- The Prisma Cloud Compliance Overview screen includes a line graph to the left showing the number of resources that exist, have failed, and passed on a monthly timeline. There is also a bar graph on the right that shows compliance coverage based on compliance frameworks. The Compliance Overview screen allows you to assess your compliance trends and coverage over time at a glance.   Web Application and API Security (WAAS) WAAS enhances the traditional Web Application Firewall (WAF) protection model by deploying closer to the application, efficiently scaling up or down, and allowing for inspection of "internal" traffic (east-to-west) from other microservices as well as inbound traffic (north-to-south). Prisma Cloud supports both inline and out-of-band WAAS, which you can use on your hosts and containers.  Inline WAAS offers more protection and features at the cost of using more resources in your cloud. Out-of-band WAAS allows you to run your production loads unchanged, with the WAAS monitoring done elsewhere in your network.    Prisma Cloud WAAS can block new zero-day attacks as soon as they are identified without waiting for modified applications.    Some Highlights of WAAS’s capabilities are: OWASP Top-10 Coverage - Protection against most critical security risks to web applications, including injection flaws, broken authentication, broken access control, security misconfigurations, etc. API Protection - WAAS can enforce API traffic security based on definitions or specs. Access Control - WAAS controls access to protected applications using Geo-based, IP-based, or HTTP Header-based user-defined restrictions. File Upload Control - WAAS secures application file uploads by enforcing file extension rules. Detection of Unprotected Web Applications - WAAS detects and flags unprotected web applications in the radar view. Penalty Box for Attackers - WAAS supports a 5 minutes ban of IPs triggering one of its protections to slow down vulnerability scanners and other attackers probing the application. Bot Protection - WAAS detects good-known bots and other bots, headless browsers, and automation frameworks. WAAS can also fend off cookie droppers and other primitive clients by mandating the use of cookies and Javascript for the client to reach the protected origin. DoS Protection - WAAS can enforce rate limitations on IPs to protect against high-rate and "low and slow" layer-7 DoS attacks.   Figure 3- Prisma Cloud’s WAAS Explorer dashboard in Prisma Cloud   There are four graphs:  Web protection coverage graph: how many critical  unprotected and vulnerable web apps you have with a line for high, medium, low & none.  Activity overview line graph: the number of policy changes, total traffic, access control, API, DoS, Custom, and WAF activities.  Line graph: the inspected traffic by WAAS, showing how many requests and bytes with the WAAS actions by effect.  Bar graph: total attacks per type and a summary of the WAAS configured policies & rules.   Runtime Security Runtime security is a vast set of features that protect containers and threat-based active protection for running containers, hosts and serverless functions. Threat-based protection includes capabilities like detecting when malware is added to a workload or when a workload connects to a botnet - all in real time. With Prisma Cloud, you can use both agent-based and agentless-based runtime defense and security separately or simultaneously. Agent-based can block threats in real-time, such as crypto mining and malicious code but is more resource intensive. With limited resources, agentless scanning can cover your entire cloud without deploying agents on every host. With both agent-based and agentless scanning, you can use Prisma Cloud to detect changes to the file system, network, and process activity, with each sensor having its own set of rules and alerting - keeping you protected no matter the number of resources you have available.     Data Security In the Run phase, data security is crucial for preventing leaks of personally identifiable information (PII) and sensitive data that may have been overlooked. With so many resources being run on your workloads, it is difficult to scan and ensure that none of them have potentially exposed data.    Prisma Cloud has 600 data profiles & patterns out of the box and is customizable for your organization’s use cases. For example, you can set various roles at your organization to only see the data masked. This provides your organization with the principle of least privilege, ensuring that only authorized users can access sensitive data.   Conclusion With faster development and release times come new technologies and challenges. Instead of relying on past methods that only scan and monitor once or twice daily, teams need real-time coverage of resources that can scale. Prisma Cloud can scale to meet these needs with automation and customizable tools that cover you from Compliance and Reporting to Runtime Security and WAAS.   About the Author     ... View more

    Join us to talk about the latest releases in Code Security, include our upcoming new module release, that expands supply chain security and simplifies finding and prioritizing issues. We’ll show a teaser for our upcoming CI/CD Security launch, enhanced Projects page, new integrations with JetBrains IDEs, Terraform Cloud and Enterprise, expanded SCA and Terraform support and more. ... View more

  By RD Singh, Sr. Customer Success Engineer   Prisma Cloud Code Security helps to detect mis-configured IaC templates based on various standards and best practices. It also helps findings vulnerabilites in open source packages and their depedencies. Watch this demo with RD Singh, Sr. Customer Success Engineer, to learn how to connect your IDE with Prisma Cloud Code Security. To read the step-by-step instructions outlined in this video, visit our TechDoc: https://docs.paloaltonetworks. com/prisma/prisma-cloud/ prisma-cloud-admin-code- security/get-started/connect- your-repositories/connect- vscode ... View more