Benchmark: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc
Description
The following approaches should be used to render PAN unreadable anywhere it is stored: One-way hashes based on strong cryptography, (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored) and strong cryptography with associated key-management processes and procedures. Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity's environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. 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. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or `home- grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.
Usage
Install the mod:
mkdir dashboardscd dashboardspowerpipe mod initpowerpipe mod install github.com/turbot/steampipe-mod-aws-compliance
Start the Powerpipe server:
steampipe service startpowerpipe server
Open http://localhost:9033 in your browser and select 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc.
Run this benchmark in your terminal:
powerpipe benchmark run aws_compliance.benchmark.pci_dss_v321_requirement_3_4
Snapshot and share results via Turbot Pipes:
powerpipe benchmark run aws_compliance.benchmark.pci_dss_v321_requirement_3_4 --share
Benchmarks
- 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials)
- 3.4.a Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using methods like truncation,one-way hashes based on strong cryptography etc
- 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text)
- 3.4.d Examine a sample of audit logs, including payment application logs, to confirm that PAN is rendered unreadable or is not present in the logs
Controls
- API Gateway stage cache encryption at rest should be enabled
- CloudTrail trail logs should be encrypted with KMS CMK
- DynamoDB Accelerator (DAX) clusters should be encrypted at rest
- DynamoDB table should be encrypted with AWS KMS
- DynamoDB table should have encryption enabled
- Attached EBS volumes should have encryption enabled
- EBS encryption by default should be enabled
- EFS file system encryption at rest should be enabled
- EKS clusters should be configured to have kubernetes secrets encrypted using KMS
- ES domain encryption at rest should be enabled
- Log group encryption at rest should be enabled
- RDS DB instance encryption at rest should be enabled
- RDS DB snapshots should be encrypted at rest
- Redshift cluster audit logging and encryption should be enabled
- S3 bucket default encryption should be enabled
- S3 bucket default encryption should be enabled with KMS
- SageMaker endpoint configuration encryption should be enabled
- SageMaker notebook instance encryption should be enabled
- SNS topics should be encrypted at rest