Shopper Login | 877-574-6682

Protecting EBR Integrity with PCI Standards

PCI and Exception-Based Reporting

Protecting Report Integrity

While all retailers are now familiar with the Payment Card Industry (PCI) Data Security Standards (DSS), some are still working on how best to protect cardholder data within their exception based reporting (EBR) application. Ultimately, the answer on how this data will be protected may depend on company-wide decisions or chosen protection methods.  However, how your company chooses to protect the data may affect your ability to also effectively utilize reporting to detect exceptions.

The most common methods of cardholder data protection currently in use are: Masking, Encrypting, and Hashing. Each of these techniques has its benefits and limitations as they relate to their ability to provide adequate reporting within an EBR application.


Masking

Masking is the method most consumers are familiar with since many retailers, restaurants, etc., began "masking" credit card numbers on receipts, even before PCI-DSS was a requirement. Masking involves "hiding" certain numbers within the credit/debit card number. Businesses that mask credit/debit card numbers can show up to the first 6 digits and the last 4 digits of the number, with all digits in between "masked" (usually shown as "X" on a receipt).

While this method is the easiest to implement, and can provide valuable information for the merchant, it has also been found to be the least "safe" method for protecting cardholder data. Since the majority of credit/debit card numbers most commonly used in the United States consist of 14-16 digits, a hacker need only to identify 4-6 digits in order to obtain a complete, valid credit/debit card number. Research suggests this can be accomplished in a matter of a few hours.

Masking in relation to EBR can also present challenges in reviewing and identifying potential fraud issues. Taking into account that a merchant may show up to the first 6 digits (which usually contains issuing bank and/or regional information) and the last 4 digits of an account number, it is quite possible for different credit/debit cards issued by the same company/bank to appear to be the same credit/debit card account number if the number is masked. The result of different account numbers appearing to be the same account number due to the use of masking is commonly referred to as a "false positive". False positives within EBR reports can be not only time-consuming, but also costly to research and investigate.

While masking may be considered an ideal option for transaction data receipts, more secure methods exist for the processing and storing of cardholder data. In the evaluation of a more secure method of compliance in conjunction with EBR, the primary consideration of an organization may need to be the system in use and IT capability. In addition, it is important to determine if the credit/debit card number will need to be retrieved for any reason in the future. This is an important consideration and the main differential between the next two methods: Encrypting and Hashing.


Encryption

Encryption is a method whereby the account number is changed into a series of alpha-numeric digits, which essentially makes the number meaningless to the viewer. Encryption is a two-way process, so if you require the need to reverse the process to obtain the actual card number within your EBR process, encryption may in fact be the preferred method of protection.

In relation to an EBR application, a primary benefit to encryption is that the encrypted number, although meaningless, will be the same each time a specific credit/debit card is used (provided the encryption key remains the same). This can greatly reduce the number of false positives as described with masking. Drawbacks to using encryption include: possible stricter PCI standards, since the encryption can be reversed to obtain true account data; increased system security measures to safeguard the encryption key; as well the possible loss of historical data if the encryption key is changed. However, it is possible to re-encrypt the historical data with the new key to ensure future use of a particular account is captured under the same encryption.


Hashing

The final most common method to protecting cardholder account data is Hashing. Hashing is very similar to encryption; however, it cannot be reversed. Like encryption, hashing also changes the credit/debit card number into a series of alpha numeric digits, creating a meaningless number to the viewer. However, hashing creates a unique number for each account number using an algorithm, which can prove to be a preferred method in conjunction to its use with an EBR tool.

Since the algorithm is the same, it will produce the same hash number each time a specific credit/debit number is used. This allows for the generation of multiple EBR reports without the fear of false positives. Again, it is important to note that unlike encryption, hashing is not reversible and the raw number cannot be retrieved systemically.


Determining Which Method is Best

The ability to maintain the integrity of the card should be considered paramount in determining the chosen method of protection for an EBR application. Hashing or encryption provides these levels of integrity. Coupling one of these chosen methods in conjunction with a masked credit card field in your reports will provide your EBR reporting with a good visible report and the necessary integrity to eliminate almost all false positive possibilities.

Beyond methods of protection, there are other considerations that need to be made by an organization prior to choosing a final method. These considerations include reviewing who requires raw number visibility, access to decryption methods and access to systems that may show raw numbers are some of these considerations. PCI standards are changing how data has been seen and utilized by retailers, and will require changes to not only systems, but processes as well. When it comes to EBR applications, the overall goal is to protect the data without losing the ability to detect the exceptions

 

 

© 2009 LP Innovations, Inc.

 

 

Subscribe to email list!

Try Our Blog!

Talk with a member of the LPI Team!

 

 

 

 

LP Innovation