DISA STIG for Prisma Cloud Compute

Palo Alto Networks is in the process of developing a DISA STIG for the configuration of a Prisma Cloud Compute implementation. We have decided to post the draft STIG settings here to facilitate collaboration. If you would like to contribute to the formulation of these settings please see this guidance.

This is a work in progress and subject to change at anytime.

Document revisions

Date Comment

20210623

Initial draft publication

20210805

Update

Download

The proposed settings can be downloaded as a CSV file from here.

Findings

IA Control CCI SRGID STIGID SRG Requirement Requirement SRG VulDiscussion VulDiscussion Status SRG Check Check SRG Fix Fix Severity Mitigation Artifact Description Status Justification

AC-17 (2)

CCI-000068

SRG-APP-000014-CTR-000035

The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources.

Prisma Cloud Compute images must be pulled from a trusted, TLS 1.2 protected image registry.

The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.

Not Applicable

Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources.

If TLS 1.2 or greater is not being used for secure container image transport, this is a finding.

Configure the container platform to use TLS 1.2 or greater when components communicate internally or externally. The fix ensures that all communication components in the container platform are configured to utilize secure versions of TLS.

CAT II

https://docs.twistlock.com/docs/compute_edition/install/twistlock_container_images.html

Prisma Cloud Compute is a container based application. Distribution of Prisma Cloud Compute images should be protected by TLS transport. This is the responsibility of the organization.

The distributive nature of containerization technology requires confidence and integrity of the images transferred between organizations.

Prisma Cloud Compute images can be pulled from the https://registry.twistlock.com TLS 1.2+ enabled registry and authentication is required.

Prisma Cloud Compute images can be pulled from the https://registry-auth.twistlock.com TLS 1.2+ enabled registry. License key authentication is required within the requested image’s URL.

Prisma Cloud Compute images can also be obtained from the Palo Alto Networks Customer Support portal, https://https://support.paloaltonetworks.com/, TLS v1.2+ enabled and authentication is required.

Prisma Cloud Compute images hosted within the organization’s registry must use TLS v1.2+ image pull transport.

AC-17 (2)

CCI-000068

SRG-APP-000014-CTR-000040

The container platform must use TLS 1.2 or greater for secure communication.

Prisma Cloud Compute Console must use TLS 1.2 for user interface and API access

The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.

Communication to Prisma Cloud Compute Console’s User Interface (UI) and API is protected by TLS v1.2+ (HTTPS). By default only HTTPS communication to the Console’s UI and API endpoints is enabled.

Applicable - Configurable

Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components.

If TLS 1.2 or greater is not being used for secure communication, this is a finding.

For Kubneretes deployment type kubectl describe pods twistlock-console-pod -n namespace and verify the MANAGEMENT_PORT_HTTP: value is NULL

For docker type docker inspect twistlock-console-container and verify MANAGEMENT_PORT_HTTP value is NULL

If the Console’s MANAGEMENT_PORT_HTTP has an assigned port number this is a finding

Configure the container platform to use TLS 1.2 or greater for node and component communication.

Redploy Prisma Cloud Compute’s Console to disable MANAGEMENT_PORT_HTTP using the twistlock.cfg configuration file’s MANAGEMENT_PORT_HTTP = null

CAT II

https://docs.twistlock.com/docs/compute_edition/howto/configure_listening_ports.html

MANAGEMENT_PORT_HTTP is disabled by default

AC-2 (1)

CCI-000015

SRG-APP-000023-CTR-000055

The container platform must use a centralized user management solution to support account management functions.

Must use external identity providers for authentication and group to role based assignments when possible.

Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.

A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.

The application must be configured to automatically provide account management functions, and these functions must immediately enforce the organization’s current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure-providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies, that when placed together, contain an overall automated mechanism supporting an organization’s automated account management requirements.

Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; or using automated telephonic notification to report atypical system account usage.

User identity and role based access is critical for the confidentiality and integrity of the system.

Integration with an organization’s existing identity management policies technologies reduce the threat of account compromise and misuse.

Applicable - Configurable

Review the container platform to determine if it is using a centralized user management system for user management functions.

If the container platform is not using a centralized user management system for user management functions, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage - Authentication - Users and inspect the users’ authentication methods, if they are set to “local” this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Identity Providers and if an external identity provider (LDAP, SAML, OAUTH & OpenID Connect) is not configured this is a finding.

If using x.509 certificate based authentication Navigate to Prisma Cloud Compute Console’s Manage - Authentication - System Certificates - un-hide “Advanced Certificate Configuration” - 2. Console authentication for x509 authentication. If local user accounts are created and not associated to x.509 certificate based authentication this is a finding.

Configure the container platform to use a centralized user management system for user management functions.

Configure Prisma Cloud Compute to use external identity provider. 

