Custom compliance checks
Table of Contents
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Custom compliance checks
Custom image checks give you a way to write and run your own compliance checks to assess, measure, and enforce security baselines in your environment.
Prisma Cloud lets you implement your custom image checks with simple scripts.
Custom compliance checks are supported for:
- Linux and Windows hosts (Host configured for docker, containerd, or CRI-O)
- Docker images on Linux hosts
- OCI images
Custom compliance checks are not supported for:
- Linux and Windows containers
- Docker images on Windows hosts
- Tanzu Application Service (TAS) defender
- GKE Autopilot
A custom image check consists of a single script.
The script’s exit code determines the result of the check, where "0" stands for pass and "1" stands for fail.
Scripts are executed in the default shell.
The most common default shell for Linux is bash, but that’s not always the case.
For Windows container images, the default shell is cmd.exe.
If you want to use a specific shell, or if your default shell is in a non-standard location, use the shebang interpreter directive at the top of your compliance check to specify the path to the executable.
For example, #!/bin/bash specifies that the Linux Bourne-again (bash) shell should parse and interpret the compliance check.
For containers, Defender runs the compliance checks inside a restricted sandboxed container instantiated from the image being scanned, thus avoiding the unnecessary risk associated with running arbitrary code.
For hosts, Defender runs the compliance checks on the host itself with unrestricted privileges to allow execution of any script.
To limit exposure, this feature is disabled by default.
Every compliance check in the system has a unique ID.
Custom checks are automatically assigned an ID, starting with the number 9000.
As new custom checks are added, they are automatically assigned the next available ID (9001, 9002, and so on).
Prisma Cloud drops the cached compliance and vulnerability scan results for registries, and rescans registry images, whenever:
- A new rule referencing a custom compliance check is added, or
- An existing compliance check referenced by some existing rule is updated, or
- An existing rule is updated with a new custom compliance check.
In a scaled-out environment with large registries, repeated changes to custom compliance checks could adversely impact on the performance of Prisma Cloud.
Create a new Custom Check
Create a new compliance rule that includes your custom check, and specify the action to take when the check fails (ignore, alert, block).
Prerequisite
- Enable custom compliance checks for hosts (By default, this is disabled).
- Go toManage > Defenders > Advanced Settings.
- SetCustom Compliance Checks for hoststo enabled.
- Deploy Defenders to your environment. Or if already deployed, redeploy your Defenders.
You must redeploy the Defenders everytime you enable
Custom Compliance Checks for hosts
.
If you enable the feature, and then later disable it, the disabled state is effective immediately.
You don’t have to redeploy Defenders when you switch to the disabled state.- Go toDefend > Compliance > Custom.
- SelectAdd check.
- Enter aNameand aDescription.
- Specify theSeverityof the compliance issue.
- Enter a script.
- SelectSave.
- Update the compliance policy to run your check.
- Go toDefend > Compliance > Containers and Imagesfor containers orDefend > Compliance > Hostsfor hosts.
- SelectAdd rule.
- Enter aRule name,Notes, and select theScopefor the resources.
- UnderCompliance actions, narrow the compliance checks displayed.For containers, on theAll typesdrop-down list, selectCustom > Image.For hosts, on theAll typesdrop-down list, selectCustom > Custom.You should see a list of custom checks you’ve implemented, starting with ID 9000.
- Select an action for your custom check (Ignore,Alert, orBlock).
- SelectSave.
- Validate your setup by reviewing the compliance reports underMonitor > Compliance.
Example scripts
The following example scripts show how to run some basic checks, such as checking file permissions.
Use them as starting point for your scripts.
Any special utilities or programs required by your script must be installed in the image being evaluated.
File permissions (Linux)
The following script checks the permissions for the /bin/busybox file.
Assuming busybox is installed in your image, this check should pass.
if [ $(stat -c %a /bin/busybox) -eq 755 ]; then echo 'test permission failure' && exit 1; fi
File exists (Linux)
The following script checks if /tmp/foo.txt exists in the container file system.
If it doesn’t exist, the check fails.
if [ ! -f /tmp/foo.txt ]; then echo "File not found!" exit 1 fi
User exists (Linux)
The following script checks if the user John exists.
If the user exists, the check passes.
Otherwise, it fails.
if grep -F "John" /etc/passwd then echo yes else echo "user not found!" exit 1 fi
File exists (Windows)
The following script checks if C:\Users exists.
If it does, the check passes.
IF EXIST C:\Users Echo test permission failure && exit 1
File does not exist (Windows)
This check is the inverse of the previous check.
The script checks if C:\Users doesn’t exist.
If it doesn’t exist, the check passes.
IF NOT EXIST C:\Users Echo test permission failure && exit 1