Features Introduced in June 2025

Learn what’s new on Prisma® Cloud in June 2025.

The June (25.6.1) release does not include any API ingestions or new policies.

• Policy Updates
• New Compliance Benchmarks and Updates
• Deprecation Notices

Policy Updates

Policy Updates	Description
Policy Updates—RQL
AWS ElastiCache Redis cluster with Redis AUTH feature disabled	Changes— The policy is updated to exclude resources with RBAC Auth configured. Current RQL– config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = 'authTokenEnabled is false or transitEncryptionEnabled is false or authTokenEnabled does not exist or transitEncryptionEnabled does not exist' Updated RQL– config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-elasticache-describe-replication-groups' AND json.rule = 'engine equal ignore case Redis and (authTokenEnabled is false or transitEncryptionEnabled is false or authTokenEnabled does not exist or transitEncryptionEnabled does not exist) and userGroupIds is empty' Policy Type– Config Policy Severity– Low Impact– Low. Open alerts where RBAC Auth is configured on AWS Elasticache Redis will be resolved.
AWS DynamoDB table Auto Scaling not enabled	Changes— The policy remediation step is updated according to AWS console change. Policy Type– Config Policy Severity– Informational Impact– No impact on alerts as only the metadata has been changed.
Azure Storage Account Container with activity log has BYOK encryption disabled	Changes— The policy is updated to enhance the RQL query. Current RQL– config from cloud.resource where api.name = 'azure-storage-account-list' as X; config from cloud.resource where api.name = 'azure-monitor-log-profiles-list' as Y; filter '($.X.properties.encryption.keySource does not equal "Microsoft.Keyvault" and $.X.properties.encryption.keyvaultproperties.keyname is not empty and $.X.properties.encryption.keyvaultproperties.keyversion is not empty and $.X.properties.encryption.keyvaultproperties.keyvaulturi is not empty and $.Y.properties.storageAccountId contains $.X.name)'; show X; Updated RQL– config from cloud.resource where api.name = 'azure-storage-account-list' as X; config from cloud.resource where api.name = 'azure-monitor-log-profiles-list' as Y; filter '($.X.properties.encryption.keySource does not equal "Microsoft.Keyvault" and $.Y.properties.storageAccountId contains $.X.name)'; show X; Policy Type– Config Policy Severity– Informational Impact– No impact on alerts as the functionality of the RQL remains same. The RQL has been updated to remove the irrelevant keys.
Azure Storage Account default network access is set to 'Allow'	Changes— The policy RQL needs to consider the existence of "publicNetworkAccess" since the attribute can be added via CLI. Current RQL– config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = properties.publicNetworkAccess equal ignore case "Enabled" AND networkRuleSet.defaultAction equal ignore case "Allow" Updated RQL– config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-storage-account-list' AND json.rule = (properties.publicNetworkAccess equal ignore case "Enabled" AND networkRuleSet.defaultAction equal ignore case "Allow") or (properties.publicNetworkAccess does not exist AND networkRuleSet.defaultAction equal ignore case "Allow") Policy Type– Config Policy Severity– Informational Impact– Medium. New alerts will be triggered if the publicNetworkAccess attribute does not exist and networkRuleSet is set to allow.
GCP PostgreSQL instance database flag log_min_messages is not set	Changes— The policy has been revised to align specifically with the Compliance requirement: ensure that the log_min_messages flag for Cloud SQL PostgreSQL instances is configured to a minimum level of WARNING, in accordance with the CIS Google Cloud Platform Benchmark. Current Policy Name— GCP PostgreSQL instance database flag log_min_messages is not set Updated Policy Name— GCP PostgreSQL instance database flag log_min_messages is not set to Warning or higher Current Description— This policy identifies PostgreSQL database instances in which database flag log_min_messages is not set to warning. The log_min_messages flag controls which message levels are written to the server log, valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each level includes all the levels that follow it. log_min_messages flag value changes should only be made in accordance with the organization’s logging policy. Auditing helps in troubleshooting operational problems and also permits forensic analysis. Updated Description— This policy detects PostgreSQL database instances where the log_min_messages configuration flag is not set to the WARNING level or higher. The log_min_messages parameter governs the minimum level of message severity that is logged by the PostgreSQL server. Acceptable values, in increasing order of severity, include: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels mentioned. Setting this flag to a lower severity level, such as the DEBUG levels or INFO, increases log verbosity, while higher levels reduce log detail. As a security best practice, setting log_min_messages to WARNING or higher helps mitigate risks associated with insufficient or excessive logging. Current RQL– config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains POSTGRES and settings.databaseFlags[?(@.name=='log_min_messages')] does not exist" Updated RQL– config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = state equal ignore case "RUNNABLE" and databaseVersion contains POSTGRES and settings.databaseFlags[?(@.name=='log_min_messages')].value is not member of ( "warning", "error", "log", "fatal", "panic") Policy Type– Config Policy Severity– Informational Impact– Low. New alerts will be triggered in case the log_min_messages flag is not set to either "warning", "error", "log", "fatal", or "panic".
GCP PostgreSQL instance database flag log_min_error_statement is not set	Current Policy Name– GCP PostgreSQL instance database flag log_min_error_statement is not set Updated Policy Name– GCP PostgreSQL instance database flag log_min_error_statement is not set to Error or higher Current Description– This policy identifies PostgreSQL database instances in which database flag log_min_error_statement is not set. The log_min_error_statement flag defines the minimum message severity level that are considered as an error statement. Messages for error statements are logged with the SQL statement. Valid values include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels. log_min_error_statement flag value changes should only be made in accordance with the organization’s logging policy. Proper auditing can help in troubleshooting operational problems and also permits forensic analysis. Updated Description– This policy detects PostgreSQL database instances where the log_min_error_statement flag is not configured at the error level or higher. This log_min_error_statement parameter sets the minimum severity level for logging SQL statements that produce errors by the PostgreSQL server. Acceptable values, in increasing order of severity: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels mentioned. Without this flag set, critical error-generating SQL statements may not be logged, leading to insufficient visibility into potential security incidents, failed attacks, or misconfigurations hindering threat detection and post-incident analysis. As a security best practice, setting log_min_error_statement to error or higher helps in troubleshooting operational problems and also permits forensic analysis. Current RQL– config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = "databaseVersion contains POSTGRES and settings.databaseFlags[?(@.name=='log_min_error_statement')] does not exist" Updated RQL– config from cloud.resource where cloud.type = 'gcp' AND api.name = 'gcloud-sql-instances-list' AND json.rule = state equals ignore case 'RUNNABLE' and databaseVersion contains POSTGRES and settings.databaseFlags[?(@.name=='log_min_error_statement')].value is not member of ( "error" , "log", "fatal", "panic") Policy Type– Config Policy Severity– Informational Impact– Low. New alerts will be triggered in case the log_min_error_statement flag is not set to "error".
GCP IAM principals with service account privileges	Current Description– This policy identifies AWS IAM Principals with service account privileges. Assigning a principal the Service account role in Google Cloud allows them to impersonate service accounts and use their permissions. This means the principal can perform actions on behalf of the service account, essentially inheriting all permissions granted to that service account. To maintain the security of your information and resources, it is crucial to assign this role only to authorized and trusted IAM Principals. Updated Description– This policy identifies GCP IAM Principals with service account privileges. Assigning a principal the Service account role in Google Cloud allows them to impersonate service accounts and use their permissions. This means the principal can perform actions on behalf of the service account, essentially inheriting all permissions granted to that service account. To maintain the security of your information and resources, it is crucial to assign this role only to authorized and trusted IAM Principals. Policy Type– Config Policy Severity– Low Impact– Low

New Compliance Benchmarks and Updates

Compliance Benchmark

Description

Australian Energy Sector Cyber Security Framework (AESCSF) V2

Prisma Cloud now supports the Australian Energy Sector Cyber Security Framework (AESCSF) V2. This compliance standard is a specialized cybersecurity standard designed to guide energy sector organizations in Australia. AESCSF V2 provides a structured approach to managing cyber risks by aligning security controls with industry-specific threats and regulatory requirements. It emphasizes resilience, risk management, and continuous improvement to protect critical energy infrastructure from evolving cyber threats. You can access this built-in compliance standard and related policies on the Compliance > Standards page. Additionally, you can generate reports to instantly view or download them, or set up scheduled reports to continuously monitor compliance.

Deprecation Notices

Change	Description
aws-emr-instance API	The aws-emr-instance API has been deprecated and is effectively no longer included in the RQL autosuggest dropdown on the Investigate page.