If local accounts are required the Console API Users endpoint (https://cdn.twistlock.com/docs/api/twistlock_api.html#users) can be used to integrate with the organization’s identity management system to add, modify and delete local user accounts.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/authentication.html

AC-2 (2)

CCI-000016

SRG-APP-000024-CTR-000060

The container platform must automatically remove or disable temporary user accounts after 72 hours.

Prisma Cloud Compute must remove or disable temporary accounts after 72 hours.

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary user accounts must be set upon account creation.

Temporary user accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.

If temporary user accounts are used, the application must be configured to automatically terminate these types of accounts after a DoD-defined period of 72 hours.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Temporary accounts are often forgotten and introduce the risk of being compromised thus providing unintended access to Prisma Cloud Compute

Applicable - Does Not Meet

Review the container platform configuration to determine if temporary user accounts are automatically removed or disabled after 72 hours.

If temporary user accounts are not automatically removed or disabled after 72 hours, this is a finding.

Configure the container platform to automatically remove or disable temporary user accounts after 72 hours.

CAT II

If Prisma Cloud Compute requires local accounts integration with organizations identity management policies and processes.

Local accounts cannot be disabled, they must be deleted

AC-2 (3)

CCI-000017

SRG-APP-000025-CTR-000065

The container platform must automatically disable accounts after a 35-day period of account inactivity.

Prisma Cloud Compute must disable accounts after 35-days of account inactivity.

Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

This policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.

Inactive accounts are often forgotten and introduce the risk of being compromised thus providing unintended access to Prisma Cloud Compute

Applicable - Does Not Meet

Determine if the container platform automatically disables accounts after a 35-day period of account inactivity.

If the container platform does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.

Configure the container platform to automatically disable accounts after a 35-day period of account inactivity.

CAT II

If Prisma Cloud Compute requires local accounts integration with organizations identity management policies and processes.

Local accounts cannot be disabled, they must be deleted

AC-2 (4)

CCI-000018

SRG-APP-000026-CTR-000070

The container platform must automatically audit account creation.

Prisma Cloud Compute account creation must be audited.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created, and provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Prisma Cloud Compute local account creation could be used to provide unintended access to the platform. Local account creation is automatically audited and should be monitored.

Applicable - Inherently Meets

Review the container platform configuration to determine if audit records are automatically created upon account creation.

If audit records are not automatically created upon account creation, this is a finding.

Configure the container platform to automatically create audit records on account creation.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

Navigate to Prisma Cloud Compute Console’s Manage -Authentication - Users : Add User and create a user account (any type). Then go to Manage -View Log - History and review the user account creation audit. If no audit of the account creation exists this is a bug and Palo Alto Networks should be notified of the observed behavior.

AC-2 (4)

CCI-001403

SRG-APP-000027-CTR-000075

The container platform must automatically audit account modification.

Prisma Cloud Compute account modification must be audited.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Prisma Cloud Compute local account modification is automatically audited.

Modification to external identities’ roles are automatically audited.

Applicable - Inherently Meets

Review the container platform configuration to determine if account modification is automatically audited.

If account modification is not automatically audited, this is a finding.

Configure the container platform to automatically audit account modification.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users, click on user account, perform the modification. Then go to Manage -View Log -History and review the user account modification audit. If no audit of the account modification exists this is a bug and Palo Alto Networks should be notified of the observed behavior

AC-2 (4)

CCI-001404

SRG-APP-000028-CTR-000080

The container platform must automatically audit account-disabling actions.

Prisma Cloud Compute account disablement must be audited.

When application accounts are disabled, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to disable authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account-disabling actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Not Applicable

Review the container platform configuration to determine if account disabling is automatically audited.

If account disabling is not automatically audited, this is a finding.

Configure the container platform to automatically audit account disabling.

CAT II

Local accounts cannot be disabled, they must be deleted

AC-2 (4)

CCI-001405

SRG-APP-000029-CTR-000085

The container platform must automatically audit account removal actions.

Prisma Cloud Compute account deletions must be audited.

When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

All account management activities should be audited to identify potential or intentional system compromise. Prisma Cloud Compute local account deletion is automatically audited.

Applicable - Inherently Meets

Review the container platform configuration to determine if account removal is automatically audited.

If account removal is not automatically audited, this is a finding.

Configure the container platform to automatically audit account removal.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

The deletion of accounts from Prisma Cloud Compute Console’s - Manage - Authentication - Users is automatically audited in Manage - View Logs - History. If no audit of the account deletion exists this is a bug and Palo Alto Networks should be notified of the observed behavior

AC-3

CCI-000213

SRG-APP-000033-CTR-000090

Least privilege access and need to know must be required to access the container platform registry.

Access to the container registry must be managed based. Upon user need and least privileged.

The container platform registry is used to store images and is the keeper of truth for trusted images within the platform. To guarantee the images integrity, access to the registry must be limited to those individuals who need to perform tasks to the images such as the update, creation, or deletion of images. Without this control access, images can be deleted that are in use by the container platform causing a denial of service (DoS), and images can be modified or introduced without going through the testing and validation process allowing for the intentional or unintentional introduction of containers with flaws and vulnerabilities.

Not Applicable

Review the container platform configuration to determine if least privilege and need-to-know access is being used for container platform registry access.

If least privilege and need-to-know access is not being used for container platform registry access, this is a finding.

Configure the container platform to use least privilege and need to know when granting access to the container platform registry. The fix ensures the proper roles and permissions are configured.

CAT II

Prisma Cloud Compute does not have container platform registry feature

AC-3

CCI-000213

SRG-APP-000033-CTR-000095

Least privilege access and need to know must be required to access the container platform runtime.

Access to the container runtime environment must be managed based upon user need and least privileged.

The container platform runtime is used to instantiate containers. If this process is accessed by those persons who are not authorized, those containers offering services can be brought to a denial of service (DoS) situation, disabling a large number of services with a small change to the container platform. To limit this threat, it is important to limit access to the runtime to only those individuals with runtime duties.

Not Applicable

Review the container platform to determine if only those individuals with runtime duties have access to the container platform runtime.

If users have access to the container platform runtime that do not have runtime duties, this is a finding.

Configure the container platform to use least privilege and need to know when granting access to the container runtime. The fix ensures the proper roles and permissions are configured.

CAT II

Prisma Cloud Compute does not directly control the privileged access of the container environment. The Docker Access (https://docs.twistlock.com/docs/compute_edition/access_control/rbac.html) and Open Policy Agent (https://docs.twistlock.com/docs/compute_edition/access_control/open_policy_agent.html) features could be used to control behaviors but it enabled/configured by default.

AC-3

CCI-000213

SRG-APP-000033-CTR-000100

Least privilege access and need to know must be required to access the container platform keystore.

Users requiring access to Prisma Cloud Compute’s Credential Store must be assigned either the Administrator or Operator role.

The container platform keystore is used to store access keys and tokens for trusted access to and from the container platform. The keystore gives the container platform a method to store the confidential data in a secure way and to encrypt the data when at rest. If this data is not protected through access controls, it can be used to access trusted sources as the container platform breaking the trusted relationship. To circumvent unauthorized access to the keystore, the container platform must have access controls in place to only allow those individuals with keystore duties.

Container environments tend to utilize many third party services across multiple cloud providers. To improve accessibility and reusability, Prisma Cloud Compute manages all credentials in a central encrypted store. Only users assigned the role of Administrator or Operator have rights to add, delete or modify credentials in the credential store.

Applicable - Configurable

Review the container platform to determine if only those individuals with keystore duties have access to the container platform keystore.

If users have access to the container platform keystore that do not have keystore duties, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users and inspect the users’ role assignments.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Groups and inspect the groups’ role assignments.

If using external identity providers and associating group membership to Prisma Cloud Compute role inspect the identity provider’s group memberships for the user.

If users have been assigned the Administrator or Operator role and do not require access to Prisma Cloud Compute’s Credential Store this is a finding.

Configure the container platform to use least privilege and need to know when granting access to the container keystore. The fix ensures the proper roles and permissions are configured.

Assign Prisma Cloud Compute Administrator and Operator roles to users requiring the rights to modify the Prisma Cloud Compute’s Credential Store

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/credentials_store.html

AC-4

CCI-001368

SRG-APP-000038-CTR-000105

The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.

Prisma Cloud Compute Collections must be used to partition views and enforce organizational defined need-to-know access.

Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.

Prisma Cloud Compute Collections are used to scope rules to target specific resources in an environment, partition views and enforce which views specific users and groups can see. Collections can control access to data on a need-to-know basis.

Applicable - Configurable

Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced.

If the organization-defined information flow policies are not being enforced, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Collections and Tags and create and assign Collections according to organizational policy. If no organizational specific policies are defined this is a finding.

Configure the container platform to enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.

Create Collections when separation of Prisma Cloud Compute data is required.

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/collections.html

AC-4

CCI-001414

SRG-APP-000039-CTR-000110

The container platform must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.

Prisma Cloud Compute Cloud Native Network Firewall (CNNF) automatically monitors layer 4 (TCP) inter-container communications. Enforcement policies must be created.

Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.

Network segmentation and compartmentalization is an important part of a comprehensive defense in depth strategy. It limits damage by preventing attackers from moving laterally through the environment.

Applicable - Configurable

Review the container platform configuration to determine if organization-defined information flow controls are implemented.

If information flow controls are not implemented, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -CNNF -Container determine if inter-container communication rules exist in accordance to organizational policy and application requirements. If not policies exist this is a finding.

Configure the container platform to implement organization-defined information flow controls.

Create a CNNF rule to monitor and/or control TCP traffic between containers in Defend -CNNF -Container

CAT II

https://docs.twistlock.com/docs/compute_edition/firewalls/cnnf_self_hosted.html

Inter-container network connectivity is automatically monitored and displayed within the Radar. CNNF policies can be created to explicitly control inter-container traffic.

AC-7 a

CCI-000044

SRG-APP-000065-CTR-000115

The container platform must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

Prisma Cloud Compute must limit brute force password attempts.

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Limiting the number of failed authentication attempts reduces the success of unauthorized access via brute force password guessing attempts.

Applicable - Does Not Meet

Review the container platform to determine if it is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

If the container platform is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding.

Configure the container platform to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

CAT II

Use external identity providers that enforce invalid logon policies.

https://docs.twistlock.com/docs/compute_edition/authentication/authentication.html

AC-8 a

CCI-000048

SRG-APP-000068-CTR-000120

The container platform must display the Standard Mandatory DoD Notice and Consent Banner before granting access to platform components.

Prisma Cloud Compute must display a logon consent banner.

The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoD-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

Users must acknowledge a consent to use a Government operated instance of Prisma Cloud Compute

Applicable - Does Not Meet

Review the container platform configuration to determine if the Standard Mandatory DoD Notice and Consent Banner is configured to be displayed before granting access to platform components.

Log in to the container platform components and verify that the Standard Mandatory DoD Notice and Consent Banner is being displayed before granting access.

If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding.

Configure the container platform to display the Standard Mandatory DoD Notice and Consent Banner before granting access to container platform components.

CAT III

Use external identity providers that display logon banner (e.g. SAML IdP).

AC-8 b

CCI-000050

SRG-APP-000069-CTR-000125

The container platform must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.

Prisma Cloud Compute must display a logon consent banner and require explicit user action to acknowledge the banner.

The banner must be acknowledged by the user prior to allowing the user access to any container platform component. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.

To establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".

Users must acknowledge a consent to use a Government operated instance of Prisma Cloud Compute by requiring user action.

Applicable - Does Not Meet

Log in to the container platform components to determine if the Standard Mandatory DoD Notice and Consent Banner remains on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.

If the Standard Mandatory DoD Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding.

Configure the container platform to retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.

CAT III

Use external identity providers that display logon banner and require acknowledgement.

AU-12 a

CCI-000169

SRG-APP-000089-CTR-000150

The container platform must generate audit records for all DoD-defined auditable events within all components in the platform.

Prisma Cloud Compute must generate DoD-defined auditable events

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, including security incidents that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to have the appropriate and required data logged. To handle the need to log DoD-defined auditable events, the container platform must offer a mechanism to change and manage the events that are audited.

Prisma Cloud Compute creates and stores audit event records (audits) for all major subsystems. Audits can be reviewed in Monitor -Events, or they can be retrieved from the Prisma Cloud API.

Applicable - Inherently Meets

Review the container platform configuration to determine if the container platform is configured to generate audit records for all DoD-defined auditable events within all components in the platform.

Generate DoD-defined auditable events within all the components to determine if the events are being audited.

If the container platform is not configured to generate audit records for all DoD-defined auditable events within the components or the events are not generating audit records, this is a finding.

Configure the container platform to generate audit records for all DoD-defined auditable events within all the components of the container platform.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit.html

Generate activity on the Prisma Cloud Compute platform. Navigate to Manage -View Logs -Console and select “Download this log” and “Download debug logs” and inspect the content of the logs. To view Defender logs navigate to Manage -Defenders -Manage -Defenders for each Defender click “…” in Actions and select Logs. Select “Download this log” and inspect the content of the log. If the log does not contain a record of the event this is a bug. Contact Palo Alto Networks to notify them of the observed behavior.

AU-12 b

CCI-000171

SRG-APP-000090-CTR-000155

The container platform must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

Prisma Cloud Compute auditable event must be selectable

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system’s performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

Not Applicable

Review the container platform to determine if the container platform is configured to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

If the container platform is not configured to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited, this is a finding.

Configure the container platform to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

Prisma Cloud Compute creates and stores audit event records (audits) for all major subsystems. Prisma Cloud Compute Alert feature (https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html) can send certain audit type to selected recipients ensuring the responsible individuals are notified.

Which events Prisma Cloud Compute audits are not modifiable.

AU-12 c

CCI-000172

SRG-APP-000091-CTR-000160

The container platform must generate audit records when successful/unsuccessful attempts to access privileges occur.

Prisma Cloud Compute successful/unsuccessful privilege access activities must be audited

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

All privileged access attempts must be audited for accountability.

Applicable - Inherently Meets

Review the container platform configuration to determine if it is configured to generate audit records when successful/unsuccessful attempts are made to access privileges.

If the container platform is not configured to generate audit records on successful/unsuccessful access to privileges, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to access privileges occur.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

Prisma Cloud Compute user interface will not render higher role privileged functions to user. To test attempt to call an API endpoint that requires a higher privilege than the user account used. If the user is able to obtain the data for a higher role holder, this is a finding.

AU-14 (1)

CCI-001464

SRG-APP-000092-CTR-000165

The container platform must initiate session auditing upon startup.

Prisma Cloud Compute must begin auditing upon application start.

When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup.

Event logging occurs at application start time.

Applicable - Inherently Meets

Review the container platform configuration for session audits.

Ensure audit policy for session logging at startup is enabled.

Verify events are written to the log.

Validate system documentation is current.

If the container platform is not configured to meet this requirement, this is a finding.

Configure the container platform to generate audit logs for session logging at startup. Revise all applicable system documentation.

CAT II

Navigate to Prisma Cloud Compute Console’s -Manage -View Logs -Console and select “Download this log” and review the log’s initial entries. If the log does not contain server initiation look in the Console container’s /var/lib/twistlock/logs/console directory for archived logs.

AU-3

CCI-000130

SRG-APP-000095-CTR-000170

All audit records must identify what type of event has occurred within the container platform.

Prisma Cloud Compute audit must contain the component information within the audit

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know what type of event occurred.

All audits are identifiable based upon the sub-system origin of the audit.

Applicable - Inherently Meets

Review the container platform configuration for audit event types. Ensure audit policy for event type is enabled.

Verify records showing what type of event occurred are written to the log.

Validate system documentation is current.

If log data does not show the type of event, this is a finding.

Configure the container platform to include the event type in the log data. Revise all applicable system documentation.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

AU-3

CCI-000131

SRG-APP-000096-CTR-000175

The container platform audit records must have a date and time association with all events.

Prisma Cloud Compute system clock must be coordinated.

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know when the event occurred. To establish the time of the event, the audit record must contain the date and time.

All Prisma Cloud Compute audits are timestamped using Coordinated Universal Time (UTC)

Applicable - Inherently Meets

Review the container platform configuration for audit events date and time.

Ensure audit policy for event date and time are enabled.

Verify records showing event date and time are included in the log.

Validate system documentation is current.

If the date and time are not included, this is a finding.

Configure the container platform to include log date and time with the event. Revise all applicable system documentation.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit.html

AU-3

CCI-000132

SRG-APP-000097-CTR-000180

All audit records must identify where in the container platform the event occurred.

Prisma Cloud Compute Defender must be deployed to containerization nodes that are to be monitored

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know where within the container platform the event occurred.

Container platforms distribute workloads across several nodes. The ability to unique identify an event within an environment is critical. Prisma Cloud Compute Container Runtime audits records the time, container, corresponding image and node that the event occurred.

Applicable - Configurable

Review the container platform configuration to determine if all audit records identify where in the container platform the event occurred.

Generate audit records and view the audit records to verify that the records do identify where in the container platform the event occurred.

If the container platform is not configured to generate audit records that identify where in the container platform the event occurred, or if the generated audit records do not identify where in the container platform the event occurred, this is a finding.

Prisma Cloud Compute Defenders have been deployed to all container runtime nodes to be monitored. Navigate to Prisma Cloud Compute Console Manage -Defender -Manage and review the list of deployed Defenders. If a Defender is missing from an intended node to be monitored this is a finding.

Configure the container platform to generate audit records that identify where in the container platform the event occurred.

Deploy Defender to containerization node. Navigate to Prisma Cloud Compute Manage -Defenders -Deploy and selected the method of Defender deployment

CAT II

https://docs.twistlock.com/docs/compute_edition/install/defender_types.html

Prisma Cloud Compute Defender runs on every node and monitors and captures the events of the container runtime.

AU-3

CCI-000133

SRG-APP-000098-CTR-000185

All audit records must identify the source of the event within the container platform.

Prisma Cloud Compute audits must identify where within a container platform an audit was generated.

Audit data is important when there are issues, to include security incidents that must be investigated. Since the audit data may be part of a larger audit system, it is important for the audit data to also include the container platform name for traceability back to the container platform itself and not just the container platform components.

Prisma Cloud Compute audits record the source IP of an event in which a network connection was established.

Applicable - Inherently Meets

Review container platform audit policy configuration for logons establishing the sources of events.

Ensure audit policy is configured to generate sufficient information to resolve the source, e.g., source IP, of the log event.

Verify records showing by requesting a user access the container platform and generate log events, and then review the logs to determine if the source of the event can be established.

If the source of the event cannot be determined, this is a finding.

Configure the container platform registry, keystore, and runtime to generate the source of each loggable event. Revise all applicable system documentation.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/event_viewer.html

Prisma Cloud Compute Defender runs on every node and monitors and captures the events of the container runtime.

AU-3

CCI-000134

SRG-APP-000099-CTR-000190

All audit records must generate the event results within the container platform.

Prisma Cloud Compute Incident Explorer automatically correlates individual events generated by the firewall and runtime sensors.

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know the outcome of the event.

Prisma Cloud Compute correlates raw audit data to actionable security intelligence, enabling a more rapid and effective response to incidents. Reducing the manual, time consuming task of correlating data.

Prisma Cloud Forensics is a lightweight distributed data recorder that runs alongside all the containers in your environment. Prisma Cloud continuously collects detailed runtime information to help incident response teams understand precisely what happened before, during, and after a breach.

Forensic data consists of additional supplemental runtime events that complement the data (audits) already captured by Prisma Cloud’s runtime sensors. It provides additional context when trying to root cause an incident.

Applicable - Configurable

Review the container platform configuration to determine if audit records contain the audit event results.

Generate audit records and review the data to validate that the record does contain the event result.

If the container platform is not configured to generate audit records with the event result or the audit record does not contain the event result, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -System -Forensics if “Forensics data collection” is disabled this is a finding.

Configure the container platform to generate audit records that contain the event result.

Navigate to Prisma Cloud Compute Console’s Manage -System -Forensics set “Forensics data collection” to enabled.

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/incident_explorer.html

https://docs.twistlock.com/docs/compute_edition/runtime_defense/incident_explorer.html#_forensics

AU-3

CCI-001487

SRG-APP-000100-CTR-000195

All audit records must identify any users associated with the event within the container platform.

User identities involved in an incident must be captured within an event audit

Without information that establishes the identity of the user associated with the events, security personnel cannot determine responsibility for the potentially harmful event.

Identifying users associated with an event is critical in determining the cause and effect of an incident. Prisma Cloud Compute audits record the user associated with an event.

Applicable - Inherently Meets

Review container platform documentation and the log files on the application server to determine if the logs contain information that establishes the identity of the user or process associated with log event data.

If the container platform does not produce logs that establish the identity of the user or process associated with log event data, this is a finding.

Configure the container platform logging system to log the identity of the user or process related to the events.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/event_viewer.html

All audits capture user identity associated with event.

AU-3

CCI-001487

SRG-APP-000100-CTR-000200

All audit records must identify any containers associated with the event within the container platform.

Prisma Cloud Compute Defender must be deployed to containerization nodes that are to be monitored

Without information that establishes the identity of the containers offering user services or running on behalf of a user within the platform associated with audit events, security personnel cannot determine responsibility for potentially harmful events.

Containers are ephemeral and it is critical to audit which container at the time of the incident was involved. Prisma Cloud Compute Container Runtime audits records the time, container, corresponding image and node that the event occurred.

Applicable - Configurable

Review the container platform configuration to determine if it is configured to generate audit records that contain the component information that generated the audit record.

Generate audit records and review the data to determine if records are generated containing the component information that generated the record.

If the container platform is not configured to generate audit records containing the component information or records are generated that do not contain the component information that generated the record, this is a finding.

Prisma Cloud Compute Defenders have been deployed to all container runtime nodes to be monitored. Navigate to Prisma Cloud Compute Console Manage -Defender -Manage and review the list of deployed Defenders. If a Defender is missing this is a finding.

Configure the container platform to include the component information that generated the audit record.

Deploy Defender to containerization node. Navigate to Prisma Cloud Compute Manage -Defenders -Deploy and selected the method of Defender deployment

CAT II

https://docs.twistlock.com/docs/compute_edition/install/defender_types.html

Prisma Cloud Compute Defender runs on every node and monitors and captures the events of the container runtime.

AU-3 (1)

CCI-000135

SRG-APP-000101-CTR-000205

The container platform must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.

Prisma Cloud Compute Runtime must be enabled for Hosts and Containers.

During an investigation of an incident, it is important to fully understand what took place. Often, information is not part of the audited event due to the data’s nature, security risk, or audit log size. Organizations must consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. At a minimum, the organization must audit either full-text recording of privileged commands, or the individual identities of group users, or both.

Monitoring the containerized environment(containers and nodes) for runtime behaviors (filesystem, network and process) is critical in collecting the appropriate audit information associated with an event.

Applicable - Configurable

Review the documentation and deployment configuration to determine if the container platform is configured to generate full-text recording of privileged commands or the individual identities of group users at a minimum.

Have a user execute a privileged command and review the log data to validate that the full-text or identity of the individual is being logged.

If the container platform is not meeting this requirement, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime -Container Policy if “Enable automatic runtime learning” is set to off and “Default - alert on suspicious runtime behavior” policy is disabled and/or not scoped to “all” this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime -Host Policy if “Default - alert on suspicious runtime behavior” policy is disabled and/or not scoped to “all” this is a finding.

Configure the container platform to generate the full-text recording of privileged commands, or the individual identities of group users, or both.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime -Container Policy set “Enable automatic runtime learning” on and the “Default - alert on suspicious runtime behavior” policy is enabled and scoped to “all.”

Navigate to Prisma Cloud Compute Console’s Defend -Runtime -Host Policy enable the “Default - alert on suspicious runtime behavior” and it is scoped to “all.”

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_overview.html

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_hosts.html

AU-5 b

CCI-000140

SRG-APP-000109-CTR-000215

The container platform must take appropriate action upon an audit failure.

Prisma Cloud Compute must natively manage audit log size and archival.

It is critical that when the container platform is at risk of failing to process audit logs as required that it take action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

Because availability of the services provided by the container platform, approved actions in response to an audit failure are as follows:

(i) If the failure was caused by the lack of audit record storage capacity, the container platform must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.

(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the container platform must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

The integrity of audit logs is critical. The application must ensure audit logs are protected from the failure to collect and store event information.

Applicable - Inherently Meets

Review the configuration settings to determine how the container platform components are configured for audit failures. When the audit failure is due to the lack of audit record storage, the container platform must continue generating audit records, restarting services if necessary, and overwrite the oldest audit records in a first-in-first-out manner.

If the audit failure is due to a communication to a centralized collection server, the container platform must queue audit records locally until communication is restored or the records are retrieved manually.

If the container platform is not configured to handle audit failures appropriately, this is a finding.

Configure the container platform to continue generating audit records overwriting oldest audit records in a first-in-first-out manner when the failure is due to a lack of audit record storage. When the audit failure is due to a communication to a centralized collection server, configure the container platform to queue audit records locally until communication is restored or the records are retrieved manually. If other actions are to be taken for audit record failures, the actions and rationale must be documented in the system security plan and risk acceptance approvals must be obtained.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/log_rotation.html

Console and Defender logs are configured as follows:

- Truncate the original log file in place after creating a copy, instead of moving the old log file. (copytruncate) - Have 10 backup files rotated. If rotation exceeds 10 files, the oldest rotated file is deleted. (rotate 10) - Don’t generate an error in case a log file doesn’t exist. (missingok) - Don’t rotate the log in case it’s empty. (notifempty) - Rotate the log only if its size is 100M or more. (size 100M) - Compress the rotated logs. (compress)

AU-6 (4)

CCI-000154

SRG-APP-000111-CTR-000220

The container platform components must provide the ability to send audit logs to a central enterprise repository for review and analysis.

Prisma Cloud Compute must be configured to send events to hosts’ syslog.

The container platform components must send audit events to a central managed audit log repository to provide reporting, analysis, and alert notification. Incident response relies on successful timely, accurate system analysis in order for the organization to identify and respond to possible security events.

Event log collection is critical in ensuring the security of a containerized environment due to the ephemeral nature of the workloads. In an environment that is continually in flux audit logs must be properly collected and secured. Prisma Cloud Compute can be configured to send audit events to the host node’s syslog in RFC5424-compliant format.

Applicable - Configurable

Review the configuration settings to determine if the container platform components are configured to send audit events to central managed audit log repository.

If the container platform is not configured to send audit events to central managed audit log repository, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Alerts -Logging if the Syslog setting is “disabled” this is a finding.

Configure the container platform components to send audit logs to a central managed audit log repository.

Navigate to Prisma Cloud Compute Console’s Manage -Alerts -Logging set Syslog to “enabled.”

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

Organization must ensure syslog collection from the nodes within the environment has been established and operating as indented.

AU-8 a

CCI-000159

SRG-APP-000116-CTR-000235

The container platform must use internal system clocks to generate audit record time stamps.

Accurate timestamp of an an audited event must be ensured.

Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock.

Accurate timestamp of an audited event is critical when examining any event. Prisma Cloud Compute uses the containerization runtime host node’s system clock

Applicable - Inherently Meets

Review the container platform configuration files to determine if the internal system clock is used for time stamps.

If the container platform does not use the internal system clock to generate time stamps, this is a finding.

Configure the container platform to use internal system clocks to generate time stamps for log records.

CAT II

Prisma Cloud Compute runs as containers within the customer’s runtime environment. The Console and Defender containers use the host node’s system clock

AU-9

CCI-000162

SRG-APP-000118-CTR-000240

The container platform must protect audit information from any type of unauthorized read access.

Users not requiring the right to view audit information must not be assigned the Administrator, Operator or Auditor roles.

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access.

This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories.

Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Only the Administrator, Operator and Auditor Prisma Cloud Compute roles have the ability to view audit information.

Applicable - Configurable

Review the container platform configuration to determine where audit information is stored.

If the audit information is not protected from any type of unauthorized read access, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users and inspect the users’ role assignments.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Groups and 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.

Configure the container platform to protect the storage of audit information from unauthorized read access.

Assign Prisma Cloud Compute Administrator, Operator and Auditor roles to users requiring the rights to view audit information

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/user_roles.html

AU-9

CCI-000163

SRG-APP-000119-CTR-000245

The container platform must protect audit information from unauthorized modification.

Prisma Cloud Compute audit logs must be stored within a secure filesystem location

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.

This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit logs are stored within the Prisma Cloud Compute Console and Defenders’ containers root only access /var/lib/twistlock/log folder.

Applicable - Inherently Meets

Review the container platform configuration to determine where audit information is stored.

If the audit log data is not protected from unauthorized modification, this is a finding.

Configure the container platform to protect the storage of audit information from unauthorized modification.

CAT II

AU-9

CCI-000164

SRG-APP-000120-CTR-000250

The container platform must protect audit information from unauthorized deletion.

All Prisma Cloud Administrators must be identified and have the operational requirement to delete audit information.

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.

Some commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.

Audit logs can be deleted only by an administrator with explicit authority to delete audit logs.

Applicable - Configurable

Review the container platform configuration to determine where audit information is stored.

If the audit log data is not protected from unauthorized deletion, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users and inspect the users with Administrator role.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Groups and inspect the groups with the Administrator role.

If any users or groups are assigned the Administrator role and are not assigned the duties of audit deletion this is a finding.

Configure the container platform to protect the storage of audit information from unauthorized deletion.

Assign Prisma Cloud Compute Administrator role to users requiring the rights to delete audit information

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/delete_audit_logs.html

Prisma Cloud Compute audit logs can be deleted by the administrator role and via an API call.

AU-9

CCI-001493

SRG-APP-000121-CTR-000255

The container platform must protect audit tools from unauthorized access.

Prisma Cloud Compute audit logs must be accessed by the appropriate role holders.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Not Applicable

Review the container platform to validate container platform audit tools are protected from unauthorized access.

If the audit tools are not protected from unauthorized access, this is a finding.

Configure the container platform to protect audit tools from unauthorized access.

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

No direct integration with 3rd party audit tools.

AU-9

CCI-001494

SRG-APP-000122-CTR-000260

The container platform must protect audit tools from unauthorized modification.

Prisma Cloud Compute audit logs must not be modifiable.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Not Applicable

Review the container platform to validate container platform audit tools are protected from unauthorized modification.

If the audit tools are not protected from unauthorized modification, this is a finding.

Configure the container platform to protect audit tools from unauthorized modification.

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

No direct integration with 3rd party audit tools.

AU-9

CCI-001495

SRG-APP-000123-CTR-000265

The container platform must protect audit tools from unauthorized deletion.

Prisma Cloud Compute audit logs must not be deleted.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Not Applicable

Review the container platform to validate container platform audit tools are protected from unauthorized deletion.

If the audit tools are not protected from unauthorized deletion, this is a finding.

Configure the container platform to protect audit tools from unauthorized deletion.

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

No direct integration with 3rd party audit tools. Prisma Cloud Compute audit logs can be deleted by the administrator role and via an API call.

AU-9 (3)

CCI-001350

SRG-APP-000126-CTR-000275

The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information.

Cryptographic modules used within U.S. Government organizations must follow the NIST FIPS 140-3 standard.

To fully investigate an incident and to have trust in the audit data that is generated, it is important to put in place data protections. Without integrity protections, unauthorized changes may be made to the audit files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Although digital signatures are one example of protecting integrity, this control is not intended to cause a new cryptographic hash to be generated every time a record is added to a log file.

Integrity protections can also be implemented by using cryptographic techniques for security function isolation and file system protections to protect against unauthorized changes.

The FIPS 140-3 standard ensure the proper level of cryptographic security is used throughout the environment.

Applicable - Does Not Meet

Review the container platform configuration to determine if FIPS-validated cryptographic mechanisms are being used to protect the integrity of log information.

If FIPS-validated cryptographic mechanisms are not being used to protect the integrity of log information, this is a finding.

Configure the container platform to use FIPS-validated cryptographic mechanisms to protect the integrity of log information.

CAT II

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

CM-5 (3)

CCI-001749

SRG-APP-000131-CTR-000280

The container platform must be built from verified packages.

Prisma Cloud Compute must use up to date packages with each release.

It is important to patch and upgrade the container platform when patches and upgrades are available. More important is to get these patches and upgrades from a known source. To validate the authenticity of any patches and upgrades before installation, the container platform must check that the files are digitally signed by sources approved by the organization.

Software packages become vulnerable over time. Every release of Prisma Cloud Compute is scanned for all known packages and their associated vulnerabilities are identified and remediated before release.

Applicable - Inherently Meets

Review the container platform configuration to verify it has been built from packages that are digitally signed by known and approved sources.

If the container platform was built from packages that are not digitally signed or are from unknown or non-approved sources, this is a finding.

Rebuild the container platform from verified packages that are digitally signed by known and approved sources.

CAT II

https://docs.twistlock.com/docs/government/government/government.html

All 3rd party software included within Prisma Cloud Compute is listed within each release’s prisma-oss-licenses.txt file, located within the release’s tar file.

All vulnerability and compliance findings are publicly posted https://docs.twistlock.com/docs/government/Release_STIG_Findings/release_stig.html

CM-5 (3)

CCI-001749

SRG-APP-000131-CTR-000285

The container platform must verify container images.

Prisma Cloud Compute images must have their associated SHA-256 digest publicly accessible/

The container platform must be capable of validating container images are signed and that the digital signature is from a recognized and approved source approved by the organization. Allowing any container image to be introduced into the registry and instantiated into a container can allow for services to be introduced that are not trusted and may contain malicious code, which introduces unwanted services. These unwanted services can cause harm and security risks to the hosting server, the container platform, other services running within the container platform, and the overall organization.

Container images are distributive is nature. It is critical to have confidence in what comprises an image before initiating as a container within the runtime environment. Trusting an image is a critical component to microservices.

Applicable - Inherently Meets

Review the container platform configuration to determine if container images are verified by enforcing image signing and that the image is signed recognized by an approved source.

If container images are not verified or the signature is not verified as a recognized and approved source, this is a finding.

Pull the Prisma Cloud Compute release tar file from the customer support site. The SHA-256 digest for that release will be posted next to the tar file download. Once the tar is downloaded generate a SHA-256 digest for the file and compare to the release’s published digest. If they do not match this is a finding.

Configure the container platform to verify container images are digitally signed and the signature is from a recognized and approved source.

Contact Palo Alto Networks Customer Support

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/trusted_images.html

Similar to Prisma Cloud Compute’s Trusted Images feature. But this is for the trust of each Prisma Cloud Compute release’s images

CM-5 (6)

CCI-001499

SRG-APP-000133-CTR-000290

The container platform must limit privileges to the container platform registry.

The permissions of the container platform registries must be managed according to the organization’s policies and procedures.

To control what is instantiated within the container platform, it is important to control access to the registry. Without this control, container images can be introduced and instantiated by accident or on container platform startup. Without control of the registry, security measures put in place for the runtime can be bypassed meaning the controls of approval and testing are also bypassed. Only those individuals and roles approved by the organization can have access to the container platform registry.

Not Applicable

Review the container platform registry configuration to determine if the level of access to the registry is controlled through user privileges.

Attempt to perform registry operations to determine if the privileges are enforced.

If the container platform registry is not limited through user privileges or the user privileges are not enforced, this is a finding.

Configure the container platform to use and enforce user privileges when accessing the container platform registry.

CAT II

Prisma Cloud Compute does not control the permissions of a container registry

CM-5 (6)

CCI-001499

SRG-APP-000133-CTR-000295

The container platform must limit privileges to the container platform runtime.

The permissions of the container platform runtime must be managed according to the organization’s policies and procedures.

To control what is instantiated within the container platform, it is important to control access to the runtime. Without this control, container platform specific services and customer services can be introduced without receiving approval and going through proper testing. Only those individuals and roles approved by the organization can have access to the container platform runtime.

Not Applicable

Review the container platform runtime configuration to determine if the level of access to the runtime is controlled through user privileges.

Attempt to perform runtime operations to determine if the privileges are enforced.

If the container platform runtime is not limited through user privileges or the user privileges are not enforced, this is a finding.

Configure the container platform to use and enforce user privileges when accessing the container platform runtime.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/kubernetes_auditing.html

https://docs.twistlock.com/docs/compute_edition/access_control/open_policy_agent.html

Prisma Cloud Compute Kubernetes Auditing and Open Policy Agent features could support this requirement

CM-5 (6)

CCI-001499

SRG-APP-000133-CTR-000300

The container platform must limit privileges to the container platform keystore.

The permissions of the container platform keystore must be managed according to the organization’s policies and procedures.

The container platform keystore is used to store credentials used to build a trust between the container platform and some external source. This trust relationship is authorized by the organization. If a malicious user were to have access to the container platform keystore, two negative scenarios could develop:

1) Keys not approved could be introduced and 2) Approved keys deleted, leading to the introduction of container images from sources that were never approved by the organization.

To thwart this threat, it is important to protect the container platform keystore and give access to only those individuals and roles approved by the organization.

Not Applicable

Review the container platform keystore configuration to determine if the level of access to the keystore is controlled through user privileges.

Attempt to perform keystore operations to determine if the privileges are enforced.

If the container platform keystore is not limited through user privileges or the user privileges are not enforced, this is a finding.

Configure the container platform to use and enforce user privileges when accessing the container platform keystore.

CAT II

Prisma Cloud Compute has a Credential Store, see SRG-APP-000033-CTR-000100 response

CM-5 (6)

CCI-001499

SRG-APP-000133-CTR-000305

Configuration files for the container platform must be protected.

The configuration integrity of the container platform must be ensured.

The secure configuration of the container platform must be protected by disallowing changes to be implemented by non-privileged users. Changes to the container platform can introduce security risks or stability issues and undermine change management procedures. Securing configuration files from non-privileged user modification can be enforced using file ownership and permissions.

Not Applicable

Review the container platform to verify that configuration files cannot be modified by non-privileged users.

If non-privileged users can modify configuration files, this is a finding.

Configure the container platform to only allow configuration modifications by privileged users.

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/cis_benchmarks.html

Prisma Cloud Compute Compliance checks could be used by customers to ensure this check. For example application of the Docker Enterprise 2.x Linux/UNIX STIG, see row #178 and #180 for mandatory policies

CM-5 (6)

CCI-001499

SRG-APP-000133-CTR-000310

Authentication files for the container platform must be protected.

The authentication integrity of the container platform must be ensured.

The secure configuration of the container platform must be protected by disallowing changing to be implemented by non-privileged users. Changes to the container platform can introduce security risks and stability issues and undermine change management procedures. To secure authentication files from non-privileged user modification can be enforced using file ownership and permissions.

Examples of authentication files are keys, certificates, and tokens.

Not Applicable

Review the container platform to verify that authentication files cannot be modified by non-privileged users.

If non-privileged users can modify key and certificate files, this is a finding.

Configure the container platform to only allow authentication file modifications by privileged users.

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/cis_benchmarks.html

Prisma Cloud Compute Compliance checks could be used by customers to ensure this check. For example, Compliance Host check #38 Verify that registry certificate file permissions are set to 444 or more restrictive

CM-7 a

CCI-000381

SRG-APP-000141-CTR-000315

The container platform must be configured with only essential configurations.

The configuration integrity of the container platform must be ensured.

The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed.

Not Applicable

Review the container platform configuration and verify that only those components needed for operation are installed.

If components are installed that are not used for the intended purpose of the organization, this is a finding.

Identify the role the container platform is intended to play in the production environment and remove any components that are not needed or used for the intended purpose.

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/host_scanning.html

Host based compliance scanning can be used by the organization to ensure the configuration of the environment has not changed

CM-7 a

CCI-000381

SRG-APP-000141-CTR-000320

The container platform registry must contain only container images for those capabilities being offered by the container platform.

Images stored within the container registry must only contain images to be ran as containers within the container platform.

Allowing container images to reside within the container platform registry that are not essential to the capabilities being offered by the container platform becomes a potential security risk. By allowing these non-essential container images to exist, the possibility for accidental instantiation exists. The images may be unpatched, not supported, or offer non-approved capabilities. Those images for customer services are considered essential capabilities.

Not Applicable

Review the container platform registry and the container images being stored.

If container images are stored in the registry and are not being used to offer container platform capabilities, this is a finding.

Remove all container images from the container platform registry that are not being used or contain features and functions not supported by the platform.

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/trusted_images.html

Can use Prisma Cloud Compute’s Trusted Images feature to support this requirement

CM-7 b

CCI-000382

SRG-APP-000142-CTR-000325

The container platform runtime must enforce ports, protocols, and services that adhere to the PPSM CAL.

Prisma Cloud Compute communication TCP ports must adhere to the PSSM CAL.

Ports, protocols, and services within the container platform runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.

Prisma Cloud Compute TCP port usage is configurable. Default configuration: TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console - to - Defender communication via mutual TLS v1.2 web socket session

Applicable - Configurable

Review the container platform documentation and deployment configuration to determine which ports and protocols are enabled.

Verify the ports and protocols being used are not prohibited by PPSM CAL in accordance to DoD Instruction 8551.01 Policy and are necessary for the operations and applications.

If any of the ports or protocols is prohibited or not necessary for the operation, this is a finding.

For Kubneretes deployment type kubectl describe pods <twistlock-console-pod—​n <namespace-and verify the MANAGEMENT_PORT_HTTPS, MANAGEMENT_PORT_HTTP & COMMUNICATION_PORT values

If any of the ports do not adhere to the PPSM CAL this is a finding.

Configure the container platform to disable any ports or protocols that are prohibited by the PPSM CAL and not necessary for the operation.

Adjust the TCP port used by Prisma Cloud Compute to adhere to the PPSM CAL.

CAT II

https://docs.twistlock.com/docs/compute_edition/howto/configure_listening_ports.html#overview

Prisma Cloud Compute Runtime Network policy can be used to enforce container port usage. https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_networking.html

CM-7 b

CCI-000382

SRG-APP-000142-CTR-000330

The container platform runtime must enforce the use of ports that are non-privileged.

Prisma Cloud Compute must use TCP ports above 1024

Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container.

Prisma Cloud Compute default TCP ports are 8083 (Console UI and API) and 8084 Console to—Defender communication. To use TCP ports below 1024 the Console would have to be configured to use privileged ports.

Applicable - Configurable

Review the container platform configuration and the containers within the platform by performing the following checks:

1. Verify the container platform is configured to disallow the use of privileged ports by containers. 2. Validate all containers within the container platform are using non-privileged ports. 3. Attempt to instantiate a container image that uses a privileged port.

If the container platform is not configured to disallow the use of privileged ports, this is a finding.

If the container platform has containers using privileged ports, this is a finding.

If the container platform allows containers to be instantiated that use privileged ports, this is a finding.

For Kubneretes deployment type kubectl describe pods <twistlock-console-pod—​n <namespace-and verify the MANAGEMENT_PORT_HTTPS, MANAGEMENT_PORT_HTTP & COMMUNICATION_PORT values

If any of the ports are below 1024 this is a finding

Configure the container platform to disallow the use of privileged ports by containers. Move any containers that are using privileged ports to non-privileged ports.

Adjust the TCP port used by Prisma Cloud Compute to non-privileged ports.

CAT II

https://docs.twistlock.com/docs/compute_edition/howto/configure_listening_ports.html#overview

IA-2

CCI-000764

SRG-APP-000148-CTR-000335

The container platform must uniquely identify and authenticate users.

All Prisma Cloud Compute users must have a unique, individual account.

The container platform requires user accounts to perform container platform tasks. These tasks may pertain to the overall container platform or may be component-specific, thus requiring users to authenticate against those specific components. To ensure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system.

Prisma Cloud Compute does not have a default account. During installation an administrator is created by the installer. This account can be removed once other accounts have been added.

Applicable - Configurable

Review the container platform configuration to determine if users are uniquely identified and authenticated.

If users are not uniquely identified or are not authenticated, this is a finding.

Navigate to Prisma Cloud Compute Manage -Authentication -Users and review that the account are unique for every user. If there are common accounts this is a finding.

Configure the container platform to uniquely identify and authenticate users.

Create accounts for each unique user of Prisma Cloud Compute

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/authentication.html

IA-2

CCI-000764

SRG-APP-000148-CTR-000340

The container platform application program interface (API) must uniquely identify and authenticate users.

All Prisma Cloud Compute users must have a unique, individual account to access the API.

The container platform requires user accounts to perform container platform tasks. These tasks are often performed through the container platform API. Protecting the API from users who are not authorized or authenticated is essential to keep the container platform stable. Protection of platform and application data and enhances the protections put in place for Denial-of Service (DoS) attacks.

Access to the Prisma Cloud Compute API requires authentication and authorization is role based.

Applicable - Inherently Meets

Review the container platform configuration to determine if users are uniquely identified and authenticated before the API is executed.

If users are not uniquely identified or are not authenticated, this is a finding.

Configure the container platform to uniquely identify and authenticate users before container platform API access.

CAT II

https://docs.twistlock.com/docs/compute_edition/api/access_api.html

IA-2

CCI-000764

SRG-APP-000148-CTR-000345

The container platform must uniquely identify and authenticate processes acting on behalf of the users.

Prisma Cloud Compute Console must run as non-root user (uid 2674)

The container platform will instantiate a container image and use the user privileges given to the user used to execute the container. To ensure accountability and prevent unauthenticated access to containers, the user the container is using to execute must be uniquely identified and authenticated to prevent potential misuse and compromise of the system.

Containers not requiring root level permissions should run as a unique user account

Applicable - Configurable

Review the container platform configuration to determine if processes acting on behalf of users are uniquely identified and authenticated.

If processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.

On the node in which the Prisma Cloud Compute Console container is running determine the process owner for “app/server” (ps -aux | grep “/app/server”) if the process is owned by root this is a finding.

Configure the container platform to uniquely identify and authenticate processes acting on behalf of users.

In the root directory of the extracted release tar file, modify the twistlock.cfg file’s line RUN_CONSOLE_AS_ROOT=false

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

CAT II

The Prisma Cloud Compute Console containers can be configured to run as non-root user (uid 2674)

IA-2

CCI-000764

SRG-APP-000148-CTR-000350

The container platform application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.

Prisma Cloud Compute API must require uniquely identifiable user authentication.

The container platform API can be used to perform any task within the platform. Often, the API is used to create tasks that perform some kind of maintenance task and run without user interaction. To guarantee the task is authorized, it is important to authenticate the task. These tasks, even though executed without user intervention, run on behalf of a user and must run with the user’s authorization. If tasks are allowed to be created without authentication, users could bypass authentication and authorization mechanisms put in place for user interfaces. This could lead to users gaining greater access than given to the user putting the container platform into a compromised state.

Not Applicable

Review the container platform API configuration to determine if processes acting on behalf of users are uniquely identified and authenticated.

If processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.

Configure the container platform API to uniquely identify and authenticate processes acting on behalf of users.

CAT II

https://docs.twistlock.com/docs/compute_edition/api/access_api.html

All API endpoints require unique Prisma Cloud Compute authentication

IA-2 (1)

CCI-000765

SRG-APP-000149-CTR-000355

The container platform must use multifactor authentication for network access to privileged accounts.

Authentication to Prisma Cloud Compute must use multi-factor authentication

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased.

Multifactor authentication requires using two or more factors to achieve authentication.

Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric).

