20.12 Release Notes
The following table outlines the release particulars:
21 December 2020
- Simplifies Defender deployment in AWS ECS clusters. Defender task definitions are now configured and generated in the Console UI. Everything Defender needs to connect to Console is packaged in the task definition. Defender auto-upgrade is also now supported.
- Adds separate port and proxy configuration settings for each Defender deployment. Makes it easier to deploy Defenders across environments.
- Increases the number of Defenders that can simultaneously connect to Console to 10K Defenders.
- Adds scalable methods for distributing Intelligence Stream data to air-gapped Consoles in environments with many deployed Consoles. Consoles can now be configured to retrieve the latest threat data from HTTPS endpoints or another centrally-maintained Console.
- Adds the ability to filter out vulnerabilities introduced by base or middleware images from scan results.
- Refactors how policy rules are scoped. Rule scope (the resources a rule targets) is now defined by referencing the relevant collections. Previously, scope was specified inline in each rule. Collections make it easier to visualize and reuse scope settings across the product. As part of this change, all your policy rules are automatically migrated to use collections on upgrade.
- Brings back CNNF with enforcement. Policy is now entirely defined by rules; learning is no longer supported. CNNF with enforcement is supported in Compute Edition only. A solution for Enterprise Edition (SaaS) customers will be unveiled shortly. CNNF monitoring is supported in both editions.
- Adds support for Prisma Cloud as a pluggable scanner for the Harbor registry.
- Adds compliance checks for CRI-O images and containers. Previously, there were only checks for Docker images and containers.
- Adds support for custom compliance checks for CRI-O images and containers. To use this feature, you must manually redeploy your Defenders. This feature will not work with auto-upgraded Defenders.
- Adds support for the layers view in image scan reports (Monitor > Vulnerabilities > Images > SCAN-REPORT > Layers) in CRI-O environments. Also, adds support for listing the labels of CRI-O containers in the image scan reports. Previously, these capabilities were only supported on hosts with Docker Engine.
- Integrates the Palo Alto Networks AutoFocus threat feed into the Prisma Cloud Compute Intelligence Stream.
- Bolsters support for the cluster resource type as a first class citizen in the product. Container Radar now shows interesting metadata for each cluster. Rules can now be scoped to clusters for things like trusted images and container runtime rules. More audits now include cluster information. More views now support filtering by cluster. Rules scoped by cluster with the block effect now work properly.
- Extends the ServiceNow integration to support sending compliance alerts to Security Incident Response with resources information (image, host, collection, project, etc).
- Increases the number of CI scan reports that Console can store from 1000 to 5000 or 500 MB (whichever limit is reached first).
- Aligns the grace period in vulnerability rules with the CVE’s fix date, rather than the publish date.
- Centralizes all AWS credential management and options into the credentials store. Things like IAM role and STS are no longer individually specified in each integration’s setting dialog.
- Adds support for Hashicorp Consul. Radar now shows connections between containers with Envoy sidecars.
- Adds support for admission control (Defend > Access > Admission) on OpenShift 4.
- Enhances support for Distroless images, with full package lists and better vulnerability analysis.
- [Enterprise Edition (SaaS)]Updates twistcli to use the latest Prisma Cloud IaC scan REST API 2, with support for Terraform v0.13, larger file sizes, and automatic detection of Terraform module structures and variable files.
- [Enterprise Edition (SaaS)]Updates twistcli so that it works with IP whitelisting. IP whitelisting is a Prisma Cloud Enterprise Edition feature that lets you restrict who can log into the system by IP address.
New features in WAAS
- Adds a sophisticated analytics view so you can better investigate and understand attacks. WAAS analytics allows for the review of incidents by analyzing events across various dimensions, inspecting individual requests, and applying filtering to focus on common characteristics or trends.
- Adds application layer DoS protection. Lets you limit client request rates based on IPs or sessions to protect against high-rate and "low and slow" application layer DoS attacks.
- Adds the ability to specify exceptions in HTTP requests (e.g., query, cookie, UserAgentHeader, header, body, XMLPath, JSONPath) for WAAS protections (e.g., SQL injection, code injection, etc). Fine-tunes WAAS policies to ensure its protection is tailored to the application needs.
In 20.09, support for enforcement in CNNF was temporarily dropped. In 20.12, enforcement returns, with one change: automatic learning of connections is no longer supported. Microsegmentation policy is now entirely defined by the rules you create.
In the 20.09 release notes, we advised that if you rely on enforcement in CNNF, then you should skip upgrading to 20.09 and wait for 20.12. When you upgrade to 20.12, we’ll migrate your original CNNF settings from 20.04 forward to 20.12. You must still follow the normal step-wise upgrade process. From 20.04, you’ll first need to upgrade to 20.09, and from 20.09, you’ll need to upgrade to 20.12. When upgrading from 20.04 to 20.09, we retain all relevant CNNF settings in the database. Then when you upgrade from 20.09 to 20.12, migration code recreates the 20.04 settings, rules, and network objects in 20.12.
The migration code does the following:
- Restores all manually defined rules in their original order.
- Restores image and DNS network objects.
- If you upgraded to 20.09 and deleted any subnet network objects, the migration code restores them so that the full 20.04 policy can be restored without holes.
- Reconfigures rules with the prevent effect to alert.
- Restores the state of CNNF for containers (enabled or disabled) from 20.04 (not 20.09)
- Restores the state of CNNF for hosts (enabled or disabled) from 20.09.
If you relied on learning for some of your policy (where learned connections allow-listed connections between entities), you’ll need to spend some time shoring up your policy, since learning is no longer supported in CNNF.
Rule scope with collections
Starting in 20.12, rule scope (the resources a rule targets) is defined by referencing the one or more collections. Previously, scope was specified inline in each rule with a resource filter. As part of this change, all your rules in 20.09 will be automatically migrated to the new structure.
Rules in 20.09 are migrated to 20.12 as follows:
- A collection is created for each rule in your 20.09 Console.
- Rules created by the migration code are named "Resources collection X".
- Only unique collections are created.
- Rules with the default resource filters (all wildcards) are assigned to the "All" collection.
- The modified time for collections created by the migration code is set to the upgrade time.
- The owner for collections created by the migration code is set to "system".
20.12 updates our integration to use account ID for the assignee when sending Jira alerts. If you’re using Jira 8.2 or older, and you upgrade to 20.12, your alerts will break. Our integration with Jira supports the latest API only. The latest API requires an account ID for the assignee, not username.
Custom compliance checks for CRI-O images and containers
Custom compliance checks for CRI-O images and containers is a new feature in 20.12. In order to use this feature, you must manually redeploy your Defenders. If your Defenders are auto-upgraded, the feature will not work properly and the Defender logs will contain errors.
Some strings have been updated to align with how our partners have rebranded their offerings. Specifically, Pivotal PCF has been renamed to VMware Tanzu Application Service (TAS) and Demisto has been renamed to Cortex XSOAR. There are some impacts on the API. For more information, see the 20.12 API porting guide.
Be aware of the following breaking changes when upgrading to 20.12:
- CI scan reports will be changed. This is required to support the new expanded limit on CI scan reports, from 1000 reports to 5000 reports or 500 MB (whichever limit is reached first). On upgrade:
- All existing CI scan results will be deleted.
- All CI scan results will be dynamically updated each time a new scan is performed (similar toMonitor > Vulnerabilities).
- [Enterprise Edition (SaaS)]When your SaaS Console is upgraded to 20.12, Defender auto-upgrade will be permanently enabled. You will not be able to disable Defender auto-upgrade. The switch to the control the setting will be removed from theAdvanced settingsview inManage > Defenders > Manage. The request param for disabling Defender auto-upgrade will be similarly disable in the API.
Breaking changes in the API
For complete information about breaking changes and deprecated endpoints in the API, see the 20.12 API porting guide.
Deprecated this release
The following features have been deprecated in 20.12:
- SCAP support.
- Support for installing Prisma Cloud on:
- Kubernetes on DC/OS (Docker-in-Docker nested virtualization).
- Support for detecting raw sockets in host network runtime policies. This control triggered too many false positives.
- If you have the same custom compliance rule in use in a host policy (effect: alert) and a container policy (effect: block), the rules will enforce your policy (as expected), but the audit message for a blocked container will incorrectly refer to the host policy and host rule name.
- Compliance checks for CRI-O images and containers that are graded Critical and High aren’t enabled in the default rule. Create new rule(s) to activate these checks. This issue only occurs if you upgrade from a previous version of Prisma Cloud. For fresh installs, these checks are properly enabled in the default rule.
- Prisma Cloud’s support for Istio consists of two parts: runtime connection tracking and compliance checks. For OpenShift environments, only connection tracking is supported. Compliance checks aren’t supported.
Nothing to announce at this time.
Recommended For You
Recommended videos not found.