Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
For Kubernetes deployment: Query the ports used by the twistlock-console service: $ kubectl describe svc twistlock-console -n twistlock If the TargetPort management-port-http exists and has a port assignment, this is a finding. Port: management-port-http 8081/TCP TargetPort: 8081/TCP For Docker deployment: Determine the name of the Console container: docker ps|grep console For example, the Console container is: ad8b41a2fec9 twistlock/private:console_22_01_840 Inspect the container's PortBindings: docker inspect ad8b41a2fec9|grep PortBindings -A 20 If port 8081 is listed, this is a finding.
For Kubernetes deployment: Edit the deployment.apps/twistlock-console. Find the - name: MANAGEMENT_PORT_HTTP setting Remove the value assignment (e.g., 8081): - name: MANAGEMENT_PORT_HTTP value: "8081" Save and exit the editing session. The Console will restart automatically. For Docker deployment: Modify the twistlock.cfg located in the extracted release tar directory. Remove the value assignment for the MANAGEMENT_PORT_HTTP= variable. Redeploy the Console using the twistlock.sh script located in the extracted release tar directory. $ sudo ./twisltock.sh -sy onebox
Confirm the Prisma Cloud Console has been configured from SAML-based authentication. Navigate to Prisma Cloud Compute Console's Manage >> Authentication >> Identity Providers tab. Verify SAML settings are "Enabled" and an identity provider has been configured. If SAML settings are not enabled and an identity provider has not been configured, this is a finding.
Configure Prisma Cloud Console for SAML-based authentication in which the SAML IdP enforces multifactor authentication (e.g., x509/smartcard authentication). Navigate to Prisma Cloud Compute Console's Manage >> Authentication >> Identity Providers: - Click "Add provider". - For Protocol, select "SAML". - For Identity provider, select provider. - Configure the settings and click "Save". SAML settings = Enabled Configure an SAML identity provider that enforces privileged account multifactor authentication for the Prisma Cloud Compute service provider.
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Users tab. Inspect the users' role assignments: - Review role assigned to users. If role and/or the Collection assignment is incorrect, this is a finding. - If a user is not assigned a role, this is a finding. - Review users assigned the administrator role. If a user has the administrator role and does not require access, this is a finding. Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Groups tab. (Only the Administrator, Operator Prisma Cloud Compute roles have the ability to create/modify policy that could affect runtime behaviors.) Inspect the groups' role assignments: - If any users or groups are assigned the Auditor or higher role and do not require access to audit information, this is a finding. - If a group is not assigned a role, this is a finding. - If role and/or Collection assignment is incorrect, this is a finding. - Review groups assigned the Administrator or Operator role. If a group has the Administrator or Operator role and does not require access to Prisma Cloud Compute's Credential Store, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Users tab. - Set the users' role assignments to the ones who have the authority to review the audit data. - Assign roles to all users and groups. - Assign administrator and operator roles only to the users requiring the rights to modify the Prisma Cloud Compute's Credential Store. - Remove the Administrator or Operator role for users who do not require access. Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Groups tab. - Set the groups' role assignments to the ones who have the authority to review audit data. - Assign roles to all users and groups. - Set the groups' Administrator and Operator role assignments to only to the groups requiring the rights to modify the Prisma Cloud Compute's Credential Store. Adjust user, group, and Collection assignments to align with organizational policies.
Navigate to Prisma Cloud Compute Console's >> Manage >> Collections and Tags >> Collections tab. Review the Collections according to organizational policy. If no organizational-specific Collections are defined, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Collections and Tags >> Collections tab. Create a collection: - Click "Add Collection". - Enter a name and description and then specify a filter to target specific resources. - Click "Save".
Navigate to Prisma Cloud Compute Console's >> Radars >> Settings. If Container network monitoring is disabled, this is a finding. If Host network monitoring is disabled, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Radars >> Settings. Set Container network monitoring to "enabled". Set Host network monitoring to "enabled".
Navigate to Prisma Cloud Compute Console's >> Manage >> Defenders >> Manage tab. Verify Prisma Cloud Compute Defenders have been deployed to all container runtime nodes to be monitored. Review the list of deployed Defenders. If a Defender is missing, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Defenders >> Manage tab. Deploy Defender to containerization node: - Select the method of Defender deployment. - Configure the Defender policy.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> Forensics tab. If "Forensics data collection" is disabled, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> Forensics tab. Set "Forensics data collection" to "enabled".
Verify runtime policies are enabled. Navigate to Prisma Cloud Compute Console's Defend >> Runtime. Select "Container policy". - If a rule does not exist, this is a finding. - If "Enable automatic runtime learning" is set to "off", this is a finding. - Click the three dots in the "Actions" column for the rule. - If the policy is disabled, this is a finding. - Click the Container runtime policy. - If the policy is not scoped to "All", this is a finding. Select the "App-Embedded policy" tab. - If a rule does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert on suspicious runtime behavior". - If the policy is disabled, this is a finding. - Click the "Default - alert on suspicious runtime behavior" policy row. - If the "Default - alert on suspicious runtime behavior" policy is not scoped to "All", this is a finding. Select the "Host policy" tab. - If a rule does not exist, this is a finding. - Click the three dots in the "Actions" column for the rule. - If the policy is disabled, this is a finding. - Click the Host runtime policy. - If the policy is not scoped to "All", this is a finding.
Enable runtime policies. Navigate to Prisma Cloud Compute Console's Defend >> Runtime. Click the tab to be edited. To add policy (for Host or App-Embedded policy): - Click "Add rule". - Enter rule name. Scope = All - Accept the defaults and click "Save". To enable policy: - Click the rule's three-dot menu. - Set to "Enable". To change scope, click the rule row: - Change the policy scope to "All". - Click "Save". To add container policy: - Select the "Container policy" tab. - Set "Enable automatic runtime learning" to "On". To create a new runtime rule: - Click "Add rule". - Configure the following settings: Enter rule name Scope = All Select the "Anti-malware" tab. Set the following: - Prisma Cloud advanced threat protection = on - Kubernetes attacks = on - Suspicious queries to cloud provider APIs = on Select the "Process" tab. Set the following: Process monitoring = enabled Select the "Network" tab. Set the following: IP connectivity = enabled Select the "File system" tab. Set the following: - File system monitoring = enabled - Accept the defaults and click "Save". Select the "App-Embedded policy" tab. - Click the rule's three-dot menu. Set to "Enable". - Click the rule name row. - Change the scope to "All". - Click "Save". Create a new runtime rule: - Click "add rule." - Enter rule name. - Scope = All - Accept the defaults and click "Save". Select the "Host policy" tab. - Click the rule's three-dot menu. Set to "Enable". - Click the rule name row. - Change the scope to "All". - Click "Save". - Click "Add rule". - Enter rule name. - Scope = All - Select the "Activities" tab. - Set the following: Host activity monitoring ="Enabled" Docker commands = "On" New sessions spawned by sshd = "On" Commands run with sudo or su = "On" Log activity from background apps = "On" Track SSH events = "On" - Accept the defaults and click "Save".
Navigate to Prisma Cloud Compute Console's >> Manage >> Alerts >> Logging tab. If the Syslog setting is "disabled", this is a finding. Select the "Manage" tab. If no Alert Providers are configured, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Alerts >> Logging tab. Set Syslog to "enabled". Select the "Manage" tab. Click "Add profile". Complete the form based on the organization. At a minimum, the following Alert triggers must be selected: - Host vulnerabilities. - Image vulnerabilities. Click "Save".
Navigate to Prisma Cloud Compute Console's >> Defend >> Compliance >> Hosts tab >> Running hosts tab. If a "Default - alert on critical and high" rule does not exist, this is a finding. Check all the rules to verify the following Actions are not set to "Ignore". (Click "Rule name".) <Filter on Rule ID> ID = 8112 - Verify the --anonymous-auth argument is set to false (kube-apiserver) - master node. ID = 8212 - Verify the --anonymous-auth argument is set to false (kubelet) - worker node. ID = 8311 - Verify the --anonymous-auth argument is set to false (federation-apiserver). ID = 81427 - Verify the Kubernetes PKI directory and file ownership are set to root:root. ID = 81428 - Verify the Kubernetes PKI certificate file permissions are set to 644 or more restrictive. ID = 8214 - Verify the --client-ca-file argument is set as appropriate (kubelet). ID = 8227 - Verify the certificate authorities file permissions are set to 644 or more restrictive (kubelet). ID = 8115 - Verify the --kubelet-https argument is set to true (kube-apiserver). ID = 8116 - Verify the --insecure-bind-address argument is not set (kube-apiserver). ID = 8117 - Verify the --insecure-port argument is set to 0 (kube-apiserver) can determine if the Kubernetes API is configured to only listen on the TLS-enabled port (TCP 6443). ID = 8118 - Verify the --secure-port argument is not set to 0 (kube-apiserver). ID = 81122 - Verify the --kubelet-certificate-authority argument is set as appropriate (kube-apiserver). ID = 81123 - Verify the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (kube-apiserver). ID = 81129 - Verify the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kube-apiserver). ID = 82112 - Verify the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kubelet). ID = 81141 - Verify the --authorization-mode argument includes RBAC (kube-apiserver). If any of these checks are set to "Ignore", to all host nodes within the intended monitored environment, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Defend >> Compliance >> Hosts tab >> Running hosts tab. Add Rule: - Click "Add rule". Name = "Default - alert on critical and high" Scope = "All" - Change Action to the values shown below (Change Action). - Accept the other defaults and click "Save". Change Action: - Click "Rule name". <Filter on Rule ID> ID = 8112 - Description (--anonymous-auth argument is set to false (kube-apiserver) - master node) - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8212 - Description (--anonymous-auth argument is set to false (kubelet) - worker node) - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8311 - Description (--anonymous-auth argument is set to false (federation-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 81427 - Description (Kubernetes PKI directory and file ownership is set to root:root). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 81428 - Description (Kubernetes PKI certificate file permissions are set to 644 or more restrictive). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8214 - Description (--client-ca-file argument is set as appropriate (kubelet)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8227 - Description (certificate authorities file permissions are set to 644 or more restrictive (kubelet)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8115 - Description (--kubelet-https argument is set to true (kube-apiserver)) - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8116 - Description (--insecure-bind-address argument is not set (kube-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8117 - Description (--insecure-port argument is set to 0 (kube-apiserver) can determine if the Kubernetes API is configured to only listen on the TLS enabled port (TCP 6443)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 8118 - Description (--secure-port argument is not set to 0 (kube-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 81122 - Description (--kubelet-certificate-authority argument is set as appropriate (kube-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 81123 - Description (--kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (kube-apiserver)). ID = 81129 - Description (--tls-cert-file and --tls-private-key-file arguments are set as appropriate (kube-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 82112 - Description (--tls-cert-file and --tls-private-key-file arguments are set as appropriate (kubelet)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save". ID = 81141 - Description (--authorization-mode argument includes RBAC (kube-apiserver)). - Change Action to "Alert" or "Block" (based on organizational needs). - Click "Save".
Verify compliance policies are enabled. Navigate to Prisma Cloud Compute Console's Defend >> Compliance. Select the "Code repositories" tab. Select the "Repositories" and "CI" tab. - If "Default – alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert all components". - If the policy is disabled, this is a finding. - Click the "Default – alert all components" policy row. - If the "Default - alert on critical and high" policy is not scoped to "All", this is a finding. Select the "Containers and images" tab. For the "Deployed" and "CI" tab: - If the "Default - alert on critical and high" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert on critical and high". - If the policy is disabled, this is a finding. - Click the "Default - alert on critical and high" policy row. - If the "Default - alert on critical and high" policy is not scoped to "All", this is a finding. Select the "Hosts" tab. For the "Running hosts" and "VM images" tab: - If the "Default - alert on critical and high" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert on critical and high". - If the policy is disabled, this is a finding. - Click the "Default - alert on critical and high" policy row. - If the "Default - alert on critical and high" policy is not scoped to "All", this is a finding. Select the "Functions" tab. For the "Functions" and "CI" tab: - If the "Default – alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default -alert all components". - If the policy is disabled, this is a finding. - Click the "Default - alert all components" policy row. - If the "Default - alert on critical and high" policy is not scoped to "All", this is a finding.
Enable compliance policies. Navigate to Prisma Cloud Compute Console's Defend >> Compliance and click tab to be edited. To add rule: - Click "Add rule." - Enter rule name. Scope = All - Accept the defaults and click "Save". Click the rule's three-dot menu. Set to "Enable". Click the rule row. - Change the policy scope to "All". - Click "Save".
Navigate to Prisma Cloud Compute Console's >> Defend >> Compliance Trusted Images tab. Select the "Trust groups" tab. If there is no Group, this is a finding. Select the "Policy" tab. If the Trusted Images Rules is set to "off", this is a finding. If a rule does not exist, this is a finding. Click the three dots in the "Actions" column for rule. If the policy is disabled, this is a finding. Click the policy row. If the policy is not scoped to "All", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Defend >> Compliance >> Trusted Images tab. Select the "Trust groups" tab. Create a trusted group: - Click "Add Group". Name: "IronBank" - Specify a registry or repository: https://ironbank.dso.mil - Click "Add to group". - Specify a registry or repository: https://registry1.dso.mil/ (There are two group images total.) - Click "Save". Select the "Policy" tab. Set the Trusted Images Rules to "on". If a rule does not exist: - Click "Add rule". Rule name = "IronBank" Scope = "All" Allowed: - Click "Select groups". - Select "IronBank". - Click "Apply". - Keep all defaults and click "Save". Enable policy: - Click the "Default - alert all components" policy three-dot menu. - Set to "Enable". Policy row scope: - Click the policy rows. - Change the policy scope to all images and containers within the intended monitored environment. - Click "Save".
For Kubernetes deployment: Query the ports used by the twistlock-console service: $ kubectl describe svc twistlock-console -n twistlock If any port number is below 1024, this is a finding. For Docker deployment: Determine the name of the Console container: docker ps|grep console For example, the Console container is: ad8b41a2fec9 ad8b41a2fec9 twistlock/private:console_22_01_840 Inspect the container's PortBindings: docker inspect ad8b41a2fec9|grep PortBindings -A 20 If the port is below 1024, this is a finding.
For Kubernetes deployment: Edit the deployment.apps/twistlock-console. Find the - name: TargetPorts below 1024. Change to port number above 1024. Save and exit the editing session. The Console will restart automatically. For Docker deployment: Modify the twistlock.cfg located in the extracted release tar directory. Change any port assignment below 1024 to above 1024: MANAGEMENT_PORT_HTTP= MANAGEMENT_PORT_HTTPS=8083 COMMUNICATION_PORT=8084 Redeploy the Console using the twistlock.sh script in the extracted release tar directory: $ sudo ./twisltock.sh -sy onebox
Confirm there is only one "break glass" local administrative account. Navigate to Prisma Cloud Compute Console's Manage >> Authentication >> Users tab. Only the administrative break glass account is allowed to have Authentication Method = Local. For all other accounts, Authentication Method = SAML. If any local account, except the administrative break glass account, has Authentication Method set to other than "SAML", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Users tab. Ensure only the break glass administrator account is a "local" account. Delete all other local accounts and use the SAML identity provider for all authentication and authorization to the Prisma Cloud Compute Console.
Locate the node in which the Prisma Cloud Compute Console container is running. Determine the process owner for "app/server". Execute: "ps -aux | grep "/app/server" If the process is owned by root, this is a finding.
In the root directory of the extracted release tar file, modify the twistlock.cfg file's line: RUN_CONSOLE_AS_ROOT=false For Kubernetes deployment, perform these additional steps: When generating the twistlock_console.yaml deployment file, supply the --run-as-user flag. Linux/twistcli console export kubernetes --service-type ClusterIP --run-as-user 2674 Modify the resulting twistlock_console.yaml file to include fsGroup: 2674 within the Deployment pod specification's securityContext: securityContext: fsGroup: 2674 Add runAsGroup: 2674 to the container specification's securityContext: securityContext: runAsUser: 2674 runAsGroup: 2674
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Users tab. Review the accounts for uniqueness. If there are shared local accounts, this is a finding.
Navigate to Prisma Cloud Compute Console's Manage >> Authentication >> Users tab. Delete shared accounts and create a unique account for every Prisma Cloud Compute user. Delete shared accounts: - Click the three-dot menu. - Click "Delete" and confirm "Delete User". Create a local user account where the local user account is unique: - Click "+Add user". - Complete the form and click "Save".
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Logon tab. - If "Token validity period" is greater than 15, this is a finding. - If "Enable context sensitive help and single sign on to the Prisma Cloud Support site" is set to "on", this is a finding. - If "Disable basic authentication for the API" is set to "off", this is a finding. - If "Require strong passwords for local accounts" is set to "off", this is a finding. - If "Require strict certificate validation in Defender installation links" is set to "on", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> Logon tab. - Set "Token validity period" to 15 or less. - Set "Enable context sensitive help and single sign on to the Prisma Cloud Support site" to "off". - Set "Disable basic authentication for the API" to "on". - Set "Require strong passwords for local accounts" to "on". - Set "Require strict certificate validation in Defender installation links" to "off". - Click "Save" and "Restart".
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> System Certificate tab. If not performing direct smart card authentication to the console, this is not a finding. If performing direct smart card authentication to the console: Revocation block: If "Enable certificate revocation checking" is set to "Off", this is a finding. Show Advanced certificate configuration: - In the "Certificate-based authentication to Console" block, verify the issuing CA(s) of the end users' certificates are within the Console CA certificate(s) field. - If there is no users' certificates, this is a finding. Click the "Users" tab. Review accounts with Authentication method "Local". If the local user account's name does not match the user's x.509 certificate's subjectName or the subject alternative name's PrincipalName value, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Authentication >> System Certificate tab. Revocation block: Set "Enable certificate revocation checking" to "On" and click "Save". In the "Certificate-based authentication to Console" block, import the smart card's issuing CA's chain of trust to the Console CA certificate(s) field. Click "Save". Click the "Users" tab. (Accounts cannot be edited. They must be removed and recreated correctly.) Delete account: - Click the three-dot menu. - Click "Delete" and confirm "Delete User". Create a local user account where the local user account name matches the user's x.509 certificate's subjectName or subject alternative name's PrincipalName value: - Click "+Add user". Authentication Source = Local Username = subject alternative name's PrincipalName value Password = random password that is not given to the user - Assign Role. - Click "Save".
Navigate to Prisma Cloud Compute Console's Defend >> Compliance >> Containers and images tab >> Deployed tab. For each rule name, click the rule and confirm the following checks: (Filter on ID) ID = 54: Do not use privileged container ID = 5525: Restrict container from acquiring additional privileges are not configured ID = 59: Do not share the host's network namespace ID = 515: Do not share the host's process namespace ID = 516: Do not share the host's IPC namespace ID = 517: Do not directly expose host devices to containers ID = 520: Do not share the host's UTS namespace ID = 530: Do not share the host's user namespaces ID = 55: Do not mount sensitive host system directories on containers ID = 57: Do not map privileged ports within containers ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately ID = 599: Container is running as root ID = 41 Image should be created with a non-root user If the action for each rule is set to "Ignore", this is a finding.
Navigate to Prisma Cloud Compute Console's Defend >> Compliance >> Containers and images tab >> Deployed tab. Change action: (Click the rule name) <Filter on Rule ID> ID = 54 - Description (Do not use privileged container) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 5525 - Description (Restrict container from acquiring additional privileges are not configured) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 59 - Description (Do not share the host's network namespace) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 515 - Description (Do not share the host's process namespace) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 516 - Description (Do not share the host's IPC namespace) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 517 - Description (Do not directly expose host devices to containers) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 520 - Description (Do not share the host's UTS namespace) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 530 - Description (Do not share the host's user namespaces) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 55 - Description (Do not mount sensitive host system directories on containers) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 57 - Description (Do not map privileged ports within containers) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 5510 - Description (Limit memory usage for container) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 5511 - Description (Set container CPU priority appropriately) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 599 - Description (Container is running as root) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save". ID = 41 - Description (Image should be created with a non-root user) Change Action to "Alert" or "Block" (based on organizational needs). Click "Save".
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> General tab. Inspect the Log Scrubbing section. If "Automatically scrub secrets from runtime events" is "off", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> General tab. In the Log Scrubbing section, set "Automatically scrub secrets from runtime events" to "on" and click "Save".
When deploying Prisma Cloud Compute within a Kubernetes cluster, the Console's persistent value is by default 100GB. The logs are stored within this persistent volume. Within the Kubernetes cluster, issue the command "kubectl get pv". If the twistlock/twistlock-console claim's capacity is not 100GB or greater, this is a finding.
When deploying the Prisma Cloud Console, specify the size of the persistent volume with the "—persistent-volume-storage" parameter.
To verify that vulnerabilities policies are enabled, navigate to Prisma Cloud Compute Console's Defend >> Vulnerabilities. Select the "Code repositories" tab. For the "Repositories" and "CI" tab: - If "Default - alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert all components". - If the policy is disabled, this is a finding. - Click the "Default - alert all components" policy row. - If "Default - alert all components" is not scoped to "All", this is a finding. Select the "Images" tab. For the "CI" and "Deployed" tab: - If "Default - alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert all components". - If the policy is disabled, this is a finding. - Click the "Default - alert all components" policy row. - If "Default - alert all components" is not scoped to "All", this is a finding. Select the "Hosts" tab. For the "Running hosts" and "VM images" tab: - If the "Default - alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert all components". - If the policy is disabled, this is a finding. - Click the "Default - alert all components" policy row. - If "Default - alert all components" is not scoped to "All", this is a finding. Select the "Functions" tab. For the "Functions" and "CI" tab: - If the "Default - alert all components" does not exist, this is a finding. - Click the three dots in the "Actions" column for rule "Default - alert all components". - If the policy is disabled, this is a finding. - Click the "Default - alert all components" policy row. - If "Default - alert all components" is not scoped to "All", this is a finding.
To enable vulnerabilities policies, navigate to Prisma Cloud Compute Console's Defend >> Vulnerabilities. Click tab to be edited. To add rule: - Click "Add rule". - Enter rule name. Scope = All - Accept the defaults and click "Save". Click the rule three-dot menu. Set to "Enable". Click the rule row: - Change the policy scope to "All". - Click "Save".
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> Scan tab. Verify that for Running images, For Running images, "Only scan images with running containers" is set to "Off". If "Only scan images with running containers" is set to "On", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> Scan tab. For Running images: - Set "Only scan images with running containers" = "Off". - Click "Save".
Navigate to Prisma Cloud Compute Console's >> Manage >> Defenders. Select the "Manage" tab. Select the "Defenders" tab. Click "Advanced Settings". If "Automatically remove disconnected Defenders after (days)" is not configured to the organization's policies, this is a finding.
Navigate to Prisma Cloud Compute's Manage >> Defenders. Select the "Manage" tab. Select the "Defenders" tab. Click "Advanced Settings". Set the "Automatically remove disconnected Defenders after (days)" value to the organization's defined period.
Verify that when deploying the Defender via daemonSet, "Run Defenders as privileged" is set to "On". Verify the Defender containers were deployed using the daemonSet.yaml in which the securityContext is privileged. If "Run Defenders as privileged" is not set to "On" or the Defender containers were not deployed using the daemonSet.yaml in which the securityContext - privileged = "on", this is a finding.
Redeploy the Defender with appropriate rights by setting Run Defenders as privileged = off. Delete old twistlock-defender-ds daemonSet and redeploy daemonSet with the new yaml.
Inspect the Kubernetes namespace in which Prisma Cloud Compute is deployed: $ kubectl get pods -n twistlock NAME READY STATUS RESTARTS AGE twistlock-console-855744b66b-xs9cm 1/1 Running 0 4d6h twistlock-defender-ds-99zj7 1/1 Running 0 58d twistlock-defender-ds-drsh8 1/1 Running 0 58d Inspect the list of pods. If a non-Prisma Cloud Compute (does not start with "twistlock") pod is running in the same namespace, this is a finding.
Deploy the Prisma Cloud Compute Console and Defender containers within a distinct namespace.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> General tab. Inspect the Telemetry section. If "Share telemetry on product usage with Palo Alto Networks" is "On", this is a finding. If "Allow admins and operators to upload logs to Customer Support directly from Console UI" is "On", this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> General tab. In the Telemetry section: Set "Share telemetry on product usage with Palo Alto Networks" to "Off". Set "Allow admins and operators to upload logs to Customer Support directly from Console UI" to "Off". Click "Save".
Navigate to the Prisma Cloud Compute Console. In the top right corner, click the bell icon. A banner with the version will display. If there is a newer version, this is a finding.
Upgrade the Prisma Cloud Compute Console and Defenders according to published procedures. https://docs.twistlock.com/docs/compute_edition/upgrade/upgrade_process_self_hosted.html
Navigate to Prisma Cloud Compute Console's >> Manage >> System >> Intelligence tab. If the "Last streams update" date is older than 36 hours, this is a finding.
Prisma Cloud Compute Console's ability to communicate with the Intelligence Stream endpoint (https://intelligence.twistlock.com) dictates the method of vulnerability updates. If the Console is able to communicate with the internet, ensure that intelligence.twistlock.com is resolvable, routable, and can establish a TLS session on TCP port 443. If the Console is in an isolated environment and is unable to communicate with the internet, configure the Console to receive Intelligence Stream updates using one of the following methods: - Manual import. - Central console. - HTTP/S distribution point. https://docs.paloaltonetworks.com/prisma/prisma-cloud/22-01/prisma-cloud-compute-edition-admin/tools/update_intel_stream_offline.html
Navigate to Prisma Cloud Compute Console's >> Manage >> Defenders. Select the "Manage" tab. Select the "Defenders" tab. Determine the deployment status of the Defenders. If a Defender is not deployed to intended workload(s) to be protected, this is a finding.
Navigate to Prisma Cloud Compute Console's >> Manage >> Defenders. Select the "Manage" tab. Select the "Defenders" tab. Deploy Defender to containerization node. Select the method of Defender deployment. https://docs.paloaltonetworks.com/prisma/prisma-cloud/22-01/prisma-cloud-compute-edition-admin/install/defender_types.html
Offline Intelligence Stream: If using Iron Bank distribution of Prisma Cloud Compute Console and Defenders, verify the Console and Defender imageID SHA256 values match the Palo Alto Networks published release values. For the Console and Defender images, perform the following command: $ docker inspect twistlock/private:console_22_01_839 | grep '"Image":' "Image": "sha256:dcd881fe9c796ed08867c242389737c4f2e8ab463377a90deddc0add4c3e8524", If the imageID values do not match the published release SHA256 for the version of the image release, this is a finding. Note: Image tag will be the release number, e.g., console_22_01_839. Published release image sha values are published here: https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-compute-edition-public-sector/isolated_upgrades/releases.html
Deploy the latest version from https://support.paloaltonetworks.com.