A privileged account is defined as an information system account with authorizations of a privileged user.

Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet).

Multi-factor authentication is an added measure to ensure a privileged user account is compromised by an unauthorized user.

Prisma Cloud Compute supports direct x.509 (smartcard) multi-factor authentication.

Other forms of multi-factor authentication can be supported through SAML and OpenID Connect identity providers

Applicable - Configurable

Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to privileged accounts.

If the container platform does not use multifactor authentication for network access to privileged accounts, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users, x.509 users are local accounts. Ensure that the password to these accounts are complex and unknown to the user. If the user can authenticate with username / password this is a finding.

Configure the container platform to use multifactor authentication for network access to privileged accounts.

Ensure the local accounts are configured for x.509 authentication.

SAML and OpenID Connect accounts multi-factor authentication enforcement occurs on the identity provider.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/oidc.html

https://docs.twistlock.com/docs/compute_edition/authentication/saml.html

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

IA-2 (2)

CCI-000766

SRG-APP-000150-CTR-000360

The container platform must use multifactor authentication for network access to non-privileged accounts.

Authentication to Prisma Cloud Compute must use multi-factor authentication

To ensure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.

Multifactor authentication uses two or more factors to achieve authentication.

Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, token); or (iii) Something you are (e.g., biometric).

A non-privileged account is any information system account with authorizations of a non-privileged user.

Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection.

Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.

Multi-factor authentication is an added measure to ensure a user account is compromised by an unauthorized user.

Prisma Cloud Compute supports direct x.509 (smartcard) multi-factor authentication.

Other forms of multi-factor authentication can be supported through SAML and OpenID Connect identity providers

Applicable - Configurable

Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to non-privileged accounts.

If the container platform does not use multifactor authentication for network access to non-privileged accounts, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users, x.509 users are local accounts. Ensure that the password to these accounts are complex and unknown to the user. If the user can authenticate with username / password this is a finding.

Configure the container platform to use multifactor authentication for network access to non-privileged accounts.

Ensure the local accounts are configured for x.509 authentication.

SAML and OpenID Connect accounts multi-factor authentication enforcement occurs on the identity provider.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/oidc.html

https://docs.twistlock.com/docs/compute_edition/authentication/saml.html

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

IA-2 (3)

CCI-000767

SRG-APP-000151-CTR-000365

The container platform must use multifactor authentication for local access to privileged accounts.

Authentication to Prisma Cloud Compute must use multi-factor authentication

To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.

Multifactor authentication is defined as using two or more factors to achieve authentication.

Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric).

A privileged account is defined as an information system account with authorizations of a privileged user.

Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

Not Applicable

Review the container platform configuration to determine if multifactor authentication is used for local access to privileged accounts.

If multifactor authentication for local access to privileged accounts is not being used, this is a finding.

Configure the container platform to use multifactor authentication for local access to privileged accounts.

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

Access to Prisma Cloud Compute Console is network based. There is no local access to the application.

IA-2 (4)

CCI-000768

SRG-APP-000152-CTR-000370

The container platform must use multifactor authentication for local access to non-privileged accounts.

Authentication to Prisma Cloud Compute must use multi-factor authentication

To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, non-privileged users must utilize multi-factor authentication for local access.

Multifactor authentication is defined as using two or more factors to achieve authentication.

Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric).

A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user.

Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

Not Applicable

Review the container platform configuration to determine if multifactor authentication is used for local access to non-privileged accounts.

If multifactor authentication for local access to non-privileged accounts is not being used, this is a finding.

Configure the container platform to use multifactor authentication for local access to non-privileged accounts.

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

Access to Prisma Cloud Compute Console is network based. There is no local access to the application.

IA-2 (5)

CCI-000770

SRG-APP-000153-CTR-000375

The container platform must ensure users are authenticated with an individual authenticator prior to using a group authenticator.

Prisma Cloud Compute must be configured with unique user accounts.

To ensure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated.

Individual accountability mandates that each user be uniquely identified. A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account.

If an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality.

Some applications may not need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.

There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server, which contains publicly releasable information.

Sharing of accounts, for example group accounts, reduces the accountability and integrity of Prisma Cloud Compute

Applicable - Configurable

Review the container platform configuration to determine if the container platform is configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator.

If the container platform is not configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator, this is a finding.

Navigate to Prisma Cloud Compute Console’s - Manage - Authentication users and review the accounts for uniqueness. If there are shared local accounts this is a finding.

Configure the container platform to ensure users are authenticated with an individual authenticator prior to using a group authenticator.

Remove the shared accounts and create an unique user account for every Prisma Cloud Compute user.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/assign_roles.html

Prisma Cloud Compute role assignment based upon group membership (LDAP & SAML) require user authentication. User identity is recorded in all audits

IA-2 (8)

CCI-001941

SRG-APP-000156-CTR-000380

The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

Communication to Prisma Cloud Compute’s UI and API must use TLS v1.2 or higher.

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.

Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant.

Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.

Protection of users’ interaction with Prisma Cloud Compute must use protocol protections to ensure the confidentiality and integrity of the session in accordance with NIST SP800-52 guidance.

Applicable - Inherently Meets

Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

If the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding.

Configure the container platform to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

IA-2 (9)

CCI-001942

SRG-APP-000157-CTR-000385

The container platform must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.

Communication to Prisma Cloud Compute’s UI and API must use TLS v1.2 or higher.

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.

A non-privileged account is any operating system account with authorizations of a non-privileged user.

Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

Protection of users’ interaction with Prisma Cloud Compute must use protocol protections to ensure the confidentiality and integrity of the session in accordance with NIST SP800-52 guidance.

Applicable - Inherently Meets

Review the container platform configuration to determine if the container platform is configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts.

If the container platform is not configured to provide replay-resistant authentication mechanisms for network access to non-privileged accounts, this is a finding.

Configure the container platform to provide replay-resistant authentication mechanisms for network access to non-privileged accounts.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

IA-3

CCI-000778

SRG-APP-000158-CTR-000390

The container platform must uniquely identify all network-connected nodes before establishing any connection.

Prisma Cloud Compute Console to Defender communication must be initiated by the Defender and must establish a mutually authenticated TLS v1.2 web socket session.

A container platform usually consists of multiple nodes. It is important for these nodes to be uniquely identified before a connection is allowed. Without identifying the nodes, unidentified or unknown nodes may be introduced, thereby facilitating malicious activity.

The Prisma Cloud Compute Console can only communicate with the Defenders it has deployed. The Defender can only communicate with the Console that deployed it. Mutual TLS authentication.

Applicable - Inherently Meets

Review the container platform configuration to determine if the container platform uniquely identifies all nodes before establishing a connection.

If the container platform is not configured to uniquely identify all nodes before establishing the connection, this is a finding.

Configure the container platform to uniquely identify all nodes before establishing the connection.

CAT II

Console — to— Defender communication via mutual TLS v1.2 web socket session

IA-4 e

CCI-000795

SRG-APP-000163-CTR-000395

The container platform must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

Inactive Prisma Cloud Compute accounts must be disabled after 35 days of inactivity

Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.

Applications need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.

To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.

Inactive Prisma Cloud Compute accounts could be susceptible to compromise thus allowing an attacker to gain access to the application. Recommend using 3rd party identity providers (e.g. LDAP, x.509, SAML, OAuth) to support more robust identity management practices.

Applicable - Does Not Meet

Review the container platform configuration to determine if the container platform is configured to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

If identifiers are not disabled after 35 days of inactivity, this is a finding.

Configure the container platform to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

CAT II

If Prisma Cloud Compute requires local accounts integration with organizations identity management policies and processes.

Recommend using external identity providers.

https://docs.twistlock.com/docs/compute_edition/authentication/authentication.html

If local accounts are used it is recommended to review the need for an account on a period basis.

IA-5 (1) (a)

CCI-000205

SRG-APP-000164-CTR-000400

The container platform must enforce a minimum 15-character password length.

Prisma Cloud Compute local accounts must enforce strong password requirements.

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Prisma Cloud Compute local accounts can be configured to require at least 12 character password lengths

Applicable - Configurable

Review the container platform configuration to determine if the container platform enforces a minimum 15-character password length.

If the container platform does not enforce a 15-character password length, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, if the “Require strong passwords for local accounts” is set to “off” this is a finding.

Configure the container platform to enforce a minimum 15-character password length.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, and set “Require strong passwords for local accounts” to “on”

CAT II

Recommend using external identity providers that provide that enforce the minimum password length of 15 characters

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

Minimum password length is 12 characters not the required 15.

IA-5 (1) (e)

CCI-000200

SRG-APP-000165-CTR-000405

The container platform must prohibit password reuse for a minimum of 10 generations.

Prisma Cloud Compute users’ passwords must not be reused

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

To meet password policy requirements, passwords need to be changed at specific policy-based intervals.

If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the result is a password that is not changed as per policy requirements.

The references for this check are: NIST SP 800-53 :: IA-5 (1) (e) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) CNSS 1253

Prisma Cloud Compute does not remember a local user’s previous passwords. Recommend using 3rd party identity providers (e.g. LDAP, x.509, SAML, OAuth) to support more robust identity management practices.

Applicable - Does Not Meet

Review the container platform configuration to determine if it prohibits password reuse for a minimum of five generations.

If the container platform does not prohibit password reuse for a minimum of five generations, this is a finding.

Configure the container platform to prohibit password reuse for a minimum of five generations.

CAT II

Recommend using external identity providers that prohibit password reuse.

https://docs.twistlock.com/docs/compute_edition/authentication/authentication.html

IA-5 (1) (a)

CCI-000192

SRG-APP-000166-CTR-000410

The container platform must enforce password complexity by requiring that at least one uppercase character be used.

Prisma Cloud Compute local accounts must enforce password complexity with upper case requirements.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.

Prisma Cloud Compute local accounts can be configured to require at least one upper case character.

Applicable - Configurable

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one uppercase character be used.

If the container platform does not enforce password complexity by requiring that at least one uppercase character be used, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, if the “Require strong passwords for local accounts” is set to “off” this is a finding.

Configure the container platform to enforce password complexity by requiring that at least one uppercase character be used.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, and set “Require strong passwords for local accounts” to “on”

CAT II

Enforces one uppercase character for local account password.

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

IA-5 (1) (a)

CCI-000193

SRG-APP-000167-CTR-000415

The container platform must enforce password complexity by requiring that at least one lowercase character be used.

Prisma Cloud Compute local accounts must enforce password complexity with lower case requirements.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Prisma Cloud Compute local accounts can be configured to require at least one lower case character

Applicable - Configurable

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one lowercase character be used.

If the container platform does not enforce password complexity by requiring that at least one lowercase character be used, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, if the “Require strong passwords for local accounts” is set to “off” this is a finding.

Configure the container platform to enforce password complexity by requiring that at least one lowercase character be used.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, and set “Require strong passwords for local accounts” to “on”

CAT II

Enforces one lower character for local account password.

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

IA-5 (1) (a)

CCI-000194

SRG-APP-000168-CTR-000420

The container platform must enforce password complexity by requiring that at least one numeric character be used.

Prisma Cloud Compute local accounts must enforce password complexity with numeric character requirements.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Prisma Cloud Compute local accounts can be configured to require at least one numeric character

Applicable - Configurable

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one numeric character be used.

If the container platform does not enforce password complexity by requiring that at least one numeric character be used, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, if the “Require strong passwords for local accounts” is set to “off” this is a finding.

Configure the container platform to enforce password complexity by requiring that at least one numeric character be used.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, and set “Require strong passwords for local accounts” to “on”

CAT II

Enforces one numeric character for local account password.

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

IA-5 (1) (a)

CCI-001619

SRG-APP-000169-CTR-000425

The container platform must enforce password complexity by requiring that at least one special character be used.

Prisma Cloud Compute local accounts must enforce password complexity with a special character requirements.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Special characters are those characters that are not alphanumeric. Examples include ~ ! @ # $ % ^ *.

Prisma Cloud Compute local accounts can be configured to require at least one special character

Applicable - Configurable

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one special character be used.

If the container platform does not enforce password complexity by requiring that at least one special character be used, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, if the “Require strong passwords for local accounts” is set to “off” this is a finding.

Configure the container platform to enforce password complexity by requiring that at least one special character be used.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon, and set “Require strong passwords for local accounts” to “on”

CAT II

Enforces one special character for local account password.

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

List of special characters: ~!@#$%^&*()-_=+|[{}];:'\",<.>/?"

IA-5 (1) (b)

CCI-000195

SRG-APP-000170-CTR-000430

The container platform must require the change of at least 15 of the total number of characters when passwords are changed.

Prisma Cloud Compute local accounts must enforce password complexity with each password change requiring at least 15 new characters requirements.

If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.

The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.

Prisma Cloud Compute local accounts can be configured to require at least 12 character password lengths

Applicable - Does Not Meet

Review the container platform configuration to determine if it requires the change of at least 15 of the total number of characters when passwords are changed.

If the container platform does not require the change of at least 15 of the total number of characters when passwords are changed, this is a finding.

Configure the container platform to require the change of at least 15 of the total number of characters when passwords are changed.

CAT II

Recommend using external identity providers that provide that enforce the change of at 15 least characters every password change.

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

Capability does not exist for local accounts

IA-5 (1) (c)

CCI-000196

SRG-APP-000171-CTR-000435

For container platform using password authentication, the application must store only cryptographic representations of passwords.

Prisma Cloud Compute local accounts must be stored using HMAC hash functions.

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication.

Examples of situations where a user ID and password might be used include:

- When the user does not use a CAC and is not a current DoD employee, member of the military, or DoD contractor.

- When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied.

- When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection.

If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user’s password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security.

Verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows:

H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt))

In the above, "n" is a cryptographically-strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value.

Another method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key.

This requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort.

Protection of Prisma Cloud Compute local account passwords stored at rest must be protected to ensure compromise of the database’s password table is minimized.

Applicable - Inherently Meets

Review the container platform configuration to determine if it using password authentication and stores only cryptographic representations of the passwords.

If the container platform is using password authentication and does not store only cryptographic representations of passwords, this is a finding.

Configure the container platform to store only cryptographic representations of passwords if passwords are being used for authentication.

CAT II

Local account passwords are hashed with hmac256

IA-5 (1) (c)

CCI-000197

SRG-APP-000172-CTR-000440

For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.

Communication to Prisma Cloud Compute’s UI and API to perform local user account password functions must use TLS v1.2 or higher.

Passwords need to be protected on entry, in transmission, during authentication, and when stored. If compromised at any of these security points, a nefarious user can use the password along with stolen user account information to gain access or to escalate privileges. The container platform may require account authentication during container platform tasks and before accessing container platform components, e.g. runtime, registry, and keystore.

During any user authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.

Protection of users’ interaction with Prisma Cloud Compute to perform authentication password functions must use protocol protections to ensure the confidentiality and integrity of the session in accordance with NIST SP800-52 guidance.

Applicable - Inherently Meets

Review the documentation and configuration to determine if the container platform enforces the required FIPS-validated encrypt passwords when they are transmitted.

If the container platform is not configured to meet this requirement, this is a finding.

Configure the container platform to transmit only encrypted FIPS-validated SHA-2 or later representations of passwords.

CAT I

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. Recommend using external identity providers that use FIPS-140 validated cryptographic modules.

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

IA-5 (1) (d)

CCI-000198

SRG-APP-000173-CTR-000445

The container platform must enforce 24 hours (one day) as the minimum password lifetime.

Prisma Cloud Compute local accounts must enforce 24 hour minimum password lifetime.

Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement.

Restricting this setting limits the user’s ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization’s policy regarding password reuse.

Minimum password lifetime reduces the chances of brute password reuse.

Applicable - Does Not Meet

Review the container platform configuration to determine if it enforces 24 hours/1 day as the minimum password lifetime.

If the container platform does not enforce 24 hours/1 day as the minimum password lifetime, this is a finding.

Configure the container platform to enforce 24 hours/1 day as the minimum password lifetime.

CAT II

Recommend using external identity providers that provide that enforce minimum 24 hour password lifetimes

Capability does not exist for local accounts

IA-5 (1) (d)

CCI-000199

SRG-APP-000174-CTR-000450

The container platform must enforce a 60-day maximum password lifetime restriction.

Prisma Cloud Compute local accounts must enforce 60 day maximum password lifetime.

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals.

One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.

This requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.

Prisma Cloud Compute local password should be changed after 60 days to ensure password compromises are minimized.

Applicable - Does Not Meet

Review the container platform configuration to determine if it enforces a 60-day maximum password lifetime restriction.

If the container platform does not enforce a 60-day maximum password lifetime restriction, this is a finding.

Configure the container platform to enforce a 60-day maximum password lifetime restriction.

CAT II

Recommend using external identity providers that provide that enforce 60-day maximum password lifetime

Capability does not exist for local accounts

IA-5 (2) (c)

CCI-000187

SRG-APP-000177-CTR-000465

The container platform must map the authenticated identity to the individual user or group account for PKI-based authentication.

Prisma Cloud Compute Console UI and API access via x.509 authentication must map a local user’s account name to the x.509 certificate’s subjectName or SubjectAlternativeName’s PrincipalName value.

The container platform and its components may require authentication before use. When the authentication is PKI-based, the container platform or component must map the certificate to a user account. If the certificate is not mapped to a user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.

x.509 identities must be based upon the client authentication certificate’s unique identifiers to ensure the smart card user is mapped to the appropriate Prisma Cloud Compute local account

Applicable - Configurable

Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoD PKI infrastructure requirements.

If the container platform is not configured to meet this requirement, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -System Certificate : show Advanced certificate configuration. In section 2 “Console Authentication” the issuing CA(s) of the end users’ certificates must be within this field, and the local user account’s name must match the user’s x.509 certificate’s subjectName or the subject alternative name’s PrincipalName value, otherwise this is a finding.

Configure the container platform to utilize the DoD Enterprise PKI infrastructure.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -System Certificate : show Advanced certificate configuration. In section 2 “Console Authentication” load the end users’ certificates’ issuing CA(s) certificates within this field. Create a local user account where the local user account name matches the user’s x.509 certificate’s subjetName or subject alternative name’s PrincipalName value.

CAT II

PKI-based authentication can also be performed by an external identity provider.

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

A random password needs to be created for the local account and does not have to be known to the user.

IA-6

CCI-000206

SRG-APP-000178-CTR-000470

The container platform must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

Prisma Cloud Compute password input must be obfuscated.

To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the container platform and its components, e.g., runtime, registry, and keystore, must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.

Obfuscation of user-provided information when typed is a method used in addressing this risk.

Displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.

Unobscured input of username / password can compromise the confidentiality and integrity of a user’s Prisma Cloud Compute authentication credentials

Applicable - Inherently Meets

Review container platform documentation and configuration to determine if any interfaces that are provided for authentication purposes display the user’s password when it is typed into the data entry field.

If authentication information is not obfuscated when entered, this is a finding.

Configure the container platform to obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

CAT II

Password input mechanisms obscure the password.

AU-7 a

CCI-001876

SRG-APP-000181-CTR-000485

The container platform must provide an audit reduction capability that supports on-demand reporting requirements.

Prisma Cloud Compute Alerts must be configured to reduce the volume and alert types sent to role stake holders.

The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization’s ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Prisma Cloud Compute Alerts can be configure to send alert types to various stake holders via their preferred method of notification.

Applicable - Configurable

Review the container platform configuration to determine if the container platform is configured to provide an audit reduction capability that supports on-demand reporting requirements.

If the container platform is not configured to support on-demand reporting requirements, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Alerts -Manage if no Alert Providers are configured this is a finding.

Configure the container platform to support on-demand reporting requirements.

Navigate to Prisma Cloud Compute Console’s Manage -Alerts -Manage and configure specific audit alert providers.

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

Alert providers allow specific types to be routed to the appropriate stake holders’ notification mechanisms.

MA-4 c

CCI-000877

SRG-APP-000185-CTR-000490

The container platform must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

Prisma Cloud Compute API must be access via TLS v1.2 protocol.

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Prisma Cloud Compute non-local maintenance can be performed via the API. Communications with the API must be secured by TLS v1.2.

Applicable - Configurable

Review the container platform configuration to determine if the container platform is configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

If the container platform is not configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions, this is a finding.

For Kubneretes deployment type kubectl describe pods <twistlock-console-pod—​n <namespace-and verify the MANAGEMENT_PORT_HTTP: value is NULL

For docker type docker inspect <twistlock-console-container-and verify MANAGEMENT_PORT_HTTP value is NULL

If Prisma Cloud Compute Console’s container MANAGEMENT_PORT_HTTP variable has a port value, this is a finding.

.

Configure the deployment of Prisma Cloud Compute to only use the MANAGEMENT_PORT_HTTPS. This will ensure communication to the API is protected by TLS v1.2

CAT II

https://docs.twistlock.com/docs/compute_edition/howto/configure_listening_ports.html

https://docs.twistlock.com/docs/compute_edition/api/access_api.html

All API endpoints require authentication

SC-2

CCI-001082

SRG-APP-000211-CTR-000530

The container platform must separate user functionality (including user interface services) from information system management functionality.

Prisma Cloud Compute user roles must be assigned

Separating user functionality from management functionality is a requirement for all the components within the container platform. Without the separation, users may have access to management functions that can degrade the container platform and the services being offered and can offer a method to bypass testing and validation of functions before introduced into a production environment.

The separation should be enforced by each component within the container platform.

User role assignment ensures that the user has the rights to perform their assigned tasks and no higher rights are granted.

Applicable - Configurable

Review the container platform configuration to determine if management functionality is separated from user functionality.

Validate that the separation is also implemented within the components by trying to execute management functions for each component as a user.

If the container platform is not configured to separate management and user functionality or if component management and user functionality are not separated, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users review role assigned to users if role assignment is incorrect this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Group review role assigned to groups if role assignment is incorrect this is a finding.

Configure the container platform and its components to separate management and user functionality.

Adjust user and group assignments to organizational policies

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/assign_roles.html

SC-23

CCI-001184

SRG-APP-000219-CTR-000550

The container platform must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 security requirements for cryptographic modules.

Prisma Cloud Compute must use a FIPS-validated 140-2 or 140-3 cryptographic module.

The container platform is responsible for pulling images from trusted sources and placing those images into its registry. To protect the transmission of images, the container platform must use FIPS-validated 140-2 or 140-3 cryptographic modules. This added protection defends against main-in-the-middle attacks where malicious code could be added to an image during transmission.

Use of NIST FIPS validated cryptographic modules ensures that the cryptographic module meets the U.S. Government’s mandated standards.

Applicable - Does Not Meet

Review the container platform configuration to determine if FIPS-validated 140-2 or 140-3 cryptographic modules are being used to protect container images during transmission.

If FIPS-validated 140-2 or 140-3 cryptographic modules are not being use, this is a finding.

Configure the container platform to use FIPS-validated 140-2 or 140-3 cryptographic modules to protect container images during transmission.

CAT I

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

SC-24

CCI-001190

SRG-APP-000225-CTR-000570

The container platform runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

Prisma Cloud Compute must fail to a secure state.

The container platform offers services for container image orchestration and services for users. If any of these services were to fail into an insecure state, security measures for user and data separation and image instantiation could become absent. In addition, audit log protections could be relaxed allowing for investigation of what occurred could be lost. To protect services and data, it is important for the container platform to fail to a secure state if the container platform registry initialization fails, shutdown fails, or aborts fail.

Prisma Cloud Compute is a distributed system with a Console providing command and control to Defenders. If the communication is lost the system must fail to a secure state in which policies are still enforced to ensure the integrity of the Defenders and their assigned functions.

Applicable - Inherently Meets

Review documentation and configuration to determine if the container platform runtime fails to a secure state if system initialization fails, shutdown fails, or aborts fail.

If the container platform runtime cannot be configured to fail securely, this is a finding.

Configure the container platform runtime to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

CAT II

The Prisma Cloud Compute Defender is explicitly designed to be survivable even in the case of a prolonged (multi-hour) disconnection from Console. Defender caches all policy locally, executes actions based on this cached policy, and spools logs locally until connectivity is restored. Defender will automatically, continuously work to re-establish connectivity and, once accomplished, will automatically re-sync policy and send spooled events.

SC-24

CCI-001665

SRG-APP-000226-CTR-000575

The container platform must preserve any information necessary to determine the cause of the disruption or failure.

Prisma Cloud Compute Console and Defenders must capture and retain operational event audits.

When a failure occurs within the container platform, preserving the state of the container platform and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.

Integrity of audit logs enables the organization to determine the reason for a disruption or failure of a service.

Applicable - Inherently Meets

