---
policy: PCI-DSS
title: Payment Card Industry - Data Security Standard (PCI-DSS)
id: pcidss_4_ocp4
version: '4.0'
source: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf

levels:
    - id: base

reference_type: pcidss4

controls:
    - id: '1.1'
      title: 'Processes and mechanisms for installing and maintaining network security controls are defined
          and understood.'
      levels:
          - base
      status: pending
      controls:
          - id: 1.1.1
            title: 'All security policies and operational procedures that are identified in Requirement
                1 are Documented, Kept up to date, In use and Known to all affected parties.'
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that security policies and
                operational procedures identified in Requirement 1 are managed in accordance with all
                elements specified in this requirement.

          - id: 1.1.2
            title: 'Roles and responsibilities for performing activities in Requirement 1 are documented,
                assigned, and understood.'
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 1 are documented, assigned and understood
                by the assigned personnel.

    - id: '1.2'
      title: 'Network Security Controls (NSCs) are configured and maintained.'
      levels:
          - base
      status: pending
      controls:
          - id: 1.2.1
            title: 'Configuration standards for NSC rulesets are Defined, Implemented and Maintained.'
            levels:
                - base
            status: not applicable
            notes: |-
                Examples of NSCs covered by these configuration standards include, but are not limited to,
                firewalls, routers configured with access control lists, and cloud virtual networks. The
                objective of this requirement is to ensure the way that NSCs are configured and operate
                are defined and consistently applied. While the tooling and standards can be automated,
                the review of allowed accesses should be manual as different sites may have different
                policies.
            rules: []

          - id: 1.2.2
            title: 'All changes to network connections and to configurations of NSCs are approved and
                managed in accordance with the change control process defined at Requirement 6.5.1.'
            levels:
                - base
            status: not applicable
            notes: |-
                Changes to network connections and NSCs cannot result in misconfiguration, implementation
                of insecure services, or unauthorized network connections. Changes to network connections
                include the addition, removal, or modification of a connection. Changes to NSC
                configurations include those related to the component itself as well as those affecting
                how it performs its security function. A formal change control process should be in place.

          - id: 1.2.3
            title: 'An accurate network diagram(s) is maintained that shows all connections between the
                CDE and other networks, including any wireless networks.'
            levels:
                - base
      # NOTE(rhmdnd): ACS can supplement this requirement through it's
      # networking graph functionality, which visually depicts the network
      # flows between resources, namespaces, and the internet. Add a rule here
      # to check if ACS is available.
            status: pending
            notes: |-
                A representation of the boundaries between the CDE, all trusted networks, and all
                untrusted networks, is maintained and available. A current network diagram(s) or other
                technical or topological solution that identifies network connections and devices can be
                used to meet this requirement.

          - id: 1.2.4
            title: 'An accurate data-flow diagram(s) is maintained'
            description: |-
                An accurate data-flow diagram(s) is maintained that meets the following:
                  - Shows all account data flows across systems and networks
                  - Updated as needed upon changes to the environment
            levels:
                - base
      # NOTE(rhmdnd): ACS can supplement this requirement through it's
      # networking graph functionality, which visually depicts the network
      # flows between resources, namespaces, and the internet. Add a rule here
      # to check if ACS is available.
            status: not applicable

          - id: 1.2.5
            title: 'All services, protocols, and ports allowed are identified, approved, and have a defined
                business need.'
            levels:
                - base
      # NOTE(rhmdnd): This is best left to the system owner to maintain, and
      # falls outside of the responsibility of OpenShift.
            status: not applicable

          - id: 1.2.6
            title: Security features are defined and implemented for all services, protocols, and ports
                that are in use and considered to be insecure, such that the risk is mitigated.
            levels:
                - base
            status: partial
            notes: |-
                The specific risks associated with the use of insecure services,
                protocols, and ports are understood, assessed, and appropriately
                mitigated.
      # NOTE(rhmdnd): Implement a rule to check for a default network policy
      # for new projects. Good practice would be to have a deny by default
      # network policy. See the following documentation for how to configure
      # this in the OpenShift configuration:
      # https://docs.openshift.com/container-platform/latest/networking/network_policy/default-network-policy.html
            rules:
                - configure_network_policies_namespaces
                - configure_network_policies_hypershift_hosted

          - id: 1.2.7
            title: Configurations of NSCs are reviewed at least once every six months to confirm they
                are relevant and effective.
            description: |-
                NSC configurations that allow or restrict access to trusted networks are verified
                periodically to ensure that only authorized connections with a current business
                justification are permitted.
            levels:
                - base
      # NOTE(rhmdnd): Support for expiring network policies, with the default
      # behavior to deny-all would be a nice feature here to help fulfill this
      # because the expiration would be set to 6 months or less. Then we'd have
      # an attribute to check on each network policy to ensure they're getting
      # reviewed to fulfill this requirement. Marking this as not applicable
      # since network policies don't have an expiration function.
            status: not applicable

          - id: 1.2.8
            title: Configuration files for NSCs are secured from unauthorized access and kept consistent
                with active network configurations.
            levels:
                - base
      # NOTE(rhmdnd): Access to OpenShift configuration falls outside the scope
      # of the Compliance Operator. While network policies and ingress/egress
      # configuration is within the realm of OpenShift, it's up to the system
      # owner to make sure those configurations are secured before, during, and
      # after being applied to an OpenShift environment.
            status: not applicable
            rules: []

    - id: '1.3'
      title: Network access to and from the cardholder data environment is restricted.
      levels:
          - base
      status: partial
      controls:
          - id: 1.3.1
            title: Inbound traffic to the CDE is restricted to only traffic that is necessary
            description: |-
                Inbound traffic to the CDE is restricted as follows:
                - To only traffic that is necessary.
                - All other traffic is specifically denied.
            levels:
                - base
            status: partial
      # NOTE(rhmdnd): Include another rule here for ingress configuration once
      # https://issues.redhat.com/browse/CMP-2407 is implemented.
            rules:
                - configure_network_policies_namespaces
                - configure_network_policies_hypershift_hosted

          - id: 1.3.2
            title: Outbound traffic from the CDE is restricted to only traffic that is necessary
            description: |-
                Outbound traffic from the CDE is restricted as follows:
                - To only traffic that is necessary.
                - All other traffic is specifically denied.
            levels:
                - base
            status: pending
      # NOTE(rhmdnd): Include another rule here for egress configuration once
      # https://issues.redhat.com/browse/CMP-2467 is implemented.
            notes: |-
                It appears there is no rule in the project to restrict outbound traffic on the firewall.
                Perhaps a rule to automates this would do more harm than good. Probably a manual
                assessment is more reasonable here.

          - id: 1.3.3
            title: NSCs are installed between all wireless networks and the CDE, regardless of whether
                the wireless network is a CDE.
            description: |-
                NSCs are installed between all wireless networks and the CDE, regardless of whether the
                wireless network is a CDE, such that:
                - All wireless traffic from wireless networks into the CDE is denied by default.
                - Only wireless traffic with an authorized business purpose is allowed into the CDE.
            levels:
                - base
      # NOTE(rhmdnd): Not applicable to OpenShift configuration, but more so
      # the configuration of the underlying RHCOS servers. We should pull in
      # any rules here through the RHCOS/RHEL profile.
            status: not applicable

    - id: '1.4'
      title: Network connections between trusted and untrusted networks are controlled.
      levels:
          - base
      status: pending
      controls:
          - id: 1.4.1
            title: NSCs are implemented between trusted and untrusted networks.
            description: |-
                Unauthorized traffic cannot traverse network boundaries between trusted and untrusted
                networks.
            levels:
                - base
            status: automated
            notes: |-
                Trusted and untrusted networks are expected to be different for each environment.
                But loopback traffic is assumed to be trusted and even necessary for some services.
                This requirement is complements 1.2.1 and 1.3.1 requirements.
      # NOTE(rhmdnd): Include additional rules here for ingress and egress
      # firewall configuration when we have them.
      # https://issues.redhat.com/browse/CMP-2467
      # https://issues.redhat.com/browse/CMP-2407
            rules:
                - configure_network_policies
                - configure_network_policies_namespaces
                - configure_network_policies_hypershift_hosted

          - id: 1.4.2
            title: Inbound traffic from untrusted networks to trusted networks is restricted.
            description: |-
                Inbound traffic from untrusted networks to trusted networks is restricted to:
                - Communications with system components that are authorized to provide publicly accessible
                services, protocols, and ports.
                - Stateful responses to communications initiated by system components in a trusted network.
                - All other traffic is denied.
            levels:
                - base
            status: pending
      # NOTE(rhmdnd): Include additional rules here for ingress firewall
      # configuration when we have them.
      # https://issues.redhat.com/browse/CMP-2407

          - id: 1.4.3
            title: Anti-spoofing measures are implemented to detect and block forged source IP addresses
                from entering the trusted network.
            levels:
                - base
            status: not applicable
            notes: |-
                Anti-spoofing and blocking forged IP addresses is outside the scope
                of the OpenShift Container Platform.

          - id: 1.4.4
            title: System components that store cardholder data are not directly accessible from untrusted
                networks.
            levels:
                - base
            status: pending
      # NOTE(rhmdnd): Include additional rules here for ingress and egress
      # firewall configuration when we have them.
      # https://issues.redhat.com/browse/CMP-2467
      # https://issues.redhat.com/browse/CMP-2407
            notes: |-
                This requirement is not intended to apply to storage of account data in volatile memory
                but does apply where memory is being treated as persistent storage (for example, RAM
                disk). Account data can only be stored in volatile memory during the time necessary to
                support the associated business process (for example, until completion of the related
                payment card transaction).

          - id: 1.4.5
            title: The disclosure of internal IP addresses and routing information is limited to only
                authorized parties.
            description: |-
                Internal network information is protected from unauthorized disclosure.
            levels:
                - base
            status: not applicable
            notes: |-
                Protection from IP address disclosure can be handled by solutions
                outside of OpenShift.

    - id: '1.5'
      title: Risks to the CDE from computing devices that are able to connect to both untrusted networks
          and the CDE are mitigated.
      levels:
          - base
      status: not applicable
      controls:
          - id: 1.5.1
            title: Security controls are implemented on any computing devices, including company- and
                employee-owned devices, that connect to both untrusted networks (including the Internet)
                and the CDE
            description: |-
                Security controls are implemented on any computing devices, including company- and
                employee-owned devices, that connect to both untrusted networks (including the Internet)
                and the CDE as follows:
                - Specific configuration settings are defined to prevent threats being introduced into the
                entity's network.
                - Security controls are actively running.
                - Security controls are not alterable by users of the computing devices unless
                specifically documented and authorized by management on a case-by-case basis for a limited
                period.
            levels:
                - base
            status: not applicable
            notes: |-
                This control depends on the context in which OpenShift is used. If
                OpenShift is used to host the CDE, then devices used to connext to
                the CDE and the security controls they implement fall outside the
                scope of OpenShift. If OpenShift is being used to interact with a
                CDE, then implementing network segmentation and access control for
                OpenShift network functionality may be required.

    - id: '2.1'
      title: Processes and mechanisms for applying secure configurations to all system components are
          defined and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 2.1.1
            title: All security policies and operational procedures that are identified in Requirement
                2 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that security policies and
                operational procedures identified in Requirement 2 are managed in accordance with all
                elements specified in this requirement.

          - id: 2.1.2
            title: Roles and responsibilities for performing activities in Requirement 2 are documented,
                assigned, and understood.
            description: |-
                Day-to-day responsibilities for performing all the activities in Requirement 2 are
                allocated. Personnel are accountable for successful, continuous operation of these
                requirements.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 2 are documented, assigned and understood
                by the assigned personnel.

    - id: '2.2'
      title: System components are configured and managed securely
      levels:
          - base
      status: partial
      controls:
          - id: 2.2.1
            title: Configuration standards are developed, implemented, and maintained
            description: |-
                Configuration standards are developed, implemented, and maintained to:
                - Cover all system components.
                - Address all known security vulnerabilities.
                - Be consistent with industry-accepted system hardening standards or vendor hardening
                recommendations.
                - Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
                - Be applied when new systems are configured and verified as in place before or
                immediately after a system component is connected to a production environment.
            levels:
                - base
            status: partial
            notes: |-
                The Compliance Operator provides an automated way of checking for a secure configuration
                of OpenShift according to known security standards, as well as automatically remediating
                deviations from the target configuration.
                Its usage is recommended to ensure appropriate configuration and is set and prevent drift.

                System components outside of OpenShift cannot be checked by the Compliance Operator.

                This control is also addressed by applying the OpenShift CIS recommendations.
            rules:
                - scansettingbinding_exists
            controls:
                - cis_ocp:all:level_2

          - id: 2.2.2
            title: Vendor default accounts are managed
            description: |-
                Vendor default accounts are managed as follows:
                - If the vendor default account(s) will be used, the default password is changed per
                Requirement 8.3.6.
                - If the vendor default account(s) will not be used, the account is removed or disabled.
            levels:
                - base
            status: automated
            notes: |-
                The Openshift Platform doesn't come with any hardcoded credentials or passwords.
                Authenticators are uniquely created at deployment-time, including credentials
                for an admin user (called `kubeadmin`) which is meant for bootstrapping purposes.
                It is recommended for deployers to delete this account in favor of using an IdP
                and setting up appropriate permissions via RBAC roles.
            rules:
                - kubeadmin_removed

          - id: 2.2.3
            title: Primary functions requiring different security levels are managed
            description: |-
                Primary functions requiring different security levels are managed as follows:
                - Only one primary function exists on a system component
                OR
                - Primary functions with differing security levels that exist on the same system component
                are isolated from each other
                OR
                - Primary functions with differing security levels on the same system component are all
                secured to the level required by the function with the highest security need.
            levels:
                - base
            status: inherently met
            notes: |-
                OpenShift nodes run RHEL CoreOS by default, which contains only the
                necessary services, protocols and daemons needed to run OpenShift and
                containers. OpenShift provides the means to separate application
                workloads within the cluster onto separate hosts and containers. It
                is the responsibility of the organization to appropriately separate
                their applications into relevant containers to meet this control.
            rules: []

          - id: 2.2.4
            title: Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary
                functionality is removed or disabled
            description: |-
                System components cannot be compromised by exploiting unnecessary functionality present in
                the system component.
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform uses RHEL CoreOS by default. In itself, it's
                a minimal operating system with the sole purpose of running OpenShift. Therefore
                it doesn't contain extra packages or functionality; only the minimal that's meant
                to run OpenShift. RHCOS is the recommended operating system for OpenShift.
            rules: []

          - id: 2.2.5
            title: If any insecure services, protocols, or daemons are present, business justification
                is documented and the risk is reduced.
            description: |-
                If any insecure services, protocols, or daemons are present:
                - Business justification is documented.
                - Additional security features are documented and implemented that reduce the risk of
                using insecure services, protocols, or daemons.
            levels:
                - base
            status: automated
            notes: |-
                OpenShift does not require any insecure services, protocols or daemons for
                proper functioning. The deployment comes with TLS enabled by default with
                strong ciphers and an appropriate version enabled.
            rules:
                - api_server_bind_address
                - api_server_client_ca
                - api_server_etcd_ca
                - api_server_etcd_cert
                - api_server_etcd_key
                - api_server_kubelet_certificate_authority
                - api_server_oauth_https_serving_cert
                - api_server_openshift_https_serving_cert
                - api_server_service_account_public_key
                - api_server_tls_cert
                - api_server_tls_cipher_suites
                - api_server_tls_private_key
                - controller_service_account_private_key
                - etcd_cert_file
                - etcd_client_cert_auth
                - etcd_key_file
                - etcd_peer_cert_file
                - etcd_peer_client_cert_auth
                - etcd_peer_key_file
                - kubelet_configure_tls_cert
                - kubelet_configure_tls_key

          - id: 2.2.6
            title: System security parameters are configured to prevent misuse.
            description: |-
                System components cannot be compromised because of incorrect security parameter
                configuration.
            levels:
                - base
            status: automated
            notes: |-
                While it's possible to manually configure the security settings
                in the Openshift Container Platform, the Compliance Operator provides
                an automated way of checking for a secure configuration and automatically
                remediating issues according to known security standards. Its usage
                is recommended to ensure appropriate configuration is set and prevent
                drift.

                Additionaly, as part of 2.2.1, the CIS recommendations for OpenShift are applied in order
                to prevent system misconfiguration and misuse.
            rules:
                - scansettingbinding_exists

          - id: 2.2.7
            title: All non-console administrative access is encrypted using strong cryptography.
            description: |-
                Cleartext administrative authorization factors cannot be read or intercepted from any
                network transmissions. This includes administrative access via browser-based interfaces
                and application programming interfaces (APIs).
            levels:
                - base
            status: automated
            notes: |-
                Related to requirement 12.3.3.
            rules:
                - api_server_bind_address
                - api_server_client_ca
                - api_server_etcd_ca
                - api_server_etcd_cert
                - api_server_etcd_key
                - api_server_https_for_kubelet_conn
                - api_server_kubelet_certificate_authority
                - api_server_oauth_https_serving_cert
                - api_server_openshift_https_serving_cert
                - api_server_service_account_public_key
                - api_server_tls_cert
                - api_server_tls_cipher_suites
                - api_server_tls_private_key
                - controller_service_account_private_key
                - etcd_cert_file
                - etcd_client_cert_auth
                - etcd_key_file
                - etcd_peer_cert_file
                - etcd_peer_client_cert_auth
                - etcd_peer_key_file
                - kubelet_configure_tls_cert
                - kubelet_configure_tls_key
                - ocp_no_ldap_insecure

    - id: '2.3'
      title: Wireless environments are configured and managed securely.
      levels:
          - base
      status: not applicable
      controls:
          - id: 2.3.1
            title: For wireless environments connected to the CDE or transmitting account data, all wireless
                vendor defaults are changed at installation or are confirmed to be secure.
            description: |-
                For wireless environments connected to the CDE or transmitting account data, all wireless
                vendor defaults are changed at installation or are confirmed to be secure, including but
                not limited to:
                - Default wireless encryption keys.
                - Passwords on wireless access points.
                - SNMP defaults.
                - Any other security-related wireless vendor defaults.
            levels:
                - base
            status: not applicable
            notes: |-
                The OpenShift Container Platform doesn't manage wireless encryptions keys nor wireless
                access points passwords.
            related_rules:
        # NOTE: (yuumasato): the node OS can explicitly disable wireless interfaces
                - wireless_disable_interfaces

          - id: 2.3.2
            title: For wireless environments connected to the CDE or transmitting account data, wireless
                encryption keys are changed
            description: |-
                For wireless environments connected to the CDE or transmitting account
                data, wireless encryption keys are changed
            levels:
                - base
            status: not applicable
            notes: |-
                The OpenShift Container Platform doesn't manage wireless encryptions keys nor wireless
                access points passwords.

    - id: '3.1'
      title: Processes and mechanisms for protecting stored account data are defined and understood.
      levels:
          - base
      status: pending
      controls:
          - id: 3.1.1
            title: All security policies and operational procedures that are identified in Requirement
                3 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that security policies and
                operational procedures identified in Requirement 3 are managed in accordance with all
                elements specified in this requirement.

          - id: 3.1.2
            title: Roles and responsibilities for performing activities in Requirement 3 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 3 are documented, assigned and understood
                by the assigned personnel.

    - id: '3.2'
      title: Storage of account data is kept to a minimum.
      levels:
          - base
      status: pending
      controls:
          - id: 3.2.1
            title: Account data storage is kept to a minimum through implementation of data retention
                and disposal policies, procedures, and processes.
            description: |-
                Account data storage is kept to a minimum through implementation of data retention and
                disposal policies, procedures, and processes that include at least the following:
                - Coverage for all locations of stored account data.
                - Coverage for any sensitive authentication data (SAD) stored prior to completion of
                authorization.
                - Limiting data storage amount and retention time to that which is required for legal or
                regulatory, and/or business requirements.
                - Specific retention requirements for stored account data that defines length of retention
                period and includes a documented business justification.
                - Processes for secure deletion or rendering account data unrecoverable when no longer
                needed per the retention policy.
                - A process for verifying, at least once every three months, that stored account data
                exceeding the defined retention period has been securely deleted or rendered unrecoverable.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift does not directly manage any account data. It is up to the application handling
                account data to appropriately store and dispose of this data.

    - id: '3.3'
      title: Sensitive authentication data (SAD) is not stored after authorization.
      levels:
          - base
      status: not applicable
      controls:
          - id: 3.3.1
            title: SAD is not retained after authorization, even if encrypted. All sensitive authentication
                data received is rendered unrecoverable upon completion of the authorization process.
            description: |-
                This requirement is not eligible for the customized approach. This requirement does not
                apply to issuers and companies that support issuing services (where SAD is needed for a
                legitimate issuing business need) and have a business justification to store the sensitive
                authentication data. Refer to Requirement 3.3.3 for additional requirements specifically
                for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1
                through 3.3.1.3.
            levels:
                - base
            status: not applicable
            notes: |-
                Proper design of the application by the payment entity can accommodate this requirement as
                a processing mandate, restricting in-memory process for this data and taking care not to
                write to file storage from within the container or pod.

            controls:
                - id: 3.3.1.1
                  title: The full contents of any track are not retained upon completion of the authorization
                      process.
                  description: |-
                      This requirement is not eligible for the customized approach. In the normal course of
                      business, the following data elements from the track may need to be retained:
                      - Cardholder name.
                      - Primary account number (PAN).
                      - Expiration date.
                      - Service code.
                      To minimize risk, store securely only these data elements as needed for business.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift does not directly manage any track data. It is up to the application to
                      appropriately store and dispose of this data.

                - id: 3.3.1.2
                  title: The card verification code is not retained upon completion of the authorization
                      process.
                  description: |-
                      This requirement is not eligible for the customized approach. The card verification code
                      is the three- or four-digit number printed on the front or back of a payment card used
                      to verify card-not-present transactions.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift does not directly manage any card verification code. It is up to the
                      application to appropriately store and dispose of this data.

                - id: 3.3.1.3
                  title: The personal identification number (PIN) and the PIN block are not retained
                      upon completion of the authorization process.
                  description: |-
                      This requirement is not eligible for the customized approach. PIN blocks are encrypted
                      during the natural course of transaction processes, but even if an entity encrypts the
                      PIN block again, it is still not allowed to be stored after the completion of the
                      authorization process.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift does not directly manage any cardc PIN or PIN block. It is up to the
                      application to appropriately dispose of this data.

          - id: 3.3.2
            title: SAD that is stored electronically prior to completion of authorization is encrypted
                using strong cryptography.
            description: |-
                This requirement is not eligible for the customized approach. Whether SAD is permitted to
                be stored prior to authorization is determined by the organizations that manage compliance
                programs (for example, payment brands and acquirers). Contact the organizations of
                interest for any additional criteria. This requirement applies to all storage of SAD, even
                if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional
                requirement that applies if SAD is stored prior to completion of authorization. This
                requirement does not apply to issuers and companies that support issuing services where
                there is a legitimate issuing business justification to store SAD. Refer to Requirement
                3.3.3 for requirements specifically for issuers. This requirement does not replace how PIN
                blocks are required to be managed, nor does it mean that a properly encrypted PIN block
                needs to be encrypted again.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift does not directly manage any SAD. It is up to the application to
                appropriately store and dispose of this data.

          - id: 3.3.3
            title: Additional requirement for issuers and companies that support issuing services and
                store sensitive authentication data.
            description: |-
                Additional requirement for issuers and companies that support issuing services and store
                sensitive authentication data: Any storage of sensitive authentication data is:
                - Limited to that which is needed for a legitimate issuing business need and is secured.
                - Encrypted using strong cryptography. This bullet is a best practice until until
                31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be
                fully considered during a PCI DSS assessment.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift does not directly manage any SAD. It is up to the application to
                appropriately store and dispose of this data.

    - id: '3.4'
      title: Access to displays of full PAN and ability to copy PAN is restricted.
      levels:
          - base
      status: not applicable
      controls:
          - id: 3.4.1
            title: PAN is masked when displayed (the BIN and last four digits are the maximum number
                of digits to be displayed), such that only personnel with a legitimate business need
                can see more than the BIN and last four digits of the PAN.
            description: |-
                PAN displays are restricted to the minimum number of digits necessary to meet a defined
                business need. This requirement does not supersede stricter requirements in place for
                displays of cardholder data — for example, legal or payment brand requirements for
                point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is
                displayed on screens, paper receipts, printouts, etc., and is not to be confused with
                Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift doesn't directly handle PANs.
                Handling and masking the PAN is resposibility of the application installed.

          - id: 3.4.2
            title: When using remote-access technologies, technical controls prevent copy and/or relocation
                of PAN for all personnel, except for those with documented, explicit authorization and
                a legitimate, defined business need.
            description: |-
                PAN cannot be copied or relocated by unauthorized personnel using remote-access
                technologies. Storing or relocating PAN onto local hard drives, removable electronic
                media, and other storage devices brings these devices into scope for PCI DSS.
                This requirement is a best practice until 31 March 2025, after which it will be required
                and must be fully considered during a PCI DSS assessment.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift doesn't directly handle PANs.
                Handling and masking the PAN is resposibility of the application installed.
                Access control, storage at rest and transport medium are to be managed by the application.

    - id: '3.5'
      title: Primary account number (PAN) is secured wherever it is stored.
      levels:
          - base
      status: pending
      controls:
          - id: 3.5.1
            title: PAN is rendered unreadable anywhere it is stored
            description: |-
                PAN is rendered unreadable anywhere it is stored by using any of the following approaches:
                - One-way hashes based on strong cryptography of the entire PAN.
                - Truncation (hashing cannot be used to replace the truncated segment of PAN).
                  - If hashed and truncated versions of the same PAN, or different truncation formats of
                  the same PAN, are present in an environment, additional controls are in place such that
                  the different versions cannot be correlated to reconstruct the original PAN.
                - Indexes tokens.
                - Strong cryptography with associated key-management processes and procedures.
            levels:
                - base
            status: partial
            controls:
                - id: 3.5.1.1
                  title: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1)
                      are keyed cryptographic hashes of the entire PAN, with associated key-management
                      processes and procedures in accordance with Requirements 3.6 and 3.7.
                  description: |-
                      This requirement applies to PANs stored in primary storage (databases, or flat files
                      such as text files spreadsheets) as well as non-primary storage (backup, audit logs,
                      exception, or troubleshooting logs) must all be protected. This requirement does not
                      preclude the use of temporary files containing cleartext PAN while encrypting and
                      decrypting PAN. This requirement is considered a best practice until 31 March 2025,
                      after which it will be required and must be fully considered during a PCI DSS
                      assessment.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift doesn't directly handle PANs.
                      Handling and masking the PAN is resposibility of the workload / application installed.

                - id: 3.5.1.2
                  title: If disk-level or partition-level encryption (rather than file-, column-, or
                      field-level database encryption) is used to render PAN unreadable, it is implemented
                      only on removable electronic media or complemented by another mechanism that meets
                      Requirement 3.5.1
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      This requirement is about ensuring PANs are also masked when disk-level and partition-level
                      encryption is used.
                      Handling and masking the PAN is resposibility of the workload / application installed.

                - id: 3.5.1.3
                  title: If disk-level or partition-level encryption is used (rather than file-, column-,
                      or field--level database encryption) to render PAN unreadable, it is managed.
                  description: |-
                      If disk-level or partition-level encryption is used (rather than file-, column-, or
                      field--level database encryption) to render PAN unreadable, it is managed as follows:
                      - Logical access is managed separately and independently of native operating system
                      authentication and access control mechanisms.
                      - Decryption keys are not associated with user accounts.
                      - Authentication factors (passwords, passphrases, or cryptographic keys) that allow
                      access to unencrypted data are stored securely.
                  levels:
                      - base
                  status: partial
                  notes: |-
                      Disk-level encryption is a node configuration, but it can be managed by the NBDE
                      Tang Server Operator to automatically unlock LUKS-encrypted volumes and rotate keys.

                      In case where card holder data may be stored on worker nodes disks, OpenShift Container
                      Platform can help to partially
                      comply with this requirement by providing several means of fully encrypting disks.
                      * Using RHEL core crypto components which are FIPS certified
                      * Or using cloud provider techniques, such as EBS encryption for AWS case.
                      For this requirement, we also check etcd is encrypted, so that secrets, but also routes
                      and oauth configurations are secured.

                      Concerning Full Disk Encryption:
                      Full Disk Encryption can be enabled on OpenShift by installing the cluster with FIPS mode
                      enabled.
                      OpenShift Container Platform uses certain FIPS Validated / Modules in Process modules
                      within RHEL and RHCOS for the operating system components that it uses.
                      See RHEL core crypto components and
                      https://docs.openshift.com/container-platform/latest/installing/installing-fips.html for
                      further information.
                      When installing the cluster, The public ssh key is passed to the Red Hat Enterprise Linux
                      CoreOS (RHCOS) nodes through their Ignition config files and is used to authenticate SSH
                      access to the nodes. The key is added to the ~/.ssh/authorized_keys list for the core user
                      on each node, which enables password-less authentication.

                      The management of the private key is up to the customer.
                      LUKS/dm-crypt (used by the FIPS mode) provides full-disk encryption that fulfills
                      requirement 3.4.1.
                      Access to the stored data is only possible via a decryption password that must be entered
                      when the disk is mounted .
                      The disk can be encrypted using a TPM v2, a secure cryptoprocessor contained
                      within a server; or a Tang server, a network-bound disk encryption (NBDE).

                      The NBDE Tang Server Operator can provide automatic unlocking of LUKS-encrypted volumes
                      and key rotation.
                  rules:
                      - machine_volume_encrypted
                      - storageclass_encryption_enabled
                      - api_server_encryption_provider_cipher
        # NOTE yuumasato: When RHCOS is supported we can add rules to check whether the encrypted
        # volume is bound to a Tang server.

    - id: '3.6'
      title: Cryptographic keys used to protect stored account data are secured.
      levels:
          - base
      status: inherently met
      notes: |-
          The cryptographic keys created and managed by OpenShift are secured by default.
          However, the keys created and managed by the application should be secured by the application
          and the organization's processes.
      controls:
          - id: 3.6.1
            title: Procedures are defined and implemented to protect cryptographic keys used to protect
                stored account data against disclosure and misuse.
            description: |-
                Procedures are defined and implemented to protect cryptographic keys used to protect
                stored account data against disclosure and misuse that include:
                - Access to keys is restricted to the fewest number of custodians necessary.
                - Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
                - Key-encrypting keys are stored separately from data-encrypting keys.
                - Keys are stored securely in the fewest possible locations and forms.
            levels:
                - base
            status: pending
            controls:
                - id: 3.6.1.1
                  title: 'Additional requirement for service providers only: A documented description
                      of the cryptographic architecture is maintained'
                  description: |-
                      Additional requirement for service providers only: A documented description of the
                      cryptographic architecture is maintained that includes:
                      - Details of all algorithms, protocols, and keys used for the protection of stored
                      account data, including key strength and expiry date.
                      - Preventing the use of the same cryptographic keys in production and test environments.
                      This bullet is a best practice until 31 March 2025, after which it will be required as
                      part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment.
                      - Description of the key usage for each key.
                      - Inventory of any hardware security modules (HSMs), key management systems (KMS), and
                      other secure cryptographic devices (SCDs) used for key management, including type and
                      location of devices, as outlined in Requirement 12.3.4.
                  levels:
                      - base
                  notes: |-
                      This requirement largely depends on the solution chosen by the customer to protect card
                      holder data at rest.
                      * When Full Disk Encryption is done using AWS EBS encryption, the algorithm used is
                        AES-256.
                        Your data key is stored on disk with your encrypted data, but not before EBS encrypts it
                        with your KMS key.
                        Your data key never appears on disk in plaintext.
                        The same data key is shared by snapshots of the volume and any subsequent volumes
                        created from those snapshots.
                        See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
                      * When Full Disk Encryption is done using LUKS with TPM2, full disk encryption utilities
                        such as dm-crypt and
                        BitLocker encrypt disks with a TPM bind key, and then store the TPM bind key in the TPM
                        (Trusted Platform Module),
                        which is a secure element attached to the motherboard of the node.
                        The main benefit of this method is that there is no external dependency, and the node is
                        able to decrypt its own
                        disks at boot time without any external interaction.
                      * When Full Disk Encryption is done using LUKS with Tang, the booting node attempts to
                        contact a predefined set
                        of Tang servers by performing a cryptographic handshake. If it can reach the required
                        number of Tang servers,
                        the node can construct its disk decryption key and unlock the disks to continue booting.
                      See https://docs.openshift.com/container-platform/4.9/security/network_bound_disk_encryption/nbde-about-disk-encryption-technology.html
                  status: inherently met

                - id: 3.6.1.2
                  title: Secret and private keys used to encrypt/decrypt stored account data are stored
                      in secure forms.
                  description: |-
                      Secret and private keys used to encrypt/decrypt stored account data are stored in one
                      (or more) of the following forms at all times:
                      - Encrypted with a key-encrypting key that is at least as strong as the data-encrypting
                      key, and that is stored separately from the data-encrypting key.
                      - Within a secure cryptographic device (SCD), such as a hardware security module (HSM)
                      or PTS-approved point-of-interaction device.
                      - As at least two full-length key components or key shares, in accordance with an
                      industry-accepted method.
                      Secret and private keys are stored in a secure form that prevents unauthorized retrieval
                      or access. It is not required that public keys be stored in one of these forms.
                      Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are
                      acceptable. A cryptographic key that is split into two parts does not meet this
                      requirement. Secret or private keys stored as key components or key shares must be
                      generated via one of the following
                  levels:
                      - base
                  status: inherently met

                - id: 3.6.1.3
                  title: Access to cleartext cryptographic key components is restricted to the fewest
                      number of custodians necessary.
                  description: |-
                      Access to cleartext cryptographic key components is restricted to necessary personnel.
                  levels:
                      - base
                  status: inherently met
                  notes: |-
                      This requirement largely depends on the solution chosen by the customer to protect card
                      holder data at rest.
                      * When Full Disk Encryption is done using AWS EBS encryption, the data key, used for
                        volume encryption, is generated
                        by AWS KMS, encrypted with the Key Encryption Key that lies in the KMS and stored with
                        the volume metadata, by EBS.
                        It is the payment entity's responsibility to limit the access to this key by ensuring
                        that Grant requests to decrypt
                        the data key using the KEK (Key Encryption Key) is given only to the need to know users
                        or AWS resources.
                        See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
                      * When Full Disk Encryption is done using LUKS with TPM2, the TPM bind key, which is used
                      to decrypt the data key is
                        stored in the TPM (Trusted Platform Module), on the motherboard of the node.
                        It is therefore not shared with anyone.
                      * When Full Disk Encryption is done using LUKS with Tang, Tang server does not store the
                      encryption key directly,
                        and never interacts with it. The metadata needed to decrypt the volume is stored on the
                        disk but can only be
                        unlocked and used when the node can correctly establish the handshake with the Tang
                        server. The data key is therefore not shared with anyone.

                - id: 3.6.1.4
                  title: Cryptographic keys are stored in the fewest possible locations.
                  description: |-
                      Cryptographic keys are retained only where necessary.
                  levels:
                      - base
                  status: inherently met
                  notes: |-
                      This requirement depends on the solution chosen by the customer to protect card holder
                      data at rest:
                      * When Full Disk Encryption is done using AWS EBS encryption, the data key is stored in
                        the volume's metadata only.
                        The KEK is stored in the AWS KMS only.
                      * When Full Disk Encryption is done using LUKS with TPM2, the TPM bind key is stored in
                        the TPM (Trusted Platform Module) only.
                        The encrypted data key is stored on the MBR of the disk only.
                      * When Full Disk Encryption is done using LUKS with Tang, the encryption key is not stored
                        to disk. Only the provisioning metadata is. A POST to the Tang server would allow the
                        node to recompute the encryption key from this metadata.
                        See https://github.com/latchset/tang

    - id: '3.7'
      title: Where cryptography is used to protect stored account data, key management processes and
          procedures covering all aspects of the key lifecycle are defined and implemented.
      levels:
          - base
      status: not applicable
      controls:
          - id: 3.7.1
            title: Key-management policies and procedures are implemented to include generation of strong
                cryptographic keys used to protect stored account data.
            description: |-
                Strong cryptographic keys are generated.
            levels:
                - base
            status: not applicable
            notes: |-
                Although some key management processes rely on OpenShift Container Platform and its
                underlying components for Full Disk Encryption, the responsibility for documentation and
                implementation of key-management processes and procedures for cryptographic keys used for
                encryption of cardholder data is still on the payment service and its
                operations team in order to cover all aspects of cardholder data protection.

          - id: 3.7.2
            title: Key-management policies and procedures are implemented to include secure distribution
                of cryptographic keys used to protect stored account data.
            description: |-
                Cryptographic keys are secured during distribution.
            levels:
                - base
            status: not applicable

          - id: 3.7.3
            title: Key-management policies and procedures are implemented to include secure storage of
                cryptographic keys used to protect stored account data.
            description: |-
                Cryptographic keys are secured when stored.
            levels:
                - base
            status: not applicable
            notes: |-
                TPM

          - id: 3.7.4
            title: Key management policies and procedures are implemented for cryptographic key changes
                for keys that have reached the end of their cryptoperiod, as defined by the associated
                application vendor or key owner, and based on industry best practices and guidelines.
            description: |-
                Key management policies and procedures are implemented for cryptographic key changes for
                keys that have reached the end of their cryptoperiod, as defined by the associated
                application vendor or key owner, and based on industry best practices and guidelines,
                including the following:
                - A defined cryptoperiod for each key type in use.
                - A process for key changes at the end of the defined cryptoperiod.
            levels:
                - base
            notes: |-
                It is the responsibility of the payment entity's operations team to rotate the
                encryption keys when they expire, according to the solution chosen for full disk
                encryption:
                * AWS EBS Encryption: Operations team creates a snapshot of the volume and then uses
                  the snapshot to create a new, encrypted copy of the volume. While creating the new volume,
                  a new encryption key is specified.
                * LUKS encryption with TPM2: The TPM secret cannot be modified after disk creation.
                * LUKS encryption with Tang: The operations performs the Tang Keys rotation as described in
                  https://access.redhat.com/solutions/4074891
            status: not applicable

          - id: 3.7.5
            title: Key management policies procedures are implemented to include the retirement, replacement,
                or destruction of keys used to protect stored account data, as deemed necessary.
            description: |-
                Key management policies procedures are implemented to include the retirement, replacement,
                or destruction of keys used to protect stored account data, as deemed necessary when:
                - The key has reached the end of its defined cryptoperiod.
                - The integrity of the key has been weakened, including when personnel with knowledge of a
                cleartext key component leaves the company, or the role for which the key component was
                known.
                - The key is suspected of or known to be compromised.
                - Retired or replaced keys are not used for encryption operations.
            levels:
                - base
            notes: |-
                It is the responsibility of the payment entity's operations team to retire or
                replace weakened keys
            status: not applicable

          - id: 3.7.6
            title: Where manual cleartext cryptographic key-management operations are performed by personnel,
                key-management policies and procedures are implemented include managing these operations
                using split knowledge and dual control.
            description: |-
                Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext
                keys cannot be carried out by a single person. This control is applicable for manual
                key-management operations or where key management is not controlled by the encryption
                product. A cryptographic key that is simply split into two parts does not meet this
                requirement. Secret or private keys stored as key components or key shares must be
                generated via one of the following
            levels:
                - base
            notes: |-
                Manual clear-text cryptographic key-management operations are not used in the context of
                Openshift Container Platform
            status: not applicable

          - id: 3.7.7
            title: Key management policies and procedures are implemented to include the prevention of
                unauthorized substitution of cryptographic keys.
            description: |-
                Cryptographic keys cannot be substituted by unauthorized personnel.
            levels:
                - base
            notes: |-
                This requirement depends on the solution chosen by the payment entity to protect card holder
                data at rest:
                * When Full Disk Encryption is done using AWS EBS encryption, the authorizations on the
                  cryptographic keys are managed in AWS IAM by the payment entity operating the service.
                * When Full Disk Encryption is done using LUKS with TPM2, no substitution of cryptographic
                  keys is possible after disk creation.
                * When Full Disk Encryption is done using LUKS with Tang, the access to the Tang server,
                  where the Tang Keys Rotation process can be handled, are the responsibility of the payment
                  entity operating the service.
            status: not applicable

          - id: 3.7.8
            title: Key management policies and procedures are implemented to include that cryptographic
                key custodians formally acknowledge (in writing or electronically) that they understand
                and accept their key-custodian responsibilities.
            description: |-
                Key custodians are knowledgeable about their responsibilities in relation to cryptographic
                operations and can access assistance and guidance when required.
            levels:
                - base
            notes: |-
                This requirement is not applicable to the OpenShift Container Platform
                as it instead pertains to the practices and documentation from the
                payment entity. The platform may not generate the entity's policies
                and security practices.
            status: not applicable

          - id: 3.7.9
            title: 'Additional requirement for service providers only: Where a service provider shares
                cryptographic keys with its customers for transmission or storage of account data, guidance
                on secure transmission, storage and updating of such keys is documented and distributed
                to the service provider’s customers.'
            description: |-
                Customers are provided with appropriate key management guidance whenever they receive
                shared cryptographic keys. This requirement applies only when the entity being assessed is
                a service provider.
            levels:
                - base
            status: not applicable

    - id: '4.1'
      title: Processes and mechanisms for protecting cardholder data with strong cryptography during
          transmission over open, public networks are defined and documented.
      levels:
          - base
      status: not applicable
      controls:
          - id: 4.1.1
            title: All security policies and operational procedures that are identified in Requirement
                4 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable

          - id: 4.1.2
            title: Roles and responsibilities for performing activities in Requirement 4 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 4 are documented, assigned and understood
                by the assigned personnel.

    - id: '4.2'
      title: PAN is protected with strong cryptography during transmission.
      levels:
          - base
      status: partial
      controls:
          - id: 4.2.1
            title: Strong cryptography and security protocols are implemented as follows to safeguard
                PAN during transmission over open, public networks.
            description: |-
                Strong cryptography and security protocols are implemented as follows to safeguard PAN
                during transmission over open, public networks:
                - Only trusted keys and certificates are accepted.
                - Certificates used to safeguard PAN during transmission over open, public networks are
                confirmed as valid and are not expired or revoked. This bullet is a best practice until
                31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be
                fully considered during a PCI DSS assessment.
                - The protocol in use supports only secure versions or configurations and does not support
                fallback to, or use of insecure versions, algorithms, key sizes, or implementations.
                - The encryption strength is appropriate for the encryption methodology in use.
            levels:
                - base
            status: partial
            notes: |-
                OpenShift provides mechanisms to securely transmit PAN over open public networks, but
                the application is still responsible for leveraging and implementing strong
                cryptography when transmitting PAN.
            rules:
                - file_permissions_openshift_pki_cert_files
                - tls_version_check_apiserver
                - tls_version_check_masters_workers
                - tls_version_check_router
                - api_server_tls_cert
                - api_server_tls_security_profile
                - api_server_tls_cipher_suites
                - ingress_controller_certificate
                - ingress_controller_tls_security_profile
                - kubelet_configure_tls_min_version
                - routes_protected_by_tls

            controls:
                - id: 4.2.1.1
                  title: An inventory of the entity's trusted keys and certificates used to protect PAN
                      during transmission is maintained.
                  description: |-
                      All keys and certificates used to protect PAN during transmission are identified and
                      confirmed as trusted. This requirement is a best practice until 31 March 2025, after
                      which it will be required and must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift doesn't directly handle PANs, the management of keys and certificates
                      protecting them is responsibility of the payment application.

                - id: 4.2.1.2
                  title: Wireless networks transmitting PAN or connected to the CDE use industry best
                      practices to implement strong cryptography for authentication and transmission.
                  description: |-
                      Cleartext PAN cannot be read or intercepted from wireless network transmissions.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      OpenShift doesn't manage wireless environments nor their security configurations.

          - id: 4.2.2
            title: PAN is secured with strong cryptography whenever it is sent via end-user messaging
                technologies.
            description: |-
                Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging
                technologies. This requirement also applies if a customer, or other third-party, requests
                that PAN is sent to them via end-user messaging technologies. There could be occurrences
                where an entity receives unsolicited cardholder data via an insecure communication channel
                that was not intended for transmissions of sensitive data. In this situation, the entity
                can choose to either include the channel in the scope of their CDE and secure it according
                to PCI DSS or delete the cardholder data and implement measures to prevent the channel
                from being used for cardholder data.
            levels:
                - base
            status: not applicable
            notes: |-
                OpenShift doesn't directly handle PANs, the application is responsible for appropriately
                securing PAN.

    - id: '5.1'
      title: Processes and mechanisms for protecting all systems and networks from malicious software
          are defined and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 5.1.1
            title: All security policies and operational procedures that are identified in Requirement
                5 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                The responsibility for documentation, maintenance, use and dissemination of the security
                policies and procedures is on the payment service and its operations team.

          - id: 5.1.2
            title: Roles and responsibilities for performing activities in Requirement 5 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                The responsibility for documentation, maintenance, use and dissemination of the security
                policies and procedures is on the payment service and its operations team.

    - id: '5.2'
      title: Malicious software (malware) is prevented, or detected and addressed.
      levels:
          - base
      status: supported
      notes: |-
          Related measures are covered by 1.2.6, 1.4.5 and 3.4.2.
      controls:
          - id: 5.2.1
            title: An anti-malware solution(s) is deployed on all system components, except for those
                system components identified in periodic evaluations per Requirement 5.2.3 that concludes
                the system components are not at risk from malware.
            description: |-
                Automated mechanisms are implemented to prevent systems from becoming an attack vector for
                malware.
            levels:
                - base
            status: supported
            notes: |-
                There are many options of anti-malware and the criteria for any adopted solution or
                approach relies on each site policy. Technologies are supported but manual assessment is
                required.

                OpenShift container platforms may install the OpenShift File
                Integrity Operator [1] which monitors file system integrity on the host.
                This may allow for the detection of threats on the hosts which attempt
                to modify the file system in malicious ways. Additionally, there exist
                several solutions to scan for container vulnerabilities which are indispensible
                from any deployment. One such example is Red Hat Quay [2] which supports
                image verification and continuous security scanning of container images.
                Another option is Red Hat Advanced Cluster Security [3] which provides a complete solution
                to build, deploy, and run containerized workloads with more security.

                [1] https://docs.openshift.com/container-platform/latest/security/file_integrity_operator/file-integrity-operator-understanding.html
                [2] https://docs.openshift.com/container-platform/latest/security/container_security/security-registries.html
                [3] https://www.redhat.com/en/resources/advanced-cluster-security-for-kubernetes-datasheet

            rules: []
            related_rules:
                - acs_sensor_exists
                - container_security_operator_exists
                - file_integrity_exists

          - id: 5.2.2
            title: The deployed anti-malware solution(s) detects all known types of malware and removes,
                blocks, or contains all known types of malware.
            levels:
                - base
            status: not applicable
            notes: |-
                It is the payment entity's responsibility to ensure that the chosen anti-malware solutions
                cover the required malware types.

          - id: 5.2.3
            title: Any system components that are not at risk for malware are evaluated periodically.
            description: |-
                Any system components that are not at risk for malware are evaluated periodically to
                include the following:
                - A documented list of all system components not at risk for malware.
                - Identification and evaluation of evolving malware threats for those system components.
                - Confirmation whether such system components continue to not require anti-malware
                protection.
            levels:
                - base
            status: not applicable
            notes: |-
                It is the payment entity's responsibility to identify and evaluate whether any system
                component is at risk of a malware attack.
            controls:
                - id: 5.2.3.1
                  title: The frequency of periodic evaluations of system components identified as not
                      at risk for malware is defined in the entity's targeted risk analysis, which is
                      performed according to all elements specified in Requirement 12.3.1.
                  description: |-
                      Systems not known to be at risk from malware are re-evaluated at a frequency that
                      addresses the entity's risk. This requirement is a best practice until 31 March 2025,
                      after which it will be required and must be fully considered during a PCI DSS
                      assessment.
                  levels:
                      - base
                  status: not applicable

    - id: '5.3'
      title: Anti-malware mechanisms and processes are active, maintained, and monitored.
      levels:
          - base
      status: not applicable
      notes: |-
          The requirements in this section depend on the malware solution deployed as part of 5.2.1.
      controls:
          - id: 5.3.1
            title: The anti-malware solution(s) is kept current via automatic updates.
            description: |-
                Anti-malware mechanisms can detect and address the latest malware threats.
            levels:
                - base
            status: not applicable

          - id: 5.3.2
            title: The anti-malware solution(s) performs periodic scans and active or real-time scans
                or performs continuous behavioral analysis of systems or processes.
            levels:
                - base
            status: not applicable
            controls:
                - id: 5.3.2.1
                  title: If periodic malware scans are performed to meet Requirement 5.3.2, the frequency
                      of scans is defined in the entity's targeted risk analysis, which is performed
                      according to all elements specified in Requirement 12.3.1.
                  description: |-
                      Scans by the malware solution are performed at a frequency that addresses the entity's
                      risk. This requirement applies to entities conducting periodic malware scans to meet
                      Requirement 5.3.2. This requirement is a best practice until 31 March 2025, after which
                      it will be required and must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

          - id: 5.3.3
            title: For removable electronic media, the anti-malware solution(s) performs automatic scans
                of when the media is inserted, connected, or logically mounted, or Performs continuous
                behavioral analysis of systems or processes when the media is inserted, connected, or
                logically mounted.
            levels:
                - base
            status: not applicable

          - id: 5.3.4
            title: Audit logs for the anti-malware solution(s) are enabled and retained in accordance
                with Requirement 10.5.1.
            description: |-
                Historical records of anti-malware actions are immediately available and retained for at
                least 12 months.
            levels:
                - base
            status: not applicable

          - id: 5.3.5
            title: Anti-malware mechanisms cannot be disabled or altered by users, unless specifically
                documented, and authorized by management on a case-by-case basis for a limited time period.
            description: |-
                Anti-malware mechanisms cannot be modified by unauthorized personnel.Anti-malware
                solutions may be temporarily disabled only if there is a legitimate technical need, as
                authorized by management on a case-by-case basis. If anti-malware protection needs to be
                disabled for a specific purpose, it must be formally authorized. Additional security
                measures may also need to be implemented for the period during which anti-malware
                protection is not active.
            levels:
                - base
            status: not applicable

    - id: '5.4'
      title: Anti-phishing mechanisms protect users against phishing attacks.
      levels:
          - base
      status: pending
      controls:
          - id: 5.4.1
            title: Processes and automated mechanisms are in place to detect and protect personnel against
                phishing attacks.
            description: |-
                Mechanisms are in place to protect against and mitigate risk posed by phishing attacks.
                This requirement applies to the automated mechanism. It is not intended that the systems
                and services providing such automated mechanisms (such as email servers) are brought into
                scope for PCI DSS. The focus of this requirement is on protecting personnel with access to
                system components in-scope for PCI DSS. Meeting this requirement for technical and
                automated controls to detect and protect personnel against phishing is not the same as
                Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not
                also meet the requirement for providing personnel with security awareness training, and
                vice versa. This requirement is a best practice until 31 March 2025, after which it will
                be required and must be fully considered during a PCI DSS assessment.
            levels:
                - base
            status: not applicable
            rules: []
            related_rules:
      # NOTE: (yuumasato) below are some node OS configurations that can help prevent
      # and detect spoofing
                - firewalld_loopback_traffic_restricted
                - sysctl_net_ipv4_conf_all_log_martians

    - id: '6.1'
      title: Processes and mechanisms for developing and maintaining secure systems and software are
          defined and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 6.1.1
            title: All security policies and operational procedures that are identified in Requirement
                6 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                The responsibility for documentation, maintenance, use and dissemination of the processes
                and mechanisms for developing and maintaining secure systems and software is on the
                payment entity and its operations team.

          - id: 6.1.2
            title: Roles and responsibilities for performing activities in Requirement 6 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                The responsibility for documentation, maintenance, use and dissemination of the processes
                and mechanisms for developing and maintaining secure systems and software is on the
                payment entity and its operations team.

    - id: '6.2'
      title: Bespoke and custom software are developed securely.
      levels:
          - base
      status: not applicable
      notes: |-
          OpenShift is developed and maintained following secure software development practices:
          https://www.redhat.com/en/topics/security/red-hat-sdl
          But this requirement applies only to software developed for or by the entity for the
          entity's own use. This does not apply to third-party software.
      controls:
          - id: 6.2.1
            title: Bespoke and custom software are developed securely.
            description: |-
                Bespoke and custom software are developed securely, as follows:
                - Based on industry standards and/or best practices for secure development.
                - In accordance with PCI DSS (for example, secure authentication and logging).
                - Incorporating consideration of information security issues during each stage of the
                software development lifecycle.
            levels:
                - base
            status: not applicable

          - id: 6.2.2
            title: Software development personnel working on bespoke and custom software are trained
                at least once every 12 months
            description: |-
                Software development personnel working on bespoke and custom software are trained at least
                once every 12 months as follows:
                - On software security relevant to their job function and development languages.
                - Including secure software design and secure coding techniques.
                - Including, if security testing tools are used, how to use the tools for detecting
                vulnerabilities in software.
            levels:
                - base
            status: not applicable

          - id: 6.2.3
            title: Bespoke and custom software is reviewed prior to being released into production or
                to customers, to identify and correct potential coding vulnerabilities.
            description: |-
                Bespoke and custom software is reviewed prior to being released into production or to
                customers, to identify and correct potential coding vulnerabilities, as follows:
                - Code reviews ensure code is developed according to secure coding guidelines.
                - Code reviews look for both existing and emerging software vulnerabilities.
                - Appropriate corrections are implemented prior to release.
            levels:
                - base
            status: not applicable
            controls:
                - id: 6.2.3.1
                  title: If manual code reviews are performed for bespoke and custom software prior to
                      release to production code changes co-reviewed and approved.
                  description: |-
                      If manual code reviews are performed for bespoke and custom software prior to release
                      to production code changes are:
                      - Reviewed by individuals other than the originating code author, and who are
                      knowledgeable about code-review techniques and secure coding practices.
                      - Reviewed and approved by management prior to release.
                  levels:
                      - base
                  status: not applicable

          - id: 6.2.4
            title: Software engineering techniques or other methods are defined and in use by software
                development personnel to prevent or mitigate common software attacks and related vulnerabilities
                in bespoke and custom software.
            levels:
                - base
            status: not applicable

    - id: '6.3'
      title: Security vulnerabilities are identified and addressed.
      levels:
          - base
      status: inherently met
      controls:
          - id: 6.3.1
            title: Security vulnerabilities are identified and managed
            description: |-
                Security vulnerabilities are identified and managed as follows:
                - New security vulnerabilities are identified using industry-recognized sources for
                security vulnerability information, including alerts from international and national
                computer emergency response teams (CERTs).
                - Vulnerabilities are assigned a risk ranking based on industry best practices and
                consideration of potential impact.
                - Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk
                or critical to the environment.
                - Vulnerabilities for bespoke and custom, and third-party software (for example operating
                systems and databases) are covered.
            levels:
                - base
            status: not applicable
            notes: |-
                The payment entity needs to establish its own process of monitoring for vulnerabilities for
                the systems in use, including bespoke and custom software.

          - id: 6.3.2
            title: An inventory of bespoke and custom software, and third-party software components incorporated
                into bespoke and custom software is maintained to facilitate vulnerability and patch
                management.
            description: |-
                Known vulnerabilities in third-party software components cannot be exploited in bespoke
                and custom software.This requirement is a best practice until 31 March 2025, after which
                it will be required and must be fully considered during a PCI DSS assessment.
            levels:
                - base
            status: not applicable

          - id: 6.3.3
            title: All system components are protected from known vulnerabilities by installing applicable
                security patches/updates.
            description: |-
                All system components are protected from known vulnerabilities by installing
                applicable security patches/updates as follows:
                - Critical or high-security patches/updates (identified according to the risk ranking
                process at Requirement 6.3.1) are installed within one month of release.
                - All other applicable security patches/updates are installed within an appropriate time
                frame as determined by the entity (for example, within three months of release).
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform provides the capability of updating
                both the Kubernetes/OCP layer, as well as the Operating System (Red Hat
                CoreOS) layer in an ubiquitous manner with over-the-air updates using
                the OpenShift Update Service (OSUS) [1]. This service can also be installed
                in clusters without internet connectivity [2].

                [1] https://access.redhat.com/documentation/en-us/openshift_container_platform/4.15/html/updating_clusters/understanding-openshift-updates-1#update-service-about_understanding-openshift-updates
                [2] https://access.redhat.com/documentation/en-us/openshift_container_platform/4.15/html/updating_clusters/performing-a-cluster-update#updating-restricted-network-cluster-OSUS

    - id: '6.4'
      title: Public-facing web applications are protected against attacks.
      levels:
          - base
      status: partial
      controls:
          - id: 6.4.1
            title: For public-facing web applications, new threats and vulnerabilities are addressed
                on an ongoing basis and these applications are protected against known attacks.
            description: |-
                For public-facing web applications, new threats and vulnerabilities are addressed on an
                ongoing basis and these applications are protected against known attacks as follows:
                - Reviewing public-facing web applications via manual or automated application
                vulnerability security assessment tools or methods as follows:
                  - At least once every 12 months and after significant changes.
                  – By an entity that specializes in application security.
                  – Including, at a minimum, all common software attacks in Requirement 6.2.4.
                  – All vulnerabilities are ranked in accordance with requirement 6.3.1.
                  – All vulnerabilities are corrected.
                  – The application is re-evaluated after the corrections
                OR
                - Installing an automated technical solution(s) that continually detects and prevents
                web-based attacks as follows:
                  - Installed in front of public-facing web applications to detect and prevent web-based
                  attacks.
                  - Actively running and up to date as applicable.
                  - Generating audit logs.
                  - Configured to either block web-based attacks or generate an alert that is immediately
                  investigated.
            levels:
                - base
            status: not applicable
            notes: |-
                It is up to the payment entity how they protect their public facing appilcations.
                Depending on the approach taken OpenShift can provide support, see req. 6.4.2, for more details.

          - id: 6.4.2
            title: For public-facing web applications, an automated technical solution is deployed that
                continually detects and prevents web-based attacks.
            levels:
                - base
            status: partial
            notes: |-
                Support for Web Application Firewall in OCP is still in development:
                https://www.redhat.com/en/blog/creating-web-application-firewall-red-hat-openshift

                While Container Security Operator (CSO) is not focused on protecting web-applications it
                can scan installed workflows and applications for known vulnerabilities.
                https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/red_hat_quay_operator_features/container-security-operator-setup

                Security Profiles Operators can also be used to contain an attack when an application
                is compromised.
                https://docs.openshift.com/container-platform/latest/security/security_profiles_operator/spo-overview.html
            rules:
                - container_security_operator_exists
                - security_profiles_operator_exists

          - id: 6.4.3
            title: All payment page scripts that are loaded and executed in the consumer's browser are
                managed
            description: |-
                All payment page scripts that are loaded and executed in the consumer's browser are
                managed as follows:
                - A method is implemented to confirm that each script is authorized.
                - A method is implemented to assure the integrity of each script.
                - An inventory of all scripts is maintained with written justification as to why each is
                necessary.
            levels:
                - base
            status: not applicable

    - id: '6.5'
      title: Changes to all system components are managed securely.
      levels:
          - base
      status: not applicable
      controls:
          - id: 6.5.1
            title: Changes to all system components in the production environment are made according
                to established procedures.
            levels:
                - base
            status: not applicable

          - id: 6.5.2
            title: Upon completion of a significant change, all applicable PCI DSS requirements are confirmed
                to be in place on all new or changed systems and networks, and documentation is updated
                as applicable.
            description: |-
                All system components are verified after a significant change to be compliant with the
                applicable PCI DSS requirements.These significant changes should also be captured and
                reflected in the entity's annual PCI DSS scope confirmation activity per Requirement
                12.5.2.
            levels:
                - base
            status: not applicable

          - id: 6.5.3
            title: Pre-production environments are separated from production environments and the separation
                is enforced with access controls.
            description: |-
                Pre-production environments cannot introduce risks and vulnerabilities into production
                environments.
            levels:
                - base
            status: not applicable

          - id: 6.5.4
            title: Roles and functions are separated between production and pre-production environments
                to provide accountability such that only reviewed and approved changes are deployed.
            description: |-
                Job roles and accountability that differentiate between pre-production and production
                activities are defined and managed to minimize the risk of unauthorized, unintentional,
                or inappropriate actions. In environments with limited personnel where individuals perform
                multiple roles or functions, this same goal can be achieved with additional procedural
                controls that provide accountability. For example, a developer may also be an administrator
                that uses an administrator-level account with elevated privileges in the development
                environment and, for their developer role, they use a separate account with user-level
                access to the production environment.
            levels:
                - base
            status: not applicable

          - id: 6.5.5
            title: Live PANs are not used in pre-production environments, except where those environments
                are included in the CDE and protected in accordance with all applicable PCI DSS requirements.
            description: |-
                Live PANs cannot be present in pre-production environments outside the CDE.s
            levels:
                - base
            status: not applicable

          - id: 6.5.6
            title: Test data and test accounts are removed from system components before the system goes
                into production.
            description: |-
                Test data and test accounts cannot exist in production environments.
            levels:
                - base
            status: not applicable

    - id: '7.1'
      title: Processes and mechanisms for restricting access to system components and cardholder data
          by business need to know are defined and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 7.1.1
            title: All security policies and operational procedures that are identified in Requirement
                7 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that security policies and
                operational procedures identified in Requirement 7 are managed in accordance with all
                elements specified in this requirement.

          - id: 7.1.2
            title: Roles and responsibilities for performing activities in Requirement 7 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 7 are documented, assigned and understood
                by the assigned personnel.

    - id: '7.2'
      title: Access to system components and data is appropriately defined and assigned.
      levels:
          - base
      status: inherently met
      controls:
          - id: 7.2.1
            title: An access control model is defined and includes granting access
            description: |-
                An access control model is defined and includes granting access as follows:
                - Appropriate access depending on the entity's business and access needs.
                - Access to system components and data resources that is based on users' job
                classification and functions.
                - The least privileges required (for example, user, administrator) to perform a job
                function.
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform comes with the Kubernetes RBAC
                feature enabled by default. This feature ensures that only if a
                user or a system account has the appropriate permission, it's able
                to operate on specific system objects. By reviewing the existing
                Role and ClusterRole objects, one is able to see the resources
                that are accessible for a certain role, as well as the "verbs" or
                operations that the role can execute on that resource.
            rules:
                - rbac_roles_defined
                - rbac_cluster_roles_defined

          - id: 7.2.2
            title: Access is assigned to users, including privileged users, based on job classification
                and function, and least privileges necessary to perform job responsibilities.
            levels:
                - base
            status: not applicable
            notes: |-
                Only the payment entity can assess whether the access privileges granted to users are
                appropriate.

          - id: 7.2.3
            title: Required privileges are approved by authorized personnel.
            description: |-
                Access privileges cannot be granted to users without appropriate, documented
                authorization.
            levels:
                - base
            status: not applicable
            notes: |-
                Only the payment entity can assess whether the access privileges granted to users are
                appropriate and documented.

          - id: 7.2.4
            title: All user accounts and related access privileges, including third-party/vendor accounts,
                are reviewed
            description: |-
                All user accounts and related access privileges, including third-party/vendor accounts,
                are reviewed as follows:
                - At least once every six months.
                - To ensure user accounts and access remain appropriate based on job function.
                - Any inappropriate access is addressed.
                - Management acknowledges that access remains appropriate.
            levels:
                - base
            status: not applicable
            notes: |-
                Only the payment entity can assess whether the access privileges granted to users are
                appropriate and documented.

          - id: 7.2.5
            title: All application and system accounts and related access privileges are assigned and
                managed.
            description: |-
                All application and system accounts and related access privileges are assigned and managed
                as follows:
                - Based on the least privileges necessary for the operability of the system or application.
                - Access is limited to the systems, applications, or processes that specifically require
                their use.
            levels:
                - base
            status: pending
            notes: |-
                General access are restricted by 2.2.6 and 8.2 section.
            controls:
                - id: 7.2.5.1
                  title: All access by application and system accounts and related access privileges
                      are reviewed.
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      The check for assignment of least privileges and requirement of use requires human
                      and manual analysis.

          - id: 7.2.6
            title: All user access to query repositories of stored cardholder data is restricted
            levels:
                - base
            status: not applicable
            notes: |-
                The payment entity is responsible implementing and managing access to card holder data.

    - id: '7.3'
      title: 'Access to system components and data is managed via an access control system(s).'
      levels:
          - base
      status: planned
      controls:
          - id: 7.3.1
            title: An access control system(s) is in place that restricts access based on a user's need
                to know and covers all system components.
            description: |-
                Access rights and privileges are managed via mechanisms intended for that purpose.
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform has RBAC enabled by default. With this
                feature, any requests to the API is denied unless an explicit
                Role or ClusterRule is bound to the entity making the request.

                All objects in Kubernetes/OpenShift are bound to RBAC permissions.

          - id: 7.3.2
            title: The access control system(s) is configured to enforce permissions assigned to individuals,
                applications, and systems based on job classification and function.
            description: |-
                Individual account access rights and privileges to systems, applications, and data are
                only inherited from group membership.
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform has RBAC enabled by default,
                and it is enforced at all times.
                There is no permissive mode for Openshift RBAC.

          - id: 7.3.3
            title: The access control system(s) is set to "deny all" by default.
            description: |-
                Access rights and privileges are prohibited unless expressly permitted.
            levels:
                - base
            status: inherently met
            notes: |-
                The OpenShift Container Platform has RBAC enabled by default. With this
                feature, any requests to the API is denied unless an explicit
                Role or ClusterRule is bound to the entity making the request.

    - id: '8.1'
      title: Processes and mechanisms for identifying users and authenticating access to system components
          are defined and understood.
      levels:
          - base
      status: pending
      controls:
          - id: 8.1.1
            title: All security policies and operational procedures that are identified in Requirement
                8 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable

          - id: 8.1.2
            title: Roles and responsibilities for performing activities in Requirement 8 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable

    - id: '8.2'
      title: User identification and related accounts for users and administrators are strictly managed
          throughout an account's lifecycle.
      levels:
          - base
      status: automated
      notes: |-
          For this control to be satisfiable an identity provider must be used and the kubeadmin user
          needs to be removed.
      rules:
          - idp_is_configured
          - kubeadmin_removed
      controls:
          - id: 8.2.1
            title: All users are assigned a unique ID before access to system components or cardholder
                data is allowed.
            description: |-
                All actions by all users are attributable to an individual. This requirement is not
                intended to apply to user accounts within point-of-sale terminals that have access to only
                one card number at a time to facilitate a single transaction (such as IDs used by cashiers
                on point-of-sale terminals).
            levels:
                - base
            status: automated
            notes: |-
                Openshift should be configured to work with an external third-party identity provider.
                Through the chosen identity provider, unique identifiers can be setup for each user.
                See more at https://docs.openshift.com/container-platform/latest/authentication/understanding-identity-provider.html

                However, the payment entity's processes and responsible personal still need to be examined
                to check whether each user is uniquely associated with an individual.
            rules:
                - idp_is_configured
            related_rules:
        # This control can be partially implemented with the following RHCOS rules
                - no_direct_root_logins
                - account_unique_id
                - account_unique_name
                - accounts_no_uid_except_zero
                - accounts_root_gid_zero
                - group_unique_id
                - group_unique_name
                - audit_rules_immutable_login_uids

          - id: 8.2.2
            title: Group, shared, or generic accounts, or other shared authentication credentials are
                only used when necessary on an exception basis, and are managed.
            description: |-
                - Account use is prevented unless needed for an exceptional circumstance.
                - Use is limited to the time needed for the exceptional circumstance.
                - Business justification for use is documented.
                - Use is explicitly approved by management.
                - Individual user identity is confirmed before access to an account is granted.
                - Every action taken is attributable to an individual user.
            levels:
                - base
            status: automated
            notes: |-
                Access tokens that are issued by OpenShift upon authentication should only be used by the
                person for whom it was issued.
            rules:
                - kubeadmin_removed
            related_rules:
        # This control can also be implemented with the following RHCOS rules
                - no_direct_root_logins

          - id: 8.2.3
            title: 'Additional requirement for service providers only: Service providers with remote
                access to customer premises use unique authentication factors for each customer premises.'
            levels:
                - base
            status: not applicable
            notes: |-
                The payment entity itself is also required to not use group, shared, or generic IDs,
                passwords, or other authentication methods. Access tokens that are issued by
                OpenShift upon authentication should only be used by the person
                for whom it was issued.

          - id: 8.2.4
            title: Addition, deletion, and modification of user IDs, authentication factors, and other
                identifier objects are managed
            levels:
                - base
            status: not applicable
            notes: |-
                Only the payment entity can assess whether the access privileges granted to users are
                appropriate and documented, and properly reflected in the configured identity provider.

          - id: 8.2.5
            title: Access for terminated users is immediately revoked.
            description: |-
                The accounts of terminated users cannot be used.
            levels:
                - base
            status: not applicable
            notes: |-
                Revocation of access for terminated users are performed by the third-party
                identity provider. Additionally, OpenShift nor the identity provider cannot by itself
                determine the users associated with an individual.

          - id: 8.2.6
            title: Inactive user accounts are removed or disabled within 90 days of inactivity.
            description: |-
                Inactive user accounts cannot be used.
            levels:
                - base
            status: not applicable
            notes: |-
                Removal or disabling of inactive user accounts within 90 days are handled with the
                identity provider.
                All user IDs, including those handled by third parties to access, support, or maintain
                system components via remote access, are handled externally to OpenShift.
            rules: []

          - id: 8.2.7
            title: Accounts used by third parties to access, support, or maintain system components via
                remote access are managed.
            levels:
                - base
            status: not applicable
            notes: |-
                Similar to how accounts for employees are managed, accounts for third parties are also
                managed by the configured identity provider, and under responsibility of the payment
                entity.

          - id: 8.2.8
            title: If a user session has been idle for more than 15 minutes, the user is required to
                re-authenticate to re-activate the terminal or session.
            description: |-
                A user session cannot be used except by the authorized user. This requirement is not
                intended to apply to user accounts on point-of-sale terminals that have access to only one
                card number at a time to facilitate a single transaction (such as IDs used by cashiers on
                point-of-sale terminals). This requirement is not meant to prevent legitimate activities
                from being performed while the console/PC is unattended.
            levels:
                - base
            status: automated
            notes: |-
                Session timeouts can be enabled with OpenShift to limit the amount of
                time that a session can be active. However, the payment entity also needs to control the
                user's and administrator's idle session timeouts on their payment applications as well.
            rules:
                - oauth_or_oauthclient_inactivity_timeout
                - var_oauth_inactivity_timeout=15m0s

    - id: '8.3'
      title: Strong authentication for users and administrators is established and managed.
      levels:
          - base
      status: partial
      notes: |-
          For this control to be satisfiable an identity provider must be used and the kubeadmin user
          needs to be removed.
      rules:
          - idp_is_configured
          - kubeadmin_removed
      controls:
          - id: 8.3.1
            title: All user access to system components for users and administrators is authenticated.
            description: |-
                All user access to system components for users and administrators is authenticated via at
                least one of the following authentication factors:
                - Something you know, such as a password or passphrase.
                - Something you have, such as a token device or smart card.
                - Something you are, such as a biometric element.
            levels:
                - base
            status: not applicable
            notes: |-
                The type of authenticators to be used (for example, password or passphrase,
                token device or smart card, or biometrics) are managed externally
                to OpenShift by the identity provider

          - id: 8.3.2
            title: Strong cryptography is used to render all authentication factors unreadable during
                transmission and storage on all system components.
            description: |-
                Cleartext authentication factors cannot be obtained, derived, or reused from the
                interception of communications or from stored data.
            levels:
                - base
            status: partial
            notes: |-
                The protection of the authentication credentials such as rendering the passwords and
                passphrases unreadable during transmission and the storage of credentials on system
                components is the responsibility of the third-party identity provider.

                If LDAP is used as the identity provider, we do not allow it to run with the
                'insecure' flag on.
            rules:
                - ocp_no_ldap_insecure

          - id: 8.3.3
            title: User identity is verified before modifying any authentication factor.
            description: |-
                Unauthorized individuals cannot gain system access by impersonating the identity of an
                authorized user.
            levels:
                - base
            status: not applicable
            notes: |-
                Modification of authentication credentials is handled by the third-party identity provider.
                All access to modify parameters for authentication tokens or for generating keys  within
                OpenShift is managed with RBAC and requires prior authentication before the user is
                authorized to act.

          - id: 8.3.4
            title: Invalid authentication attempts are limited.
            description: |-
                - Locking out the user ID after not more than 10 attempts.
                - Setting the lockout duration to a minimum of 30 minutes or until the user's identity is
                confirmed.
            levels:
                - base
            status: partial
            notes: |-
                Account lockout for failed attempts are managed by the identity provider as all
                authentication attempts that occur prior to granting access from OpenShift.
                Establishing a threshold for limiting repeated failed attempts are configured with
                the chosen identity provider.

                In this control we do not allow usage of htpasswd as the identity provider, as it
                doesn't provide user lockout feature.
            rules:
                - ocp_idp_no_htpasswd

          - id: 8.3.5
            title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1,
                they are set and reset for each user.
            description: |-
                - Set to a unique value for first-time use and upon reset.
                - Forced to be changed immediately after the first use.
            levels:
                - base
            status: not applicable
            notes: |-
                Parameters for authenticators such as password length, maximum password
                age, minimum password age, password history, and requirements to change
                the password on first use are handled by the third-party identity provider.

          - id: 8.3.6
            title: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1,
                they meet the minimum level of complexity.
            description: |-
                - A minimum length of 12 characters (or IF the system does not support 12 characters, a
                minimum length of eight characters).
                - Contain both numeric and alphabetic characters.
                A guessed password/passphrase cannot be verified by either an online or offline brute
                force attack.
            levels:
                - base
            status: not applicable
            notes: |-
                Parameters for authenticators such as password length, maximum password
                age, minimum password age, password history, and requirements to change
                the password on first use are handled by the third-party identity provider.

          - id: 8.3.7
            title: Individuals are not allowed to submit a new password/passphrase that is the same as
                any of the last four passwords/passphrases used.
            description: |-
                A previously used password cannot be used to gain access to an account for at least 12
                months.
            levels:
                - base
            status: not applicable
            notes: |-
                Parameters for authenticators such as password length, maximum password
                age, minimum password age, password history, and requirements to change
                the password on first use are handled by the third-party identity provider.

          - id: 8.3.8
            title: Authentication policies and procedures are documented and communicated to all users.
            levels:
                - base
            status: not applicable

          - id: 8.3.9
            title: If passwords/passphrases are used as the only authentication factor for user access
                (i.e., in any single-factor authentication implementation) they should have a limited
                lifetime.
            description: |-
                If passwords/passphrases are used as the only authentication factor for user access (i.e.,
                in any single-factor authentication implementation) then either:
                - Passwords/passphrases are changed at least once every 90 days,
                OR
                - The security posture of accounts is dynamically analyzed, and real-time access to
                resources is automatically determined accordingly.
            levels:
                - base
            status: not applicable
            notes: |-
                Parameters for authenticators such as password length, maximum password
                age, minimum password age, password history, and requirements to change
                the password on first use are handled by the third-party identity provider.

          - id: 8.3.10
            title: 'Additional requirement for service providers only: If passwords/passphrases are used
                as the only authentication factor for customer user access to cardholder data (i.e.,
                in any single-factor authentication implementation) then guidance is provided to customer
                users.'
            levels:
                - base
            status: not applicable
            controls:
                - id: 8.3.10.1
                  title: 'Additional requirement for service providers only: If passwords/passphrases
                      are used as the only authentication factor for customer user access (i.e., in any
                      single-factor authentication implementation) they should have a limited lifetime.'
                  levels:
                      - base
                  status: not applicable
                  notes: |-
                      Parameters for authenticators such as password length, maximum password
                      age, minimum password age, password history, and requirements to change
                      the password on first use are handled by the third-party identity provider.

          - id: 8.3.11
            title: Where authentication factors such as physical or logical security tokens, smart cards,
                or certificates are used, factors are not shared among multiple users and the usage is
                controlled.'
            levels:
                - base
            status: not applicable
            notes: |-
                The type of authenticators to be used (for example, password or passphrase,
                token device or smart card, or biometrics) are managed externally
                to OpenShift by the identity provider

    - id: '8.4'
      title: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
      levels:
          - base
      status: not applicable
      notes: |-
          Multi-factor authenticators are managed externally to OpenShift by the identity provider
      controls:
          - id: 8.4.1
            title: MFA is implemented for all non-console access into the CDE for personnel with administrative
                access.
            levels:
                - base
            status: not applicable

          - id: 8.4.2
            title: MFA is implemented for all access into the CDE.
            description: |-
                Access into the CDE cannot be obtained by the use of a single authentication factor.
            levels:
                - base
            status: not applicable

          - id: 8.4.3
            title: MFA is implemented for all remote network access originating from outside the entity's
                network that could access or impact the CDE.
            levels:
                - base
            status: not applicable

    - id: '8.5'
      title: Multi-factor authentication (MFA) systems are configured to prevent misuse.
      levels:
          - base
      status: not applicable
      notes: |-
          Multi-factor authenticators are managed externally to OpenShift by the identity provider
      controls:
          - id: 8.5.1
            title: MFA systems are properly implemented.
            description: |-
                - The MFA system is not susceptible to replay attacks.
                - MFA systems cannot be bypassed by any users, including administrative users unless
                specifically documented, and authorized by management on an exception basis, for a limited
                time period.
                - At least two different types of authentication factors are used.
                - Success of all authentication factors is required before access is granted.
            levels:
                - base
            status: not applicable

    - id: '8.6'
      title: Use of application and system accounts and associated authentication factors is strictly
          managed.
      levels:
          - base
      status: supported
      controls:
          - id: 8.6.1
            title: If accounts used by systems or applications can be used for interactive login, they
                are managed.
            description: |-
                - Interactive use is prevented unless needed for an exceptional circumstance.
                - Interactive use is limited to the time needed for the exceptional circumstance.
                - Business justification for interactive use is documented.
                - Interactive use is explicitly approved by management.
                - Individual user identity is confirmed before access to account is granted.
                - Every action taken is attributable to an individual user.
            levels:
                - base
            status: not applicable
            notes: |-
                All user IDs, including those handled by third parties to access, support, or maintain
                system components via remote access, are handled externally to OpenShift.
            rules: []
            related_rules:
        # The following RHCOS rule can also contribute to the implementation of this control.
                - securetty_root_login_console_only

          - id: 8.6.2
            title: Passwords/passphrases for any application and system accounts that can be used for
                interactive login are not hard coded in scripts, configuration/property files, or bespoke
                and custom source code.
            description: |-
                Passwords/passphrases used by application and system accounts cannot be used by
                unauthorized personnel.
            levels:
                - base
            status: supported
            notes: |-
                OpenShift can be integrated with a Vault to manage secrets.

          - id: 8.6.3
            title: Passwords/passphrases for any application and system accounts are protected against
                misuse.
            description: |-
                - Passwords/passphrases are changed periodically (at the frequency defined in the entity's
                targeted risk analysis, which is performed according to all elements specified in
                Requirement 12.3.1) and upon suspicion or confirmation of compromise.
                - Passwords/passphrases are constructed with sufficient complexity appropriate for how
                frequently the entity changes the passwords/passphrases.
            levels:
                - base
            status: not applicable
            notes: |-
                Parameters for authenticators such as password length, maximum password
                age, minimum password age, password history, and requirements to change
                the password on first use are handled by the third-party identity provider.

    - id: '9.1'
      title: Processes and mechanisms for restricting physical access to cardholder data are defined
          and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 9.1.1
            title: All security policies and operational procedures that are identified in Requirement
                9 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable

          - id: 9.1.2
            title: Roles and responsibilities for performing activities in Requirement 9 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable

    - id: '9.2'
      title: Physical access controls manage entry into facilities and systems containing cardholder
          data.
      levels:
          - base
      status: not applicable
      controls:
          - id: 9.2.1
            title: Appropriate facility entry controls are in place to restrict physical access to systems
                in the CDE.
            description: |-
                System components in the CDE cannot be physically accessed by unauthorized personnel.
            levels:
                - base
            status: not applicable
            controls:
                - id: 9.2.1.1
                  title: Individual physical access to sensitive areas within the CDE is monitored with
                      either video cameras or physical access control mechanisms (or both).
                  levels:
                      - base
                  status: not applicable

          - id: 9.2.2
            title: Physical and/or logical controls are implemented to restrict use of publicly accessible
                network jacks within the facility.
            description: |-
                Unauthorized devices cannot connect to the entity's network from public areas within the
                facility.
            levels:
                - base
            status: not applicable

          - id: 9.2.3
            title: Physical access to wireless access points, gateways, networking/communications hardware,
                and telecommunication lines within the facility is restricted
            description: |-
                Physical networking equipment cannot be accessed by unauthorized personnel.
            levels:
                - base
            status: not applicable

          - id: 9.2.4
            title: Access to consoles in sensitive areas is restricted via locking when not in use.
            description: |-
                Physical consoles within sensitive areas cannot be used by unauthorized personnel.
            levels:
                - base
            status: not applicable

    - id: '9.3'
      title: Physical access for personnel and visitors is authorized and managed.
      levels:
          - base
      status: not applicable
      controls:
          - id: 9.3.1
            title: Procedures are implemented for authorizing and managing physical access of personnel
                to the CDE.
            levels:
                - base
            status: not applicable
            controls:
                - id: 9.3.1.1
                  title: Physical access to sensitive areas within the CDE for personnel is controlled
                  levels:
                      - base
                  status: not applicable

          - id: 9.3.2
            title: Procedures are implemented for authorizing and managing visitor access to the CDE.
            levels:
                - base
            status: not applicable

          - id: 9.3.3
            title: Visitor badges or identification are surrendered or deactivated before visitors leave
                the facility or at the date of expiration.
            description: |-
                Visitor identification or badges cannot be reused after expiration.
            levels:
                - base
            status: not applicable

          - id: 9.3.4
            title: A visitor log is used to maintain a physical record of visitor activity within the
                facility and within sensitive areas.
            levels:
                - base
            status: not applicable

    - id: '9.4'
      title: Media with cardholder data is securely stored, accessed, distributed, and destroyed.
      levels:
          - base
      status: not applicable
      controls:
          - id: 9.4.1
            title: All media with cardholder data is physically secured.
            description: |-
                Media with cardholder data cannot be accessed by unauthorized personnel.
            levels:
                - base
            status: not applicable
            notes: |-
                Openshift uses the Kubernetes persistent volume (PV) framework, which allows separation
                between storage provisioners and consumers.
                The payment entity needs to ensure that they are using persistent storages for which
                they have control over its location and physical access.
            controls:
                - id: 9.4.1.1
                  title: Offline media backups with cardholder data are stored in a secure location.
                  description: |-
                      Offline backups cannot be accessed by unauthorized personnel.
                  levels:
                      - base
                  status: not applicable

                - id: 9.4.1.2
                  title: The security of the offline media backup location(s) with cardholder data is
                      reviewed at least once every 12 months.
                  description: |-
                      The security controls protecting offline backups are verified periodically by
                      inspection.
                  levels:
                      - base
                  status: not applicable

          - id: 9.4.2
            title: All media with cardholder data is classified in accordance with the sensitivity of
                the data.
            description: |-
                Media are classified and protected appropriately.
            levels:
                - base
            status: not applicable

          - id: 9.4.3
            title: Media with cardholder data sent outside the facility is secured.
            description: |-
                Media is secured and tracked when transported outside the facility.
                - Media sent outside the facility is logged.
                - Media is sent by secured courier or other delivery method that can be accurately
                tracked.
                - Offsite tracking logs include details about media location.
            levels:
                - base
            status: not applicable

          - id: 9.4.4
            title: Management approves all media with cardholder data that is moved outside the facility
                (including when media is distributed to individuals).
            description: |-
                Media cannot leave a facility without the approval of accountable personnel. Individuals
                approving media movements should have the appropriate level of management authority to
                grant this approval. However, it is not specifically required that such individuals have
                "manager" as part of their title.
            levels:
                - base
            status: not applicable

          - id: 9.4.5
            title: Inventory logs of all electronic media with cardholder data are maintained.
            description: |-
                Accurate inventories of stored electronic media are maintained.
            levels:
                - base
            status: not applicable
            controls:
                - id: 9.4.5.1
                  title: Inventories of electronic media with cardholder data are conducted at least
                      once every 12 months.
                  description: |-
                      Media inventories are verified periodically.
                  levels:
                      - base
                  status: not applicable

          - id: 9.4.6
            title: Hard-copy materials with cardholder data are destroyed when no longer needed for business
                or legal reasons.
            levels:
                - base
            status: not applicable

          - id: 9.4.7
            title: Electronic media with cardholder data is destroyed when no longer needed for business
                or legal reasons.
            description: |-
                - The electronic media is destroyed.
                - The cardholder data is rendered unrecoverable so that it cannot be reconstructed.
            levels:
                - base
            status: not applicable

    - id: '9.5'
      title: Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution.
      levels:
          - base
      status: not applicable
      controls:
          - id: 9.5.1
            title: POI devices that capture payment card data via direct physical interaction with the
                payment card form factor are protected from tampering and unauthorized substitution.
            levels:
                - base
            status: not applicable
            controls:
                - id: 9.5.1.1
                  title: An up-to-date list of POI devices is maintained.
                  levels:
                      - base
                  status: not applicable

                - id: 9.5.1.2
                  title: POI device surfaces are periodically inspected to detect tampering and unauthorized
                      substitution.
                  description: |-
                      Point of Interaction Devices cannot be tampered with, substituted without authorization,
                      or have skimming attachments installed without timely detection.
                  levels:
                      - base
                  status: not applicable
                  controls:
                      - id: 9.5.1.2.1
                        title: The frequency of periodic POI device inspections and the type of inspections
                            performed is defined in the entity's targeted risk analysis, which is performed
                            according to all elements specified in Requirement 12.3.1.
                        description: |-
                            POI devices are inspected at a frequency that addresses the entity's risk.
                            This requirement is a best practice until 31 March 2025, after which it will be
                            required and must be fully considered during a PCI DSS assessment.
                        levels:
                            - base
                        status: not applicable

                - id: 9.5.1.3
                  title: Training is provided for personnel in POI environments to be aware of attempted
                      tampering or replacement of POI devices.
                  levels:
                      - base
                  status: not applicable

    - id: '10.1'
      title: Processes and mechanisms for logging and monitoring all access to system components and
          cardholder data are defined and documented.
      levels:
          - base
      status: not applicable
      controls:
          - id: 10.1.1
            title: All security policies and operational procedures that are identified in Requirement
                10 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable

          - id: 10.1.2
            title: Roles and responsibilities for performing activities in Requirement 10 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable

    - id: '10.2'
      title: Audit logs are implemented to support the detection of anomalies and suspicious activity,
          and the forensic analysis of events.
      levels:
          - base
      status: inherently met
      controls:
          - id: 10.2.1
            title: Audit logs are enabled and active for all system components and cardholder data.
            description: |-
                Records of all activities affecting system components and cardholder data are captured.
            levels:
                - base
            status: inherently met
            rules: []
            controls:
                - id: 10.2.1.1
                  title: Audit logs capture all individual user access to cardholder data.
                  description: |-
                      Records of all individual user access to cardholder data are captured.
                  levels:
                      - base
                  status: inherently met
                  notes: >-
                      All user and/or service account accesses to OpenShift components are logged.
                      However, the payment entity still is responsible for logging events for access
                      to
                      applications within workloads hosted in containers in OpenShift.

                - id: 10.2.1.2
                  title: Audit logs capture all actions taken by any individual with administrative access,
                      including any interactive use of application or system accounts.
                  description: |-
                      Records of all actions performed by individuals with elevated privileges are captured.
                  levels:
                      - base
                  status: inherently met
                  notes: >-
                      All actions taken by individual with root or administrative privileges to OpenShift
                      and
                      Red Hat CoreOS are logged.
                      However, the payment entity still is responsible for logging events for access
                      to
                      applications within workloads hosted in containers in OpenShift.

                - id: 10.2.1.3
                  title: Audit logs capture all access to audit logs.
                  description: |-
                      Records of all access to audit logs are captured.
                  levels:
                      - base
                  status: inherently met
                  notes: >-
                      Access to audit trails relative to OpenShift are made available at the OS level
                      with
                      administrator accounts.
                      Red Hat CoreOS can be configured to log access to the journal or log file. For
                      better
                      protection of audit trails, including improved access controls, it is recommended
                      to
                      direct logs to an external log server or Security Information Event Management
                      (SIEM)
                      solution.
                  rules:
                      - audit_logging_enabled

                - id: 10.2.1.4
                  title: Audit logs capture all invalid logical access attempts.
                  description: |-
                      Records of all invalid access attempts are captured.
                  levels:
                      - base
                  status: inherently met
                  notes: |-
                      Unauthorized attempts to access system components or run unauthorized commands against
                      OpenShift are logged.

                - id: 10.2.1.5
                  title: Audit logs capture all changes to identification and authentication credentials.
                  levels:
                      - base
                  status: inherently met

                - id: 10.2.1.6
                  title: Audit logs capture the initialization of new audit logs, and starting, stopping,
                      or pausing of the existing audit logs.
                  levels:
                      - base
                  status: inherently met
                  notes: |-
                      Stopping the mechanisms for log creation in OpenShift requires stopping the OpenShift
                      Control Plane itself, which would have the effect of preventing any further access for
                      any users to the API, CLI, or Web UI.
                      Auditing within OpenShift cannot be reconfigured or stopped without reconfiguring
                      OpenShift.
                      Any attempt to reconfigure OpenShift will be logged.

                - id: 10.2.1.7
                  title: Audit logs capture all creation and deletion of system-level objects.
                  description: |-
                      Records of alterations that indicate a system has been modified from its intended
                      functionality are captured.
                  levels:
                      - base
                  status: inherently met
                  notes: >-
                      Creation and deletion of system levels objects is logged by OpenShift and by
                      Red Hat CoreOS.

          - id: 10.2.2
            title: Audit logs record sufficient details for each auditable event.
            description: |-
                - User identification.
                - Type of event.
                - Date and time.
                - Success and failure indication.
                - Origination of event.
                - Identity or name of affected data, system component, resource, or service (for example,
                  name and protocol).
            levels:
                - base
            status: automated
            notes: >-
                The logs generated by OpenShift and Red Hat CoreOS include all the data required.
            rules:
                - audit_profile_set
                - var_openshift_audit_profile=WriteRequestBodies

    - id: '10.3'
      title: Audit logs are protected from destruction and unauthorized modifications.
      levels:
          - base
      status: partial
      controls:
          - id: 10.3.1
            title: Read access to audit logs files is limited to those with a job-related need.
            description: |-
                Stored activity records cannot be accessed by unauthorized personnel.
            levels:
                - base
            status: manual
            notes: |-
                Access to audit logs is limited to the cluster-admin role. Ensure that only those
                user with a job-related need have the cluster-admin role.
            rules:
        # This rule doesn't have an automated check
                - rbac_limit_cluster_admin

          - id: 10.3.2
            title: Audit log files are protected to prevent modifications by individuals.
            description: |-
                Stored activity records cannot be modified by personnel.
            levels:
                - base
            status: planned
            notes: >-
                Limited access to the audit trails on OpenShift hosts provides minimal protection from
                unauthorized modification.
                Use of an external log collector or SIEM solution may provide improved protections against
                unauthorized modifications by adding additional features such as file integrity monitoring,
                digital signing, or Write Once, Read Many (WORM) storage.
            rules:
                - directory_access_var_log_kube_audit
                - directory_access_var_log_oauth_audit
                - directory_access_var_log_ocp_audit
                - directory_permissions_var_log_kube_audit
                - directory_permissions_var_log_oauth_audit
                - directory_permissions_var_log_ocp_audit
                - file_ownership_var_log_kube_audit
                - file_ownership_var_log_oauth_audit
                - file_ownership_var_log_ocp_audit
                - file_permissions_var_log_kube_audit
                - file_permissions_var_log_oauth_audit
                - file_permissions_var_log_ocp_audit

          - id: 10.3.3
            title: Audit log files, including those for external-facing technologies, are promptly backed
                up to a secure, central, internal log server(s) or other media that is difficult to modify.
            description: |-
                Stored activity records are secured and preserved in a central location to prevent
                unauthorized modification.
            levels:
                - base
            status: manual
            notes: |-
                Although the technologies in general allow to send logs to a centralized server, some
                parameters for this configuration are specific to each site policy and therefore the
                requirement demands manual assessment.
            rules: []

          - id: 10.3.4
            title: File integrity monitoring or change-detection mechanisms is used on audit logs to
                ensure that existing log data cannot be changed without generating alerts.
            description: |-
                Stored activity records cannot be modified without an alert being generated.
            levels:
                - base
            status: partial
            rules:
        # TODO: Add FIO config to allow /var/log/... to extend in size but monitor perms.
                - file_integrity_exists

    - id: '10.4'
      title: Audit logs are reviewed to identify anomalies or suspicious activity.
      levels:
          - base
      status: manual
      controls:
          - id: 10.4.1
            title: The audit logs are reviewed at least once daily.
            description: |-
                - All security events.
                - Logs of all system components that store, process, or transmit CHD and/or SAD.
                - Logs of all critical system components.
                - Logs of all servers and system components that perform security functions (for example,
                  network security controls, intrusion-detection systems/intrusion-prevention systems
                  (IDS/IPS), authentication servers).
            levels:
                - base
            status: manual
            controls:
                - id: 10.4.1.1
                  title: Automated mechanisms are used to perform audit log reviews.
                  description: |-
                      Potentially suspicious or anomalous activities are identified via a repeatable and
                      consistent mechanism. This requirement is a best practice until 31 March 2025, after
                      which it will be required and must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

          - id: 10.4.2
            title: Logs of all other system components (those not specified in Requirement 10.4.1) are
                reviewed periodically.
            description: |-
                Potentially suspicious or anomalous activities for other system components (not included
                in 10.4.1) are reviewed in accordance with the entity's identified risk. This requirement
                is applicable to all other in-scope system components not included in Requirement 10.4.1.
            levels:
                - base
            status: not applicable
            controls:
                - id: 10.4.2.1
                  title: The frequency of periodic log reviews for all other system components (not defined
                      in Requirement 10.4.1) is defined in the entity's targeted risk analysis, which
                      is performed according to all elements specified in Requirement 12.3.1
                  description: |-
                      Log reviews for lower-risk system components are performed at a frequency that addresses
                      the entity's risk. This requirement is a best practice until 31 March 2025, after which
                      it will be required and must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

          - id: 10.4.3
            title: Exceptions and anomalies identified during the review process are addressed.
            description: |-
                Suspicious or anomalous activities are addressed.
            levels:
                - base
            status: not applicable

    - id: '10.5'
      title: Audit log history is retained and available for analysis.
      levels:
          - base
      status: supported
      controls:
          - id: 10.5.1
            title: Retain audit log history for at least 12 months, with at least the most recent three
                months immediately available for analysis.
            description: |-
                Historical records of activity are available immediately to support incident response and
                are retained for at least 12 months.
            levels:
                - base
            status: supported
            notes: |-
                Log retention in OpenShift is not time based, the default configuration rotates 10 log
                files of 100 MB each, allowing up to 1GB of retention.

                To implement time based audit log retention configure log forwarding to a third party
                storage, for example Elasticsearch or LokiStack.
            rules: []

    - id: '10.6'
      title: Time-synchronization mechanisms support consistent time settings across all systems.
      levels:
          - base
      status: planned
      controls:
          - id: 10.6.1
            title: System clocks and time are synchronized using time-synchronization technology.
            description: |-
                Common time is established across all systems. Keeping time-synchronization technology
                current includes managing vulnerabilities and patching the technology according to PCI DSS
                Requirements 6.3.1 and 6.3.3.
            levels:
                - base
            status: inherently met
            notes: |-
                By default OpenShift uses a public Network Time Protocol (NTP) server.
                However, additional configuration is needed to use a local enterprise NTP server,
                or in disconnected environments.

          - id: 10.6.2
            title: Systems are configured to the correct and consistent time.
            description: |-
                - One or more designated time servers are in use.
                - Only the designated central time server(s) receives time from external sources.
                - Time received from external sources is based on International Atomic Time or Coordinated
                  Universal Time (UTC).
                - The designated time server(s) accept time updates only from specific industry-accepted
                  external sources.
                - Where there is more than one designated time server, the time servers peer with one
                  another to keep accurate time.
                - Internal systems receive time information only from designated central time server(s).
            levels:
                - base
            status: planned
            notes: |-
                OpenShift is configured to use a public ntppool.org which is good and reliable, but
                ultimately is not enterprise grade.
                The notion of central time server implies that an exclusive NTP server is deployed to
                serve the cluster.

                NTP configuration is done at the node level, except when using Precision Time Protocol
                (PTP), for which PTP Operator can be used. PTP can only be used on bare metal deployments.
                https://docs.openshift.com/container-platform/latest/networking/ptp/about-ptp.html
            rules: []
            related_rules:
                - service_chronyd_enabled
                - var_multiple_time_servers=generic
                - chronyd_specify_remote_server

          - id: 10.6.3
            title: Time synchronization settings and data are protected.
            description: |-
                - Access to time data is restricted to only personnel with a business need.
                - Any changes to time settings on critical systems are logged, monitored, and reviewed.
            levels:
                - base
            status: planned
            notes: |-
                As NTP is configured directly on the node the audit should also be configured there.
            rules: []
            related_rules:
                - audit_rules_time_watch_localtime
                - audit_rules_time_settimeofday
                - audit_rules_time_clock_settime
                - audit_rules_time_stime
                - audit_rules_time_adjtimex
                - chronyd_run_as_chrony_user

    - id: '10.7'
      title: Failures of critical security control systems are detected, reported, and responded to promptly.
      levels:
          - base
      status: partial
      controls:
          - id: 10.7.1
            title: 'Additional requirement for service providers only: Failures of critical security
                control systems are detected, alerted, and addressed promptly.'
            description: |-
                It includes but is not limited to failure of the following critical security control
                systems:
                - Network security controls.
                - IDS/IPS.
                - FIM.
                - Anti-malware solutions.
                - Physical access controls.
                - Logical access controls.
                - Audit logging mechanisms.
                - Segmentation controls (if used).
            levels:
                - base
            status: not applicable

          - id: 10.7.2
            title: Failures of critical security control systems are detected, alerted, and addressed
                promptly.
            description: |-
                It includes but is not limited to failure of the following critical security control
                systems:
                - Network security controls.
                - IDS/IPS.
                - Change-detection mechanisms.
                - Anti-malware solutions.
                - Physical access controls.
                - Logical access controls.
                - Audit logging mechanisms.
                - Segmentation controls (if used).
                - Audit log review mechanisms.
                - Automated security testing tools (if used).
            levels:
                - base
            status: partial
            rules:
                - alert_receiver_configured
                - audit_error_alert_exists

          - id: 10.7.3
            title: Failures of any critical security controls systems are responded to restore security
                functions, ensure documentation, address security issues and prevent other failures.
            description: |-
                It includes but is not limited to:
                - Restoring security functions.
                - Identifying and documenting the duration (date and time from start to end) of the
                  security failure.
                - Identifying and documenting the cause(s) of failure and documenting required
                  remediation.
                - Identifying and addressing any security issues that arose during the failure.
                - Determining whether further actions are required as a result of the security failure.
                - Implementing controls to prevent the cause of failure from reoccurring.
                - Resuming monitoring of security controls.
            levels:
                - base
            status: manual

    - id: '11.1'
      title: Processes and mechanisms for regularly testing security of systems and networks are defined
          and understood.
      levels:
          - base
      status: not applicable
      controls:
          - id: 11.1.1
            title: All security policies and operational procedures that are identified in Requirement
                11 are Documented, Kept up to date, In use and Known to all affected parties.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that security policies and
                operational procedures identified in Requirement 11 are managed in accordance with all
                elements specified in this requirement.

          - id: 11.1.2
            title: Roles and responsibilities for performing activities in Requirement 11 are documented,
                assigned, and understood.
            levels:
                - base
            status: not applicable
            notes: |-
                Examine documentation and interview personnel to verify that day-to-day responsibilities
                for performing all the activities in Requirement 11 are documented, assigned and
                understood by the assigned personnel.

    - id: '11.2'
      title: Wireless access points are identified and monitored, and unauthorized wireless access points
          are addressed.
      levels:
          - base
      status: not applicable
      notes: |-
          OpenShift doesn't manage wireless environments nor their security configurations.
      controls:
          - id: 11.2.1
            title: Authorized and unauthorized wireless access points are managed.
            levels:
                - base
            status: not applicable

          - id: 11.2.2
            title: An inventory of authorized wireless access points is maintained, including a documented
                business justification.
            description: |-
                Unauthorized wireless access points are not mistaken for authorized wireless access
                points.
            levels:
                - base
            status: not applicable

    - id: '11.3'
      title: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
      levels:
          - base
      status: not applicable
      notes: |-
          This control is about the payment entity keeping keeping processes and personnel to conduct
          vulnerability scans.
      controls:
          - id: 11.3.1
            title: Internal vulnerability scans are performed.
            levels:
                - base
            status: not applicable
            controls:
                - id: 11.3.1.1
                  title: All other applicable vulnerabilities (those not ranked as high-risk or critical
                      per the entity's vulnerability risk rankings defined at Requirement 6.3.1) are
                      managed
                  levels:
                      - base
                  status: not applicable

                - id: 11.3.1.2
                  title: Internal vulnerability scans are performed via authenticated scanning.
                  levels:
                      - base
                  status: not applicable

                - id: 11.3.1.3
                  title: Internal vulnerability scans are performed after any significant change.
                  levels:
                      - base
                  status: not applicable
          - id: 11.3.2
            title: External vulnerability scans are performed.
            levels:
                - base
            status: not applicable
            notes: |-
                The scans are to be performed by a PCI SCC Approved Scanning Vendor
            controls:
                - id: 11.3.2.1
                  title: External vulnerability scans are performed after any significant change.
                  levels:
                      - base
                  status: not applicable

    - id: '11.4'
      title: External and internal penetration testing is regularly performed, and exploitable vulnerabilities
          and security weaknesses are corrected.
      levels:
          - base
      status: not applicable
      controls:
          - id: 11.4.1
            title: A penetration testing methodology is defined, documented, and implemented by the entity.
            levels:
                - base
            status: not applicable

          - id: 11.4.2
            title: Internal penetration testing is performed.
            levels:
                - base
            status: not applicable

          - id: 11.4.3
            title: External penetration testing is performed.
            levels:
                - base
            status: not applicable

          - id: 11.4.4
            title: Exploitable vulnerabilities and security weaknesses found during penetration testing
                are corrected
            levels:
                - base
            status: not applicable

          - id: 11.4.5
            title: If segmentation is used to isolate the CDE from other networks, penetration tests
                are performed on segmentation controls.
            levels:
                - base
            status: not applicable

          - id: 11.4.6
            title: 'Additional requirement for service providers only: If segmentation is used to isolate
                the CDE from other networks, penetration tests are performed on segmentation controls.'
            levels:
                - base
            status: not applicable

          - id: 11.4.7
            title: 'Additional requirement for multi-tenant service providers only: Multi-tenant service
                providers support their customers for external penetration testing per Requirement 11.4.3
                and 11.4.4.'
            description: |-
                Multi-tenant service providers support their customers' need for technical testing either
                by providing access or evidence that comparable technical testing has been undertaken.
            levels:
                - base
            status: not applicable

    - id: '11.5'
      title: Network intrusions and unexpected file changes are detected and responded to.
      levels:
          - base
      status: automated
      controls:
          - id: 11.5.1
            title: Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or
                prevent intrusions into the network.
            levels:
                - base
            status: partial
            controls:
                - id: 11.5.1.1
                  title: 'Additional requirement for service providers only: Intrusion-detection and/or
                      intrusion-prevention techniques detect, alert on/prevent, and address covert malware
                      communication channels.'
                  description: |-
                      Mechanisms are in place to detect and alert/prevent covert communications with
                      command-and-control systems. Alerts generated by these mechanisms are responded to by
                      personnel, or by automated means that ensure that such communications are blocked. This
                      requirement applies only when the entity being assessed is a service provider. This
                      requirement is a best practice until 31 March 2025, after which it will be required and
                      must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: partial
                  notes: |-
                      The policy is not explicit about any specific solution. The solution might vary
                      depending on site policies.
                  rules:
                      - acs_sensor_exists

    - id: 11.5.2
      title: A change-detection mechanism (for example, file integrity monitoring tools) is deployed.
      levels:
          - base
      status: partial
      notes: |-
          Once configured the File Integrity Operator (FIO) can detect unexpected changes in the node
          filesystem.
      rules:
          - file_integrity_exists
          - file_integrity_notification_enabled

    - id: '11.6'
      title: Unauthorized changes on payment pages are detected and responded to.
      levels:
          - base
      status: not applicable
      notes: |-
          OpenShift does not directly handle payment pages.
      controls:
          - id: 11.6.1
            title: A change- and tamper-detection mechanism is deployed.
            levels:
                - base
            status: not applicable

    - id: '12.1'
      title: A comprehensive information security policy that governs and provides direction for protection
          of the entity's information assets is known and current.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.1.1
            title: An overall information security policy is established, published, maintained and disseminated
                to all relevant personnel, as well as to relevant vendors and business partners.
            levels:
                - base
            status: not applicable

          - id: 12.1.2
            title: The information security policy is updated and reviewed at least once every 12 months.
            levels:
                - base
            status: not applicable

          - id: 12.1.3
            title: The security policy clearly defines information security roles and responsibilities
                for all personnel, and all personnel are aware of and acknowledge their information security
                responsibilities.
            description: |-
                Personnel understand their role in protecting the entity's cardholder data.
            levels:
                - base
            status: not applicable

          - id: 12.1.4
            title: Responsibility for information security is formally assigned to a Chief Information
                Security Officer or other information security knowledgeable member of executive management.
            description: |-
                A designated member of executive management is responsible for information security.
            levels:
                - base
            status: not applicable

    - id: '12.2'
      title: Acceptable use policies for end-user technologies are defined and implemented.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.2.1
            title: Acceptable use policies for end-user technologies are documented and implemented.
            levels:
                - base
            status: not applicable

    - id: '12.3'
      title: Risks to the cardholder data environment are formally identified, evaluated, and managed.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.3.1
            title: Each PCI DSS requirement that provides flexibility for how frequently it is performed
                (for example, requirements to be performed periodically) is supported by a targeted risk
                analysis that is documented.
            levels:
                - base
            status: not applicable

          - id: 12.3.2
            title: A targeted risk analysis is performed for each PCI DSS requirement that the entity
                meets with the customized approach
            levels:
                - base
            status: not applicable

          - id: 12.3.3
            title: Cryptographic cipher suites and protocols in use are documented and reviewed at least
                once every 12 months.
            levels:
                - base
            status: not applicable
            notes: |-
                Related to requirement 2.2.7.

          - id: 12.3.4
            title: Hardware and software technologies in use are reviewed at least once every 12 months.
            levels:
                - base
            status: not applicable
            notes: |-
                The technical requirement related to this is 6.3.3.

    - id: '12.4'
      title: PCI DSS compliance is managed.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.4.1
            title: 'Additional requirement for service providers only: Responsibility is established
                by executive management for the protection of cardholder data and a PCI DSS compliance
                program.'
            levels:
                - base
            status: not applicable

          - id: 12.4.2
            title: 'Additional requirement for service providers only: Reviews are performed at least
                once every three months to confirm that personnel are performing their tasks in accordance
                with all security policies and operational procedures.'
            description: |-
                Reviews are performed by personnel other than those responsible for performing the given
                task.
            levels:
                - base
            status: not applicable
            controls:
                - id: 12.4.2.1
                  title: 'Additional requirement for service providers only: Reviews conducted in accordance
                      with Requirement 12.4.2 are documented.'
                  levels:
                      - base
                  status: not applicable

    - id: '12.5'
      title: PCI DSS scope is documented and validated.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.5.1
            title: An inventory of system components that are in scope for PCI DSS, including a description
                of function/use, is maintained and kept current.
            description: |-
                All system components in scope for PCI DSS are identified and known.
            levels:
                - base
            status: not applicable

          - id: 12.5.2
            title: PCI DSS scope is documented and confirmed by the entity at least once every 12 months
                and upon significant change to the in-scope environment.
            levels:
                - base
            status: not applicable
            controls:
                - id: 12.5.2.1
                  title: 'Additional requirement for service providers only: PCI DSS scope is documented
                      and confirmed by the entity at least once every six months and upon significant
                      change to the in-scope environment. At a minimum, the scoping validation includes
                      all the elements specified in Requirement 12.5.2.'
                  description: |-
                      The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive
                      analysis and appropriate technical measures. This requirement applies only when the
                      entity being assessed is a service provider. This requirement is a best practice until
                      31 March 2025, after which it will be required and must be fully considered during a
                      PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

          - id: 12.5.3
            title: 'Additional requirement for service providers only: Significant changes to organizational
                structure result in a documented (internal) review of the impact to PCI DSS scope and
                applicability of controls, with results communicated to executive management.'
            description: |-
                PCI DSS scope is confirmed after significant organizational change. This requirement
                applies only when the entity being assessed is a service provider. This requirement is a
                best practice until 31 March 2025, after which it will be required and must be fully
                considered during a PCI DSS assessment.
            levels:
                - base
            status: not applicable

    - id: '12.6'
      title: Security awareness education is an ongoing activity.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.6.1
            title: A formal security awareness program is implemented to make all personnel aware of
                the entity's information security policy and procedures, and their role in protecting
                the cardholder data.
            description: |-
                Personnel are knowledgeable about the threat landscape, their responsibility for the
                operation of relevant security controls, and are able to access assistance and guidance
                when required.
            levels:
                - base
            status: not applicable

          - id: 12.6.2
            title: The security awareness program is updated and reviewed at least once every 12 months.
            levels:
                - base
            status: not applicable

          - id: 12.6.3
            title: Personnel receive security awareness training upon hire and at least once every 12
                months via multiple methods of communication.
            levels:
                - base
            status: not applicable
            controls:
                - id: 12.6.3.1
                  title: Security awareness training includes awareness of threats and vulnerabilities
                      that could impact the security of the CDE.
                  levels:
                      - base
                  status: not applicable

                - id: 12.6.3.2
                  title: Security awareness training includes awareness about the acceptable use of end-user
                      technologies in accordance with Requirement 12.2.1.
                  description: |-
                      Personnel are knowledgeable about their responsibility for the security and operation of
                      end-user technologies and are able to access assistance and guidance when required. This
                      requirement is a best practice until 31 March 2025, after which it will be required and
                      must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

    - id: '12.7'
      title: Personnel are screened to reduce risks from insider threats.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.7.1
            title: Potential personnel who will have access to the CDE are screened, within the constraints
                of local laws, prior to hire to minimize the risk of attacks from internal sources.
            description: |-
                The risk related to allowing new members of staff access to the CDE is understood and
                managed. For those potential personnel to be hired for positions such as store cashiers,
                who only have access to one card number at a time when facilitating a transaction, this
                requirement is a recommendation only.
            levels:
                - base
            status: not applicable

    - id: '12.8'
      title: Risk to information assets associated with third-party service provider (TPSP) relationships
          is managed.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.8.1
            title: A list of all third-party service providers (TPSPs) with which account data is shared
                or that could affect the security of account data is maintained, including a description
                for each of the services provided.
            description: |-
                Records are maintained of TPSPs and the services provided. The use of a PCI DSS compliant
                TPSP does not make an entity PCI DSS compliant, nor does it remove the entit's
                responsibility for its own PCI DSS compliance.
            levels:
                - base
            status: not applicable

          - id: 12.8.2
            title: Written agreements with TPSPs are maintained
            levels:
                - base
            status: not applicable

          - id: 12.8.3
            title: An established process is implemented for engaging TPSPs, including proper due diligence
                prior to engagement.
            description: |-
                The capability, intent, and resources of a prospective TPSP to adequately protect account
                data are assessed before the TPSP is engaged.
            levels:
                - base
            status: not applicable

          - id: 12.8.4
            title: A program is implemented to monitor TPSPs' PCI DSS compliance status at least once
                every 12 months.
            description: |-
                The PCI DSS compliance status of TPSPs is verified periodically. Where an entity has an
                agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for
                example, via a firewall service), the entity must work with the TPSP to make sure the
                applicable PCI DSS requirements are met. If the TPSP does not meet those applicable
                PCI DSS requirements, then those requirements are also "not in place" for the entity.
            levels:
                - base
            status: not applicable

          - id: 12.8.5
            title: Information is maintained about which PCI DSS requirements are managed by each TPSP,
                which are managed by the entity, and any that are shared between the TPSP and the entity.
            description: |-
                Records detailing the PCI DSS requirements and related system components for which each
                TPSP is solely or jointly responsible, are maintained and reviewed periodically.
            levels:
                - base
            status: not applicable

    - id: '12.9'
      title: Third-party service providers (TPSPs) support their customers' PCI DSS compliance.
      levels:
          - base
      status: not applicable
      controls:
          - id: 12.9.1
            title: |-
                Additional requirement for service providers only: TPSPs acknowledge in writing to
                customers that they are responsible for the security of account data the TPSP possesses or
                otherwise stores, processes, or transmits on behalf of the customer, or to the extent that
                they could impact the security of the customer's CDE.
            description: |-
                TPSPs formally acknowledge their security responsibilities to their customers. This
                requirement applies only when the entity being assessed is a service provider. The exact
                wording of an acknowledgment will depend on the agreement between the two parties, the
                details of the service being provided, and the responsibilities assigned to each party.
                The acknowledgment does not have to include the exact wording provided in this
                requirement.
            levels:
                - base
            status: not applicable

          - id: 12.9.2
            title: |-
                Additional requirement for service providers only: TPSPs support their customers' requests
                for information to meet Requirements 12.8.4 and 12.8.5.
            levels:
                - base
            status: not applicable

    - id: '12.10'
      title: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
      levels:
          - base
      status: pending
      controls:
          - id: 12.10.1
            title: An incident response plan exists and is ready to be activated in the event of a suspected
                or confirmed security incident.
            levels:
                - base
            status: not applicable

          - id: 12.10.2
            title: At least once every 12 months, the security incident response plan is reviewed, updated,
                and tested.
            levels:
                - base
            status: not applicable

          - id: 12.10.3
            title: Specific personnel are designated to be available on a 24/7 basis to respond to suspected
                or confirmed security incidents.
            description: |-
                Incidents are responded to immediately where appropriate.
            levels:
                - base
            status: not applicable

          - id: 12.10.4
            title: Personnel responsible for responding to suspected and confirmed security incidents
                are appropriately and periodically trained on their incident response responsibilities.
            description: |-
                Personnel are knowledgeable about their role and responsibilities in incident response and
                are able to access assistance and guidance when required.
            levels:
                - base
            status: not applicable
            controls:
                - id: 12.10.4.1
                  title: The frequency of periodic training for incident response personnel is defined
                      in the entity's targeted risk analysis, which is performed according to all elements
                      specified in Requirement 12.3.1.
                  description: |-
                      Incident response personnel are trained at a frequency that addresses the entity's risk.
                      This requirement is a best practice until 31 March 2025, after which it will be required
                      and must be fully considered during a PCI DSS assessment.
                  levels:
                      - base
                  status: not applicable

          - id: 12.10.5
            title: The security incident response plan includes monitoring and responding to alerts from
                security monitoring systems.
            levels:
                - base
            status: not applicable

          - id: 12.10.6
            title: The security incident response plan is modified and evolved according to lessons learned
                and to incorporate industry developments.
            description: |-
                The effectiveness and accuracy of the incident response plan is reviewed and updated after
                each invocation.
            levels:
                - base
            status: not applicable

          - id: 12.10.7
            title: Incident response procedures are in place, to be initiated upon the detection of stored
                PAN anywhere it is not expected.
            levels:
                - base
            status: not applicable

    - id: A1.1
      title: Multi-tenant service providers protect and separate all customer environments and data.
      levels:
          - base
      status: pending
      controls:
          - id: A1.1.1
            title: Logical separation is implemented.
            description: |-
                - The provider cannot access its customers' environments without authorization.
                - Customers cannot access the provider's environment without authorization.
            levels:
                - base
            status: pending

          - id: A1.1.2
            title: Controls are implemented such that each customer only has permission to access its
                own cardholder data and CDE.
            description: |-
                Customers cannot access other customers' environments.
            levels:
                - base
            status: pending

          - id: A1.1.3
            title: Controls are implemented such that each customer can only access resources allocated
                to them.
            description: |-
                Customers cannot impact resources allocated to other customers.
            levels:
                - base
            status: pending

          - id: A1.1.4
            title: The effectiveness of logical separation controls used to separate customer environments
                is confirmed at least once every six months via penetration testing.
            description: |-
                Segmentation of customer environments from other environments is periodically validated to
                be effective. The testing of adequate separation between customers in a multi-tenant
                service provider environment is in addition to the penetration tests specified in
                Requirement 11.4.6. This requirement is a best practice until 31 March 2025, after which
                it will be required and must be fully considered during a PCI DSS assessment.
            levels:
                - base
            status: pending

    - id: A1.2
      title: Multi-tenant service providers facilitate logging and incident response for all customers.
      levels:
          - base
      status: pending
      controls:
          - id: A1.2.1
            title: Audit log capability is enabled for each customer's environment that is consistent
                with PCI DSS Requirement 10.
            levels:
                - base
            status: pending

          - id: A1.2.2
            title: Processes or mechanisms are implemented to support and/or facilitate prompt forensic
                investigations in the event of a suspected or confirmed security incident for any customer.
            description: |-
                Forensic investigation is readily available to all customers in the event of a suspected
                or confirmed security incident.
            levels:
                - base
            status: pending

          - id: A1.2.3
            title: Processes or mechanisms are implemented for reporting and addressing suspected or
                confirmed security incidents and vulnerabilities.
            levels:
                - base
            status: pending

    - id: A2.1
      title: POI terminals using SSL and/or early TLS are confirmed as not susceptible to known SSL/TLS
          exploits.
      description: |-
          Appendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for
          Card-Present POS POI Terminal Connections.
      levels:
          - base
      status: pending
      controls:
          - id: A2.1.1
            title: Where POS POI terminals at the merchant or payment acceptance location use SSL and/or
                early TLS, the entity confirms the devices are not susceptible to any known exploits
                for those protocols.
            levels:
                - base
            status: pending
            notes: |-
                Related to requirements 2.2.7 and 3.5.1.1.
                Service level settings for web servers such as Apache and NGINX should also be checked.

          - id: A2.1.2
            title: 'Additional requirement for service providers only: All service providers with existing
                connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1
                have a formal Risk Mitigation and Migration Plan in place.'
            levels:
                - base
            status: pending

          - id: A2.1.3
            title: 'Additional requirement for service providers only: All service providers provide
                a secure service offering.'
            description: |-
                This requirement is not eligible for the customized approach. This requirement applies
                only when the entity being assessed is a service provider.
            levels:
                - base
            status: pending

    - id: A3.1
      title: A PCI DSS compliance program is implemented.
      description: |-
          Appendix A3: Designated Entities Supplemental Validation (DESV)
      levels:
          - base
      status: pending
      controls:
          - id: A3.1.1
            title: Responsibility is established by executive management for the protection of account
                data and a PCI DSS compliance program.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 12

          - id: A3.1.2
            title: A formal PCI DSS compliance program is in place.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirements 1-12

          - id: A3.1.3
            title: PCI DSS compliance roles and responsibilities are specifically defined and formally
                assigned to one or more personnel.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 12

          - id: A3.1.4
            title: Up-to-date PCI DSS and/or information security training is provided at least once
                every 12 months to personnel with PCI DSS compliance responsibilities (as identified
                in A3.1.3).
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 12

    - id: A3.2
      title: PCI DSS scope is documented and validated.
      levels:
          - base
      status: pending
      controls:
          - id: A3.2.1
            title: PCI DSS scope is documented and confirmed for accuracy at least once every three months
                and upon significant changes to the in-scope environment.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12.

          - id: A3.2.2
            title: PCI DSS scope impact for all changes to systems or networks is determined, including
                additions of new systems and new network connections.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12
            controls:
                - id: A3.2.2.1
                  title: Upon completion of a change, all relevant PCI DSS requirements are confirmed
                      to be implemented on all new or changed systems and networks, and documentation
                      is updated as applicable.
                  levels:
                      - base
                  status: pending
                  notes: |-
                      PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12

          - id: A3.2.3
            title: Changes to organizational structure result in a formal (internal) review of the impact
                to PCI DSS scope and applicability of controls.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 12

          - id: A3.2.4
            title: If segmentation is used, PCI DSS scope is confirmed.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 11

          - id: A3.2.5
            title: A data-discovery methodology is implemented.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Scope of PCI DSS Requirements.
            controls:
                - id: A3.2.5.1
                  title: Data discovery methods are confirmed.
                  levels:
                      - base
                  status: pending
                  notes: |-
                      PCI DSS Reference: Scope of PCI DSS Requirements.

                - id: A3.2.5.2
                  title: Response procedures are implemented to be initiated upon the detection of cleartext
                      PAN outside the CDE.
                  levels:
                      - base
                  status: pending

          - id: A3.2.6
            title: Mechanisms are implemented for detecting and preventing cleartext PAN from leaving
                the CDE via an unauthorized channel, method, or process.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12
            controls:
                - id: A3.2.6.1
                  title: Response procedures are implemented to be initiated upon the detection of attempts
                      to remove cleartext PAN from the CDE via an unauthorized channel, method, or process.
                  levels:
                      - base
                  status: pending
                  notes: |-
                      PCI DSS Reference: Requirement 12

    - id: A3.3
      title: PCI DSS is incorporated into business-as-usual (BAU) activities.
      levels:
          - base
      status: pending
      controls:
          - id: A3.3.1
            title: Failures of critical security control systems are detected, alerted, and addressed
                promptly.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 12
            controls:
                - id: A3.3.1.2
                  title: Failures of any critical security control systems are responded to promptly.
                  levels:
                      - base
                  status: pending
                  notes: |-
                      PCI DSS Reference: Requirements 1-12
                      If you noticed, this requirement should be A3.3.1.1 instead of A3.3.1.2 but it was kept
                      this way to be aligned to the policy.

          - id: A3.3.2
            title: Hardware and software technologies are reviewed at least once every 12 months to confirm
                whether they continue to meet the organization's PCI DSS requirements.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirements 2, 6, 12.

          - id: A3.3.3
            title: Reviews are performed at least once every three months to verify BAU activities are
                being followed.
            description: |-
                Reviews are performed by personnel assigned to the PCI DSS compliance program (as
                identified in A3.1.3).
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirements 1-12.

    - id: A3.4
      title: Logical access to the cardholder data environment is controlled and managed.
      levels:
          - base
      status: pending
      controls:
          - id: A3.4.1
            title: User accounts and access privileges to in-scope system components are reviewed at
                least once every six months to ensure user accounts and access privileges remain appropriate
                based on job function, and that all access is authorized.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 7.

    - id: A3.5
      title: Suspicious events are identified and responded to.
      levels:
          - base
      status: pending
      controls:
          - id: A3.5.1
            title: A methodology is implemented for the prompt identification of attack patterns and
                undesirable behavior across systems.
            levels:
                - base
            status: pending
            notes: |-
                PCI DSS Reference: Requirement 10, 12.
