VISA Ais Guide Stepspcicompliant
VISA Ais Guide Stepspcicompliant
VISA Ais Guide Stepspcicompliant
Contents
Contents
How to make sure your business does not store Sensitive Cardholder Data Introduction Understanding Cardholder Data Sensitive Authentication Data Explained Track Data Card Verification Value 2 (CVV2) Personal Identification Number (PIN) and PIN Block Understanding Other Types of Cardholder Data Primary Account Number (PAN) Cardholder Name and Expiration Date Service Code Finding Sensitive Authentication Data Where to Look Detecting Sensitive Authentication Data How to Look Removing Sensitive Authentication Data Methods by Media Contact Information 2 2 2 4 4 5 5 6 6 7 7 8 10 12 12 13
2 How to make sure your business does not store Sensitive Cardholder Data
How to make sure your business does not store Sensitive Cardholder Data
Introduction
Card transactions have become a common way for customers to purchase goods and services at their local retail stores over the Internet and while shopping abroad. To help keep card payments safe and convenient, Visa has helped form an organization called the Payment Card Industry Security Standards Council (PCI SSC). PCI SSC maintains and supports a number of different security standards, with perhaps the most well known being the PCI Data Security Standard (PCI DSS). This standard details the requirements which all entities that store, process or transmit cardholder data must follow to ensure that cardholder data is kept secure. Two key requirements of the PCI DSS address directly the handling of cardholder data. These requirements are: Do not store1 sensitive authentication data subsequent to authorization Secure non-sensitive authentication data, wherever it is stored
MERCHANT
PROCESSOR
ACQUIRER
VISANET
ISSUER
Figure 1
How to make sure your business does not store Sensitive Cardholder Data 3
Transactions are performed using information from the cardholders payment card and may include other authentication data provided by the customer themselves, such as a signature or a personal identification number (PIN). This information is used by the card issuer to verify and approve transactions, and therefore it is vital that such data is protected. A representation of a payment card is provided below:
1 2 3 4
1 - Chip of a smart card 2 - Primary Account Number (PAN) 3 - Expiry date of the card 4 - Cardholder name
1 2 4
Figure 2
1 - Magnetic strip 2 - Cardholder signature 3 - Visa security code (CVV2) 4 - Visa Hologram
Sensitive cardholder data refers to cardholder data that must not be stored subsequent to transaction authorization. Storage of such data is not permitted under any circumstances, even if the data is encrypted or otherwise protected. There are three types of sensitive cardholder data values, collectively known as sensitive authentication data, which are used by the card issuer to confirm the presence of the physical card plastic and/or cardholder at the time of the authorization. The three types of sensitive authentication data are: Full contents of the magnetic stripe, also referred to as Track Data Security code (called a Card Verification Value 2, or CVV2, by Visa) PIN or PIN block
In the normal operation of your business there should not be need to store sensitive authentication data subsequent to authorization. Storage of this data decreases the effectiveness of authorization and fraud detection systems in the authorization process and can lead to increased credit card fraud if compromised. Visa does not require that sensitive authorization data be kept subsequent to authorization in fact it is a violation of the PCI DSS requirements and Visas International Operating Regulations to store such data after authorization.
Track 1
Track 2
The sensitive authentication data can be found towards the end of both Track 1 and Track 2. It is a violation of the Visa International Operating Regulations and the PCI Data Security Standards to store sensitive authentication data subsequent to authorization. Non-sensitive authentication on the track may be stored but must be protected in accordance to the PCI DSS requirements.
Great care needs to be taken with CVV2 since a cardholder may communicate this value to you directly, for example, via your call center or website. Even in these cases, the CVV2 must not be stored post authorization.
0, 1, 2, 3
0 9 or A C
0 9
Encrypted PIN blocks take the form of 64 bits, or 16 hexadecimal numbers, of random digits. The encrypted PIN block is transmitted in ISO 8583 compliant messages in field 454.
Luhn 10 check
The Luhn 10 check formula verifies a number against its check digit (the rightmost digit). A compliant account number must pass the following test: 1. Counting from the check digit, which is the rightmost digit, and moving left, double the value of every second digit. 2. Sum the digits of the products together with the non-doubled digits from the original number. 3. If the total ends in 0, then the number is valid according to the Luhn formula; otherwise it is not a valid PAN. As an illustration, if the account number is 49927398716, it will be alidated as follows: v 1. Double every second digit, from the rightmost: (1x2) = 2, (8x2) = 16, (3x2) = 6, (2x2) = 4, (9x2) = 18 2. Sum all digits (digits in parentheses are the products from Step 1: 6 + (2) + 7 + (1 + 6) + 9 + (6) + 7 + (4) + 9 + (1 + 8) + 4 = 70 3. As the result (70) has a zero on the end and therefore can be divided by ten, the result is a valid PAN value.
When printed or embossed, the expiration date is recorded in MM/YY format, but is recorded in track data as YYMM. This date is generated by the card issuer.
Service Code
The service code defines various services, differentiates cards used in international or domestic environments and identifies card restrictions. The service code is digitally recorded in Track 1 and Track 2 or in the chip. It is a 3 decimal digit number and is generated by the card issuer. Common service code values are 101 or 104.
Name
Storage of this data (even if encrypted) post authorization is a violation of the data handling requirements.
Other processes that may involve the use of cardholder data include: Customer service/transaction dispute Merchant settlement Customer identification
It is important to take special care when the data passes through computer systems. Modern computer systems often create logs or use virtual memory to ensure smooth system processing these must also be taken into account while looking for the storage of sensitive data. The scope of your investigation on your computer infrastructure can be significantly reduced (with associated time and money savings) by the implementation of network segmentation (e.g. using VLANs) and firewalls. However, it should be understood that when looking for the storage of sensitive authentication data you are essentially validating any network segregation that you have put in place therefore, it is vital that systems that should not be storing, processing or transmitting such data are checked to confirm that this is indeed the case.
10
Procedure 1. For each of the transaction types used by your business, enter a transaction making note of the values, e.g. PAN, expiry date, CVV2, Track 1, Track 2. 2. Investigate each item in the transaction flow, looking for sensitive authentication data.
Comments This method is useful for checking for CVV2 and encrypted PIN block values where the data may be difficult to find otherwise.
The following data items have known patterns and can be scanned using scanning tools: PAN (Luhn 10 check) PAN starting digits Track 1 and Track 2 formats Plaintext PIN block formats Review the layout or schema of the databases used in your company to see if any columns or entries have headings (such as track data or CVV2) that may indicate that sensitive data is being stored. Do not look for sensitive authentication data only in places where you expect it may be. This data can occur in many different Databases may be used by companyspecific systems or may be part of a commercial software package Locations for many different reasons. Do not look for sensitive authentication data only in places where you expect it may be. This data can occur in many different locations for many different reasons.
Sensitive authentication data may be stored either deliberately or inadvertently in many different places. Payment software may be designed to store data deliberately for error recovery or communications software logs may be inadvertently storing data. Talk to your payment system vendors and determine how their systems operate if there is an error. Often systems store sensitive authentication data to assist in finalizing payment processing when an error occurs.
When looking for sensitive authentication data it is important to understand the transaction process not only when the payment works, but also what happens when the payment does not work.
Methods by Media
The following table details common storage locations and suggested actions to assist in compliance. Media Paper/fax Soft copy images (scanned documents, fax servers) Call center call recording Computers and computer storage Actions Shred post authorization Blackout cardholder data with ink Alter processes so data is no longer required Delete post authorization If possible, electronically black sensitive fields Confirm if CVV2 is being recorded; if it is, consider blanking technology Encrypt and securely store all call data at a minimum6 Use only PA-DSS approved applications Consult with software developer and confirm if application is PCI DSS compliant and if any special settings are required Analyze all applications known to handle sensitive data Scan all storage for PAN and track data, including log and backups Consult with manufacturer and confirm if device is PCI DSS compliant and if any special settings are required Analyze all log file for sensitive data If backup is pre-authorization, review the purpose of the backup and where possible modify Encrypt backups
Network equipment
Backups
Storage of sensitive authentication data within voice recordings is acceptable only if there is no commercially feasible method of removing this data, and any such data that is stored is securely encrypted.
Contact Information 13
Contact Information
For more information on this document or the AIS program, please visit our website at www.visa-asia.com/secured or contact:
Ian McKindley
Risk Management Australia, New Zealand & the Pacific Islands IMckind@visa.com
Tony Zhu
Murugesh Krishnan
Risk Management South & Southeast Asia murugesh@visa.com
Navy Li
Vincent Lee
Raveendhrun Anantharaman
Risk Management South Asia raveesa@visa.com
Ryoji Ihara
Michael Chan
Igarashi Kouji
Risk Management Japan koigara@visa.com