Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMP-2455: PCI-DSS v4 Requirement 3 #11951

Merged
merged 8 commits into from
May 10, 2024
Merged

CMP-2455: PCI-DSS v4 Requirement 3 #11951

Changes from 6 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
e786757
CMP-2455: Requirement 3.1 isnot applicable
yuumasato May 6, 2024
2d24c70
CMP-2455: Requirement 3.2 is not applicable
yuumasato May 6, 2024
34e755a
CMP-2455: Requirement 3.3 is not applicable
yuumasato May 6, 2024
1c72715
CMP-2455: Requirement 3.4 is not applicable
yuumasato May 6, 2024
41cacc0
CMP-2455: Requirement 3.5 is partially applicable
yuumasato May 6, 2024
765304a
CMP-2455: Requirement 3.6 is inherently met
yuumasato May 6, 2024
917057d
CMP-2455: Requirement 3.7 is not applicable
yuumasato May 6, 2024
0983a3d
CMP-2455: Adjust text and typos
yuumasato May 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
203 changes: 153 additions & 50 deletions controls/pcidss_4_ocp4.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -592,7 +592,7 @@ controls:
are Documented, Kept up to date, In use and Known to all affected parties.
levels:
- base
status: pending
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
Expand All @@ -603,7 +603,7 @@ controls:
documented, assigned, and understood.
levels:
- base
status: pending
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
Expand Down Expand Up @@ -634,16 +634,16 @@ controls:
exceeding the defined retention period has been securely deleted or rendered unrecoverable.
levels:
- base
status: pending
status: not applicable
notes: |-
This requirement is very dependent on each site policies and business model.
Local policies should be consulted and audited. Manual checking is reasonable.
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: pending
status: not applicable
controls:
- id: 3.3.1
title: SAD is not retained after authorization, even if encrypted. All sensitive
Expand All @@ -658,7 +658,12 @@ controls:
through 3.3.1.3.
levels:
- base
status: pending
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
Expand All @@ -673,13 +678,10 @@ controls:
To minimize risk, store securely only these data elements as needed for business.
levels:
- base
status: pending
status: not applicable
notes: |-
This requirement consists in auditing files, databases and memory to make sure the full
content of any track is not unnecessarily retained. It involves manual auditing but some
automated rules fit this requirement in order to reduce the chances if this data be
unintentionally stored in memory.
rules: []
OpenShift does not directly manage any track data. It is up to the application to
appropriately and dispose of this data.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved

- id: 3.3.1.2
title: The card verification code is not retained upon completion of the authorization
Expand All @@ -690,9 +692,10 @@ controls:
to verify card-not-present transactions.
levels:
- base
status: pending
status: not applicable
notes: |-
Same rules already selected in 3.3.1.1 are valid here, but they are not repeated.
OpenShift does not directly manage any card verification code. It is up to the
application to appropriately and dispose of this data.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved

- id: 3.3.1.3
title: The personal identification number (PIN) and the PIN block are not retained upon
Expand All @@ -704,9 +707,10 @@ controls:
authorization process.
levels:
- base
status: pending
status: not applicable
notes: |-
Same rules already selected in 3.3.1.1 are valid here, but they are not repeated.
OpenShift does not directly manage any cardc PIN or PIN block. It is up to the
yuumasato marked this conversation as resolved.
Show resolved Hide resolved
application to appropriately dispose of this data.

- id: 3.3.2
title: SAD that is stored electronically prior to completion of authorization is encrypted
Expand All @@ -725,13 +729,10 @@ controls:
needs to be encrypted again.
levels:
- base
status: pending
status: not applicable
notes: |-
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.
This requirement consists of auditing information stored during a relatively short period
of time. Where and how the information is possibly stored depends in each Business and
local policies so the check is not actually automatable.
OpenShift does not directly manage any SAD . It is up to the application to
yuumasato marked this conversation as resolved.
Show resolved Hide resolved
appropriately and dispose of this data.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved

- id: 3.3.3
title: Additional requirement for issuers and companies that support issuing services and
Expand All @@ -745,13 +746,16 @@ controls:
fully considered during a PCI DSS assessment.
levels:
- base
status: pending
status: not applicable
notes: |-
OpenShift does not directly manage any SAD . It is up to the application to
appropriately and dispose of this data.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved

- id: '3.4'
title: Access to displays of full PAN and ability to copy PAN is restricted.
levels:
- base
status: pending
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
Expand All @@ -766,10 +770,10 @@ controls:
Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
levels:
- base
status: pending
status: not applicable
notes: |-
Consists on examining documented policies and procedures, checking system configurations
and observing relevant applications.
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
Expand All @@ -783,11 +787,11 @@ controls:
and must be fully considered during a PCI DSS assessment.
levels:
- base
status: pending
status: not applicable
notes: |-
There are technical rules to disable removable storage devices. However, this requirement
still demand some manual auditing in documentation and eventual exceptions.
rules: []
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.
Expand All @@ -808,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)
Expand All @@ -824,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
Expand All @@ -841,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
Expand All @@ -857,15 +859,56 @@ 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
yuumasato marked this conversation as resolved.
Show resolved Hide resolved
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.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved

- id: '3.6'
title: Cryptographic keys used to protect stored account data are secured.
levels:
- base
status: pending
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 processeses.
yuumasato marked this conversation as resolved.
Show resolved Hide resolved
controls:
- id: 3.6.1
title: Procedures are defined and implemented to protect cryptographic keys used to protect
Expand Down Expand Up @@ -898,7 +941,32 @@ controls:
location of devices, as outlined in Requirement 12.3.4.
levels:
- base
status: pending
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
Expand All @@ -920,7 +988,7 @@ controls:
generated via one of the following
levels:
- base
status: pending
status: inherently met

- id: 3.6.1.3
title: Access to cleartext cryptographic key components is restricted to the fewest number
Expand All @@ -929,15 +997,50 @@ controls:
Access to cleartext cryptographic key components is restricted to necessary personnel.
levels:
- base
status: pending
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: pending
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
Expand Down