CMP-2455: PCI-DSS v4 Requirement 3

controls/pcidss_4_ocp4.yml

@@ -812,7 +812,7 @@ controls:
         - Strong cryptography with associated key-management processes and procedures.
       levels:
         - base
-      status: pending
+      status: partial
       controls:
       - id: 3.5.1.1
         title: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1)
@@ -828,15 +828,10 @@ controls:
           assessment.
         levels:
           - base
-        status: planned
+        status: not applicable
         notes: |-
-          This requirement likely demand assessment in application level for some environments and
-          this would be too specific to be automated. However, on system level we can ensure some
-          strong cryptographic algorithms. This is also generally covered by 2.2.7 but here would
-          be possible to include more specific rules, for openssl and libreswan for example.
-          However it would be first necessary to include a platform conditional in these rules
-          before selecting them so they are applicable only if the respective packages are
-          installed.
+          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
@@ -845,8 +840,11 @@ controls:
           Requirement 3.5.1
         levels:
           - base
-        status: pending
-        rules: []
+        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
@@ -861,9 +859,46 @@ controls:
           access to unencrypted data are stored securely.
         levels:
           - base
-        status: pending
+        status: partial
         notes: |-
-          To properly check this requirement, site policies and documentation should be consulted.
+          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 RHEL7 core crypto components and https://docs.openshift.com/container-platform/4.15/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 Req-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 boud to a Tang server.
 
   - id: '3.6'
     title: Cryptographic keys used to protect stored account data are secured.