Review the container platform configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

If the information is not preserved, this is a finding.

Configure the container platform to preserve information necessary to determine the cause of the disruption or failure.

CAT II

Organization should implement periodic log collections from Prisma Cloud Compute Console and Defenders. Enabling syslog integration as another method of capturing audit events.

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

https://docs.twistlock.com/docs/compute_edition/audit/log_rotation.html

SC-3

CCI-001084

SRG-APP-000233-CTR-000585

The container platform runtime must isolate security functions from non-security functions.

Prisma Cloud Compute Roles and Collections must be used to separate security and non-security functions

The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups.

Separation of user roles and the associated data for their role, through the use of Collections, will minimize the risk of improper isolation of security functions and data.

Applicable - Configurable

Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups.

If security-related functions are not separate, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Users review role assigned to users if role and/or the Collection assignment is incorrect this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Group review role assigned to groups if role and/or Collection assignment is incorrect this is a finding.

Configure the container platform runtime to isolate security functions from non-security functions.

Adjust user, group and Collection assignments to organizational policies

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/assign_roles.html

https://docs.twistlock.com/docs/compute_edition/configure/collections.html

AC-2 (2)

CCI-001682

SRG-APP-000234-CTR-000590

The container platform must never automatically remove or disable emergency accounts.

Prisma Cloud Compute local emergency accounts must never be removed or disabled.

Emergency accounts are administrator accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.

Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account that is created for use by vendors or system maintainers.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

The organization can create Prisma Cloud Compute local emergency accounts. These local account should never be disabled or removed without explicit instructions

Applicable - Inherently Meets

Review the container platform to determine if emergency accounts are automatically removed or disabled.

If emergency accounts are automatically removed or disabled, this is a finding.

Configure the container platform to never remove or disable emergency accounts.

CAT II

Prisma Cloud Compute does not automatically delete accounts.

https://docs.twistlock.com/docs/troubleshooting/troubleshooting/console/forgot_console_passwd.html

Local administrative account password can be recovered in an emergency situation.

SC-4

CCI-001090

SRG-APP-000243-CTR-000595

The container platform must prohibit containers from accessing privileged resources.

Prisma Cloud Compute Compliance Container Policy: ID = 54: Do not use privileged containers” ID = 5525: Restrict container from acquiring additional privileges must be enabled

Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given.

When access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources.

Examples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr.

Prisma Cloud Compute Compliance policies must be enabled to ensure running containers must not access privileged resources.

Applicable - Configurable

Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources.

If the container platform does not block containers requesting host system privileged resources, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed. If the applied rules do not have compliance checks:

ID = 54 Do not use privileged container ID = 5525: Restrict container from acquiring additional privileges are not configured

set to Block this is a finding

Configure the container platform to block instantiation of containers requesting access to host system-privileged resources.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed and set all applied rules compliance checks:

ID = 54, Do not use privileged containers ID = 5525: Restrict container from acquiring additional

to Block

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

SC-4

CCI-001090

SRG-APP-000243-CTR-000600

The container platform must prevent unauthorized and unintended information transfer via shared system resources.

Prisma Cloud Compute Compliance policies: 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 Must be enabled

The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users.

Prisma Cloud Compute Compliance policies must be enabled to ensure running containers must not transfer data via system resources.

Applicable - Configurable

Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process.

If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed. If the applied rules do not have compliance checks:

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

set to Block this is a finding

Deploy a container platform capable of effectively protecting the resources of one process or user from unauthorized access by another user or process. Configure the container platform to effectively protect the resources of one process or user from unauthorized access by another user or process. The container security solution should help the user understand where the code in the environment was deployed from, and provide controls that prevent deployment from untrusted sources or registries.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed and set all applied rules compliance checks:

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

to Block

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

SC-5 (1)

CCI-001094

SRG-APP-000246-CTR-000605

The container platform must restrict individuals' ability to launch organizationally defined denial-of-service (DoS) attacks against other information systems.

Prisma Cloud Compute Compliance policies: ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately Must be enabled

The container platform will offer services to users and these services share resources available on the hosting system. To share the resources in a manner that does not exhaust or over utilize resources, it is necessary for the container platform to have mechanisms that allow developers to size there containers to provide minimum and maximum amounts. If there is no mechanism to specify limits, container services can cause DoS by over utilization.

Prisma Cloud Compute Compliance policies must be enabled to ensure running containers do not over subscribe system resources.

Applicable - Configurable

Review the container platform implementation and security documentation and components settings to determine if the information system restricts the ability of users or systems to launch organization-defined DoS attacks against other information systems or networks from the container platform.

If the container platform is not configured to restrict this ability, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed. If the applied rules do not have compliance checks:

ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately

set to Block this is a finding

Configure the container platform to restrict the ability of users or other systems to launch DoS attacks from the container platform components by setting resource quotas on resources such as memory, storage, and CPU utilization.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed set all applied rules compliance checks:

ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately

to Block

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

Multiple compliance policies can be created. The policy scope will determine which rule is applied to which image/container. Rule processing is based upon the resource matching the first rule.

SI-11 a

CCI-001312

SRG-APP-000266-CTR-000625

The container platform must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.

Prisma Cloud Compute must not write sensitive data to event logs.

The container platform is responsible for offering services to users. These services could be across diverse user groups and data types. To protect information about the container platform, services, users, and data, it is important during error message generation to offer enough information to diagnose the error, but not reveal information that needs to be protected.

The determination of what is sensitive data varies from organization to organization. The organization must ensure the recipients for the event log information have a need to know and the log is sanitized based upon the audience

Applicable - Inherently Meets

Review documentation and logs to determine if the container platform writes sensitive information such as passwords or private keys into the logs and administrative messages.

If the container platform writes sensitive or potentially harmful information into the logs and administrative messages, this is a finding.

Configure the container platform to not write sensitive information into the logs and administrative messages.

CAT II

The organization must review the Prisma Cloud Compute logs to determine if the the log contains sensitive data to their organization.

No sensitive data (i.e. user passwords) is captured in the audit logs.

AU-9 (3)

CCI-001496

SRG-APP-000290-CTR-000670

The container platform must use cryptographic mechanisms to protect the integrity of audit tools.

Prisma Cloud Compute must use cryptographic mechanisims to protect the integrity of audit tools

Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

It is common for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.

To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Not Applicable

Review the container platform configuration to determine if the integrity of the audit tools is protected using cryptographic mechanisms.

If audit tools are not protected through cryptographic mechanisms, this is a finding.

Configure the container platform to use cryptographic mechanisms to protect the integrity of audit tools.

CAT II

Audit data rendered within Prisma Cloud Compute is json formatted data returned via API calls. Audit data collected by audit tools can not modify the audit logs within the platform.

AC-2 (4)

CCI-001683

SRG-APP-000291-CTR-000675

The container platform must notify system administrators and ISSO when accounts are created.

Prisma Cloud Compute syslog integration must be configured.

Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Sending notification of account creation events to the system administrator and ISSO is one method for mitigating this risk.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

The organization’s ISSO must be informed if Prisma Cloud Compute account creations.

Applicable - Configurable

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are created.

If system administrators and ISSO are not notified, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging if syslog or stdout is not enabled this is a finding

Configure the container platform to notify system administrators and ISSO when accounts are created.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging and enable syslog and/or stdout and configuration the organization’s log collection tools to route account creation events to ISSO

CAT II

All account creation events are logged and can be viewed within the Console’s -Manage -View Logs -History interface

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

To ensure the account creation audited event is sent the ISSO, Prisma Cloud Compute should be integrated with the organizations SIEM solution.

AC-2 (4)

CCI-001684

SRG-APP-000292-CTR-000680

The container platform must notify system administrators and ISSO when accounts are modified.

Prisma Cloud Compute syslog integration must be configured.

When application accounts are modified, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account modification events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

The organization’s ISSO must be informed if Prisma Cloud Compute account modifications.

Applicable - Configurable

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are modified.

If system administrators and ISSO are not notified, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging if syslog or stdout is not enabled this is a finding

Configure the container platform to notify system administrators and ISSO when accounts are modified.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging and enable syslog and/or stdout and configuration the organization’s log collection tools to route account creation events to ISSO

CAT II

All account modification events are logged and can be viewed within the Console’s -Manage -View Logs -History interface

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

To ensure the account creation audited event is sent the ISSO, Prisma Cloud Compute should be integrated with the organizations SIEM solution.

AC-2 (4)

CCI-001685

SRG-APP-000293-CTR-000685

The container platform must notify system administrators and ISSO for account disabling actions.

When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Not Applicable

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are disabled.

If system administrators and ISSO are not notified, this is a finding.

Configure the container platform to notify system administrators and ISSO when accounts are disabled.

CAT II

Local accounts cannot be disabled, they must be deleted

AC-2 (4)

CCI-001686

SRG-APP-000294-CTR-000690

The container platform must notify system administrators and ISSO for account removal actions.

Prisma Cloud Compute syslog integration must be configured.

When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying users or for identifying the application processes themselves. Sending notification of account removal events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time, and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

The organization’s ISSO must be informed if Prisma Cloud Compute account deletion.

Applicable - Configurable

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are removed.

If system administrators and ISSO are not notified, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging if syslog or stdout is not enabled this is a finding

Configure the container platform to notify system administrators and ISSO when accounts are removed.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging and enable syslog and/or stdout and configuration the organization’s log collection tools to route account creation events to ISSO

CAT II

All account removal events are logged and can be viewed within the Console’s -Manage -View Logs -History interface

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

To ensure the account creation audited event is sent the ISSO, Prisma Cloud Compute should be integrated with the organizations SIEM solution.

AC-12 (1)

CCI-002364

SRG-APP-000297-CTR-000705

Access to the container platform must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions.

User must click the user icon in the top right corner of the UI and select “Log out”

Access to the container platform will occur through web and terminal sessions. Any web interfaces must conform to application and web security requirements. Terminal access to the container platform and its components must provide a logout facility that terminates the connection to the component or the platform.

User logon function must effectively remove all user access to the current Prisma Cloud Compute session. The user must re-authenticate to create a new authenticated session.

Applicable - Inherently Meets

Review documentation and configuration settings to determine if the container platform displays a logout message.

If the container platform does not display a logout message, this is a finding.

Configure the container platform components to display an explicit logout message to users.

CAT III

Clicking “Log out” from the UI will clear the users session token and will return the users to the login screen.

AC-2 (10)

CCI-002142

SRG-APP-000317-CTR-000735

The container platform must terminate shared/group account credentials when members leave the group.

Shared/group accounts must be managed by an external identity provider (e.g. LDAP, SAML, etc.)

If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.

The use of shared/group credentials should be strictly monitored as to who has access to the accounts and their organizational responsibilities

Not Applicable

Determine if the container platform is configured to terminate shared/group account credentials when members leave the group.

If the container platform does not terminated shared/group account credentials when members leave the group, this is a finding.

Configure the container platform to terminate shared/group account credentials when members leave the group.

CAT II

Use external identity providers to enforce organizational policies associated with shared/group accounts.

Account sharing and group accounts is the responsibility of the organization.

AC-2 (11)

CCI-002145

SRG-APP-000318-CTR-000740

The container platform must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

The enforcement of account usage conditions must be managed by an external identity provider (e.g. LDAP, SAML, etc.)

Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during business hours can indicate hostile activity if it occurs during off hours.

Depending on mission needs and conditions, account usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the application must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time).

Restricting when Prisma Cloud Compute can operated can mitigate the effects of a compromised account.

Not Applicable

Determine if the container platform is configured to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

If the container platform does not enforce organization-defined circumstances and/or usage conditions for organization-defined accounts, this is a finding.

Configure the container platform to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

CAT II

Use external identity providers to enforce organizational policies of when accounts can authenticate to Prisma Cloud Compute.

Account time restrictions is the responsibility of the organization.

AC-2 (4)

CCI-002130

SRG-APP-000319-CTR-000745

The container platform must automatically audit account-enabling actions.

All Prisma Cloud Compute account creation events must be audited

Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Automatically auditing account enabling actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Prisma Cloud Compute account creation is an enabling action.

Applicable - Inherently Meets

Determine if the container platform is configured to automatically audit account-enabling actions.

If the container platform is not configured to automatically audit account-enabling actions, this is a finding.

Configure the container platform to automatically audit account-enabling actions.

CAT II

Prisma Cloud Compute local accounts cannot be disabled/enabled they can only be created/deleted

AC-2 (4)

CCI-002132

SRG-APP-000320-CTR-000750

The container platform must notify system administrator and ISSO of account enabling actions.

Prisma Cloud Compute syslog integration must be configured.

Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Sending notification of account enabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals so they can investigate the event.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

The organization’s ISSO must be informed if Prisma Cloud Compute account creations. An account creation is an enabling action.

Applicable - Configurable

Determine if the container platform is configured to notify system administrator and ISSO of account enabling actions.

If the container platform is not configured to notify system administrator and ISSO of account enabling actions, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging if syslog or stdout is not enabled this is a finding

Configure the container platform to notify system administrator and ISSO of account enabling actions.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging and enable syslog and/or stdout and configuration the organization’s log collection tools to route account creation events to ISSO

CAT II

All account creation events are logged and can be viewed within the Console’s -Manage -View Logs -History interface

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

To ensure the account creation audited event is sent the ISSO, Prisma Cloud Compute should be integrated with the organizations SIEM solution.

AC-6 (10)

CCI-002235

SRG-APP-000340-CTR-000770

The container platform must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Users of Prisma Cloud Compute must be assigned roles based upon their responsibilities.

Controlling what users can perform privileged functions prevents unauthorized users from performing tasks that may expose data or degrade the container platform. When users are not segregated into privileged and non-privileged users, unauthorized individuals may perform tasks such as deploying containers, pulling images into the register, and modify keys in the keystore. These actions can introduce malicious containers and cause denial-of-service (DoS) attacks and undermine the container platform integrity. The enforcement may take place at the container platform and can be implemented within each container platform component (e.g. runtime, registry, and keystore).

Excessive Prisma Cloud Compute role permissions could allow an attacker to create policy that would adversely affect the operation of the environment.

Applicable - Configurable

Review documentation to obtain the definition of the container platform functionality considered privileged in the context of the information system in question.

Review the container platform security configuration and/or other means used to protect privileged functionality from unauthorized use.

If the configuration does not protect all of the actions defined as privileged, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage -Authentication -Users and Group if a user or groups is assigned a role that has the ability to set vulnerability, compliance and/or runtime policy in which they do not have the organizational authority this is a finding

Configure the container platform to security to protect all privileged functionality. Assigning roles that limit what actions a particular user can perform are the most common means of meeting this requirement.

Assign users and groups to their appropriate roles based upon the organizational structure.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/user_roles.html

AC-6 (8)

CCI-002233

SRG-APP-000342-CTR-000775

Container images instantiated by the container platform must execute using least privileges.

Prisma Cloud Compute Compliance Container Policy: ID = 54: Do not use privileged containers ID = 599: Container is running as root ID = 41 Image should be created with a non-root user must be enabled

Containers running within the container platform must execute as non-privileged. When a container can execute as a privileged container, the privileged container is also a privileged user within the hosting system, and the hosting system becomes a major security risk. It is important for the container platform runtime to validate the container user and disallow instantiation if the container is trying to execute with more privileges than required, as a privileged user, or is trying to perform a privilege escalation.

When privileged access is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged execution.

Examples of privileged users are root, admin, and default service accounts for the container platform.

Prisma Cloud Compute Compliance policies must be enabled to ensure running containers run as least privileged.

Applicable - Configurable

Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to execute with more privileges than required or with privileged permissions.

If the container platform does not block containers requesting privileged permissions, privilege escalation, or allows containers to have more privileges than required, this is a finding.

If Prisma Cloud Compute does not have Compliance policies ID = 54: Do not use privileged containers ID = 599: Container is running as root ID = 41 Image should be created with a non-root user are not configured to Block this is a finding

Configure the container platform to block instantiation with no more privileges than necessary.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Containers and Images : Deployed and review the policies to ensure the Container rule ID = 54: Do not use privileged containers ID = 599: Container is running as root ID = 41 Image should be created with a non-root rules are set to Block

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

Multiple compliance policies can be created. The policy scope will determine which rule is applied to which image/container. Rule processing is based upon the resource matching the first rule.

AC-6 (9)

CCI-002234

SRG-APP-000343-CTR-000780

The container platform must audit the execution of privileged functions.

Prisma Cloud Compute Kubernetes auditing must be enabled

Privileged functions within the container platform can be component specific or can envelope the entire container platform. Because of the nature of the commands, it is important to understand what command was executed for either investigation of an incident or for debugging/error correction; therefore, privileged function execution must be audited.

The Kubernetes auditing system records the activities of users, administrators, and other components, that have affected the cluster. Prisma Cloud can ingest, analyze, and alert on security-relevant events.

Applicable - Configurable

Review container platform documentation and log configuration to verify the application server logs privileged activity.

If the container platform is not configured to log privileged activity, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Access -Kubernetes and is Kubernetes auditing is set to “disabled” this is a finding

Configure the container platform to log privileged activity.

Set Prisma Cloud Compute Console’s -Defend -Access -Kubernetes and is Kubernetes auditing is set to “enabled.”

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/kubernetes_auditing.html

The STIG should define some default Kubernetes audit policies

AC-7 b

CCI-002238

SRG-APP-000345-CTR-000785

The container platform must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

Prisma Cloud Compute users must be authenticated by an external identity provider (e.g. LDAP, SAML, x.509, OAuth)

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Prisma Cloud Compute must employ protections to protect against brute force attacks on user accounts

Applicable - Does Not Meet

Determine if the container platform is configured to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

If the container platform is not configured to lock the account, this is a finding.

Configure the container platform to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

CAT II

Use external identity providers to enforce unsuccessful logon attempts and enforce policy

This policy cannot be enforced on local Prisma Cloud Compute accounts.

AU-4

CCI-001849

SRG-APP-000357-CTR-000800

The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.

The node that runs Prisma Cloud Compute containers must have sufficient disk space.

In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity.

The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.

Insufficient disk space of the compute nodes will impact the performance and effectiveness of Prisma Cloud Compute

Applicable - Inherently Meets

Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements.

If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding.

Configure the container platform to allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.

CAT II

https://docs.twistlock.com/docs/compute_edition/install/system_requirements.html

Prisma Cloud Compute system requirements specify the amount of disk space required for the Console and Defender containers.

AU-4 (1)

CCI-001851

SRG-APP-000358-CTR-000805

Audit records must be stored at a secondary location.

Prisma Cloud Compute syslog integration or log retrieval process must be implemented

Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading.

Retention of audit record external to Prisma Cloud Compute will ensure the integrity of the audit events

Applicable - Configurable

Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself.

The information system may demonstrate this capability using a log management application, system configuration, or other means.

If logs are not being off-loaded, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging if syslog or stdout is not enabled this is a finding

Configure the container platform to off-load the logs to a remote log or management server.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts -Logging and enable syslog and/or stdout and configuration the organization’s log collection for external archival

CAT II

Syslog integration is a configurable method to ensure audit events are externally collected.

Audit logs can be downloaded from the UI and pulled via the API to retain for archival purposes. Recommend organization develops a standard operating procedure to perform this task

https://cdn.twistlock.com/docs/api/20.12/twistlock_api.html#logs

AU-5 (1)

CCI-001855

SRG-APP-000359-CTR-000810

The container platform must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

The node that runs Prisma Cloud Compute containers must have sufficient disk space.

If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion.

The nodes in which Prisma Cloud Compute runs upon must be monitored for the consumption and availability of disk space

Not Applicable

Review the container platform configuration to determine if it is configured to provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

If the container platform is not configured to provide an immediate real-time alert, this is a finding.

Configure the container platform to provide an immediate real-time alert to the SA and ISSO when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

CAT II

https://docs.twistlock.com/docs/compute_edition/install/system_requirements.html

Prisma Cloud Compute runs as containers on virtualization nodes. It is the responsibly to the organization to ensure sufficient storage is available for the operation of Prisma Cloud Compute

AU-5 (2)

CCI-001858

SRG-APP-000360-CTR-000815

The container platform must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.

Prisma Cloud Compute Alerts must be implemented.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.

Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).

Prisma Cloud lets the organization surface critical policy breaches by sending alerts to any number of channels. Alerts ensure that significant events are put in front of the right audience at the right time.

Applicable - Configurable

Review the container platform configuration to determine if it is configured to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.

If the container platform is not configured to provide an immediate real-time alert, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage - Alerts, if an Alert provider does not exist for the required alerts for the SA and ISSO roles this is a finding

Configure the container platform to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.

Navigate to Prisma Cloud Compute Console’s Manage - Alerts, create Alert providers for the required alerts for the SA and ISSO roles

CAT II

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

AU-8 b

CCI-001890

SRG-APP-000374-CTR-000865

All audit records must use UTC or GMT time stamps.

Prisma Cloud Compute audit log time stamps must be in Coordinated Universal Time (UTC)

The container platform and its components must generate audit records using either Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) time stamps or local time that offset from UTC. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform.

Time stamps generated by the container platform and its components must include date and time.

Time synchronization of all system and audited events within the container platform is critical for the availability and integrity of the system.

Applicable - Inherently Meets

Review the container platform documentation and configuration files to determine if time stamps for log records can be mapped to UTC or GMT or local time that offsets from UTC.

If the time stamp cannot be mapped to UTC or GMT, this is a finding.

Generate an audit event (e.g. create new user account) and review the associated audit in the Console’s Manage -View Logs -History if the corresponding audit does not contain the UTC time of the event this is a finding.

Configure the container platform to use UTC or GMT or local time that offset from UTC based time stamps for log records.

Ensure the system clocks of the nodes in which Prisma Cloud Compute run upon are properly configured.

CAT II

Prisma Cloud Compute Console and Defender containers use the compute node’s system clock. The organization is responsible for the correct time synchronization configuration

Audit events are in RFC-5424 compliant format using the compute node’s system clock.

AU-8 b

CCI-001889

SRG-APP-000375-CTR-000870

The container platform must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.

Prisma Cloud Compute audit log time stamps must contain seconds.

To properly investigate an event, it is important to have enough granularity within the time stamps to determine the chronological order of the audited events. Without this granularity, events may be interpreted out of proper sequence, thus hobbling the investigation or causing the investigation to come to inaccurate conclusions.

Time stamps generated by the container platform include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.

Time fidelity of all system and audited events within the container platform is critical for the availability and integrity of the system.

Applicable - Inherently Meets

Review the container platform documentation and configuration files to determine if time stamps for log records meet a granularity of one second.

If the time stamp cannot generate to a one-second granularity, this is a finding.

Generate an audit event (e.g. create new user account) and review the associated audit in the Console’s Manage -View Logs -History if the corresponding audit does not contain a seconds value this is a finding.

Configure the container platform to use time stamps for log records that can meet a granularity of one second.

Ensure the system clocks of the nodes in which Prisma Cloud Compute run upon are properly configured.

CAT II

Prisma Cloud Compute audit events are time stamped DATE:HH:MM:SEC:MSEC

Audit events are in RFC-5424 compliant format.

CM-11 (2)

CCI-001812

SRG-APP-000378-CTR-000880

The container platform must prohibit the installation of patches and updates without explicit privileged status.

Prisma Cloud Compute upgrade must be performed by a user with delegated rights within the orchestration engine (e.g. Kubernetes).

Controlling access to those users and roles responsible for patching and updating the container platform reduces the risk of untested or potentially malicious software from being installed within the platform. This access may be separate from the access required to install container images into the registry and those access requirements required to instantiate an image into a service. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Every Primsa Cloud Compute release includes the latest security updates. It is the responsibility of the organization’s container environment administrator to deploy the newer version of Prisma Cloud Compute to mitigate the vulnerabilities in the previous release.

Applicable - Inherently Meets

Review the container platform configuration to determine if patches and updates can only be installed through accounts with privileged status.

Attempt to install a patch or upgrade using a non-privileged user account.

If patches or updates can be installed using a non-privileged account or the container platform is not configured to stop the installation using a non-privileged account, this is a finding.

Configure the container platform to only allow patch installation and upgrades using privileged accounts.

CAT II

https://docs.twistlock.com/docs/compute_edition/upgrade/upgrade_process_self_hosted.html

The deployment of the Defender daemonSet must be performed by the containerized environment’s administrator

CM-11 (2)

CCI-001812

SRG-APP-000378-CTR-000885

The container platform runtime must prohibit the instantiation of container images without explicit privileged status.

Container platform must explicitly authorize administrators the ability to instantiate containers

Controlling access to those users and roles responsible for container image instantiation reduces the risk of untested or potentially malicious containers from being executed within the platform and on the hosting system. This access may be separate from the access required to install container images into the registry and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Not Applicable

Review the container platform runtime configuration to determine if only accounts given specific container instantiation privileges can execute the container image instantiation process.

Attempt to instantiate a container image using an account that does not have the proper privileges to execute the process.

If container images can be instantiated using an account without the proper privileges, this is a finding.

Configure the container platform runtime to prohibit the instantiation of container images without explicit container image instantiation privileges given to users.

CAT I

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_hosts.html

https://docs.twistlock.com/docs/compute_edition/access_control/open_policy_agent.html

This is the responsibility for the container orchestration

Host runtime policies can be enabled to monitor the behavior of user activity on the host including docker commands, for example ‘docker run -it image’

Admission Control can we use to alert or block the creation of a Pod based upon the rules.

CM-11 (2)

CCI-001812

SRG-APP-000378-CTR-000890

The container platform registry must prohibit installation or modification of container images without explicit privileged status.

