PCI Requirement 3
This is some of the meat of the spec, in my opinion. This is yet another area for managed service providers to develop a solution for this. It wouldn't be that hard.
Requirement 3: Protect stored cardholder data
•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.
•3.2 Do not store sensitive authentication data subsequent to authorization (even if encrypted).
•Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
–3.2.1 Do not store the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data
–In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements. Note: See “Glossary” for additional information.
–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 “Glossary” for additional information.
–3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
•3.4 Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:
• Strong one-way hash functions (hashed indexes)
•Truncation
•Index tokens and pads (pads must be securely stored)
•Strong cryptography with associated key management processes and procedures.
–The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”
–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
Payment Card Industry (PCI) Data Security Standard 5
–mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
•3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse.TNT will allow a company to restrict and audit in real time, access to all sensitive data. Including access to the network, the server, and the application in which it is stored. TNT will also cloak all of the sensitive assets so that if a user using a specific machine tries to access an application.
•3.5.1 Restrict access to keys to the fewest number of custodians necessary TNT will enable and enforce from 2 to n users from 2 to n specific machines
•3.5.2 Store keys securely in the fewest possible locations and forms.
•3.6 Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following:
–3.6.1 Generation of strong keys
–3.6.2 Secure key distribution
–3.6.3 Secure key storage
–3.6.4 Periodic changing of keys
As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically. At least annually. The TNT Solution offers one of the most compelling ways to handle this that I've seen. Their software binds the user's fully qualified domain name (post authentication) AND a unique machine ID together, hashes and encrypts it and then inserts it into the packets leaving a machine. This means that if the machine is lost and/or compromised that the machine and the user will noyt be able to gain access to that application from that device again. If hardware changes on the machine (someone installs another hard drive with hacker tools) then the machine invalidates itself and must get a new software key.
–3.6.5 Destruction of old keys
–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)
–3.6.7 Prevention of unauthorized substitution of keys
–3.6.8 Replacement of known or suspected compromised keys
–3.6.9 Revocation of old or invalid keys
–3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
Requirement 3: Protect stored cardholder data
•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.
•3.2 Do not store sensitive authentication data subsequent to authorization (even if encrypted).
•Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
–3.2.1 Do not store the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data
–In the normal course of business, the following data elements from the magnetic stripe may need to be retained: the accountholder’s name, primary account number (PAN), expiration date, and service code. To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements. Note: See “Glossary” for additional information.
–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 “Glossary” for additional information.
–3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
•3.4 Render PAN, at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:
• Strong one-way hash functions (hashed indexes)
•Truncation
•Index tokens and pads (pads must be securely stored)
•Strong cryptography with associated key management processes and procedures.
–The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.”
–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
Payment Card Industry (PCI) Data Security Standard 5
–mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
•3.5 Protect encryption keys used for encryption of cardholder data against both disclosure and misuse.TNT will allow a company to restrict and audit in real time, access to all sensitive data. Including access to the network, the server, and the application in which it is stored. TNT will also cloak all of the sensitive assets so that if a user using a specific machine tries to access an application.
•3.5.1 Restrict access to keys to the fewest number of custodians necessary TNT will enable and enforce from 2 to n users from 2 to n specific machines
•3.5.2 Store keys securely in the fewest possible locations and forms.
•3.6 Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following:
–3.6.1 Generation of strong keys
–3.6.2 Secure key distribution
–3.6.3 Secure key storage
–3.6.4 Periodic changing of keys
As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically. At least annually. The TNT Solution offers one of the most compelling ways to handle this that I've seen. Their software binds the user's fully qualified domain name (post authentication) AND a unique machine ID together, hashes and encrypts it and then inserts it into the packets leaving a machine. This means that if the machine is lost and/or compromised that the machine and the user will noyt be able to gain access to that application from that device again. If hardware changes on the machine (someone installs another hard drive with hacker tools) then the machine invalidates itself and must get a new software key.
–3.6.5 Destruction of old keys
–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)
–3.6.7 Prevention of unauthorized substitution of keys
–3.6.8 Replacement of known or suspected compromised keys
–3.6.9 Revocation of old or invalid keys
–3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
posted by Mark Mac Auley at 10:31 AM
1 Comments:
Mark: Merchants are caught between a rock and a hard place. New laws forbid them from storing certain payment data, but PCI requirement 3.1 recognizes they may need to store that data for business, legal or regulatory purposes. When auditors search for historical fraud, they need access to very detailed data.
Post a Comment
<< Home