aws-lexv2-slots
Additional permissions required:
lex:GetBotslex:ListBotLocaleslex:ListIntentslex:ListSlotsThe Security audit role does not include the permissions.
| | **Amazon Detective** |aws-detective-member
Additional permissions required:
detective:ListGraphsdetective:ListMembersdetective:GetMembersThe Security audit role includes the detective:ListGraphs and detective:ListMembers permissions but does not include the detective:GetMembers permission.
aws-appfabric-app-bundle
Additional permissions required:
appfabric:ListAppBundlesappfabric:GetAppBundleappfabric:ListTagsForResourceThe Security audit role does not include the permissions.
| | **AWS AppFabric** |aws-appfabric-app-authorization
Additional permissions required:
appfabric:ListAppBundlesappfabric:ListAppAuthorizationsappfabric:GetAppAuthorizationappfabric:ListTagsForResourceThe Security audit role does not include the permissions.
| | **AWS Organizations** |aws-organizations-aws-service-access-for-organization
Additional permission required:
organizations:ListAWSServiceAccessForOrganizationThe Security audit role includes the permission.
| | **AWS Organizations** |aws-organizations-delegated-services-for-account
Additional permission required:
organizations:ListDelegatedServicesForAccountThe Security audit role includes the permission.
| | **Amazon Keyspaces** |aws-keyspaces-table
Additional permission required:
cassandra:SelectThe Security audit role does not include the permission.
| | **Amazon QuickSight** |aws-quicksight-iam-policy-assignment
Additional permissions required:
quicksight:DescribeIAMPolicyAssignmentquicksight:ListNamespacesquicksight:ListIAMPolicyAssignmentsThe Security audit role includes the permissions.
| | **Azure Log Analytics** |azure-log-analytics-data-exports
Additional permissions required:
Microsoft.OperationalInsights/workspaces/readMicrosoft.OperationalInsights/workspaces/dataexports/readThe Reader role includes the permissions.
| | **Azure Arc** |azure-arc-machine-license-profile
Additional permissions required:
Microsoft.HybridCompute/machines/readMicrosoft.HybridCompute/machines/licenseProfiles/readThe Reader role includes the permissions.
| | **Azure Arc** |azure-arc-machine
Additional permission required:
Microsoft.HybridCompute/machines/readThe Reader role includes the permission.
| | **Azure Arc** |azure-arc-private-link-scope
Additional permission required:
Microsoft.HybridCompute/privateLinkScopes/readThe Reader role includes the permission.
| | **Azure Arc** |azure-arc-license
Additional permission required:
Microsoft.HybridCompute/licenses/readThe Reader role includes the permission.
| | **Azure App Service** |azure-app-service-certificate-order
Additional permission required:
Microsoft.CertificateRegistration/certificateOrders/ReadThe Reader role includes the permission.
| | **Azure API Management Services** |azure-api-management-service-private-endpoint-connection
Additional permissions required:
Microsoft.ApiManagement/service/readMicrosoft.ApiManagement/service/privateEndpointConnections/readThe Reader role includes the permissions.
| | **Azure API Management Services** |azure-api-management-service-cache
Additional permissions required:
Microsoft.ApiManagement/service/readMicrosoft.ApiManagement/service/caches/readThe Reader role includes the permissions.
| | **Azure Event Grid** |azure-event-grid-topic-event-subscription
Additional permissions required:
Microsoft.EventGrid/topics/readMicrosoft.EventGrid/topics/eventSubscriptions/readThe Reader role includes the permissions.
| | **Azure Event Grid** |azure-event-grid-domain-event-subscription
Additional permissions required:
Microsoft.EventGrid/domains/readMicrosoft.EventGrid/domains/eventSubscriptions/readThe Reader role includes the permissions.
| | **Google Backup and DR** |gcloud-backup-dr-backup-vault-data-source-backup
Additional permissions required:
backupdr.backupVaults.listbackupdr.bvdataSources.listbackupdr.bvbackups.listThe Viewer role includes the permissions.
| | **Google Backup and DR** |gcloud-backup-dr-backup-vault-data-source
Additional permissions required:
backupdr.backupVaults.listbackupdr.bvdataSources.listThe Viewer role includes the permissions.
| | **Google Backup and DR** |gcloud-backup-dr-backup-vault
Additional permission required:
backupdr.backupVaults.listThe Viewer role includes the permission.
| | **Google Backup and DR** |gcloud-backup-dr-backup-plan-association
Additional permission required:
backupdr.backupPlanAssociations.listThe Viewer role includes the permission.
| | **Google Backup and DR** |gcloud-backup-dr-backup-plan
Additional permission required:
backupdr.backupPlans.listThe Viewer role includes the permission.
| | **OCI IAM** |oci-iam-user-db-credential
Additional permissions required:
USER\_INSPECTDB\_CREDENTIAL\_INSPECTThe Reader role includes the permissions.
| ## New Policies| Policies | Description |
| AWS Lightsail Instance allows ingress from the internet | Policy Description— Unrestricted internet ingress to AWS Lightsail instances exposes them to unauthorized access. This misconfiguration leaves instances vulnerable to various attacks. AWS Lightsail instances use a built-in firewall to control inbound traffic. By default, or through misconfiguration, all ports might be open to the internet. This allows attackers to easily scan for open ports and exploit known vulnerabilities, leading to instance compromise and data breaches. Attackers can launch brute-force attacks against common services like SSH, potentially gaining full control. The impact of this misconfiguration includes data exfiltration, unauthorized modification of instance resources, and potential use as a stepping stone for further attacks within the cloud environment. Limiting access to only trusted IP addresses is crucial for minimizing the attack surface and preventing unauthorized access. Implement a least privilege approach. Configure the Lightsail instance’s firewall to allow only necessary ports and specific trusted IP addresses. Regularly review and update firewall rules to remove any unnecessary access and mitigate the risk of unauthorized connections. Monitor logs for suspicious activity. Policy Severity— Low Policy Type— Config |
| AWS Lightsail Instance not configured with Instance Metadata Service v2 (IMDSv2) | Policy Description— AWS Lightsail instances lacking Instance Metadata Service version 2 (IMDSv2) configuration pose a significant security risk. Instances without IMDSv2 are vulnerable to unauthorized access to sensitive metadata, potentially leading to data breaches or server compromise. The Instance Metadata Service provides metadata about the instance, including details like instance ID, security credentials, and private IP address. Without IMDSv2’s session authentication, attackers could exploit misconfigurations or vulnerabilities in other services (like misconfigured firewalls or reverse proxies) to access this sensitive information. This access can facilitate lateral movement within an environment or enable unauthorized actions on the instance. Failure to enforce IMDSv2 exposes the instance to various attack vectors, resulting in data exfiltration, privilege escalation, and complete system compromise. Employing IMDSv2 ensures requests are authenticated, thereby mitigating these risks and protecting sensitive data. To remediate this misconfiguration, explicitly enable IMDSv2 for all AWS Lightsail instances. This can typically be accomplished through the AWS console or CLI, configuring the instance settings. Regularly audit your instances to ensure consistent IMDSv2 implementation across your environment. Policy Severity— Medium Policy Type— Config |
| GCP AlloyDB Cluster instance allows direct unencrypted connection | Policy Description— GCP AlloyDB Cluster instances permitting unencrypted connections pose a significant security risk, exposing sensitive data in transit to eavesdropping and unauthorized access. The AlloyDB service allows both encrypted and unencrypted connections by default if SSL is not explicitly enabled. Disabling SSL introduces a major security risk, as all communication with the database instance occurs in plain text. Attackers can intercept this data easily, potentially leading to data breaches and unauthorized database modifications. A misconfiguration allowing unencrypted connections exposes sensitive data, impacting confidentiality and integrity. Enabling SSL is crucial to protect data in transit, ensuring only authorized users with properly authenticated connections can access the database. This practice aligns with industry best practices for securing database communication. To mitigate this, enforce SSL encryption on all AlloyDB Cluster instances. Configure the instance to only accept encrypted connections. Regularly audit configurations to ensure SSL remains enabled and verify all connections utilize SSL encryption. Policy Severity— Medium Policy Type— Config |
| GCP AlloyDB instance with IAM authentication disabled | Policy Description— GCP AlloyDB instances lacking IAM authentication are susceptible to unauthorized access. Disabling IAM authentication relies solely on database passwords for access, increasing the risk of breaches via password compromise or leaks. AlloyDB’s IAM authentication integrates with Google Cloud’s Identity and Access Management system, enabling granular control over database access. Without IAM, security relies on password management alone, which is vulnerable to brute-force attacks, phishing, or weak password policies. This misconfiguration exposes sensitive data within the database to unauthorized individuals or malicious actors. The impact of this misconfiguration includes data breaches, unauthorized database modifications, and potential service disruptions. Enabling IAM authentication provides a more secure authentication method by leveraging the robust security features of GCP’s IAM system, minimizing the risk of unauthorized access and improving overall security posture. To mitigate this, ensure IAM authentication is enabled on all AlloyDB instances. Regularly review and update IAM permissions to ensure only authorized users and service accounts have access. Implement strong password policies and multi-factor authentication (MFA) for all database users, even when IAM authentication is enabled, as an additional layer of security. Policy Severity— Medium Policy Type— Config |
| GCP AlloyDB Instance with insecure password policy | Policy Description— Insecure password policies on GCP AlloyDB instances allow unauthorized access. Weak or easily guessable passwords increase the risk of database compromise. GCP AlloyDB instances utilize password-based authentication. A weak password policy increases the likelihood of brute-force or credential stuffing attacks leading to data breaches and unauthorized modifications. Failure to enforce strong passwords exposes the database to significant security risks. Compromised AlloyDB instances can result in data exfiltration, service disruption, and financial losses. Enforcing a robust password policy significantly reduces the risk of unauthorized access by requiring complex and regularly updated passwords. Implement a strong password policy for all AlloyDB instances. Ensure 'password.enforce_complexity', 'password.enforce_expiration', and 'password.enforce_password_does_not_contain_username' are set to 'on'. 'password.expiration_in_days' should be less than 90, 'password.min_pass_length' greater than or equal to 10, and 'password.min_uppercase_letters' and 'password.min_numerical_chars' should be at least 1. Regularly review and update password policies. Policy Severity— Medium Policy Type— Config |
| GCP AlloyDB Cluster’s Continuous Backup not encrypted with CMEK | Policy Description— GCP AlloyDB clusters lacking CMEK encryption for continuous backups expose sensitive data to unauthorized access. AlloyDB’s continuous backup feature, enabled by default, creates cluster backups. Without CMEK encryption, these backups are protected by Google-managed keys, reducing organizational control over sensitive data. Attackers gaining access to Google’s infrastructure could potentially decrypt and exfiltrate this data. A data breach resulting from this misconfiguration could lead to significant financial losses, regulatory penalties, and reputational damage. Encrypting backups with CMEK ensures only authorized users with access to the customer-managed encryption keys can decrypt and access the data, aligning with data security best practices and minimizing the impact of potential breaches. To mitigate this risk, enable CMEK encryption for all AlloyDB cluster continuous backups. Regularly review and audit CMEK key management practices to ensure ongoing protection. Implement strong access controls to restrict access to the CMEK keys. Policy Severity— Medium Policy Type— Config |
| GCP Dataproc Serverless Batch is using default network | Policy Description— GCP Dataproc Serverless Batch instances are deployed on the default network, exposing them to unnecessary risks. This misconfiguration increases the attack surface and compromises security posture. The default network lacks granular control over network traffic and resource isolation. It offers broad access between resources, allowing unauthorized communication between Dataproc instances and other GCP services or external entities. This can lead to data breaches, unauthorized access to sensitive data, and lateral movement within the GCP environment. This misconfiguration significantly impacts the organization’s security and compliance posture. A compromised Dataproc Serverless Batch instance could lead to data loss, service disruption, and reputational damage. Implementing a custom Virtual Private Cloud (VPC) network with appropriate firewall rules and subnets is crucial for enhancing security and mitigating risks. To remediate this, use a custom VPC network for Dataproc Serverless Batch. Configure appropriate firewall rules to restrict inbound and outbound traffic to only necessary services and IP addresses. Segment your network using subnets to isolate resources and enhance security. Utilize private Google Access for secure communication with Google services. Policy Severity— Medium Policy Type— Config |
| GCP Dataproc Serverless Session template is using default network | Policy Description— GDataproc Serverless session templates utilizing the default network in GCP pose a significant security risk. The default network lacks the necessary security controls and isolation for production workloads, increasing the attack surface. GCP’s default network offers broad access between resources, enabling unauthorized communication between instances. This lack of segmentation and inherent misconfiguration increases the risk of data breaches and lateral movement if an attacker compromises a single instance. Without customized firewall rules and network policies, the default network’s open nature is easily exploited. The impact of this misconfiguration is substantial, potentially leading to unauthorized data access, system compromise, and significant business disruption. Implementing a custom Virtual Private Cloud (VPC) network with tailored firewall rules and appropriate subnet segmentation is crucial for mitigating these risks. This provides better control over network traffic, access, and resource isolation. To remediate this issue, use a custom VPC network and migrate Dataproc Serverless session templates to this new network. Implement appropriate firewall rules to restrict access to only authorized IP addresses and services. Segment the network using subnets to further isolate resources and enforce the principle of least privilege. Regularly review and update network configurations to maintain security posture. Policy Severity— Medium Policy Type— Config |
| GCP Dataproc Serverless Session is using default network | Policy Description— Dataproc Serverless sessions using the default network in GCP pose a significant security risk. This misconfiguration exposes resources to unintended network access and lacks essential security controls. The default network in GCP provides broad, unrestricted access between all instances. This lack of network segmentation allows unauthorized communication between sensitive and non-sensitive workloads. An attacker exploiting a misconfigured application within one instance could easily pivot to other instances within the default network. This lack of isolation dramatically increases the attack surface and the potential for data breaches or system compromises. The impact of this misconfiguration includes data breaches, unauthorized access to sensitive information, and compromised application integrity. Employing a custom VPC with appropriate firewall rules and network segmentation ensures that only authorized traffic can access resources. This practice enhances security posture and reduces the likelihood of successful attacks. To mitigate this risk, use a custom Virtual Private Cloud (VPC) network for Dataproc Serverless. Configure appropriate firewall rules to restrict inbound and outbound network traffic to only authorized sources and destinations. Implement network segmentation by creating subnets for different workloads, further limiting the impact of potential breaches. Policy Severity— Medium Policy Type— Config |
| GCP Dataproc Cluster on GKE is using default network | Policy Description— Dataproc clusters on Google Kubernetes Engine (GKE) using the default network in GCP pose a significant security risk. This misconfiguration allows broad, unrestricted communication between all instances within the default network, bypassing necessary security controls. The default network lacks essential security features like segmentation and fine-grained control over network traffic. It offers no inherent isolation between different workloads, increasing the risk of lateral movement and data breaches. Attackers could exploit this lack of isolation to compromise multiple systems, potentially accessing sensitive data or disrupting operations. The impact of this misconfiguration is far-reaching. It increases the attack surface, exposes sensitive data to unauthorized access, and hinders compliance efforts. A custom Virtual Private Cloud (VPC) provides robust security through subnets, firewall rules, and improved network segmentation, mitigating these risks. Implementing these controls enhances security posture and reduces the likelihood of successful attacks. To remediate this, use a custom VPC network with appropriately configured subnets and firewall rules. Restrict traffic flow between resources based on least privilege principles. Ensure proper segmentation of workloads and implement robust access controls to isolate sensitive data. Regularly review and update network configurations to maintain security. Policy Severity— Medium Policy Type— Config |
| GCP Dataproc Cluster on Compute Engine is using default network | Policy Description— GCP Dataproc clusters deployed on the default network pose significant security risks due to its inherent lack of security controls and segmentation. This misconfiguration exposes the cluster to unauthorized access and potential data breaches. The default network in GCP offers minimal security controls, allowing broad access between resources within the network. This lack of isolation increases the attack surface, enabling lateral movement and unauthorized access to sensitive data within the Dataproc cluster. Attackers could exploit this misconfiguration to gain access to the cluster and its underlying resources, potentially leading to data exfiltration or disruption of services. The impact of this misconfiguration could range from unauthorized access to sensitive data and system compromise to complete data loss. Using a custom Virtual Private Cloud (VPC) network with appropriate firewall rules, subnets, and access controls enhances security, promotes better resource organization, and enables compliance with security regulations. Implementing robust network segmentation is crucial for isolating sensitive workloads and minimizing the impact of potential breaches. To mitigate this risk, use a custom VPC network specifically for your Dataproc cluster. Configure appropriate firewall rules to restrict inbound and outbound traffic, allowing only necessary connections. Utilize subnets to isolate resources and apply appropriate Identity and Access Management ('IAM') policies to limit access to authorized users and services only. Regularly review and update network configurations to maintain a strong security posture. Policy Severity— Medium Policy Type— Config |
| Policy Updates | Description |
| Policy Updates—RQL | |
| AWS MFA is not enabled on Root account | Changes— The Policy RQL is updated to consider the centralized root access introduced by AWS thereby reducing false positives. Current Description– This policy identifies root account which has MFA enabled. Root accounts have privileged access to all AWS services. Without MFA, if the root credentials are compromised, unauthorized users will get full access to your account. This policy does not apply to AWS GovCloud Accounts. As you cannot enable an MFA device for AWS GovCloud (US) account root user. For more details refer: https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-console.html. Updated Description– This policy identifies root account which does not have MFA enabled. Root accounts have privileged access to all AWS services and can perform critical actions within the environment. In the event that the root credentials are compromised, malicious users could gain full control over the AWS account. This could lead to unauthorized access, data breaches, and potential damage to resources or services. To address this risk, the solution is to enforce the activation of MFA for all root accounts. By enabling MFA, any attempt to access the root account would require both the root credentials and the second factor of authentication. This significantly reduces the likelihood of unauthorized access and enhances the overall security of the AWS environment. This policy does not apply to AWS GovCloud Accounts. As you cannot enable an MFA device for AWS GovCloud (US) account root user. For more details refer: https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-console.html. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Medium Impact– Low. Open alerts where centralized root access is enabled will be resolved. |
| Azure SQL server public network access setting is enabled | Changes— The Policy RQL is updated to align with the latest changes and updates in Azure Cloud. This update ensures improved compatibility and performance, providing users with the most up-to-date security and compliance checks specific to Azure Cloud environments. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Medium Impact– Low. No impact on the valid alerts. Open alerts are resolved as Policy updated. |
| Azure Network Watcher Network Security Group (NSG) flow logs are disabled | Changes— The Policy RQL is updated to exclude resources created by Prisma for agentless scans to reduce the noise. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Medium Impact– Low. Open alerts where the resource is created by prismacloud-agentless-scan will be resolved. |
| Azure Cosmos DB Virtual network is not configured | Changes— The Policy RQL is updated to consider cosmos DB is configured with private access to reduce false positives. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Low Impact– Low. Open alerts where private access is configured will be resolved. |
| Azure Microsoft Defender for Cloud email notification for subscription owner is not set | Changes— The Policy RQL is updated to check for notifications configured for Owner role as per the latest Azure updates. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Informational Impact– Low. New alerts will be generated in case the Owner is not configured to receive email notifications. Open alerts for the security contact where the email is configured will be resolved. |
| Azure Function app configured with public network access | Changes— The Policy RQL is updated to consider private endpoints as well to reduce false positives. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Medium Impact– Low. Open alerts where private link identifiers exist will be resolved. |
| Azure Storage account encryption key is not rotated regularly | Changes— The Policy RQL is updated to alert based on the specific key associated with the storage account reducing false positives. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Low Impact– Low. Open alerts where multiple keys exist and a correct key is associated with the Storage Account for encryption will be resolved. |
| GCP Vertex AI Workbench Instance has Secure Boot disabled | Changes— The Policy RQL is updated due to changes in the GCP API. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Low Impact– Low. New alerts are generated based on the updated RQL. |
| GCP Vertex AI Workbench Instance has Integrity monitoring disabled | Changes— The Policy RQL is updated due to changes in the GCP API. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Low Impact– Low. New alerts are generated based on the updated RQL. |
| GCP Vertex AI Workbench Instance has vTPM disabled | Changes— The Policy RQL is updated due to changes in the GCP API. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Low Impact– Low. New alerts are generated based on the updated RQL. |
| GCP SQL database instance deletion protection is disabled | Changes— The Policy RQL is updated with the right attribute to raise alerts on the vulnerable resources only. Current RQL– Updated RQL– Policy Type– Config Policy Severity– Informational Impact– Low. Open alerts where the deletion protection setting is enabled will be resolved. |
New Policy mappings are added to the AWS Foundational Security Best Practices compliance standard.
Impact: As new mappings are introduced, compliance scoring may vary.
| | **\[Update] CIS v3.0.0 (Azure) Level 1, CIS v2.1.0 (Azure) Level 1 & CIS v2.0.0 (Azure) Level 1** |New Policy mappings are added to the CIS v3.0.0 (Azure) Level 1, CIS v2.1.0 (Azure) Level 1 & CIS v2.0.0 (Azure) Level 1 compliance standards.
Impact: As new mappings are introduced, compliance scoring may vary.
| | **\[Update] CIS v4.0.0 (AWS) Level 2 & CIS v3.0.0 (AWS) Level 2** |New Policy mappings are added to the CIS v4.0.0 (AWS) Level 2 & CIS v3.0.0 (AWS) Level 2 compliance standards.
Impact: As new mappings are introduced, compliance scoring may vary.
| --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/release-notes/prisma-cloud-release-information/features-introduced-in-2025/features-introduced-in-april-2025.md?ask=