Container platform must explicitly authorize administrators the ability push images to the organization’s registry

Controlling access to those users and roles that perform container platform registry functions reduces the risk of untested or potentially malicious containers from being introduced into the platform. This access may be separate from the access required to instantiate container images into services and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Not Applicable

Review container platform registry security settings with respect to non-administrative users' ability to create, alter, or replace container images.

If any such permissions exist and are not documented and approved, this is a finding.

Document and obtain approval for any non-administrative users who require the ability to create, alter, or replace container images within the container platform registry. Implement the approved permissions. Revoke any unapproved permissions.

CAT II

Prisma Cloud Compute does not have a container registry feature.

CM-5 (1)

CCI-001813

SRG-APP-000380-CTR-000900

The container platform must enforce access restrictions for container platform configuration changes.

Container platform must explicitly authorize administrators ability to change the container platform’s configuration

Configuration changes cause the container platform to change the way it operates. These changes can be used to improve the system with added features or performance, but these configuration changes can also be used to introduce malicious features and degrade performance. To control the configuration changes made to the container platform, it is important that only authorized users are allowed, through container platform enforcement, to make configuration changes.

Not Applicable

Review documentation and configuration settings to determine if the container platform enforces access restrictions associated with changes to container platform components configuration.

If the container platform does not enforce such access restrictions, this is a finding.

Configure the container platform to enforce access restrictions associated with changes to the container platform components configuration.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/kubernetes_auditing.html

Prisma Cloud Compute does not enforce permissions of the orchestration engine. Kubernetes Auditing can be used to monitor kubernetes administrator behaviors

CM-5 (1)

CCI-001814

SRG-APP-000381-CTR-000905

The container platform must enforce access restrictions and support auditing of the enforcement actions.

Container platform must explicitly audit and enforce administrative actions

Auditing the enforcement of access restrictions against changes to the container platform helps identify attacks and provides forensic data for investigation for after-the-fact actions. Attempts to change configurations, components, or data maintained by a component (e.g., images in the registry, running containers in the runtime, or keys in the keystore) must be audited.

Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Not Applicable

Review container platform documentation and logs to determine if enforcement actions used to restrict access associated with changes to the container platform are logged.

If these actions are not logged, this is a finding.

Configure the container platform to log the enforcement actions used to restrict access associated with changes.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/kubernetes_auditing.html

Prisma Cloud Compute Kubernetes auditing can be used to identify access audits but cannot enforce restrictions within the orchestration engine

CM-7 (1) (b)

CCI-001762

SRG-APP-000383-CTR-000910

All non-essential, unnecessary, and unsecure DoD ports, protocols, and services must be disabled in the container platform.

The container platform must not use unsecured DoD ports.

To properly offer services to the user and to orchestrate containers, the container platform may offer services that use ports and protocols that best fit those services. The container platform, when offering the services, must only offer the services on ports and protocols authorized by the DoD.

To validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of the container platform and disable functions, ports, protocols, and services deemed to be unneeded or non-secure.

Not Applicable

Review the container platform configuration to determine if services or capabilities presently on the information system are required for operational or mission needs.

If additional services or capabilities are present on the system, this is a finding.

Configure the container platform to only utilize secure ports and protocols required for operation that have been accepted for use as per the Ports, Protocols, and Services Category Assignments List (CAL) from DISA (PPSM).

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_hosts.html#networking

Prisma Cloud Compute Host Runtime Network can be used to monitor what TCP port a container platform host is using

CM-7 (2)

CCI-001764

SRG-APP-000384-CTR-000915

The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.

Prisma Cloud Compute Host vulnerability, compliance and runtime policies must be created in accordance to the organization’s containerization requirements.

The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization’s mission.

Policies must be applied to the underlying container platform to ensure it is operating within the authorization boundary

Applicable - Configurable

Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components.

If no such no restrictions are in place, this is not a finding.

Identify any components the organization requires to be disabled or removed and configure the container platform according to that policy.

If the container platform components are not disabled or removed according to the organization’s policy, this is a finding.

Review all Prisma Cloud Compute’s -Defend -Vulnerability | Compliance | Runtime | WAAS | CNNF | Access policies to ensure the organization’s containerization policies are properly enforced, otherwise this is a finding

Configure the container platform so that any platform components that are not required in order to meet the organization’s mission are disabled or removed. Document the components that must be disabled or removed for reference.

Adjust Prisma Cloud Compute Defend policies in accordance to the organization’s policies.

CAT II

https://docs.twistlock.com/docs/compute_edition/vulnerability_management/vuln_management_rules.html

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_overview.html

https://docs.twistlock.com/docs/compute_edition/waas/deploy_waas.html

https://docs.twistlock.com/docs/compute_edition/firewalls/cnnf_self_hosted.html

https://docs.twistlock.com/docs/compute_edition/access_control/access_control.html

This could be a really big answer, this is the whole purpose of Prisma Cloud Compute.

CM-7 (5) (b)

CCI-001774

SRG-APP-000386-CTR-000920

The container platform registry must employ a deny-all, permit-by-exception (whitelist) policy to allow only authorized container images in the container platform.

The container platform registry must only allow explicitly trusted images to be push/pulled

Controlling the sources where container images can be pulled from allows the organization to define what software can be run within the container platform. Allowing any container image to be introduced and instantiated within the container platform may introduce malicious code and vulnerabilities to the platform and the hosting system.

The container platform registry must deny all container images except for those signed by organizational-approved sources.

Not Applicable

Review documentation and configuration settings to identify if the container platform whitelisting specifies which container platform components are allowed to execute.

Check for the existence of policy settings or policy files that can be configured to restrict container platform component execution. Demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction.

Some methods for restricting execution include but are not limited to the use of custom capabilities built into the application or Software Restriction Policies, Application Security Manager, or Role-Based Access Controls (RBAC).

If container platform whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.

Configure the container platform to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.

CAT II

Prisma Cloud Compute does not have a container registry feature.

IA-11

CCI-002038

SRG-APP-000389-CTR-000925

The container platform must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.

Prisma Cloud Compute’sToken validity period must be configured.

Controlling user access is paramount in securing the container platform. During a user’s access to the container platform, events may occur that change the user’s access and which require reauthentication. For instance, if the capability to change security roles or escalate privileges is implemented, it is critical the user reauthenticate.

In addition to the reauthentication requirements associated with change in security roles or privilege escalation, organizations may require reauthentication of individuals in other situations, including (but not limited to) the following circumstances:

(i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically.

Within the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

The lifetime of the session tokens for an user’s interaction with Prisma Cloud Compute should have a lifetime that conforms the organization’s policy

Applicable - Configurable

Review documentation and configuration to determine if the container platform requires a user to reauthenticate when organization-defined circumstances or situations are met.

If the container platform does not meet this requirement, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon -Token validity period is in compliance with the organization’s policy, otherwise this is a finding.

Configure the container platform to require a user to reauthenticate when organization-defined circumstances or situations are met.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -Logon -Token validity period is in accordance to the organization’s policy

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

For security, users are redirected to the login page when an inactive Console session exceeds a configurable timeout. By default, the timeout is 30 minutes. This configurable timeout value also controls the validity period for API tokens. For Console web interface tokens: If a user explicitly logs out, the claim to access Console is revoked.

If Console is restarted, all users are automatically logged out.

IA-11

CCI-002039

SRG-APP-000390-CTR-000930

The container platform must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication.

Prisma Cloud Compute Defender must re-establish communication to the Console via mutual TLS v1.2 web socket session.

The container platform may require external devices be used to fully orchestrate the services needed for users. Examples would be storage or external servers. Without reauthentication, unidentified or unknown devices may be introduced; thereby facilitating malicious activity.

The container platform must be capable of allowing the organization to set requirements associated with device reauthentication. Examples are:

Organizations may require reauthentication of devices, including (but not limited to), the following other situations:

(i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) After a fixed period of time; or (v) Periodically.

For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.

When the secure web socket session between the Prisma Cloud Compute Console and Defenders the Defender will continually attempt to re-establish the session. The Console can be configured to remove a Defender that has not established a connection is a specified period of days.

Applicable - Configurable

Review documentation and configuration to determine if the container platform requires devices to reauthenticate when organization-defined circumstances or situations require reauthentication.

If the container platform does not require a device to reauthenticate, this is a finding.

Navigate to Prisma Cloud Compute’s - Manage - Defenders - Manage - Defenders - Advanced Settings, if the Automatically remove disconnected Defenders after (days) is not configured to the organization’s policies this is a finding

Configure the container platform to require devices to reauthenticate when organization-defined circumstances or situations require reauthentication.

Navigate to Prisma Cloud Compute’s - Manage - Defenders - Manage - Defenders - Advanced Settings, set the Automatically remove disconnected Defenders after (days) value to the organization’s defined period

CAT II

https://docs.twistlock.com/docs/compute_edition/technology_overviews/defender_architecture.html#defender-console-communication

The Defender will automatically and continually attempt to re-establish the mutually authenticated secure web socket session.

IA-2 (12)

CCI-001953

SRG-APP-000391-CTR-000935

The container platform must be configured to use multi-factor authentication for user authentication.

Prisma Cloud Compute must be configured to require local user accounts use x.509 multi-factor authentication.

Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. To standardize and reduce the risks of unauthorized access, the use of multifactor token-based credentials is the preferred method.

DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.

User access to Prisma Cloud Compute must use multi-factor (x.509 based) authentication when possible.

Applicable - Configurable

Review documentation and configuration to ensure the container platform is configured to use an approved DoD multifactor token (CAC) when accessing platform via user interfaces.

If multifactor authentication is not configured, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication the issuing CA certificate(s) of the x.509 certificates used for authentication are listed in Console CA certificate(s) field. If the issuing CA certificate(s) are not listed this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -User and local accounts associated to the user’s x.509 certificate the User name must match the certificate’s subjectName or SubjectAlternativeName’s PrinicipalName value. If the user uses the user name / password to authenticate this is a finding

Configure the container platform to accept standard DoD multifactor token-based credentials when users interface with the platform.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication put the issuing CA certificate(s) of the x.509 certificates used for authentication are listed into Console CA certificate(s) field.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -User and local accounts associated to the user’s x.509 certificate the User name must match the certificate’s subjectName or SubjectAlternativeName’s PrinicipalName value.

CAT II

External identity providers can be a method of enforcing multi-factor authentication.

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

x.509 authentication can be performed by the Prisma Cloud Compute Console or by an identity provider that enforces x.509 based authentication.

IA-5 (1) (f)

CCI-002041

SRG-APP-000397-CTR-000955

The container platform must allow the use of a temporary password for system logons with an immediate change to a permanent password.

Prisma Cloud Compute local account temporary password authentication must follow the organizational standard operating procedure

Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial login.

Temporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts, which allow the users to log in, yet forces them to change the password once they have successfully authenticated.

Local account users must be instructed to perform a password change upon connecting to the Console with a temporary password.

Applicable - Does Not Meet

Review the container platform configuration to determine if the platform is configured to allow the use of a temporary password for system logons with an immediate change to a permanent password.

If the container platform is not configured to allow temporary passwords with immediate change to a permanent password, this is a finding.

Configure the container platform to allow the use of a temporary password for system logons with an immediate change to a permanent password.

CAT II

If local accounts are used an organizational standard operating procedure should be developed for when a local user’s password is changed to a temporary password.

Enforcing temporary password change is not a Prisma Cloud Compute capability.

IA-5 (13)

CCI-002007

SRG-APP-000400-CTR-000960

The container platform must prohibit the use of cached authenticators after an organization-defined time period.

Prisma Cloud Compute’s Token validity period must be configured.

If cached authentication information is out of date, the validity of the authentication information may be questionable.

The Prisma Cloud Compute session token is generated after the user’s successful authentication. The lifetime of the session tokens for an user’s interaction with Prisma Cloud Compute should have a lifetime that conforms the organization’s policy

Applicable - Configurable

Review the container platform configuration to determine if the platform is configured to prohibit the use of cached authenticators after an organization-defined time period.

If the container platform is not configured to prohibit the use of cached authenticators after an organization-defined time period, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -Logon -Token validity period is in configured with the organization’s policy. Authenticate to the Console and allow an inactive session to elapse pass the configured time. If the user still has access to the Console after the token’s validity period this is a finding.

Configure the container platform to prohibit the use of cached authenticators after an organization-defined time period.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -Logon -Token validity period is in accordance to the organization’s policy

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/logon_settings.html

IA-5 (2) (d)

CCI-001991

SRG-APP-000401-CTR-000965

The container platform, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

Prisma Cloud Compute certificate revocation checking must be disabled when access to users’ authentication certificate’s CRL and OCSP endpoints are not accessible.

The potential of allowing access to users who are no longer authorized (have revoked certificates) increases unless a local cache of revocation data is configured.

Prisma Cloud Compute Console will perform x.509 CRL and OCSP revocation checks as part of the certificate validation process.

Applicable - Configurable

Review the container platform configuration.

If the container platform is not implemented to use a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication the Certificate revocation : Enable certificate revocation checking = off, this is a finding.

Configure the container platform to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

Configure Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication the Certificate revocation : Enable certificate revocation checking = on.

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

OCSP and CRL validation checks are performed when enabled and based upon certificate’s extensions.

IA-8 (1)

CCI-002009

SRG-APP-000402-CTR-000970

The container platform must accept Personal Identity Verification (PIV) credentials from other federal agencies.

Prisma Cloud Compute must be configured to require local user accounts use PIV (x.509) multi-factor authentication.

Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. It is essential to accept PIV credentials from other federal agencies and eliminate the possibility of access being denied to authorized users.

PIV credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.

x.509 authentication should allow client authentication certificates issued by other issuing CAs (e.g. Federal Agencies)

Applicable - Configurable

Review the documentation and configuration to determine if the container platform accepts PIV credentials from other federal agencies.

If the container platform does not accept other federal agency PIV credentials, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication the issuing CA certificate(s) of the HSPD-12 client authentication using x.509 certificates are listed in Console CA certificate(s) field. If the issuing CA certificate(s) are not listed this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -Authentication -User and local accounts associated to the user’s x.509 certificate the User name must match the certificate’s subjectName or SubjectAlternativeName’s PrinicipalName value. If the user uses the user name / password to authenticate this is a finding

Configure the container platform to accept PIV credentials from other federal agencies.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -System Certificates -Advanced Configuration (unhide) -Console authentication put the issuing CA certificate(s) of the HSPD-12 client authentication using x.509 certificates are listed in Console CA certificate(s) field.

Configure to Prisma Cloud Compute Console’s Manage -Authentication -User and local accounts associated to the user’s x.509 certificate the User name must match the certificate’s subjectName or SubjectAlternativeName’s PrinicipalName value.

CAT II

https://docs.twistlock.com/docs/compute_edition/configure/authenticate_console_with_certs.html

PIV x.509 client authentication is supported.

MA-4 (1) (a)

CCI-002884

SRG-APP-000409-CTR-000990

The container platform must audit non-local maintenance and diagnostic sessions' organization-defined audit events associated with non-local maintenance.

Prisma Cloud Compute must be configured for forensic data collection.

To fully investigate an attack, it is important to understand the event and those events taking place during the same time period. Often, non-local administrative access and diagnostic sessions are not logged. These events are seen as only administrative functions and not worthy of being audited, but these events are important in any investigation and are a major tool for assessing and investigating attacks.

Forensic data consists of additional supplemental runtime events that complement the data (audits) already captured by Prisma Cloud’s runtime sensors. It provides additional context when trying to root cause an incident.

Applicable - Configurable

Review the container platform to verify if the platform is auditing non-local maintenance and diagnostic sessions' organization-defined audit events.

If the container platform is not auditing non-local maintenance and diagnostic sessions' organization-defined audit events, this is a finding.

Navigate to Prisma Cloud Compute Console’s Manage -System -Forensics : Forensics data collection = disabled is a finding

Configure the container platform to audit non-local maintenance and diagnostic sessions' organization-defined audit events.

Configure to Prisma Cloud Compute Console’s Manage -System -Forensics : Forensics data collection = enabled

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/incident_explorer.html#_forensics

Prisma Cloud Compute Forensics is a data recorder to enable event investigations.

MA-4 (6)

CCI-002890

SRG-APP-000411-CTR-000995

Container platform applications and Application Program Interfaces (API) used for nonlocal maintenance sessions must use FIPS-validated keyed-hash message authentication code (HMAC) to protect the integrity of nonlocal maintenance and diagnostic communications.

Non-local maintenance sessions via the Prisma Cloud Compute API must occur over a TLS v1.2+ protected channel.

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified, and therefore cannot be relied on to provide confidentiality or integrity, and DoD data may be compromised.

Nonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.

Currently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2 validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules.

Separate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSHv2, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement. The SSHv2 protocol suite must be mandated in the product because it includes layer 7 protocols such as SCP and SFTP that can be used for secure file transfers.

Use of NIST FIPS validated HMAC algorithms to ensure data integrity within the TLS v1.2 session.

Applicable - Does Not Meet

Validate that container platform applications and APIs used for nonlocal maintenance sessions are using FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.

If the sessions are not using FIPS-validated HMAC, this is a finding.

Configure the container platform applications and APIs used for nonlocal maintenance sessions to use FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

MA-4 (6)

CCI-003123

SRG-APP-000412-CTR-001000

The container platform must configure web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

Prisma Cloud Compute UI access must occur over a TLS v1.2+ protected channel using the AES cipher block algorithm.

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Nonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.

Use of NIST FIPS validated cipher block algorithms ensures the protection of the data transferred over the network

Applicable - Does Not Meet

Validate the container platform web management tools and Application Program Interfaces (API) are configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

If the web management tools and API are not configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms, this is a finding.

Configure the container platform web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. Note encryption algorithms are AES_256

RA-5 (5)

CCI-001067

SRG-APP-000414-CTR-001010

Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities.

Prisma Cloud Compute Defender containers must run as root.

In certain situations, the nature of the vulnerability scanning may be more intrusive, or the container platform component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.

The vulnerability scanning application must utilize privileged access authorization for the scanning account.

Prisma Cloud Compute Defenders perform the vulnerability scanning function. The Defender container must run as root and not privileged

Applicable - Configurable

Validate that scanning applications have privileged access to container platform components, containers, and container images to properly perform vulnerability scans.

If privileged access is not given to the scanning application, this is a finding.

When deploying the Defender via daemonSet deployment ensure the setting ‘Run Defenders as privileged’ = on, and the Defender containers were deployed using the daemonSet.yaml in which the securityContext - privileged = sure this is a finding

Configure the vulnerability scanning application to have privileged access to the container platform components, containers, and container images.

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.

CAT II

https://docs.twistlock.com/docs/compute_edition/technology_overviews/defender_architecture.html

Prisma Cloud Compute Defender architecture requires specific system privileges (root user required) to perform its functions.

SC-13

CCI-002450

SRG-APP-000416-CTR-001015

The container platform must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Prisma Cloud Compute must use NSA-approved cryptography

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data and images. The container platform must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Use of NSA-apporved encryption algorithms ensures the protection of the data transferred over the network

Applicable - Does Not Meet

Review documentation to verify that the container platform is using NSA-approved cryptography to protect classified data and applications.

If the container platform is not using NSA-approved cryptography for classified data and applications, this is a finding.

Configure the container platform to utilize NSA-approved cryptography to protect classified information.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Prisma Cloud Compute uses the Golang’s crypto library which is not a NSA approved cryptographic module. Note AES_256 encryption is implemented

SC-28 (1)

CCI-002476

SRG-APP-000429-CTR-001060

The container platform keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform.

Prisma Cloud Compute Credential Store must implement encryption for the storage of credential

Container platform keystore is used for container deployments for persistent storage of all its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any unauthorized disclosure. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information.

The storage of secret keys must be secured at rest to ensure unintended disclosure

Applicable - Inherently Meets

Review container platform keystore documentation and configuration to verify encryption levels meet the information sensitivity level.

If the container platform keystore encryption configuration does not meet system requirements, this is a finding.

Configure the container platform keystore encryption to maintain the confidentiality and integrity of information for applicable sensitivity level.

CAT II

https://docs.twistlock.com/docs/compute_edition/authentication/credentials_store.html

Prisma Cloud manages all credentials in a central encrypted store.

SC-39

CCI-002530

SRG-APP-000431-CTR-001065

The container platform runtime must maintain separate execution domains for each container by assigning each container a separate address space.

Prisma Cloud Compute must run within a define/separate namespace (e.g. Twistlock)

Container namespace access is limited upon runtime execution. Each container is a distinct process so that communication between containers is performed in a manner controlled through security policies that limits the communication so one container cannot modify another container. Different groups of containers with different security needs should be deployed in separate namespaces as a first level of isolation.

Namespaces are a key boundary for network policies, orchestrator access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users.

Prisma Cloud Compute containers running within a separate and exclusive namespace will inherit the namespace’s security features

Applicable - Configurable

Review container platform runtime documentation and configuration is maintaining a separate execution domain for each executing process. Different groups of applications, and services with different security needs, should be deployed in separate namespaces as a first level of isolation.

If container platform runtime is not configured to execute processes in separate domains and namespaces, this is a finding.

If namespaces use defaults, this is a finding.

Inspect Kubernetes namespace in which Prisma Cloud Compute is deployed, if non-Prism Cloud Compute pods and resources are in the same namespace this is a finding

Deploy a container platform runtime capable of maintaining a separate execution domain and namespace for each executing process. Create a namespace for each containers, defining them as logical groups.

Deploy the Prisma Cloud Compute Console and Defender containers within a distinct namespace

CAT II

https://docs.twistlock.com/docs/compute_edition/install/install_kubernetes.html

SC-5

CCI-002385

SRG-APP-000435-CTR-001070

The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.

Prisma Cloud Compute Container, Image and Host compliance policies must be configured

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

This requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU).

Processes are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names.

The same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly.

Consistent application of policy can minimized the effects of a Denial of Service attack.

Applicable - Configurable

Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU.

If the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Container and Images the rule “Default - alert on critical and high” is enabled

Navigate to Prisma Cloud Compute Console’s -Defend -Compliance -Hosts the rule “Default - alert on critical and high” is enabled

If these policies are not enabled and/or note scoped to all resources this is a finding

Configure the container platform to protect against or limit the effects of all types of DoS attacks by employing defined security safeguards. Safeguards such as resource limits on memory, storage, and CPU can be used.

Enable and scope Prisma Cloud Compute Console’s -Defend -Compliance -Container and Images the rule “Default - alert on critical and high”

Enable and scope Prisma Cloud Compute Console’s -Defend -Compliance -Hosts the rule “Default - alert on critical and high”

CAT II

https://docs.twistlock.com/docs/compute_edition/compliance/manage_compliance.html

See line #178 and #180 for required compliance policies

SC-8 (2)

CCI-002420

SRG-APP-000441-CTR-001090

The container platform must maintain the confidentiality and integrity of information during preparation for transmission.

Prisma Cloud Compute Console to Defender communications is a mutual-TLS authenticated secure web socket session.

Information may be unintentionally or maliciously disclosed or modified during preparation for transmission within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When transmitting data, the container platform components need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.

The communications between the Prisma Cloud Compute Console and Defender(s) must ensure the confidentiality and integrity of the information to be transported to ensure the integrity and performance of the solution. The data within the Console and Defender containers is within a root-only permission file system location.

Applicable - Inherently Meets

Review the documentation and deployed configuration to determine if the container platform maintains the confidentiality and integrity of information during preparation before transmission.

If the confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during preparation before transmission, this is a finding.

Configure the container platform to maintain the confidentiality and integrity of information using mechanisms such as TLS, TLS VPNs, or IPsec during preparation for transmission.

CAT II

https://docs.twistlock.com/docs/compute_edition/technology_overviews/defender_architecture.html#defender-console-communication

Runtime protect might be a better fit if the goal is the provide this control to containers running within the environment and not just Prisma Cloud Compute containers - covered in SRG-APP-000447-CTR-001100

SC-8 (2)

CCI-002422

SRG-APP-000442-CTR-001095

The container platform must maintain the confidentiality and integrity of information during reception.

Prisma Cloud Compute Console to Defender communications is a mutual-TLS authenticated secure web socket session.

Information either can be unintentionally or maliciously disclosed or modified during reception for reception within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When receiving data, the container platform components need to leverage protection mechanisms, such as TLS, TLS VPNs, or IPsec.

The communications between the Prisma Cloud Compute Console and Defender(s) must ensure the confidentiality and integrity of the information during transport to ensure the integrity and performance of the solution.

Applicable - Inherently Meets

Review documentation and configuration settings to determine if the container platform maintains the confidentiality and integrity of information during reception.

If confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during reception, this is a finding.

Configure the container platform to maintain the confidentiality and integrity using mechanisms such as TLS, TLS VPNs, or IPsec during reception.

CAT II

https://docs.twistlock.com/docs/compute_edition/technology_overviews/defender_architecture.html#defender-console-communication

SI-10 (3)

CCI-002754

SRG-APP-000447-CTR-001100

The container platform must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

Prisma Cloud Compute Runtime Defense must be enabled

Software or code parameters typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata.

This requirement guards against adverse or unintended system behavior caused by invalid inputs, where container platform components responses to the invalid input may be disruptive or cause the container image runtime to fail into an unsafe state.

The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.

Prisma Cloud Compute’s Runtime defense is the set of features that provide both predictive and threat based active protection for running containers. 

Applicable - Configurable

Review the configuration to determine if the container platform behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

If the container platform does not meet this requirement, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime and if Enable automatic runtime learning is set to off and/or the Default - alert on suspicious runtime behavior rule is disables and/or not scoped to all this is a finding

