DISA STIG compliance checks
Prisma Cloud supports the Docker Enterprise 2.x Linux/Unix STIG - Ver 2, Rel 1 and the Kubernetes STIG - Ver 1, Rel 2 compliance checks. Defense Information Systems Agency Security Technical Implementation Guides (DISA STIGs) contain technical guidance to lock down systems that might otherwise be vulnerable to attack. These STIGs help ensure your environments are properly secured, based on Department of Defense guidance. Prisma Cloud will continue to incorportate DISA STIG guidance as existing STIGs are updated and new STIGs are published.
For an overview of the STIG, see here.
To download the STIGs, see here.
Prisma Cloud Compute has a compliance template "DISA STIG" for images, containers and hosts. This compliance template maps individual STIG rules to existing compliance checks within Compute. In some cases, we’ve implemented checks specficially to support the STIGs. When configuring your compliance policy, simply select the DISA STIG template to enable ("Alert") all relevant checks.
CAT I is a category code for any vulnerability, which when exploited, will directly and immediately result in loss of Confidentiality, Availability, or Integrity. These risks are the most severe.
The following table lists the CAT I checks implemented in Prisma Cloud, and how they map to existing Prisma Cloud checks. All CAT I checks, except DKER-EE-001070, map to CIS Docker Benchmark checks. A separate check has been implemented for DKER-EE-001070 to support the Docker Enterprise STIG.
Prisma Cloud ID
FIPS mode must be enabled on all Docker Engine - Enterprise nodes.
Docker Enterprise hosts network namespace must not be shared.
All Docker Enterprise containers root filesystem must be mounted as read only.
Docker Enterprise host devices must not be directly exposed to containers.
The Docker Enterprise default seccomp profile must not be disabled.
Docker Enterprise exec commands must not be used with privileged option.
All Docker Enterprise containers must be restricted from acquiring additional privileges.
The Docker Enterprise hosts user namespace must not be shared.
The Docker Enterprise socket must not be mounted inside any containers.
Docker Enterprise privileged ports must not be mapped within containers.
Docker Enterprise docker.service file ownership must be set to root:root.
Docker Enterprise docker.socket file ownership must be set to root:root.
Docker Enterprise /etc/docker directory ownership must be set to root:root.
Docker Enterprise registry certificate file ownership must be set to root:root.
Docker TLS certificate authority (CA) certificate file ownership must be set to root:root
Docker server certificate file ownership must be set to root:root
Docker server certificate key file permissions must be set to 400
Docker Enterprise socket file ownership must be set to root:docker.
Docker Enterprise socket file permissions must be set to 660 or more restrictive.
Docker Enterprise daemon.json file ownership must be set to root:root.
Docker Enterprise daemon.json file permissions must be set to 644 or more restrictive.
Docker Enterprise /etc/default/docker file ownership must be set to root:root.
Docker Enterprise /etc/default/docker file permissions must be set to 644 or more restrictive.
The Kubernetes Controller Manager must create unique service accounts for each work payload.
The Kubernetes API server must have the insecure port flag disabled.
The Kubernetes Kubelet must have the read-only port flag disabled.
The Kubernetes API server must have the insecure bind address not set.
The Kubernetes API server must have anonymous authentication disabled.
The Kubernetes Kubelet must have anonymous authentication disabled.
The Kubernetes kubelet must enable explicit authorization.
Secrets in Kubernetes must not be stored as environment variables.