Sunday, August 27, 2017

PCI-DSS Standard

Basic PCI Data Storage Guidelines for Merchants

Cardholder data refers to any information contained on a customer’s payment card. The data is
printed on either side of the card and is contained in digital format on the magnetic stripe embedded
in the backside of the card. Some payment cards store data in chips embedded on the front side.
The front side usually has the primary account number (PAN), cardholder name and expiration date.
The magnetic stripe or chip holds these plus other sensitive data for authentication and authorization.
In general, no payment card data should ever be stored by a merchant unless it’s necessary to meet
the needs of the business. Sensitive data on the magnetic stripe or chip must never be stored. Only
the PAN, expiration date, service code, or cardholder name may be stored, and merchants must use
technical precautions for safe storage (see back of this fact sheet for a summary). The matrix below
shows basic “do’s” and “don’ts” for data storage security

Technical Guidelines for Stored Payment Card Data

PCI DSS Requirement 3 details technical guidelines for protecting stored cardholder data. Merchants
should develop a data retention and storage policy that strictly limits storage amount and retention
time to that which is required for business, legal, and/or regulatory purposes.

Sensitive authentication data must never be stored after authorization – even if this data is encrypted.

• Never store full contents of any track from the card’s magnetic stripe or chip (referred to as full
track, track, track 1, track 2, or magnetic stripe data). If required for business purposes, the
cardholder’s name, PAN, expiration date, and service code may be stored as long as they are
protected in accordance with PCI DSS requirements.

• Never store the card-validation code or value (three- or four-digit number printed on the front or
back of a payment card used to validate card-not-present transactions).

• Never store the personal identification number (PIN) or PIN Block. Be sure to mask PAN whenever
it is displayed. The first six and last four digits are the maximum number of digits that may be
displayed. This requirement does not apply to those authorized with a specific need to see the full
PAN, nor does it supersede stricter requirements in place for displays of cardholder data such as
on a point-of-sale receipt.

Technical Guidelines for Protecting Stored Payment Card Data

At a minimum, PCI DSS requires PAN to be rendered unreadable anywhere it is stored – including
portable digital media, backup media, and in logs. Software solutions for this requirement may
include one of the following:

One-way hash functions based on strong cryptography – also called hashed index, which
displays only index data that point to records in the database where sensitive data actually reside.
Truncation – removing a data segment, such as showing only the last four digits.
Index tokens and securely stored pads – encryption algorithm that combines sensitive plain text
data with a random key or “pad” that works only once.
Strong cryptography – with associated key management processes and procedures. Refer to the
PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms for the definition of “strong
cryptography.”

Some cryptography solutions encrypt specific fields of information stored in a database; others
encrypt a singular file or even the entire disk where data is stored. If full-disk encryption is used,
logical access must be managed independently of native operating system access control
mechanisms. Decryption keys must not be tied to user accounts. Encryption keys used for
encryption of cardholder data must be protected against both disclosure and misuse. All key
management processes and procedures for keys used for encryption of cardholder data must be
fully documented and implemented. For more details, see PCI DSS Requirement 3.

No comments:

Post a Comment

Cross Site Request Forgery Protection with Double Submit Cookies Patterns

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudo-random value and set it as a cookie on the...