Configure the container platform behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime and set Enable automatic runtime learning to on and enable the Default - alert on suspicious runtime behavior rule and scope to all

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_overview.html

Automatic runtime learning will model the runtime behaviors (process, filesystem and network) of a container and automatically associate the observed behaviors to the corresponding image. After this process completes (1 hour) any container starting based upon the image will be monitored for the learned “allowed” behaviors. Any process, filesystem call or network behaviors that have not been identified can generate an alert, prevent the action from occurring or terminate the running container

SI-16

CCI-002824

SRG-APP-000450-CTR-001105

The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution.

Prisma Cloud Compute Runtime Defense must be enabled

The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime.

Security safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container.

Prisma Cloud Compute’s Runtime defense is the set of features that provide both predictive and threat based active protection for running containers. 

Applicable - Configurable

Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution.

If safeguards are not in place, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime and if Enable automatic runtime learning is set to off and/or the Default - alert on suspicious runtime behavior rule is disables and/or not scoped to all this is a finding

Configure the container platform to have safeguards in place to protect the system memory and CPU from resource depletion and unauthorized code execution.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime and set Enable automatic runtime learning to on and enable the Default - alert on suspicious runtime behavior rule and scope to all

CAT II

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_processes.html

SI-2 (6)

CCI-002617

SRG-APP-000454-CTR-001110

The container platform must remove old components after updated versions have been installed.

Prisma Cloud Compute must be running the latest release

Previous versions of container platform components that are not removed from the container platform after updates have been installed may be exploited by adversaries by causing older components to execute which contain vulnerabilities. When these components are deleted, the likelihood of this happening is removed.

Prisma Cloud Compute releases are distributed as docker images. Each release updates or removes components as needed based upon the vulnerabilities associated with the component or the functional need of the component.

Applicable - Configurable

Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version.

If organization-defined images do not contain the latest approved vendor software image version, this is a finding.

Review container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed.

If organization-defined images are not removed after updated versions have been installed, this is a finding.

Review container platform runtime documentation and configuration to determine if organization-define images are executing latest image version from the container platform registry.

If container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.

Navigate to the Prisma Cloud Compute Console, in the top right corner click the bell icon. If there is a newer version this is a finding

Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.

Upgrade the Prisma Cloud Compute Console and Defenders according to published procedures

CAT II

For Prisma Cloud Compute running in isolated environments version information is posted https://docs.twistlock.com/docs/releases/release-information/latest.html#

https://docs.twistlock.com/docs/compute_edition/upgrade/upgrade_process_self_hosted.html

This is for the updating of Prisma Cloud Compute specifically. Vulnerability rules can be created to help the organization define when an image is not longer allowed based upon the vulnerability posture of the image. https://blog.paloaltonetworks.com/prisma-cloud/continuous-authority-operate/

SI-2 (6)

CCI-002617

SRG-APP-000454-CTR-001115

The container platform registry must remove old container images after updating versions have been made available.

Obsolete and stale images need to be removed from the registry to ensure the container platform maintains a secure posture. While the storing of these images does not directly pose a threat, they do increase the likelihood of these images being deployed. Removing stale or obsolete images and only keeping the most recent versions of those that are still in use removes any possibility of vulnerable images being deployed.

Not Applicable

Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version.

If organization-defined images do not contain the latest approved vendor software image version, this is a finding.

Review container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed.

If organization-defined images are not removed after updated versions have been installed, this is a finding.

Review container platform runtime documentation and configuration to determine if organization-defined images are executing latest image version from the container registry.

If container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.

Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.

CAT II

Prisma Cloud Compute does not have a container registry feature.

SI-2 c

CCI-002605

SRG-APP-000456-CTR-001125

The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs.

Prisma Cloud Compute must be configured to scan the organizations container registries

Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities.

Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.

Organization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).

This requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.

The container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).

Constant scanning of images within an organizations container platform registry will ensure the organization is aware of existing and emerging vulnerabilities within their utilized repositories.

Applicable - Configurable

Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.).

If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.

The container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries.

Navigate to Prisma Cloud Compute Console’s -Defend -Vulnerabilities -Images -Registry settings if a registry used within the environment is not listed this is a finding

Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed.

Add the registries used by environment to the Prisma Cloud Compute Console’s -Defend -Vulnerabilities -Images -Registry

CAT II

https://docs.twistlock.com/docs/compute_edition/vulnerability_management/registry_scanning.html

The frequency of the scanning of the registry should be a STIG setting in my opinion

https://docs.twistlock.com/docs/compute_edition/configure/configure_scan_intervals.html

SI-2 c

CCI-002605

SRG-APP-000456-CTR-001130

The container platform runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).

Prisma Cloud Compute’s Intelligence Stream must be kept up to date.

The container platform runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes.

The latest vulnerability and threat information is pulled by the Prisma Cloud Compute Console from the Intelligence Stream (intelligence.twistlock.com). The Prisma Cloud Intelligence Stream provides timely vulnerability data collected and processed from a variety of certified upstream sources. 

Applicable - Configurable

Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.).

If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.

The container platform registry should help the user understand where the code in the environment was deployed from and must provide controls that prevent deployment from untrusted sources or registries.

Navigate to Prisma Cloud Compute Console’s -Manage -System -Intelligence if the status is “disconnected” or the last update is over 24 hours old this is a finding

Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed within the time period directed by the authoritative source.

Configure Prisma Cloud Compute’s Console to either automatically pull Intelligence Stream updates or develop process for the retrieval and distribution of updates.

CAT II

Prisma Cloud Compute ships configured for the Console to attempt connection to public Intelligence Stream endpoint (intelligence.twistlock.com)

https://docs.twistlock.com/docs/compute_edition/tools/update_intel_stream_offline.html

Prisma Cloud Compute Intelligence Stream can support large deployments in isolated environments. https://blog.paloaltonetworks.com/prisma-cloud/threat-intelligence-isolated-environments/

SI-6 a

CCI-002696

SRG-APP-000472-CTR-001170

The organization-defined role must verify correct operation of security functions in the container platform.

Configuration of Prisma Cloud Compute must be continuously verified

Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. The container platform components must identity and ensure the security functions are still operational and applicable to the organization.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to system administrators.

Prisma Cloud Compute’s configurations must be monitored for configuration drift and addressed according to organizational policy. Ensure that the default vulnerability, compliance and runtime policies are enabled.

Applicable - Configurable

Review container platform documentation and configuration verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM).

If verification of the correct operation of security functions is not performed, this is a finding.

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Functions - CI - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Functions - Functions - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - Running hosts - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - VM images - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Code repositories - Repositories - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Code repositories - CI - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - CI - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - Deploy - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Functions - CI - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Functions - Functions - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Hosts - Running hosts - Default - alert on critical and high is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Hosts - VM images - Default - alert on critical and high is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Code repositories - Repositories - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Code repositories - CI - Default - alert all components is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Compliance - Containers &and images - CI - Default - alert on critical and high is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend -Compliance - Containers and images - Deploy - Default - alert on critical and high is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Runtime - Host policy : Default - alert on suspicious runtime behavior is disabled this is a finding

Navigate to Prisma Cloud Compute Console’s - Defend - Runtime - Container policy : Default - alert on suspicious runtime behavior is disabled this is a finding

Configure the container platform configuration and installation settings to perform verification of the correct operation of security functions.

Of the checks that failed enabled the associated policy

CAT II

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/configure/rule_ordering_pattern_matching.html

SI-6 b

CCI-002699

SRG-APP-000473-CTR-001175

The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Configuration of Prisma Cloud Compute must be continuously verified

Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to organization-defined role.

Prisma Cloud Compute’s configuration of Defender deployment must be monitored to ensure the proper coverage of monitoring and protection of the environment is in accordiance to organizational policy

Applicable - Configurable

Review container platform documentation.

Verify that the container platform is configured to perform verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM), upon product startup/restart, by a user with privileged access, and/or every 30 days.

If it is not, this is a finding.

Navigate to Prisma Cloud Compute Console’s - Manage - Defenders - Manage to determine the deployment status of the Defenders. If a Defender is not deployed to an intended workload(s) to be protected this is a finding.

Configure the container platform to perform verification of the correct operation of security functions, which may include the connection validation, upon product startup/restart, or by a user with privileged access, and/or every 30 days.

Deploy Defender to containerization node. Navigate to Prisma Cloud Compute Manage -Defenders -Deploy and selected the method of Defender deployment

CAT II

SI-6 d

CCI-002702

SRG-APP-000474-CTR-001180

The container platform must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered.

Configuration of Prisma Cloud Compute must be continuously verified

If anomalies are not acted upon, security functions may fail to secure the container within the container platform runtime.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to system administrators.

Prisma Cloud Compute’s administrative events must be monitored for configuration drift and addressed according to organizational policy

Applicable - Configurable

Review container platform runtime documentation and configuration settings.

If the container platform is not configured to notify organization-defined information system role when anomalies in the operation of security functions as defined by site security plan are discovered, this is a finding.

If the organization does not monitor the administrative audits of the Prisma Cloud Compute platform this is a finding.

Configure the container platform runtime to notify system administrator and operation staff when anomalies in the operation of the security functions as defined in site security plan are discovered.

Establish organization policy to ensure Prisma Cloud Compute administrative audits are performed. Prisma Cloud Compute can be configured to disseminate administrative events to 3rd party notification tools.

Review Prisma Cloud Compute Console’s -Manage -Alerts -Logging -Syslog configuration

Review Prisma Cloud Compute Console’s -Manage -Alerts -Manage alert provider(s) configuration

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/logging.html

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

AU-12 c

CCI-000172

SRG-APP-000492-CTR-001220

The container platform must generate audit records when successful/unsuccessful attempts to access security objects occur.

Prisma Cloud Compute administrative activity must be audited

The container platform and its components must generate audit records when successful and unsuccessful access security objects occur. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation access controls levels can access by unauthorized users unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security objects.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts to access security objects occur.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000493-CTR-001225

The container platform must generate audit records when successful/unsuccessful attempts to access security levels occur.

Prisma Cloud Compute must audit successful/unsuccessful access attempts

Unauthorized users could access the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can access security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security levels.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts to access security levels occur.

Review Prisma Cloud Compute Console’s -Manage -Alerts -Manage alert provider(s) configuration

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/howto/review_debug_logs.html

AU-12 c

CCI-000172

SRG-APP-000494-CTR-001230

The container platform must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.

Prisma Cloud Compute must audit successful/unsuccessful access attempts

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access categories of information.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records on successful/unsuccessful attempts to access categories of information.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/howto/review_debug_logs.html

AU-12 c

CCI-000172

SRG-APP-000495-CTR-001235

The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur.

Prisma Cloud Compute must audit the modification of user / group privileges

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records on successful/unsuccessful attempts to modify privileges.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000496-CTR-001240

The container platform must generate audit records when successful/unsuccessful attempts to modify security objects occur.

Prisma Cloud Compute must audit the modification of security objects

The container platform and its components must generate audit records when modifying security objects. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can modify security objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security objects.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security objects.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000497-CTR-001245

The container platform must generate audit records when successful/unsuccessful attempts to modify security levels occur.

Prisma Cloud Compute must audit the modification of user / group role assignment

Unauthorized users could modify the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can modify security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute’s audits are in RFC5424-compliant format

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security levels.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security levels.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of access to security objects

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000498-CTR-001250

The container platform must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.

Prisma Cloud Compute must audit the creation and/or modification of Collections

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Prisma Cloud Compute Collections are predefined filters for segments of your environment. They’re centrally defined, and they’re used in rules and views across the product.

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to modify categories of information.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to modify categories of information.

CAT II

Creation, modification and deletion of Collections is captured within the Console logs. The organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting.

https://docs.twistlock.com/docs/compute_edition/howto/review_debug_logs.html

AU-12 c

CCI-000172

SRG-APP-000499-CTR-001255

The container platform must generate audit records when successful/unsuccessful attempts to delete privileges occur.

Prisma Cloud Compute must audit the deletion of user / group role assignment

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Auditing the rights assignments to Prisma Cloud Compute uses and groups can be used to facilitate incident responses

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to delete privileges.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to delete privileges occur.

CAT II

Organization should implement SIEM integration with Prisma Cloud Compute to ensure timely alerting of the changing of user and group rights assignments

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000500-CTR-001260

The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur.

Prisma Cloud Compute must audit the deletion of a role

The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute allow the deletion of a custom role. Auditing the deletion of a custom rule ensures the integrity of the system

Applicable - Inherently Meets

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records when successful/unsuccessful attempts to delete security levels.

CAT II

The organization should create policy corresponding to the use of custom roles and should implement SIEM integration to monitor the deletion of the custom roles.

https://docs.twistlock.com/docs/compute_edition/authentication/user_roles.html

The default Prisma Cloud Compute roles cannot be deleted. Only custom roles can be deleted

AU-12 c

CCI-000172

SRG-APP-000501-CTR-001265

The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur.

Prisma Cloud Compute must audit administrative events that successfully or unsuccessfully delete security objects.

Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute audits all administrative events can be used to determine the successful or unsuccessful deletion of a security object

Applicable - Inherently Meets

Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records on successful/unsuccessful attempts to delete security objects occur.

CAT II

It is recommended organization should implement SIEM integration to monitor the deletion of the security objects.

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/audit/audit_admin_activity.html

All administrative event audits are rendered in the Prisma Cloud Compute Console’s - Manage - View logs -History

AU-12 c

CCI-000172

SRG-APP-000502-CTR-001270

The container platform must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.

Prisma Cloud Compute must audit the deletion of Collections

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Prisma Cloud Compute Collections are predefined filters for segments of your environment. They’re centrally defined, and they’re used in rules and views across the product.

Applicable - Inherently Meets

Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete categories of information occur.

If audit records are not generated, this is a finding.

Configure the container platform to generate audit records on successful/unsuccessful attempts to delete categories of information occur.

CAT II

The organization should create policy corresponding to the use of custom roles and should implement SIEM integration to monitor the deletion of Collections.

https://docs.twistlock.com/docs/compute_edition/howto/review_debug_logs.html

AU-12 c

CCI-000172

SRG-APP-000503-CTR-001275

The container platform must generate audit records when successful/unsuccessful logon attempts occur.

Prisma Cloud Compute must audit all logon attempts.

The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Monitoring all authentication failed and successful will ensure the safe and intended operation of Prisma Cloud Compute.

Applicable - Inherently Meets

Review the container platform configuration for audit logon events.

Ensure audit policy for successful and unsuccessful logon events are enabled.

Verify events are written to the log.

Validate system documentation is current.

If logon attempts do not generate log records, this is a finding.

Configure the container platform registry, keystore, and runtime to generate audit log for successful and unsuccessful logon for any all accounts and services. Revise all applicable system documentation.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

All authentications to the Console will be audited and can be viewed within the Prisma Cloud Compute’s Console’s Mange -View Logs -History both failed and successful logon will appear with type = login

AU-12 c

CCI-000172

SRG-APP-000504-CTR-001280

The container platform must generate audit record for privileged activities.

Prisma Cloud Compute must audit all administrative activities

The container platform components will generate audit records for privilege activities and container platform runtime, registry, and keystore must generate access audit records to detect possible malicious intent. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without these activities. Audit records can be generated from various components within the container platform.

The auditing of all privileged activities will ensure the safe and intended operation of Prisma Cloud Compute.

Applicable - Inherently Meets

Review the documentation and configuration guides to determine if the container platform generates log records for privileged activities.

If log records are not generated for privileged activities, this is a finding.

Configure the container platform to generate log records for privileged activities.

CAT II

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000505-CTR-001285

The container platform audit records must record user access start and end times.

Prisma Cloud Compute must Audit user login and logout times

The container platform must generate audit records showing start and end times for users and services acting on behalf of a user accessing the registry and keystore. These components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

The ability to monitor a users login and logout timestamps will ensure the safe and intended operation of Prisma Cloud Compute.

Applicable - Inherently Meets

Review the container platform configuration for audit user access start and end times.

Ensure audit policy for user access start and end times are enabled.

Verify events are written to the log.

Validate system documentation is current.

If user access start and end times do not generate log records, this is a finding.

Configure the container platform to generate audit log for user access start and end times for any all accounts and services. Revise all applicable system documentation.

CAT II

Logins audits are shown within the Console’s Manage - View Logs - History Logout audits are shown within the Console’s Manage - View Logs - Console

https://docs.twistlock.com/docs/compute_edition/howto/review_debug_logs.html

https://docs.twistlock.com/docs/compute_edition/audit/audit_admin_activity.html

AU-12 c

CCI-000172

SRG-APP-000506-CTR-001290

The container platform must generate audit records when concurrent logons from different workstations and systems occur.

Prisma Cloud Compute must capture the authenticating user’s IP address

The container platform and its components must generate audit records for concurrent logons from workstations perform remote maintenance, runtime instances, connectivity to the container registry, and keystore. All the components must use the same standard so the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

The ability to monitor a users login source IP address will ensure the safe and intended operation of Prisma Cloud Compute.

Applicable - Inherently Meets

Review the container platform configuration for audit logon events.

Ensure audit policy for concurrent logons from different workstations and systems is enabled.

Verify events are written to the log.

Validate system documentation is current.

If concurrent logons from different workstations and systems do not generate log records, this is a finding.

Configure the container platform to generate audit log for concurrent logins from multiple workstations and systems. Revise all applicable system documentation.

CAT II

IP source is dependent upon the network architecture and possible network address translations

AU-12 c

CCI-000172

SRG-APP-000507-CTR-001295

The container platform runtime must generate audit records when successful/unsuccessful attempts to access objects occur.

Prisma Cloud Compute Trusted Images must be enabled

Container platform runtime objects are defined as configuration files, code, etc. This provides the ability to configure resources and software parameters prior to image execution from the container platform registry. An unauthorized user with malicious intent could modify existing objects causing vulnerabilities or attacks. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without audit record generation.

Without audit record generation, unauthorized users can access objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Prisma Cloud Compute’s Trusted images is a security control that lets you declare, by policy, which registries, repositories, and images you trust, and how to respond when untrusted images are started in your environment.

Applicable - Configurable

Review the container platform configuration to verify that the runtime generates audit records on successful/unsuccessful access to objects.

If audit records are not generated by the runtime when objects are successfully/unsuccessfully accessed, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Compliance - Trusted Images - Policy and if Trusted images rules is set to off this is a finding

Configure the container platform runtime to generate audit records on successful/unsuccessful access to objects.

Navigate to Prisma Cloud Compute Console’s Defend -Compliance - Trusted Images - Policy and set Trusted images rules to on

CAT II

Trusted Image compliance feature configuration is audited as an administrative event.

https://docs.twistlock.com/docs/compute_edition/compliance/trusted_images.html

Trusted Images will control the behaviors of when an untrusted image tries to start as a container

AU-12 c

CCI-000172

SRG-APP-000508-CTR-001300

Direct access to the container platform must generate audit records.

Prisma Cloud Compute Default Host Runtime policy must be enabled

Direct access to the container platform and its components must generate audit records. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Prisma Cloud Compute Host Runtime - Avtivity monitoring will record interactive user session activities on the nodes on which Defenders have been deployed

Applicable - Configurable

Review the container platform configuration to determine if direct access of the container platform generates audit records.

If audit records are not generated, this is a finding.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime - Host Policy if the Default - alert on suspicious runtime behavior rule is disabled or the rule is not scoped to All this is a finding

Configure the container platform to generate audit records when accessed directly.

Navigate to Prisma Cloud Compute Console’s Defend -Runtime - Host Policy enable the Default - alert on suspicious runtime behavior rule and scope the rule to All

CAT II

Host runtime activity audits will be audited and displayed in Monitor - Event - Host - Host Audits. Alerts can be created to send host activity audits to role holders responsible for the integrity and monitoring of the hosts.

https://docs.twistlock.com/docs/compute_edition/runtime_defense/runtime_defense_hosts.html#activities

AU-12 c

CCI-000172

SRG-APP-000509-CTR-001305

The container platform must generate audit records for all account creations, modifications, disabling, and termination events.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Not Applicable

Review the container platform configuration to determine if the container platform is configured to generate audit records for all account creations, modifications, disabling, and termination events.

If the container platform is not configured to generate the audit records, this is a finding.

Configure the container platform to generate audit records for all account creations, modifications, disabling, and termination events.

CAT II

Creation, modification and deletion of Prisma Cloud Compute accounts was explained in SRG-APP-000026-CTR-000070

Monitoring the creation of is a function of the container platform (e.g. Kubernetes)

AU-12 c

CCI-000172

SRG-APP-000510-CTR-001310

The container runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.

The container runtime must generate audit records that are specific to the security and mission needs of the organization. Without audit record, it would be difficult to establish, correlate, and investigate events relating to an incident.

Not Applicable

Review the container runtime configuration to validate audit record generation for container execution, shutdown, and restart events.

If the container runtime does not generate records for container execution, shutdown and restart events, this is a finding.

Configure the container runtime to generate audit records for container execution, shutdown, and restart events.

CAT II

Function of the container platform (e.g. Kubernetes)

SC-13

CCI-002450

SRG-APP-000514-CTR-001315

The container platform must use a valid FIPS 140-2 approved cryptographic modules to generate hashes.

The cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the container platform components being evaluated.

FIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.

Applicable - Does Not Meet

Review the container platform configuration to validate that valid FIPS 140-2 approved cryptographic modules are being used to generate hashes.

If non-valid or unapproved FIPS 140-2 cryptographic modules are being used to generate hashes, this is a finding.

Configure the container platform to use valid FIPS 140-2 approved cryptographic modules to generate hashes.

CAT II

Compliance check 701070, FIPS mode must be enabled on all Docker Engine - Enterprise nodes can query the nodes (running Docker Enterprise) can determine if the docker daemon is leveraging FIPS validated modules.

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

CM-6 b

CCI-000366

SRG-APP-000516-CTR-000790

The container platform must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds.

Prisma Cloud Compute Alert audits must be configurable

Auditing requirements may change per organization or situation within and organization. With the container platform allowing an organization to customize the auditing, an organization can decide to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.

Modifying auditing within the container platform must be controlled to only those individuals or roles identified by the organization to modify auditable events.

Prisma Cloud Compute Alerts can be configure to send alert types to various stake holders via their preferred method of notification.

Applicable - Configurable

Review documentation and configuration setting.

If the container platform does not provide the ability for users in authorized roles to reconfigure auditing at any time of the user’s choosing, this is a finding.

If changes in audit configuration cannot take effect until after a certain time or date, or until some event, such as a server restart, has occurred, and if that time or event does not meet the requirements specified by the organization, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts review the Alert provider configurations. If the configurations are incorrect this is a finding

Deploy a container platform that provides the ability for users in authorized roles to reconfigure auditing at any time. Deploy a container platform that allows audit configuration changes to take effect within the timeframe required by the organization and without involving actions or events that the organization rules unacceptable.

Navigate to Prisma Cloud Compute Console’s -Manage - Alerts and create, modify and/or delete an Alert provider as stipulated by the organization’s policies

CAT II

Alert audit aggregation period is configurable to second, minutes, hour or day

https://docs.twistlock.com/docs/compute_edition/alerts/alerts.html

CM-6 b

CCI-000366

SRG-APP-000516-CTR-001325

Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

Prisma Cloud Compute DISA Docker STIG Compliance Template must be implemented

Container platform components are part of the overall container platform, offering services that enable the container platform to fully orchestrate user containers. These components may fall outside the scope of this document, but they still must be secured. Examples of such components are DNS, routers, and firewalls. These and any other services offered by the container platform must follow the appropriate STIG or SRG for the technology offered. If a STIG or SRG is not available for the technology, then best practices for the technology must be used. For example, the Cloud Native Computing Foundation (CNCF) is an open-source organization that is working on container platform best practices.

Applicable - Configurable

Review the container platform configuration to determine the services offered by the container platform and validate that any services that are offered are configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

If container platform services are not configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding.

See lines #178 and #180, the compliance checks include the Docker Enterprise DISA STIG and all “critical” and “high” compliance checks.

Configure container services in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

CAT II

https://docs.twistlock.com/docs/government/Release_STIG_Findings/release_stig.html

See lines #178 and #180, the compliance checks include the Docker Enterprise DISA STIG and all “critical” and “high” compliance checks.

CM-6 b

CCI-000366

SRG-APP-000516-CTR-001330

The container platform must be able to store and instantiate industry standard container images.

Monitoring the container images and containers during their lifecycle is important to guarantee the container platform is secure. To monitor the containers and images, security tools can be put in place. To fully utilize the security tools available, using images formatted in an industry standard format should be used. This allows the tools to fully understand the images and containers. One standard being worked on by industry leaders in the container space is the Open Container Initiative (OCI). This group is developing a standard container image format.

Not Applicable

Review the container platform configuration and documentation to determine if the platform is configured to store and instantiate industry standard container images.

If the container platform cannot instantiate industry standard container images, this is a finding.

Enable the container platform to store and instantiate industry standard container image formats.

CAT II

Function of the container platform (e.g. Kubernetes/CRI-O)

CM-6 b

CCI-000366

SRG-APP-000516-CTR-001335

The container platform must continuously scan components, containers, and images for vulnerabilities.

Prisma Cloud Compute default vulnerability rule must be enabled and scoped to all

Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications.

Vulnerability scanning can be performed by the container platform or by external applications.

Prisma Cloud Compute ships with the Default - alert all components vulnerability rule enabled and scoped to all

Applicable - Configurable

Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed.

