GUIDANCE FOR REQUIREMENTS 3 AND 4: PROTECT CARDHOLDER DATA

Requirement 3: Protect stored cardholder data

Protection measures such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.

Requirement Guidance
3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.Extended storage of cardholder data that exceeds business need creates an unnecessary risk. The only cardholder data that may be stored is the primary account number or PAN (rendered unreadable), expiration date, name, and service code. Remember, if you don't need it, don't store it!
Previous versions stored the same information as PCI versions, however the information was not stored in a PCI Compliant manner. Control Version 4.3x and older and SMS Version 8.9 and older are not PCI compliant and can not be made PCI compliant without considerable extra work at the users expense. Cyrious strongly recommends upgrading to the PCI compliant version of the software product they are using.
Since Control 4.0 and SMS 8.6, we have never stored any information that is not permanently retained (vcode and mag-stripe data). Prior to those versions, this information was stored in the system. The update process removes all of this sensitive information from the historical record. There is also an option to purge credit card data from the system after a customer-specified amount of time.
For users with Control 4.3x and earlier, and SMS 8.9 and earlier, upgrading to Control 4.4 or SMS 8.9pci is necessary for PCI compliance.
For problem solving:
1. Collect sensitive authentication only when needed to solve a specific problem.
2. Store such data only in specific, known locations with limited access.
3. Collect only the limited amount of data needed to solve a specific problem.
4. Encrypt sensitive authentication data while stored.
5. Securely delete such data immediately after use.
3.2 Do not store sensitive authentication data after authorization (even if encrypted).
Sensitive authentication data includes the data as cited in the following Requirements, 3.2.1 through 3.2.3: 		Sensitive authentication data consists of magnetic stripe (or track) data7, card validation code or value8, and PIN data9. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for the full definition of “sensitive authentication data.”
Since Control 4.0 and SMS 8.6, we have never stored any information that is not permanently retained (vcode and mag-stripe data). Prior to those versions, this information was stored in the system. The update process removes all of this sensitive information from the historical record.
For users with Control 4.3x and earlier, and SMS 8.9 and earlier, upgrading to Control 4.4 or SMS 8.9pci is necessary for PCI compliance.
3.2.1 Do not store the full contents of any track from the magnetic stripe (located is on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
* The cardholder's name,
* Primary account number (PAN),
* Expiration date, and
* Service code
To minimize risk, store only these data elements as needed for business.
Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. 		If full track data is stored, malicious individuals who obtain that data can reproduce and sell payment cards around the world.
Since Control 4.0 and SMS 8.6, we have never stored any information that is not permanently retained (vcode and mag-stripe data). Prior to those versions, this information was stored in the system. The update process removes all of this sensitive information from the historical record.
3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions
Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. 		The purpose of the card validation code is to protect “card-not-present” transactions—Internet or mail order/telephone order (MO/TO) transactions— where the consumer and the card are not present. These types of transactions can be authenticated as coming from the card owner only by requesting this card validation code, since the card owner has the card in-hand and can read the value. If this prohibited data is stored and subsequently stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions.
Since Control 4.0 and SMS 8.6, we have never stored any information that is not permanently retained (vcode and mag-stripe data). Prior to those versions, this information was stored in the system. The update process removes all of this sensitive information from the historical record.
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.These values should be known only to the card owner or bank that issued the card. If this prohibited data is stored and subsequently stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals).
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
Notes:
* This requirement does not apply to employees and other parties with a specific need to see the full PAN;
* This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point of sale [POS] receipts. 		The display of full PAN on items such as computer screens, payment card receipts, faxes, or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently. The PAN can be displayed in full form on the “merchant copy” receipts; however the paper receipts should adhere to the same security requirements as electronic copies and follow the guidelines of the PCI Data Security Standard, especially Requirement 9 regarding physical security. The full PAN can also be displayed for those with a legitimate business need to see the full PAN.
3.4 Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs) by using any of the following approaches:Lack of protection of PANs can allow malicious individuals to view or download this data. 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. Damage from theft or loss of backup tapes during transport can be reduced by ensuring PANs are rendered unreadable via encryption, truncation, or hashing. Since audit, troubleshooting, and exception logs have to be retained, you can prevent disclosure of data in logs by rendering PANs unreadable (or removing or masking them) in logs. Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography”
* One-way hashes based on strong cryptographyOne-way hash functions (such as SHA-1) 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).
* TruncationThe intent of truncation is that only a portion (not to exceed the first six and last four digits) of the PAN is stored. This is different from masking, where the whole PAN is stored but the PAN is masked when displayed (i.e., only part of the PAN is displayed on screens, reports, receipts, etc.).
* Index tokens and pads (pads must be securely stored)Index tokens and pads may also be used to render cardholder data unreadable. 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 private key, generated randomly, is used only once to encrypt a message that is then decrypted using a matching one-time pad and key.
* Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
Notes:
* If for some reason, a company is unable to render the PAN unreadable, refer to “Appendix B: Compensating Controls.”
* “Strong cryptography” is defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms. 		The intent of strong cryptography (see definition and key lengths 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).
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.The intent of this requirement is to address the acceptability of disk encryption for rendering cardholder data unreadable. Disk encryption encrypts data stored on a computer's mass storage and automatically decrypts the information when an authorized user requests it. Disk encryption systems intercept operating system read and write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase at the beginning of a session. Based on these characteristics of disk encryption, to be compliant with this requirement, the disk encryption method cannot have:
1) A direct association with the operating system, or
2) Decryption keys that are associated with user accounts.
3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data.
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessaryThere should be very few who have access to cryptographic keys, usually only those who have key custodian responsibilities.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.Cryptographic keys must be stored securely, usually encrypted with key encrypting keys, and stored in very few locations.
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key management process, whether it is manual or automated as part of the encryption product, addresses all key elements at 3.6.1 through 3.6.8.
Since Control 4.0 and SMS 8.6, we have never stored any information that is not permanently retained (vcode and mag-stripe data). Prior to those versions, this information was stored in the system. The update process removes all of this sensitive information from the historical record.
For users with Control 4.3x and earlier, and SMS 8.9 and earlier, upgrading to Control 4.4 or SMS 8.9pci is necessary for PCI compliance.
3.6.1 Generation of strong cryptographic keysThe encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under “strong cryptography.”
3.6.2 Secure cryptographic key distributionThe encryption solution must distribute keys securely, meaning the keys are not distributed in the clear, and only to custodians identified in 3.5.1.
3.6.3 Secure cryptographic key storageThe encryption solution must store keys securely, meaning the keys are not stored in the clear (encrypt them with a key-encryption key).
3.6.4 Periodic cryptographic key changes
* As deemed necessary and recommended by the associated application (for example, re-keying), preferably automatically
* At least annually		If provided by encryption application vendor, follow any vendor processes or recommendations for periodic changing of keys.
Annual changing of encryption keys is imperative to minimize the risk of someone's obtaining the encryption keys, and being able to decrypt data.
3.6.5 Retirement or replacement of old or suspected compromised cryptographic keysOld keys that are no longer used or needed should be retired and destroyed to ensure that the keys can no longer be used. If old keys need to be kept (to support archived, encrypted data, for example) they should be strongly protected. (See 3.6.6 below.) The encryption solution should also allow for and facilitate a process to replace keys that are known to be, or suspected of being, compromised.
3.6.6 Split knowledge and establishment of dual control of cryptographic keysSplit knowledge and dual control of keys are used to eliminate the possibility of one person's having access to the whole key. This control is usually applicable for manual key-encryption systems, or where key management is not implemented by the encryption product. This type of control is usually implemented within hardware security modules.
3.6.7 Prevention of unauthorized substitution of cryptographic keysThe encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes.
3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.This process will ensure the individual commits to the key-custodian role and understands his/her responsibilities.

Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Requirement Guidance
4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.
Examples of open, public networks that are in scope of the PCI DSS are:
* The Internet,
* Wireless technologies,
* Global System for Mobile Communications (GSM),
and
* General Packet Radio Service (GPRS. 		Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure Sockets Layer encrypts web pages and the data entered into them. When using SSL secured websites, ensure “https” is part of the URL.
Note that SSL versions prior to v3.0 contain documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the affected system.
This application uses TCP to communicate between the Client and Server. All of these should be behind the firewall or in the same VPN, though the customer could reconfigure it (against our recommendation) to go across a public network. In all cases, the transmitted information is encrypted using TDES.
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.
* For new wireless implementations, it is prohibited to implement WEP after March 31, 2009.
* For current wireless implementations, it is prohibited to use WEP after June 30, 2010. 		Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of appropriate encryption can prevent eavesdropping and disclosure of sensitive information across the network. Many known compromises of cardholder data stored only in the wired network originated when a malicious user expanded access from an insecure wireless network.
Strong encryption for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network— the data on the network—or utilizing the wireless networks to get to other internal networks or data. WEP does not utilize strong encryption. WEP encryption should never be used alone since it is vulnerable due to weak initial vectors (IV) in the WEP key-exchange process, and lack of required rotation of keys. An attacker can use freely available brute-force cracking tools to penetrate WEP encryption.
Current wireless devices should be upgraded (example: upgrade access point firmware to WPA) to support strong encryption. If current devices cannot be upgraded, new equipment should be purchased.
If wireless networks are utilizing WEP, they should not have access to cardholder data environments.
Cyrious strongly recommends against using wireless technologies to access the software. However, if wireless access is deployed (against our recommendation) the customer must still ensure that the wireless network is fully secured and using an approved wireless encryption technology.
4.2 Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat).Cyrious does not facilitate any sending of PANs out of the program, and internal communication with the PANs is always encrypted using TDES.


You could leave a comment if you were logged in.