PCI Data Security Compliance Checklist
How EncryptRIGHT Meets PCI Data Security Requirements
The Payment Card Industry Data Security Standard (PCI DSS or just PCI) is a multifaceted security standard that includes requirements for security management policies, procedures, network architecture, software design, and other critical protective measures. Every organization with confidential data - and that includes just about everyone - could use the PCI security requirements as a guide to establish their data protection policies and procedures.
The document recommends 12 broad PCI security requirements which range from firewalls and physical access to software and data security systems, and documented procedures. EncryptRIGHT can help you meet aspects of PCI compliance required for cryptography and key management.
Six of the 12 PCI security requirements address encryption and key management, and EncryptRIGHT helps you comply with all six (in bold below):
- Install and maintain a firewall configuration to protect cardholder data.
- Do not use vendor-supplied defaults for system passwords and other security parameters.
- Protect stored cardholder data.
- Encrypt transmission of cardholder data across open, public networks.
- Use and regularly update anti-virus software.
- Develop and maintain secure systems and applications.
- Restrict access to cardholder data by business need-to-know.
- Assign a unique ID to each person with computer access.
- Restrict physical access to cardholder data.
- Track and monitor all access to network resources and cardholder data.
- Regularly test security systems and processes.
- Maintain a policy that addresses information security.
The other requirements relate to policies, procedures and network architecture. Here is a requirement-by-requirement evaluation of how EncryptRIGHT meets PCI encryption and key management requirements:
PCI Requirement #2
Do not use vendor-supplied defaults for system passwords and other security parameters.
EncryptRIGHT does not have a default User ID or password. On installation a UserID and password must be created and given administrative rights before installation can continue.
PCI Requirement #3
Protect stored cardholder data.
EncryptRIGHT complies with this requirement in each of the following specifics:
Requirement
|
EncryptRIGHT Compliance
|
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
|
EncryptRIGHT provides the capability to define a group of users that only have rights to view a masked portion of a data field. This includes applications that decrypt the data, the EncryptRIGHT audit log and EncryptRIGHT trace files.
|
3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs).
|
EncryptRIGHT provides strong cryptography and key management to protect your data. This includes strong hashing (SHA 2 256/384/512) and encryption (Triple DES 2/3 key, and AES 128/192/256).
|
3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse.
|
EncryptRIGHT requires a UserID and password for all users. Each user is assigned to one (or more) groups. Each group is assigned the types of access within the EncryptRIGHT administration application. This includes the ability to view or maintain keys and other information. In addition EncryptRIGHT allows you to require a quorum of logged on users for administration functions.
|
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.
3.6.1 Generation of strong cryptographic keys.
|
EncryptRIGHT supports Triple DES 2/3 keys. AES 128, 192 and 256. RSA public keys from 1024 to 4096 bits.
|
3.6.2 Secure cryptographic key distribution.
|
Secure key distribution is provided in EncryptRIGHT when the client/server option is licensed. This provides for a server where keys are maintained and one or more client computers connected through a TCP/IP network. Each client computer is registered to the server and the server automatically distributes key changes to the clients. All key distributions are encrypted.
|
3.6.3 Secure cryptographic key storage
|
EncryptRIGHT hashes and encrypts all records within the EncryptRIGHT security database using a randomly generated local master key. The master key is protected by the software license which is restricted to licensed computers only.
|
3.6.4 Periodic cryptographic key changes
|
EncryptRIGHT allows you to change key values manually or automatically. Automatic key changes can be set to occur weekly, monthly, quarterly or yearly.
|
3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys
|
EncryptRIGHT allows you to designate when a key can be destroyed. The choices are never (for long term data storage), on expiration, expiration plus 1 week, expiration plus 1 month, expiration plus 1 quarter, expiration plus 1 year, expiration plus 2 years, expiration plus 3 years, expiration plus 4 years, expiration plus 5 years, expiration plus 6 years and expiration plus 7 years.
Any key that becomes compromised or invalid can be marked as revoked. A new value can easily be created. Every production key value is assigned a unique key version number. When a specific key value is marked as revoked, or is otherwise superseded, a new version is created. Both keys still exist in the database, so if an application attempts to use a revoked key, they will receive an indication that the key is revoked.
|
3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key)
|
EncryptRIGHT provides the ability for up to 3 different people to enter key components. Additionally you can require that the components must be entered by different users. You also have the ability to require a quorum of users to be logged on. For example you can require two people with rights for key management be logged on at the same time to enter a key component, where one person enters the key and the other observes.
|
3.6.7 Prevention of unauthorized substitution of cryptographic keys
|
Key values cannot be substituted by unauthorized people. Every user should be assigned a unique UserID and password. Every key change is logged in the EncryptRIGHT secure audit log.
|
PCI Requirement #4
Encrypt transmission of cardholder data across open, public networks.
Although this requirement talks about using SSL and TLS security over networks, it is always better to also encrypt sensitive data from application to application so the data is not only protected during transmission, but also between transmission and the application that will process the data. For example, when you send an un-encrypted file through a secure network, the file may temporarily reside on the receiving computer until some process uses the data. During this time someone could access or even change the data without your knowledge. Use EncryptRIGHT to protect this data until the receiving application can process the data.
PCI Requirement #7
Restrict access to cardholder data by business need-to-know.
EncryptRIGHT provides the ability to define the level of data access for each user. Access can be specified at the record and/or data field level. The type of access that can be defined is no access, masked access (specifying the mask character, the position and length of the clear data), read only or read/write. By default no access is allowed for anyone when creating record definitions. In order to use a definition you must provide access definitions.
PCI Requirement #8
Assign a unique ID to each person with computer access.
EncryptRIGHT complies with this requirement in each of the following specifics:
Requirement
|
EncryptRIGHT Compliance
|
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
|
EncryptRIGHT allows for all users to have a unique UserID and password. This is used not only for access to the EncryptRIGHT database, but also for access to cryptography for your defined user data records and fields.
|
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.
|
Passwords are stored self encrypted. This means that they are encrypted using a key derived from the password itself. These passwords cannot be decrypted. The only way to verify a password is to enter the same password, which is encrypted and then compared to the original encrypted password.
|
8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
|
Only user administrators can add, delete and change users. In addition this can be further controlled by requiring a quorum of logged on users so no single person can maintain user information without supervision.
|
8.5.2 Verify user identity before performing password resets.
|
Passwords can only be changed by a user if the user also enters the current password.
|
8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use
|
EncryptRIGHT defaults to forcing the user to change their password anytime an administrator sets or changes a user's password.
|
8.5.4 Immediately revoke access for any terminated users.
8.5.5 Remove/disable inactive user accounts at least every 90 days.
8.5.6 Enable accounts used by vendors for remote maintenance only during the time period needed.
|
Users can be temporarily disabled or entirely deleted by user administrators at any time.
|
8.5.9 Change user passwords at least every 90 days.
8.5.10 Require a minimum password length of at least seven characters.
8.5.11 Use passwords containing both numeric and alphabetic characters.
8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.
8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.
8.5.14 Set the lockout duration to 30 minutes or until administrator enables the user ID.
|
EncryptRIGHT provides a password policy that can specify the following:
- Maximum and minimum password age.
- Minimum password length
- Password uniqueness. This includes how many passwords to remember, the maximum characters that can be repeated from the previous password, and a password dictionary.
- Required special characters, upper/lower case and numerics.
- Bad attempts lockout count, and the duration of the lockout.
|
8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.
|
EncryptRIGHT can optionally require a UserID and password for API use. This means that in order for an application to use the EncryptRIGHT library to encrypt any data, a UserID and password has to be given to the library for verification. With this, EncryptRIGHT fetches the access rights the user has. When a data record definition in EncryptRIGHT is used to encrypt or decrypt data, the user's access rights are checked to determine if they can decrypt data, and if so, do they only see a masked version of the data, or can the view or update the data.
|
PCI Requirement #10
Track and monitor all access to network resources and cardholder data.
EncryptRIGHT complies with this requirement in each of the following specifics:
Requirement
|
EncryptRIGHT Compliance
|
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
|
EncryptRIGHT allows for all users to have a unique UserID and password.
|
10.2 Implement automated audit trails for all system components to reconstruct the following events.
|
EncryptRIGHT provides the ability to create a secure audit log entry for access to data down to the field level. An audit log entry is made for Invalid access attempts also. Audit log entries are made for all changes made to definitions within EncryptRIGHT. An audit log entry is optionally created for all user logons and logoffs.
|
10.3 Record at least the following audit trail entries for all system components for each event.
|
The EncryptRIGHT audit log contains the UserID, the type of message, date and time, the EncryptRIGHT subsystem name and the success or failure message.
|
10.5 Secure audit trails so they cannot be altered.
|
The EncryptRIGHT audit log is secure. Each entry contains a sequence number and the entire entry is hashed and encrypted. When viewing the log, each entry hash and sequence number is verified. The ability to view the audit log can be assigned to groups of users.
|
| |
|