If continuous vulnerability scans are not being performed, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Defend -Vulnerabilities -Images -Deployed and if the Default - alert all components rule is disabled and/or is not scoped to all then this is a finding

Implement continuous vulnerability scans of container platform components, containers, and container images either by the container platform or from external vulnerability scanning applications.

Enable Prisma Cloud Compute Console’s -Defend -Vulnerabilities -Images -Deployed Default - alert all components rule and set scope to all

CAT II

https://docs.twistlock.com/docs/compute_edition/vulnerability_management/vuln_management_rules.html

Default - alert all components is a catch all rule

AC-17 (2)

CCI-001453

SRG-APP-000560-CTR-001340

The container platform must prohibit communication using TLS versions 1.0 and 1.1, and SSL 2.0 and 3.0.

Prisma Cloud Compute must only use TLS v1.2 or higher protocol

The container platform and its components will prohibit the use of SSL and unauthorized versions of TLS protocols to properly secure communication.

The use of unsupported protocol exposes vulnerabilities to the container platform by rogue traffic interceptions, man-in-the middle-attacks, and impersonation of users or services from the container platform runtime, registry, and keystore.

The container platform and its components will adhere to NIST 800-52R2.

Prisma Cloud Compute will implement TLS v1.2 or higher cyber suites for network communications

Applicable - Inherently Meets

Review the container platform configuration to determine if TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 are prohibited for communication.

If communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 is permitted, this is a finding.

Configure the container platform to prohibit communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0.

CAT II

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

If this is more of a check of the container platform’s enforcement TLS this is a Not Applicable check

IA-5 (2) (a)

CCI-000185

SRG-APP-000605-CTR-001380

The container platform must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation.

Prisma Cloud Compute must perform TLS certificate validation

A certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate and discourages the use of self-signed certificates.

Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Compliance checks should be in accordance to RFC 5280.

Not adhering to RFC 5280 could result in rogue certificates, session hijacks, man-in-the-middle, denial-of-service attacks, malware, and data or information manipulation.

Prisma Cloud Compute ships with a self-signed x.509 certificate for UI and API TLS protected communication.

Applicable - Inherently Meets

Review the container platform configuration to verify the container platform is validating certificates used for Transport Layer Security (TLS) functions by performing a RFC 5280-compliant certification path validation and that self-signed certificates are not being used.

If the container platform is not validating certificates used for TLS functions by performing an RFC 5280-compliant certification path validation, this is a finding.

If self-signed certificates are in use, this is a finding.

Configure the container platform to validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation and to disable the use of self-signed certificates.

CAT II

Customers can issue a 3rd party x.509 certificate for the Console’s UI and API TLS communication

https://docs.twistlock.com/docs/compute_edition/authentication/use_custom_certs_for_auth.html#explicit-certificate-trust-list

Prisma Cloud Compute performs certificate path validation, CRL and OCSP revocation check. Compute leverages the host node’s trusted root certificates.

IA-7

CCI-000803

SRG-APP-000610-CTR-001385

The container platform must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).

Prisma Cloud Compute release tar distributions must have an associated SHA-256 digest

Without the use of digital signature, information can be altered by unauthorized accounts accessing or modifying the container platform registry, keystore, and container at runtime. Digital signatures provide non-repudiation for transactions between the components within the container platform. Without the use of approved FIPS-validated SHA-2 or higher hash function with digital signatures, the container platform cannot claim the validity of the individual or service identity and guarantee private key is kept secret. Keeping the private keys secure is vital for validating individuals or service identity prior to information exchange. The container platform must be configured to use SHA-2 or higher hash functions for digital signatures in accordance with SP 800-131Ar2.

Each Prisma Cloud Compute release’s tar file has an associated SHA-256 digest hash value to ensure the components have not be modified.

Applicable - Configurable

Review the container platform configuration to validate that a FIPS-validated SHA-2 or higher hash function is being used for digital signature generation and verification.

If a FIPS-validated SHA-2 or higher hash function is not being used for digital signature generation and verification, this is a finding.

Download the latest Prisma Cloud Compute release, generate a SHA-256 hash digest, (e.g. openssl dgst -sha256 prisma_cloud_compute_edition_20_12_531.tar.gz), if this value does not match the published release hash disgust this is a finding

Configure the container platform to use a FIPS-validated SHA-2 or higher hash function for digital signature generation and verification.

CAT II

https://docs.twistlock.com/docs/releases/release-information/download.html

Notify Prisma Cloud Compute support if hash values are not matching

SC-13

CCI-002450

SRG-APP-000635-CTR-001405

The container platform must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.

Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.

Cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the container platform component and information residing in the container platform registry and keystore.

Not Applicable

Review the container platform configuration to ensure FIPS-validated cryptographic modules are implemented to encrypt unclassified information requiring confidentiality.

If FIPS-validated cryptographic modules are not being used, this is a finding.

Configure the container platform to use FIPS-validated cryptographic modules to encrypt unclassified information requiring confidentiality.

CAT I

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

CM-7 b

CCI-000382

SRG-APP-000645-CTR-001410

The container platform must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.

Prisma Cloud Compute’s MANAGE_PORT_HTTP must not be used

The use of secure ports, protocols and services within the container platform must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.

Unsecure protocols for transmission will expose the information system data and information, making the session susceptible to manipulation, hijacking, and man-in-the middle attacks.

Communication to Prisma Cloud Compute Console’s User Interface (UI) and API is protected by TLS v1.2+ (HTTPS). By default only HTTPS communication to the Console’s UI and API endpoints is enabled.

Applicable - Configurable

Review the container platform configuration to verify that container platform is not using protocols that transmit authentication data unencrypted and that the container platform is not using flawed cryptographic algorithms for transmission.

If the container platform is using protocols to transmit authentication data unencrypted or is using flawed cryptographic algorithms, this is a finding.

For Kubneretes deployment type kubectl describe pods <twistlock-console-pod—​n <namespace-and verify the MANAGEMENT_PORT_HTTP: value is NULL

For docker type docker inspect <twistlock-console-container-and verify MANAGEMENT_PORT_HTTP value is NULL

If the Console’s MANAGEMENT_PORT_HTTP has an assigned port number this is a finding

Configure the container platform to use protocols that transmit authentication data encrypted and to use cryptographic algorithms that are not flawed.

Redploy Prisma Cloud Compute’s Console to disable MANAGEMENT_PORT_HTTP using the twistlock.cfg configuration file’s MANAGEMENT_PORT_HTTP = <null>

CAT I

https://docs.twistlock.com/docs/compute_edition/howto/configure_listening_ports.html

MANAGEMENT_PORT_HTTP is disabled by default

AC-3 (7)(8)

Least privilege access and need to know must be required to access the Prisma Cloud Compute platform.

Access to the Prisma Cloud Compute must be managed based upon user need and least privileged.

Prisma Cloud Compute is used to secure to implementation of micro service environments. If this platform is accessed by those persons who are not authorized, the environment can be brought to a denial of service (DoS) situation, disabling a large number of services with a small change to the container platform. To limit this threat, it is important to limit access to the Prisma Cloud Compute Console to only those individuals with specified roles.

Excessive Prisma Cloud Compute role permissions could allow an attacker to create policy that would adversely affect the operation of the environment.

Applicable - Configurable

Review the Prisma Cloud Compute Console to determine if only those individuals with accounts and roles have the appropriate authentication and roles.

If users have access to Prisma Cloud Compute Console that do not have organization duties, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage -Authentication - Users. Review all accounts, “Authentication method,” “Role” & Permission.

Navigate to Prisma Cloud Compute Console’s -Manage -Authentication - Groups. Review all groups, “Authentication method,” “Role” & Permission.

If any user or group is not within the organization’s intended roles and responsibilities then this is a finding

Configure Prisma Cloud Compute to use least privilege and need to know when granting access to the Console. The fix ensures the proper roles and permissions are configured.

Adjust users and groups methods of authentication, role and permissions base upon the organization’s policies

CAT II

IA-2 (1)(2)

The container platform must use multifactor authentication for network access to privileged accounts.

The container platform must use multifactor authentication for network access to non-privileged accounts.

Multi-factor authentication is required for all network based access.

Without the use of multifactor authentication, the ease of access to functions is greatly increased.

Multifactor authentication requires using two or more factors to achieve authentication.

Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric).

Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet).

Only network based access to the Prisma Cloud Compute Console is allowed. To ensure multi-factor authentication is enforced basic authentication to Console UI and API can be disabled.

Applicable - Configurable

Review the Prisma Cloud Compute Console to determine if basic authentication has been disabled for the Console UI and API

Navigate to Prisma Cloud Compute Console’s - Manage - Authentication - Logon - Disable basic authentication for the API is set to “off” this is a finding

Configure Prisma Cloud Compute Console’s to disable basic authentication for the Console and API.

Navigate to Prisma Cloud Compute Console’s - Manage - Authentication - Logon - Disable basic authentication for the API and set to “on.”

CAT II

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/configure/logon_settings.html#basic-authentication-to-console-and-api

CM-2

Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system

Prisma Cloud Compute image and container compliance baseline policies

Default baseline compliance policies ensures consistent monitoring of the images, containers and hosts

Consistent application of Prisma Cloud Compute compliance policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute compliance policies

Navigate to Prisma Cloud Compute Console’s Defend - Compliance - Containers and Images - Deployed if the “Default - alert on critical and high” policy is disabled this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s Defend - Compliance - Containers and Images - Deployed and enable the “Default - alert on critical and high” policy

CAT I

See lines #178 & #180

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/compliance/disa_stig_docker_enterprise.html

CM-2

Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system

Prisma Cloud Compute host compliance baseline policies

Default baseline compliance policies ensures consistent monitoring of the images, containers and hosts

Consistent application of Prisma Cloud Compute compliance policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute compliance policies

Navigate to Prisma Cloud Compute Console’s Defend - Compliance - Hosts - Running Hosts if the “Default - alert on critical and high” policy is disabled this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s Defend - Compliance - Hosts - Running Hosts and enable the “Default - alert on critical and high” policy

CAT I

See lines #178 & #180

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/compliance/disa_stig_docker_enterprise.html

RA-5

Monitor and scan for vulnerabilities in the system and hosted applications

Prisma Cloud Compute image vulnerabilities baseline policies

Default baseline vulnerability policies ensures consistent monitoring of images

Consistent application of Prisma Cloud Compute vulnerability policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute vulnerability policies

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - Deployed if the “Default - alert all components” policy is disabled this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - Deployed and enable the “Default - alert all components” policy

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/vulnerability_management/vuln_management_rules.html

RA-5

Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

Prisma Cloud Compute image compliance baseline policies

Default baseline compliance policies ensures consistent monitoring of images

Consistent application of Prisma Cloud Compute compliance policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute compliance policies

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - Deployed if the following “Default - alert all components” policy checks

ID = 41: Image should be created with a non-root user ID = 422: Image contains malware ID = 424: Sensitive information provided in environment variables ID = 425: Private keys stored in image ID = 426: Image contains binaries used for crypto mining ID = 448: Package binaries should not be altered ID = 5041: Image should be created with a non-root user ID = 5051: Verify AppArmor profile, if applicable ID = 5052: Verify SELinux security options, if applicable ID = 5054: Do not use privileged containers ID = 5055: Do not mount sensitive host system directories on containers ID = 5056: Do not run ssh within containers ID = 5059: Do not share the host’s network namespace ID = 51: Verify AppArmor profile, if applicable ID = 510: Limit memory usage for container ID = 511: Set container CPU priority appropriately ID = 512: Mount container’s root filesystem as read only ID = 514: Do not set the 'on-failure' container restart policy to always 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 = 519: Do not set mount propagation mode to shared ID = 520: Do not share the host’s UTS namespace ID = 52: Verify SELinux security options, if applicable ID = 521: Do not disable default seccomp profile ID = 524: Confirm cgroup usage ID = 525: Restrict container from acquiring additional privileges ID = 528: Use PIDs cgroup limit ID = 530: Do not share the host’s user namespaces ID = 531: Do not mount the Docker socket inside any containers ID = 54: Do not use privileged containers ID = 55: Do not mount sensitive host system directories on containers ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately ID = 5512: Mount container’s root filesystem as read only ID = 5515: Do not share the host’s process namespace ID = 5516: Do not share the host’s IPC namespace ID = 5519: Do not set mount propagation mode to shared ID = 5520: Do not share the host’s UTS namespace ID = 5521: Do not disable default seccomp profile ID = 5524: Confirm cgroup usage ID = 5525: Restrict container from acquiring additional privileges ID = 5528: Use PIDs cgroup limit ID = 5531: Do not mount the CRI socket inside any containers ID = 56: Do not run ssh within containers ID = 57: Do not map privileged ports within containers ID = 58: Open only needed ports on container ID = 59: Do not share the host’s network namespace ID = 597: Secrets in clear text environment variables ID = 598: Container app is running with weak settings ID = 599: Container is running as root ID = 406: Add HEALTHCHECK instruction to the container image ID = 513: Bind incoming container traffic to a specific host interface ID = 518: Override default ulimit at runtime only if needed ID = 53: Restrict Linux kernel capabilities within containers

are set to ignore this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Images - Deployed “Default - alert all components” and set the following policy checks checks to either alert or block

ID = 41: Image should be created with a non-root user ID = 422: Image contains malware ID = 424: Sensitive information provided in environment variables ID = 425: Private keys stored in image ID = 426: Image contains binaries used for crypto mining ID = 448: Package binaries should not be altered ID = 5041: Image should be created with a non-root user ID = 5051: Verify AppArmor profile, if applicable ID = 5052: Verify SELinux security options, if applicable ID = 5054: Do not use privileged containers ID = 5055: Do not mount sensitive host system directories on containers ID = 5056: Do not run ssh within containers ID = 5059: Do not share the host’s network namespace ID = 51: Verify AppArmor profile, if applicable ID = 510: Limit memory usage for container ID = 511: Set container CPU priority appropriately ID = 512: Mount container’s root filesystem as read only ID = 514: Do not set the 'on-failure' container restart policy to always 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 = 519: Do not set mount propagation mode to shared ID = 520: Do not share the host’s UTS namespace ID = 52: Verify SELinux security options, if applicable ID = 521: Do not disable default seccomp profile ID = 524: Confirm cgroup usage ID = 525: Restrict container from acquiring additional privileges ID = 528: Use PIDs cgroup limit ID = 530: Do not share the host’s user namespaces ID = 531: Do not mount the Docker socket inside any containers ID = 54: Do not use privileged containers ID = 55: Do not mount sensitive host system directories on containers ID = 5510: Limit memory usage for container ID = 5511: Set container CPU priority appropriately ID = 5512: Mount container’s root filesystem as read only ID = 5515: Do not share the host’s process namespace ID = 5516: Do not share the host’s IPC namespace ID = 5519: Do not set mount propagation mode to shared ID = 5520: Do not share the host’s UTS namespace ID = 5521: Do not disable default seccomp profile ID = 5524: Confirm cgroup usage ID = 5525: Restrict container from acquiring additional privileges ID = 5528: Use PIDs cgroup limit ID = 5531: Do not mount the CRI socket inside any containers ID = 56: Do not run ssh within containers ID = 57: Do not map privileged ports within containers ID = 58: Open only needed ports on container ID = 59: Do not share the host’s network namespace ID = 597: Secrets in clear text environment variables ID = 598: Container app is running with weak settings ID = 599: Container is running as root ID = 406: Add HEALTHCHECK instruction to the container image ID = 513: Bind incoming container traffic to a specific host interface ID = 518: Override default ulimit at runtime only if needed ID = 53: Restrict Linux kernel capabilities within containers

CAT II

Combination of the all high and critical compliance check and DISA Docker Enterprise STIG checks

RA-5

Monitor and scan for vulnerabilities in the system and hosted applications

Prisma Cloud Compute host vulnerabilities baseline policies

Default baseline vulnerability policies ensures consistent monitoring of images

Consistent application of Prisma Cloud Compute vulnerability policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute vulnerability policies

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - Running Hosts if the “Default - alert all components” policy is disabled this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - Running Hosts and enable the “Default - alert all components” policy

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/vulnerability_management/vuln_management_rules.html

RA-5

Container platform components must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

Prisma Cloud Compute host compliance baseline policies

Default baseline compliance policies ensures consistent monitoring of images

Consistent application of Prisma Cloud Compute compliance policies ensures the continual application of policies and the associated effects.

Applicable - Configurable

Review Prisma Cloud Compute vulnerability policies

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - Running Hosts if the following “Default - alert all components” policy checks

ID = 6216: Ensure rsh server is not enabled ID = 8134: Ensure that the --use-service-account-credentials argument is set to true (kube-controller-manager) ID = 81419: Ensure that the API server pod specification file permissions are set to 644 or more restrictive ID = 8145: Ensure that the scheduler file ownership is set to root:root ID = 5036: Verify that /etc/crio and /etc/crio/conf.d directories permissions are set to 755 or more restrictive ID = 8118: Ensure that the --secure-port argument is not set to 0 (kube-apiserver) ID = 200004: Verify antivirus signatures are up-to-date ID = 319: Verify that /etc/default/docker file ownership is set to root:root ID = 6529: Ensure SSH PermitEmptyPasswords is disabled ID = 66213: Ensure users' .netrc Files are not group or world accessible ID = 6518: Ensure at/cron is restricted to authorized users ID = 8112: Ensure that the --anonymous-auth argument is set to false (kube-apiserver) ID = 62216: Ensure rsync service is not enabled ID = 66218: Ensure no duplicate user names exist ID = 81418: Ensure that the controller-manager.conf file ownership is set to root:root ID = 8211: Ensure that the --allow-privileged argument is set to false (kubelet) ID = 61613: Ensure SELinux policy is configured ID = 6361: Ensure iptables is installed ID = 81421: Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive ID = 8232: Ensure that the proxy kubeconfig file ownership is set to root:root ID = 35: Verify that /etc/docker directory ownership is set to root:root ID = 65414: Ensure inactive password lock is 30 days or less ID = 81137: Ensure that the AdvancedAuditing argument is not set to false (kube-apiserver) ID = 200005: Verify antivirus signatures expiration policy ID = 81129: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kube-apiserver) ID = 8223: Ensure that the kubelet file permissions are set to 644 or more restrictive ID = 8311: Ensure that the --anonymous-auth argument is set to false (federation-apiserver) ID = 8141: Ensure that the apiserver file permissions are set to 644 or more restrictive ID = 8152: Ensure that the --client-cert-auth argument is set to true (etcd) ID = 215: Do not enable swarm mode, if not needed ID = 315: Verify that Docker socket file ownership is set to root:docker ID = 8215: Ensure that the --read-only-port argument is set to 0 (kubelet) ID = 81111: Ensure that the admission control policy is not set to AlwaysAdmit (kube-apiserver) ID = 5037: Verify that CRI global auth file ownership is set to root:root ID = 21: Restrict network traffic between containers ID = 8117: Ensure that the --insecure-port argument is set to 0 (kube-apiserver) ID = 81427: Ensure that the Kubernetes PKI directory and file ownership is set to root:root ID = 37: Verify that registry certificate file ownership is set to root:root ID = 8114: Ensure that the --insecure-allow-any-token argument is not set (kube-apiserver) ID = 8156: Ensure that the --peer-auto-tls argument is not set to true (etcd) ID = 8230: Ensure that the kubelet service file ownership is set to root:root ID = 81112: Ensure that the admission control policy is set to AlwaysPullImages (kube-apiserver) ID = 82112: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kubelet) ID = 6143: Ensure authentication required for single user mode ID = 81127: Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate (kube-apiserver) ID = 81120: Ensure that the --authorization-mode argument is not set to AlwaysAllow (kube-apiserver) ID = 6412: Ensure auditd service is enabled ID = 8231: Ensure that the proxy kubeconfig file permissions are set to 644 or more restrictive ID = 81428: Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive ID = 81422: Ensure that the controller manager pod specification file ownership is set to root:root ID = 6229: Ensure FTP Server is not enabled ID = 6628: Ensure users' home directories permissions are 750 or more restrictive ID = 200007: Verify antispyware signatures expiration policy ID = 81410: Ensure that the flanneld file ownership is set to root ID = 8234: Ensure that the kubelet configuration file has permissions set to 644 or more restrictive ID = 64115: Ensure changes to system administration scope (sudoers) is collected ID = 6612: Ensure permissions on /etc/passwd are configured ID = 8143: Ensure that the config file permissions are set to 644 or more restrictive ID = 60522: Ensure permissions on SSH private host key files are configured ID = 8225: Ensure that the proxy file permissions are set to 644 or more restrictive ID = 6153: Ensure address space layout randomization (ASLR) is enabled ID = 24: Do not use insecure registries ID = 320: Verify that /etc/default/docker file permissions are set to 644 or more restrictive ID = 28: Enable user namespace support ID = 6521: Ensure permissions on /etc/ssh/sshd_config are configured ID = 5320: Verify that CRIO systemd daemon environment file permissions are set to 644 or more restrictive ID = 6219: Ensure tftp server is not enabled ID = 81412: Ensure that the etcd data directory ownership is set to etcd:etcd ID = 8313: Ensure that the --insecure-allow-any-token argument is not set (federation-apiserver) ID = 62212: Ensure Samba is not enabled ID = 200400: Verify Windows Update is enabled ID = 449: Ensure no pending OS security updates ID = 64116: Ensure system administrator actions (sudolog) are collected ID = 6613: Ensure permissions on /etc/shadow are configured ID = 33: Verify that docker.socket file ownership is set to root:root ID = 81132: Ensure that the --authorization-mode argument is set to Node (kube-apiserver) ID = 81417: Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive ID = 8151: Ensure that the --cert-file and --key-file arguments are set as appropriate (etcd) ID = 8214: Ensure that the --client-ca-file argument is set as appropriate (kubelet) ID = 83119: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (federation-apiserver) ID = 200201: Verify Windows Defender Control Flow Guard (CFG) is enabled ID = 62214: Ensure SNMP Server is not enabled ID = 641113: Ensure successful file system mounts are collected ID = 8233: Ensure that the kubelet configuration file ownership is set to root:root ID = 66210: Ensure users' dot files are not group or world writable ID = 8136: Ensure that the --root-ca-file argument is set as appropriate (kube-controller-manager) ID = 38: Verify that registry certificate file permissions are set to 444 or more restrictive ID = 8111: Ensure that the --allow-privileged argument is set to false (kube-apiserver) ID = 81126: Ensure that the --service-account-key-file argument is set as appropriate (kube-apiserver) ID = 6627: Ensure all users' home directories exist ID = 6151: Ensure core dumps are restricted ID = 62210: Ensure HTTP server is not enabled ID = 62211: Ensure IMAP and POP3 server is not enabled ID = 5031: Verify that /usr/lib/systemd/system/crio.service file ownership is set to root:root ID = 81128: Ensure that the admission control plugin ServiceAccount is set (kube-apiserver) ID = 81424: Ensure that the scheduler pod specification file ownership is set to root:root ID = 8142: Ensure that the apiserver file ownership is set to root:root ID = 6629: Ensure users own their home directories ID = 81133: Ensure that the admission control policy is set to NodeRestriction (kube-apiserver) ID = 200202: Verify Windows Defender Data Execution Prevention (DEP) is enabled ID = 6224: Ensure CUPS is not enabled ID = 6621: Ensure password fields are not empty ID = 64117: Ensure kernel module loading and unloading is collected ID = 6218: Ensure telnet server is not enabled ID = 6522: Ensure SSH Protocol is set to 2 ID = 5024: Do not use insecure registries ID = 83114: Ensure that the --authorization-mode argument is not set to AlwaysAllow (federation-apiserver) ID = 61612: Ensure the SELinux state is enforcing ID = 317: Verify that daemon.json file ownership is set to root:root ID = 200006: Verify antispyware signatures are up-to-date ID = 8153: Ensure that the --auto-tls argument is not set to true (etcd) ID = 322: Verify that /etc/sysconfig/docker file permissions are set to 644 or more restrictive ID = 6615: Ensure permissions on /etc/gshadow are configured ID = 81426: Ensure that the etcd pod specification file ownership is set to root:root ID = 83117: Ensure that the --service-account-key-file argument is set as appropriate (federation-apiserver) ID = 6525: Ensure SSH MaxAuthTries is set to 4 or less ID = 7162: Ensure SELinux is installed ID = 81414: Ensure that the admin.conf file ownership is set to root:root ID = 8149: Ensure that the flanneld file permissions are set to 644 or more restrictive ID = 8315: Ensure that the --insecure-port argument is set to 0 (federation-apiserver) ID = 200401: Verify Windows Update is set to automatically install ID = 62217: Ensure NIS Server is not enabled ID = 8146: Ensure that the scheduler file permissions are set to 644 or more restrictive ID = 217: Bind swarm services to a specific host interface ID = 8229: Ensure that the kubelet service file permissions are set to 644 or more restrictive ID = 36: Verify that /etc/docker directory permissions are set to 755 or more restrictive ID = 8148: Ensure that the etcd.conf file ownership is set to root:root ID = 81138: Ensure that the --request-timeout argument is set as appropriate (kube-apiserver) ID = 61611: Ensure SELinux or AppArmor are installed ID = 6616: Ensure permissions on /etc/passwd- are configured ID = 6345: Ensure permissions on /etc/hosts.deny are configured ID = 219: Encrypt data exchanged between containers on different nodes on the overlay network ID = 8116: Ensure that the --insecure-bind-address argument is not set (kube-apiserver) ID = 6141: Ensure permissions on bootloader config are configured ID = 62213: Ensure HTTP Proxy Server is not enabled ID = 200203: Verify Windows Defender Address Space Layout Randomization (ASLR) is enabled ID = 8228: Ensure that the client certificate authorities file ownership is set to root:root ID = 5315: Verify that crio.socket file ownership is set to root:root ID = 200002: Verify Windows Defender antivirus is enabled ID = 8135: Ensure that the --service-account-private-key-file argument is set as appropriate (kube-controller-manager) ID = 81420: Ensure that the API server pod specification file ownership is set to root:root ID = 6223: Ensure Avahi Server is not enabled ID = 8133: Ensure that the --insecure-experimental-approve-all-kubelet-csrs-for-group argument is not set (kube-controller-manager) ID = 6618: Ensure permissions on /etc/group- are configured ID = 5032: Verify that /usr/lib/systemd/system/crio.service file permissions are set to 644 or more restrictive ID = 39: Docker TLS certificate authority (CA) certificate file ownership must be set to root:root ID = 6152: Ensure XD/NX support is enabled ID = 5316: Verify that crio.socket file permissions are set to 660 or more restrictive ID = 224: Ensure containers are restricted from acquiring new privileges ID = 5026: Configure TLS authentication for CRI-O daemon ID = 8314: Ensure that the --insecure-bind-address argument is not set (federation-apiserver) ID = 6614: Ensure permissions on /etc/group are configured ID = 6528: Ensure SSH root login is disabled ID = 66217: Ensure no duplicate GIDs exist ID = 5038: Verify that CRI global auth file permissions are set to 444 or more restrictive ID = 81423: Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive ID = 81122: Ensure that the --kubelet-certificate-authority argument is set as appropriate (kube-apiserver) ID = 8318: Ensure that the admission control policy is not set to AlwaysAdmit (federation-apiserver) ID = 213: Disable operations on legacy registry (v1) ID = 321: Verify that /etc/sysconfig/docker file ownership is set to root:root ID = 8212: Ensure that the --anonymous-auth argument is set to false (kubelet) ID = 32: Verify that docker.service file permissions are set to 644 or more restrictive ID = 81413: Ensure that the admin.conf file permissions are set to 644 or more restrictive ID = 81411: Ensure that the etcd data directory permissions are set to 700 or more restrictive ID = 6617: Ensure permissions on /etc/shadow- are configured ID = 200001: Verify Windows Defender antivirus is running ID = 82113: Ensure that the --cadvisor-port argument is set to 0 (kubelet) ID = 5318: Verify that crio.conf file permissions are set to 644 or more restrictive ID = 6625: Ensure root is the only UID 0 account ID = 83118: Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate (federation-apiserver) ID = 60523: Ensure permissions on SSH public host key files are configured ID = 6225: Ensure DHCP Server is not enabled ID = 8224: Ensure that the kubelet file ownership is set to root:root ID = 6112: Ensure /tmp is configured ID = 8144: Ensure that the config file ownership is set to root:root ID = 8226: Ensure that the proxy file ownership is set to root:root ID = 16: Only allow trusted users to control Docker daemon ID = 313: Docker server certificate key file ownership must be set to root:root ID = 66215: Ensure all groups in /etc/passwd exist in /etc/group ID = 6619: Ensure permissions on /etc/gshadow- are configured ID = 62110: Ensure xinetd is not enabled ID = 81429: Ensure that the Kubernetes PKI key file permissions are set to 600 ID = 8155: Ensure that the --peer-client-cert-auth argument is set to true (etcd) ID = 221: Avoid experimental features in production ID = 81425: Ensure that the etcd pod specification file permissions are set to 644 or more restrictive ID = 211: Use authorization plugin ID = 64118: Ensure the audit configuration is immutable ID = 8316: Ensure that the --secure-port argument is not set to 0 (federation-apiserver) ID = 5319: Verify that CRIO systemd daemon environment file ownership is set to root:root ID = 26: Configure TLS authentication for Docker daemon ID = 6227: Ensure NFS and RPC are not enabled ID = 34: Verify that docker.socket file permissions are set to 644 or more restrictive ID = 316: Verify that Docker socket file permissions are set to 660 or more restrictive ID = 6344: Ensure permissions on /etc/hosts.allow are configured ID = 8154: Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate (etcd) ID = 6226: Ensure LDAP server is not enabled ID = 8147: Ensure that the etcd.conf file permissions are set to 644 or more restrictive ID = 31: Verify that docker.service file ownership is set to root:root ID = 66216: Ensure no duplicate UIDs exist ID = 5035: Verify that /etc/crio and /etc/crio/conf.d directories ownership is set to root:root ID = 8115: Ensure that the --kubelet-https argument is set to true (kube-apiserver) ID = 311: Docker server certificate file ownership must be set to root:root ID = 81131: Ensure that the --etcd-cafile argument is set as appropriate (kube-apiserver) ID = 8213: Ensure that the --authorization-mode argument is not set to AlwaysAllow (kubelet) ID = 6228: Ensure DNS Server is not enabled ID = 81123: Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (kube-apiserver) ID = 318: Verify that daemon.json file permissions are set to 644 or more restrictive ID = 6321: Ensure source routed packets are not accepted ID = 8227: Ensure that the certificate authorities file permissions are set to 644 or more restrictive (kubelet) ID = 5317: Verify that crio.conf file ownership is set to root:root ID = 81130: Ensure that the --client-ca-file argument is set as appropriate (kube-apiserver) ID = 218: Disable userland Proxy ID = 223: Run swarm manager in auto-lock mode ID = 25: Do not use the aufs storage driver ID = 310: Docker TLS certificate authority (CA) certificate file permissions must be set to 444 or more restrictive ID = 312: Docker server certificate file permissions must be set to 444 or more restrictive ID = 314: Docker server certificate key file permissions must be set to 400 ID = 701070: FIPS mode must be enabled on all Docker Engine - Enterprise nodes

