The act of storing primary account numbers (PANs) has already had a profound effect on network security for a plethora of organizations. Massive data breaches have ensued over the years based on companies choosing to store PANs on their servers for ease of access.
Many companies who have been inflicted by a data breach use this excuse of consumer convenience in their choice to store PAN data on their network. These companies who use this excuse also are not Payment Card Industry Data Security Standard (PCI DSS) compliant as the PCI DSS requires that merchants never store track data, for any reason.
When merchants get into the habit of storing customer PAN, they run the risk of becoming breached by hackers who gain access to their system to wreak havoc on their infrastructure. Thankfully, the more merchants understand how their organization’s card data flows, the better they will be equipped to implement the correct series of controls necessary to combat the seizure of sensitive PAN under their watch.
With this in mind, let’s define PAN more broadly, understand its importance, and what measures an organization that handles PANs need to take to become PCI DSS compliant.
What is PAN Data?
The PCI Glossary goes on to define it as the “unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.” In short, the 14-, 15-, or 16-digit numbers on the front of your credit card, otherwise known as primary account numbers (PANs) are issued and used to identify individual cards by merchants at the point of sale (POS).
If merchants get in the habit of storing unencrypted PAN on their networks, they can potentially put their entire network at big risk for a breach. 67% of PANscan users admitted to storing unencrypted PAN in 2016 alone (a nearly 3% increase from the year before). The same report found that more than 5% of these businesses stored track PAN that year (a 40% increase over the previous year).
These data points are constantly increasing as merchants are looking for new ways to cut steps out of the payment process at the POS for their customers to have a more streamlined checkout process.
Assess your PCI compliance
What these merchants neglect to fully understand is that if a fraudster gains access to PAN, they will be able to identify the card issuer and trace back an account through the credit card data to the actual cardholder. Therefore, it is necessary that this information be protected and not stored to prevent it from getting into the wrong hands.
A common misconception is that all elements of cardholder data must be encrypted when stored — in reality it is only the PAN that needs to be encrypted. Sensitive authentication data (SAD), on the other hand, can never be stored by merchants.
All in all, the PAN is the defining factor in the storage of cardholder data. The times that PAN is not considered to be cardholder data would be if there is no mention of the cardholder’s name and/or expiration date on the card itself. This doesn’t happen often, thus it is better if merchants prepare their data network to deal with PAN in a way that accommodates the most common form of this type of consumer data. This ensures that there is consistency in how the organization handles PAN as it is most commonly transmitted at the POS.
Read RSI Security’s related blog article about tracking and monitoring all access to network resources and cardholder data.
Importance of PAN Data
PAN data is immensely important for your organization from many standpoints. If there are security vulnerabilities in your system and you have PAN data in your network (encrypted or unencrypted), you better believe that hackers will sniff out those vulnerabilities quickly and with ferocity. Therefore, it is incredibly important to keep all your systems and applications updated with the latest security patches.
Also of great importance is to secure customer data through the entire payment life cycle from credit card acceptance to payment processing. By protecting your customer’s SAD at the POS as it flows into your payment system, you can minimize the risk to your organization and improve your standing with your customers simultaneously.
PCI DSS Compliance
All merchant and service providers who store, process or transmit cardholder data must be PCI DSS compliant. The 12 PCI DSS requirements apply to all payment channels including (but not limited to) e-commerce business, retail shops and mail/telephone order companies. Becoming compliant calls for the entity to speak to their merchant acquiring bank about compliance who then will refer them to a Quality Security Assessor (QSA). These QSA’s will perform comprehensive PCI compliance assessments that relate to the protection of customer SAD such as PAN.
If a merchant travels down the path towards compliance, they need to maintain their compliance or they will be hit by fines ranging from $5,000 to $100,000 per month by banks and credit card institutions. These fines can have a significant negative financial impact for merchants and can lead to their actions becoming more scrutinized by the Council and the consumers that frequent their organization.
Necessary Security Precautions
One of the main things that trips up merchants is their inability to configure a secure solution for safely storing consumer cardholder data after authorization (including PAN). Even if the PAN is encrypted, it is still in violation of Requirement 3 of PCI DSS. Card verification codes (CVCs) and personal identification numbers (PINs) data also need to be rendered unrecoverable upon completion of the authorization process.
The cardholder data that can be stored and the security that merchants need to implement to keep that data safe isn’t a “one size fits all” concept. Merchants need to understand the locations where their cardholder data is stored and to protect it by taking the necessary security precautions.
Even if the merchant implements strong security measures, they need to follow up with configuring an appropriate key management process through all payment life cycles. The merchant’s success in managing their keys will depend on how well their trusted cryptographic key custodians are at keeping keys secured from hackers who attempt to collude to attack their systems.
Documentation and Prevention
By fully documenting the way they implement and manage various keys throughout their life cycles, merchants can decrease their risk for a data breach exponentially. Taking shortcuts in your key management protocols will ultimately lead to QSAs (and attackers) finding errors in your security measures and exploiting them.
It is extremely important to consistently take preventative measures to not store any cardholder data unless you have a legitimate business need to do so. The PCI Security Standards Council (SSC) which oversees and administers the PCI DSS is the organization that constitutes what a legitimate business need truly.
The decision by the Council to deem PAN storable will depend on the merchant’s industry, the amount of transactions they process in each year, and their historical standings related to PCI DSS. These matters are taken extremely seriously by the Council which is why any request by a merchant to store customer PAN is investigated and approved on a case-by-case basis.
If ever in doubt of whether to store cardholder data or documents, remember this mantra: “if you don’t need it, don’t store it.”
Requirement 3
The best measures to take in handling PAN is to follow PCI DSS requirement 3 which calls for the merchant to focus on developing a data retention and storage policy that limits storage amount and retention time for cardholder data. Storing cardholder data needs to be done in a way that leaves any stored PAN completely unreadable via strong cryptography measures.
Merchants can go so far as to encrypt the entire storage disk that the cardholder data is present on and make the data inaccessible unless via natively selected access controls. Merchants can also can take the data offline to be accessed via random encrypted keys completely to protect it from unintentional disclosure or misuse.
It is paramount that your organization truncate, redact, and/or mask PAN data to keep it away from the grasp of individuals that do not have the necessary authorization access.
PCI DSS Requirement 3.3 calls for merchants to limit the PAN display to the minimum number of digits necessary to perform basic job functions (the display should not exceed the first 6 and last 4 digits). If merchants are unfamiliar with the protocol for masking their PAN, a QSA can help them configure the methodology for protecting their PAN and render it unreadable wherever it happens to be stored.
PAN Cryptography Strategies
No matter the approach merchants intend to use to render their stored data unreadable, they need to be secured by being associated with cryptographic keys and/or index tokens. The Council defines these keys and tokens as, “a cryptographic token that replaces the PAN based on a given index for an unpredictable value.”
If the PAN data that the merchant is using has been encrypted, the QSA will need to verify that the merchant is using an industry-accepted encryption protocol to ensure full compliance with requirement 3. Merchants should go about handling their cardholder data or SAD in their Cardholder Data Environment (CDE) via following the below guidelines:
| Data Element | Storage Permitted | Render Stored Data Unreadable | ||
| Account Data | Cardholder Data | Primary Account Number (PAN) | Yes | Yes |
| Cardholder Name | Yes | No | ||
| Service Code | Yes | No | ||
| Expiration Date | Yes | No | ||
| Sensitive Authentication Data | Full Track Data | No | Cannot store per PCI DSS Requirement 3.2 | |
| CAV2/CVC2/CVV2/CID | No | Cannot store per PCI DSS Requirement 3.2 | ||
| PIN/PIN Block | No | Cannot store per PCI DSS Requirement 3.2 | ||
If cardholder data was printed, processed, transmitted or stored in the CDE, merchants must implement the same security measures for their wired network as they implement for their wireless network to protect their cardholder data at the POS. Other strategies for making PAN unreadable are one-way hashing and truncation which we will cover in the following sections.
Check to see if there is unprotected PAN data on your computer
One-Way Hashing
One-way hashing is the process of making PAN unreadable while in storage. The intention is for the hash data to be irreversible via taking a variable-length input and producing a fixed-length string of cipher text.
This is an appropriate measure to take when there is no need to retrieve the original PAN. The difference in how the Council classifies the data within the merchant’s PCI DSS scope is related to where the data is hashed and stored.
If the result of the one-way hashing is then transferred and stored within a separate environment from where it was originally produced, the transferred hashed data would no longer be considered cardholder data, thus making the system(s) storing the hashed data out of scope.
On the other hand, if the hashed out and stored data remains in the same system, then the stored cardholder data is within PCI DSS scope.
Performing these complex tasks calls for an algorithm that uses strong cryptography that ensures that the hash cannot be recovered or easily determined during a potential attack. If the merchant intends to recover and use the PAN for a legitimate business need, then one-way hashing would not be a strong enough encryption method.
Instead, the Council recommends removing the PAN altogether from the CDE rather than run the risk of the possibility of a compromise potentially cracking the hash and revealing the original PAN.
The upside of merchants only storing hash values of PAN data within their system is that they are not exposing the real PAN data (even to analysts). This increases the security effectiveness of the methodology, but doesn’t make it entirely risk-free.
Truncation
Truncation permanently removes some of the PAN data so that only a portion (not to exceed the first six and last four digits) of the PAN is stored. This is a popular method that Card-Not-Present (CNP) transactions employ to combat credit card fraud for purchases made over the internet on a global scale.
Truncation of PAN offers cardholders and merchants with greater security and protection from losses resulting from the theft and misuse of card data. Truncation ensures that the complete card number not be available in the future which may have a slight impact on internal operational control and consumer purchasing habits, but overall makes for a more secure checkout process.
Read more about the acceptable PAN truncation formats for the major credit card companies in the table below:
| Acceptable PAN Truncation Formats | |||||
| PAN Length | American Express | Discover | MasterCard | JCB | Visa |
| > 16-digit PAN with 6 digit BIN | N/A | N/A | At least 6 digits removed for 17, 18, and 19-digit PAN. | N/A | At least 6 digits removed for 17, 18, and 19-digit PAN. |
| 16-digit PAN with 8 digit BIN | N/A | At least 6 digits removed. | N/A | N/A | At least 6 digits removed. |
Closing Thoughts
With 67% of merchants admitting to actively storing unencrypted PANs and over 88 million unencrypted cards being found stored on business networks in 2016 alone, we can see that there is a major problem in how merchants handle PAN and store cardholder data.
Ensuring that customer PAN is encrypted using one-way hashing or truncation methodologies will ensure that cardholder data remains in PCI DSS scope and free from the risk of a future breach.
Understanding the importance of PAN and how to circumvent breaches by taking a defensive stance towards handling such sensitive data is the first of many key steps for merchants to take in their quest to become and maintain their PCI DSS compliance with requirement 3. Contact the experts at RSI Security for more information about PAN data, compliance advisory services, and cybersecurity solutions.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.