1. Overview

Prisma Cloud Labs compliance checks are designed by our research team and fill gaps not offered by other benchmarks. Like all compliance checks, Prisma Cloud’s supplementary checks monitor and enforce a baseline configuration across your environment.

Prisma Cloud Labs compliance checks can be enabled or disabled in custom rules. New rules can be created under Defend > Compliance > Policy.

2. Checks

597 — Secrets in clear text environment variables (container and serverless function check)

Checks if a running container (instantiated from an image) or serverless function contains sensitive information in its environment variables. These env vars can be easily exposed with docker inspect, and thus compromise privacy.

598 — Container app is running with weak settings

Weak settings incidents indicate that a well-known service is running with a non-optimal configuration. This covers settings for common applications, specifically: Mongo, Postgres, Wordpress, Redis, Kibana, Elasitc Search, RabbitMQ, Tomcat, Haproxy, KubeProxy, Httpd, Nginx, MySql, and registries. These check for things such as the use of default passwords, requiring SSL, etc. The output for a failed compliance check will contain a "Cause" field that gives specifics on the exact settings detected that caused a failure.

599 — Container is running as root (container check)

Checks if the user value in the container configuration is root. If the user value is 0, root, or "" (empty string), the container is running as a root user, and the policy’s configured effect (ignore, alert, or block) is actuated.

420 — Image is not updated to latest (image check)

For running containers, Prisma Cloud checks that the creation time of each layer in image:tag is the same as its corresponding image:tag in the registry.

For any image pulled from a password protected registry/repo, the registry must be configured in Prisma Cloud. To add a registry, go to Defend > Vulnerabilities > Registry.

If an image does not belong to any user configured registry, and the image origin is Docker Hub, the image is compared against image:tag in Docker Hub.

Each layer in the image is assessed separately. If a layer cannot be found in the registry, it is skipped, and the next layer is assessed.

422 — Image contains malware (image check)

Checks if any binary in the image matches the md5 checksum for known malicous software.

423 — Image is not trusted (image check)

Checks if unauthorized (untrusted) images are pulled or loaded into your environment.

Prisma Cloud provides a mechanism to specify specific registries, repositories, and images that are considered trusted. Enable this check to prevent unauthorized containers from running in your critical environment. For more information, see Trusted images.

424 — Sensitive information provided in environment variables (image and serverless function check)

Checks if images or serverless functions contain sensitive information in their environment variables. Container images define environment variables with the Dockerfile ENV instruction. These environment variables can be easily exposed with docker inspect.

425 — Private keys stored in image (image and serverless function check)

Searches for private keys stored in an image or serverless function. If found, the policy effect (ignore, alert, block) is applied on deployment.

426 — Image contains binaries used for crypto mining (image check)

Detects when there are crypto miners in an image. Attackers have been quietly poisoning registries and injecting crypto mining tools into otherwise legitimate images. When you run these images, they perform their intended function, but also mine Bitcoin for the attacker. This check is based on research from Prisma Cloud Labs. For more information, see Real World Security: Software Supply Chain.

428 — Package binaries should not be altered

Checks the integrity of package binaries in an image. During an image scan, every binary’s checksum is compared with its package info. If there’s a mismatch, a compliance issue is raised.

Besides scan-time, this compliance issue an also be raised at run-time if a modified binary is spawned.

3. Prisma Cloud Labs Istio compliance checks

The Istio family of compliance checks lets you enforce a secure Istio configuration and address risks such as misconfigured TLS settings and universally scoped service roles. The goals of the compliance rules are to:

  • Ensure mutual TLS is configured correctly (enabled and over HTTPs).

  • Ensure RBAC policy is configured with service level access control (service x can only talk with service y).

  • Ensure RBAC policy is not too permissive.

3.1. Checks

427 — Configure TLS per service using Destination Rule traffic policy
428 — Enable mesh-wide mutual TLS authentication using Mesh Policy

Ensures mutual TLS is globally enabled.

429 — Enable Istio authorization by creating RbacConfig named default

430 — Remove any additional RbacConfig and ensure there is only one RbacConfig named default

431 — Set RbacConfig mode to ON, ON_WITH_INCLUSION or ON_WITH_EXCLUSION

Extracts RbacConfig resource and make sure it is not set to OFF.

432 — Avoid using service role rules that grant access to all services

Ensures RBAC rules not too permissive. Verify there are no wildcards in the service roles.

433 — Avoid binding service roles to all service accounts

Ensures service roles are at the service level and not the namespace level, which grants access to all services in the namespace.