are set to ignore this is a finding

Enable default compliance policies.

Navigate to Prisma Cloud Compute Console’s - Defend - Vulnerabilities - Hosts - Running Hosts “Default - alert all components” and set the following policy checks checks to either alert or block

ID = 6216: Ensure rsh server is not enabled ID = 8134: Ensure that the --use-service-account-credentials argument is set to true (kube-controller-manager) ID = 81419: Ensure that the API server pod specification file permissions are set to 644 or more restrictive ID = 8145: Ensure that the scheduler file ownership is set to root:root ID = 5036: Verify that /etc/crio and /etc/crio/conf.d directories permissions are set to 755 or more restrictive ID = 8118: Ensure that the --secure-port argument is not set to 0 (kube-apiserver) ID = 200004: Verify antivirus signatures are up-to-date ID = 319: Verify that /etc/default/docker file ownership is set to root:root ID = 6529: Ensure SSH PermitEmptyPasswords is disabled ID = 66213: Ensure users' .netrc Files are not group or world accessible ID = 6518: Ensure at/cron is restricted to authorized users ID = 8112: Ensure that the --anonymous-auth argument is set to false (kube-apiserver) ID = 62216: Ensure rsync service is not enabled ID = 66218: Ensure no duplicate user names exist ID = 81418: Ensure that the controller-manager.conf file ownership is set to root:root ID = 8211: Ensure that the --allow-privileged argument is set to false (kubelet) ID = 61613: Ensure SELinux policy is configured ID = 6361: Ensure iptables is installed ID = 81421: Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive ID = 8232: Ensure that the proxy kubeconfig file ownership is set to root:root ID = 35: Verify that /etc/docker directory ownership is set to root:root ID = 65414: Ensure inactive password lock is 30 days or less ID = 81137: Ensure that the AdvancedAuditing argument is not set to false (kube-apiserver) ID = 200005: Verify antivirus signatures expiration policy ID = 81129: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kube-apiserver) ID = 8223: Ensure that the kubelet file permissions are set to 644 or more restrictive ID = 8311: Ensure that the --anonymous-auth argument is set to false (federation-apiserver) ID = 8141: Ensure that the apiserver file permissions are set to 644 or more restrictive ID = 8152: Ensure that the --client-cert-auth argument is set to true (etcd) ID = 215: Do not enable swarm mode, if not needed ID = 315: Verify that Docker socket file ownership is set to root:docker ID = 8215: Ensure that the --read-only-port argument is set to 0 (kubelet) ID = 81111: Ensure that the admission control policy is not set to AlwaysAdmit (kube-apiserver) ID = 5037: Verify that CRI global auth file ownership is set to root:root ID = 21: Restrict network traffic between containers ID = 8117: Ensure that the --insecure-port argument is set to 0 (kube-apiserver) ID = 81427: Ensure that the Kubernetes PKI directory and file ownership is set to root:root ID = 37: Verify that registry certificate file ownership is set to root:root ID = 8114: Ensure that the --insecure-allow-any-token argument is not set (kube-apiserver) ID = 8156: Ensure that the --peer-auto-tls argument is not set to true (etcd) ID = 8230: Ensure that the kubelet service file ownership is set to root:root ID = 81112: Ensure that the admission control policy is set to AlwaysPullImages (kube-apiserver) ID = 82112: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (kubelet) ID = 6143: Ensure authentication required for single user mode ID = 81127: Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate (kube-apiserver) ID = 81120: Ensure that the --authorization-mode argument is not set to AlwaysAllow (kube-apiserver) ID = 6412: Ensure auditd service is enabled ID = 8231: Ensure that the proxy kubeconfig file permissions are set to 644 or more restrictive ID = 81428: Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive ID = 81422: Ensure that the controller manager pod specification file ownership is set to root:root ID = 6229: Ensure FTP Server is not enabled ID = 6628: Ensure users' home directories permissions are 750 or more restrictive ID = 200007: Verify antispyware signatures expiration policy ID = 81410: Ensure that the flanneld file ownership is set to root ID = 8234: Ensure that the kubelet configuration file has permissions set to 644 or more restrictive ID = 64115: Ensure changes to system administration scope (sudoers) is collected ID = 6612: Ensure permissions on /etc/passwd are configured ID = 8143: Ensure that the config file permissions are set to 644 or more restrictive ID = 60522: Ensure permissions on SSH private host key files are configured ID = 8225: Ensure that the proxy file permissions are set to 644 or more restrictive ID = 6153: Ensure address space layout randomization (ASLR) is enabled ID = 24: Do not use insecure registries ID = 320: Verify that /etc/default/docker file permissions are set to 644 or more restrictive ID = 28: Enable user namespace support ID = 6521: Ensure permissions on /etc/ssh/sshd_config are configured ID = 5320: Verify that CRIO systemd daemon environment file permissions are set to 644 or more restrictive ID = 6219: Ensure tftp server is not enabled ID = 81412: Ensure that the etcd data directory ownership is set to etcd:etcd ID = 8313: Ensure that the --insecure-allow-any-token argument is not set (federation-apiserver) ID = 62212: Ensure Samba is not enabled ID = 200400: Verify Windows Update is enabled ID = 449: Ensure no pending OS security updates ID = 64116: Ensure system administrator actions (sudolog) are collected ID = 6613: Ensure permissions on /etc/shadow are configured ID = 33: Verify that docker.socket file ownership is set to root:root ID = 81132: Ensure that the --authorization-mode argument is set to Node (kube-apiserver) ID = 81417: Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive ID = 8151: Ensure that the --cert-file and --key-file arguments are set as appropriate (etcd) ID = 8214: Ensure that the --client-ca-file argument is set as appropriate (kubelet) ID = 83119: Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (federation-apiserver) ID = 200201: Verify Windows Defender Control Flow Guard (CFG) is enabled ID = 62214: Ensure SNMP Server is not enabled ID = 641113: Ensure successful file system mounts are collected ID = 8233: Ensure that the kubelet configuration file ownership is set to root:root ID = 66210: Ensure users' dot files are not group or world writable ID = 8136: Ensure that the --root-ca-file argument is set as appropriate (kube-controller-manager) ID = 38: Verify that registry certificate file permissions are set to 444 or more restrictive ID = 8111: Ensure that the --allow-privileged argument is set to false (kube-apiserver) ID = 81126: Ensure that the --service-account-key-file argument is set as appropriate (kube-apiserver) ID = 6627: Ensure all users' home directories exist ID = 6151: Ensure core dumps are restricted ID = 62210: Ensure HTTP server is not enabled ID = 62211: Ensure IMAP and POP3 server is not enabled ID = 5031: Verify that /usr/lib/systemd/system/crio.service file ownership is set to root:root ID = 81128: Ensure that the admission control plugin ServiceAccount is set (kube-apiserver) ID = 81424: Ensure that the scheduler pod specification file ownership is set to root:root ID = 8142: Ensure that the apiserver file ownership is set to root:root ID = 6629: Ensure users own their home directories ID = 81133: Ensure that the admission control policy is set to NodeRestriction (kube-apiserver) ID = 200202: Verify Windows Defender Data Execution Prevention (DEP) is enabled ID = 6224: Ensure CUPS is not enabled ID = 6621: Ensure password fields are not empty ID = 64117: Ensure kernel module loading and unloading is collected ID = 6218: Ensure telnet server is not enabled ID = 6522: Ensure SSH Protocol is set to 2 ID = 5024: Do not use insecure registries ID = 83114: Ensure that the --authorization-mode argument is not set to AlwaysAllow (federation-apiserver) ID = 61612: Ensure the SELinux state is enforcing ID = 317: Verify that daemon.json file ownership is set to root:root ID = 200006: Verify antispyware signatures are up-to-date ID = 8153: Ensure that the --auto-tls argument is not set to true (etcd) ID = 322: Verify that /etc/sysconfig/docker file permissions are set to 644 or more restrictive ID = 6615: Ensure permissions on /etc/gshadow are configured ID = 81426: Ensure that the etcd pod specification file ownership is set to root:root ID = 83117: Ensure that the --service-account-key-file argument is set as appropriate (federation-apiserver) ID = 6525: Ensure SSH MaxAuthTries is set to 4 or less ID = 7162: Ensure SELinux is installed ID = 81414: Ensure that the admin.conf file ownership is set to root:root ID = 8149: Ensure that the flanneld file permissions are set to 644 or more restrictive ID = 8315: Ensure that the --insecure-port argument is set to 0 (federation-apiserver) ID = 200401: Verify Windows Update is set to automatically install ID = 62217: Ensure NIS Server is not enabled ID = 8146: Ensure that the scheduler file permissions are set to 644 or more restrictive ID = 217: Bind swarm services to a specific host interface ID = 8229: Ensure that the kubelet service file permissions are set to 644 or more restrictive ID = 36: Verify that /etc/docker directory permissions are set to 755 or more restrictive ID = 8148: Ensure that the etcd.conf file ownership is set to root:root ID = 81138: Ensure that the --request-timeout argument is set as appropriate (kube-apiserver) ID = 61611: Ensure SELinux or AppArmor are installed ID = 6616: Ensure permissions on /etc/passwd- are configured ID = 6345: Ensure permissions on /etc/hosts.deny are configured ID = 219: Encrypt data exchanged between containers on different nodes on the overlay network ID = 8116: Ensure that the --insecure-bind-address argument is not set (kube-apiserver) ID = 6141: Ensure permissions on bootloader config are configured ID = 62213: Ensure HTTP Proxy Server is not enabled ID = 200203: Verify Windows Defender Address Space Layout Randomization (ASLR) is enabled ID = 8228: Ensure that the client certificate authorities file ownership is set to root:root ID = 5315: Verify that crio.socket file ownership is set to root:root ID = 200002: Verify Windows Defender antivirus is enabled ID = 8135: Ensure that the --service-account-private-key-file argument is set as appropriate (kube-controller-manager) ID = 81420: Ensure that the API server pod specification file ownership is set to root:root ID = 6223: Ensure Avahi Server is not enabled ID = 8133: Ensure that the --insecure-experimental-approve-all-kubelet-csrs-for-group argument is not set (kube-controller-manager) ID = 6618: Ensure permissions on /etc/group- are configured ID = 5032: Verify that /usr/lib/systemd/system/crio.service file permissions are set to 644 or more restrictive ID = 39: Docker TLS certificate authority (CA) certificate file ownership must be set to root:root ID = 6152: Ensure XD/NX support is enabled ID = 5316: Verify that crio.socket file permissions are set to 660 or more restrictive ID = 224: Ensure containers are restricted from acquiring new privileges ID = 5026: Configure TLS authentication for CRI-O daemon ID = 8314: Ensure that the --insecure-bind-address argument is not set (federation-apiserver) ID = 6614: Ensure permissions on /etc/group are configured ID = 6528: Ensure SSH root login is disabled ID = 66217: Ensure no duplicate GIDs exist ID = 5038: Verify that CRI global auth file permissions are set to 444 or more restrictive ID = 81423: Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive ID = 81122: Ensure that the --kubelet-certificate-authority argument is set as appropriate (kube-apiserver) ID = 8318: Ensure that the admission control policy is not set to AlwaysAdmit (federation-apiserver) ID = 213: Disable operations on legacy registry (v1) ID = 321: Verify that /etc/sysconfig/docker file ownership is set to root:root ID = 8212: Ensure that the --anonymous-auth argument is set to false (kubelet) ID = 32: Verify that docker.service file permissions are set to 644 or more restrictive ID = 81413: Ensure that the admin.conf file permissions are set to 644 or more restrictive ID = 81411: Ensure that the etcd data directory permissions are set to 700 or more restrictive ID = 6617: Ensure permissions on /etc/shadow- are configured ID = 200001: Verify Windows Defender antivirus is running ID = 82113: Ensure that the --cadvisor-port argument is set to 0 (kubelet) ID = 5318: Verify that crio.conf file permissions are set to 644 or more restrictive ID = 6625: Ensure root is the only UID 0 account ID = 83118: Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate (federation-apiserver) ID = 60523: Ensure permissions on SSH public host key files are configured ID = 6225: Ensure DHCP Server is not enabled ID = 8224: Ensure that the kubelet file ownership is set to root:root ID = 6112: Ensure /tmp is configured ID = 8144: Ensure that the config file ownership is set to root:root ID = 8226: Ensure that the proxy file ownership is set to root:root ID = 16: Only allow trusted users to control Docker daemon ID = 313: Docker server certificate key file ownership must be set to root:root ID = 66215: Ensure all groups in /etc/passwd exist in /etc/group ID = 6619: Ensure permissions on /etc/gshadow- are configured ID = 62110: Ensure xinetd is not enabled ID = 81429: Ensure that the Kubernetes PKI key file permissions are set to 600 ID = 8155: Ensure that the --peer-client-cert-auth argument is set to true (etcd) ID = 221: Avoid experimental features in production ID = 81425: Ensure that the etcd pod specification file permissions are set to 644 or more restrictive ID = 211: Use authorization plugin ID = 64118: Ensure the audit configuration is immutable ID = 8316: Ensure that the --secure-port argument is not set to 0 (federation-apiserver) ID = 5319: Verify that CRIO systemd daemon environment file ownership is set to root:root ID = 26: Configure TLS authentication for Docker daemon ID = 6227: Ensure NFS and RPC are not enabled ID = 34: Verify that docker.socket file permissions are set to 644 or more restrictive ID = 316: Verify that Docker socket file permissions are set to 660 or more restrictive ID = 6344: Ensure permissions on /etc/hosts.allow are configured ID = 8154: Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate (etcd) ID = 6226: Ensure LDAP server is not enabled ID = 8147: Ensure that the etcd.conf file permissions are set to 644 or more restrictive ID = 31: Verify that docker.service file ownership is set to root:root ID = 66216: Ensure no duplicate UIDs exist ID = 5035: Verify that /etc/crio and /etc/crio/conf.d directories ownership is set to root:root ID = 8115: Ensure that the --kubelet-https argument is set to true (kube-apiserver) ID = 311: Docker server certificate file ownership must be set to root:root ID = 81131: Ensure that the --etcd-cafile argument is set as appropriate (kube-apiserver) ID = 8213: Ensure that the --authorization-mode argument is not set to AlwaysAllow (kubelet) ID = 6228: Ensure DNS Server is not enabled ID = 81123: Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (kube-apiserver) ID = 318: Verify that daemon.json file permissions are set to 644 or more restrictive ID = 6321: Ensure source routed packets are not accepted ID = 8227: Ensure that the certificate authorities file permissions are set to 644 or more restrictive (kubelet) ID = 5317: Verify that crio.conf file ownership is set to root:root ID = 81130: Ensure that the --client-ca-file argument is set as appropriate (kube-apiserver) ID = 218: Disable userland Proxy ID = 223: Run swarm manager in auto-lock mode ID = 25: Do not use the aufs storage driver ID = 310: Docker TLS certificate authority (CA) certificate file permissions must be set to 444 or more restrictive ID = 312: Docker server certificate file permissions must be set to 444 or more restrictive ID = 314: Docker server certificate key file permissions must be set to 400 ID = 701070: FIPS mode must be enabled on all Docker Engine - Enterprise nodes

CAT II

Combination of the all high and critical compliance check and DISA Docker Enterprise STIG checks

RA-5

Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.

Prisma Cloud Compute Intelligence Stream is up to date

Vulnerabilities are continually discovered and the engine that performs vulnerability identification must be continually updated with the latest vulnerability signatures.

The Prisma Cloud Intelligence Stream is a real-time feed that contains vulnerability data and threat intelligence from commercial providers, Prisma Cloud Labs, and the open source community.

Applicable - Configurable

Determine if the vulnerability scan engine has up-to-date vulnerability information

Navigate to Prisma Cloud Compute Console’s - Manage - System - Intelligence and if the “Last streams update” date is older than 24 hours this is a finding

Configure vulnerability scan engine to receive frequent updates.

Depending on the Prisma Cloud Compute Console’s ability to communicate with the Intelligence Stream endpoint (https://intelligence.twistlock.com) dictates the method of vulnerability updates.

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/tools/update_intel_stream_offline.html

AC-4

Enforce approved authorizations for controlling the flow of information within the system and between connected systems

Enable Prisma Cloud Compute Network Monitoring for containers.

Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information.

Network segmentation and compartmentalization is an important part of a comprehensive defense in depth strategy. Cloud Native Network Firewall (CNNF) works as an east-west firewall for containers. It limits damage by preventing attackers from moving laterally through your environment when they’ve already compromised your perimeter.

Applicable - Configurable

Determine if east-west container traffic is monitored

Navigate to Prisma Cloud Compute Console’s - Radars - Settings - Network Monitoring and if Container network monitoring is “disabled” this is a finding

Enable east-west container traffic is monitored

Navigate to Prisma Cloud Compute Console’s - Radars - Settings - Network Monitoring and set Container network monitoring to “enabled.”

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/firewalls/cnnf_self_hosted.html

AC-4

Enforce approved authorizations for controlling the flow of information within the system and between connected systems

Enable Prisma Cloud Compute Network Monitoring for hosts.

Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information.

Network segmentation and compartmentalization is an important part of a comprehensive defense in depth strategy. Cloud Native Network Firewall (CNNF) works as an east-west firewall for hosts. It limits damage by preventing attackers from moving laterally through your environment when they’ve already compromised your perimeter.

Applicable - Configurable

Determine if east-west container traffic is monitored

Navigate to Prisma Cloud Compute Console’s - Radars - Settings - Network Monitoring and if Host network monitoring is “disabled” this is a finding

Enable east-west container traffic is monitored

Navigate to Prisma Cloud Compute Console’s - Radars - Settings - Network Monitoring and set Host network monitoring to “enabled.”

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/firewalls/cnnf_self_hosted.html

IR-4

Organizations recognize that incident response capabilities are dependent on the capabilities of organizational systems and the mission and business processes being supported by those systems. Organizations consider incident response as part of the definition, design, and development of mission and business processes and systems. Incident-related information can be obtained from a variety of sources, including audit monitoring, physical access monitoring, and network monitoring; user or administrator reports; and reported supply chain events.

Container runtime policy: Enable automatic runtime learning

Containers are discrete compute instances that can be monitored to identify runtime behaviors that are outside of the container’s intended functions.

Runtime defense is the set of features that provide both predictive and threat based active protection for running containers. For example, predictive protection includes capabilities like determining when a container runs a process not included in the origin image or creates an unexpected network socket. Threat based protection includes capabilities like detecting when malware is added to a container or when a container connects to a botnet.

Applicable - Configurable

Determine if container runtime process, file and networking modeling and enforcement is enabled

Navigate to Prisma Cloud Compute Console’s - Defend - Runtime - Container policy and if Enable automatic runtime learning is set to “off” this is a finding

Enable automatic runtime behavior modeling.

Navigate to Prisma Cloud Compute Console’s - Defend - Runtime - Container policy and set Enable automatic runtime learning to “on.”

CAT I

https://docs.prismacloudcompute.com/docs/compute_edition_21_04/runtime_defense/runtime_defense_containers.html

CM-6 b

The container platform must continuously scan images that have not instantiated as containers for vulnerabilities.

Prisma Cloud Compute must be configured to scan images that have not be instantiated as containers.

Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications.

Vulnerability scanning can be performed by the container platform or by external applications.

Prisma Cloud Compute ships with Only scan images with running containers set to on.

Applicable - Configurable

Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed.

If continuous vulnerability scans are not being performed, this is a finding.

Navigate to Prisma Cloud Compute Console’s -Manage - System - Scan: Running images, Only scan images with running containers = on this is a finding

Implement continuous vulnerability scans of container platform components, containers, and container images either by the container platform or from external vulnerability scanning applications.

Navigate to Prisma Cloud Compute Console’s -Manage - System - Scan: Running images, Only scan images with running containers set to off

CAT I

Similar to check RG-APP-000516-CTR-001335, this setting ensures that images that have not been run as a container are scanned as well