RSI Security

How to Keep Data Secure for Cardholders (PCI DSS Req. 3)

The Payment Card Industry (PCI) is a coalition of credit card companies including American Express, Discover, MasterCard and Visa. Non-compliance with the 12 requirements specified in the PCI Data Security Standards (DSS) puts your company at greater risk of a future data breach that comes with a steep financial cost as evidenced by the plethora of well publicized data breaches last year alone. Of the 12 PCI DSS requirements, it was found that 79% of failed PCI Compliance assessments were in non-compliance because of not being able to protect cardholder data via requirement 3. Thats huge.

Limiting the potential for a data breach is one thing, but protecting stored cardholder data and sensitive authentication data (SAD) as a security standard in the case of malicious network activity is an entirely different beast. Through compliance with PCI DSS Requirement 3 and several subcategories in requirements, your customers sensitive card data can be authenticated and authorized with ease.

 

Protecting Stored Cardholder Data (CDE) Network

Merchants who do not store any cardholder data as a security policy automatically provide stronger protection by having eliminated a key target for data thieves. Merchants who have a legitimate business reason to store cardholder data, must comply with all 7 subcategories of PCI DSS requirement 3 (that carry over into several other PCI DSS requirements) to protect their cardholder data:

Section Requirements
3.0 Install and maintain a firewall configuration to protect cardholder data.
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage.
3.2 Do not store sensitive authentication data (SAD) after authorization. If SAD is received, render all data unrecoverable upon completion of the authorization process.
3.3 Mask Primary Account Numbers (PANs) when displayed such that only personnel with a legitimate business need can see the full PAN.
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs).
3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.
3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

PCI DSS Requirement 3.1

PCI security standards requirement 3.1 specifies that organizations must define time limits for cardholder data retention with proper justification. They must define and implement manual or automated processes that run at least quarterly to identify and delete cardholder data that has passed its intended retention time. A formal data retention policy identifies what data needs to be retained, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. Understanding where cardholder data is located is necessary so it can be properly retained or disposed of when no longer needed.

 

 

PCI DSS Requirement 3.2

Sensitive authentication data (SAD) pre-authorization data includes track data from the magnetic stripe, card verification codes or values, and the PIN or PIN-block. The only entity that can keep SAD is the issuer for its own issued cards, and those must be given the highest amount of protection possible. If you store, process, or transmit cardholder data, interact with payment card data in any way, it can impact someone elses cardholder information or the security of that information, you are subject to comply with the PCI DSS.

 

PCI DSS Requirement 3.3

Requirement 3.3 specifies PAN display should be limited to the minimum number of digits necessary to perform job functions and should not exceed the first six and last four digits. If full PAN is displayed on a physical location, the data could be stolen from service providers by an unauthorized or malicious individual who might use this information to make fraudulent transactions. Masking PANs should always ensure that only the minimum number of digits (no more than the first 6 and last 4 digits of the PAN) is displayed as necessary to perform a specific business function within the scope of reason. It is paramount that your organization truncate, redact, or mask PAN data for individuals who are not authorized to see it.

PCI DSS Requirement 3.4

Whereas requirement 3.3 relates to protection of PAN displayed on screens, paper receipts, printouts, etc., requirement 3.4 is specific to protection of PAN when stored in files, databases, etc. A recent study found that 67% of merchants were actively storing unencrypted PANs with over 88 million unencrypted cards being found stored on business networks in 2016 alone. Requirement 3.4 ensures that organizations do not store, process or transmit the cardholder name, service code or expiration date that are present in the PAN. This requirement calls for organizations to ensure that all stored PANs are rendered unreadable at a minimum. One-way hash, truncation or index tokens can be stored in place of the PAN if necessary.

 

PCI DSS Requirement 3.5

Requirement 3.5 entails documenting cryptographic architecture for use in better understanding and protection of algorithms, protocols, and cryptographic keys used to protect cardholder data. Detecting lost or missing keys or key-management devices on the fly allows you to identify unauthorized additions to your cryptographic architecture. To deter complication, it is best to store cryptographic keys in the fewest locations. This helps your organization keep track of and monitor all key locations thereby minimizing the potential for keys to be exposed to unauthorized parties.

PCI DSS Requirement 3.6

The management of cryptographic keys is a critical part of the continued security of the encryption solution. The secure storing, updating and transmitting of cryptographic keys used to encrypt stored cardholder data to customers can help prevent keys from being mismanaged or disclosed to unauthorized entities. Keys that are no longer used or needed must be revoked and/or destroyed to ensure that they can no longer be used by a compromised source.

 

PCI DSS Requirement 3.7

Requirement 3.7 requires that you have and maintain policies, procedures, and standards. Compliance with this subcategory entails implementing an initiative that ensures that the appropriate staff are knowledgeable of the organizational data security policies. Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis. Assessing this entails interviewing staff on the policies and procedures to ensure that they understand them and are actively practicing them daily.

PCI DSS Requirement 6.6

Requirement 6.6 calls for publicly-facing web applications to address new threats and vulnerabilities on an ongoing basis via manual or automatic application vulnerability security assessment tools or methods on at least an annual basis. Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. A compromise of web applications can allow an attacker to steal information from any connected databases and/or infect other users of the site with web-based malware.

To reduce the number of compromises on public-facing web applications, organizations can installing web application firewalls (WAFs). A WAF can protect web applications visible or accessible from the Internet, including outward facing or intranet applications involving payment card acceptance. An organizations WAF must be up to date, generate audit logs, and block cyber-attacks or generate a cyber security alert if an imminent attack is suspected.

 

PCI DSS Requirement 10.6.1

Many breaches occur over days or months before being detected. Its not sufficient just to collect the data; you must also make sure youre sending that information to your logging tool in the appropriate way. Checking logs daily minimizes the amount of time and exposure of a potential breach. Reviewing security events, critical systems component and server logs at least daily is central to compliance with this PCI DSS requirement. Attacks revealed by your critical system component logs will show you what areas you need to strengthen your security in. Daily review of security events (i.e. notifications or alerts that identify suspicious or anomalous activities) as well as logs from systems that perform security functions (firewalls, IDS/IPS, FIM systems, etc.) is essential in identifying potential issues before they spread.

PCI DSS Requirement 11.2

Requirement 11.2 requires that an organization run internal and external network vulnerability scans at least quarterly and following any significant network change such as new system component installations. A vulnerability scan is a combination of automated or manual tools, techniques, and/or methods run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals. Identifying and addressing vulnerabilities in a timely manner reduces the likelihood of a vulnerability being exploited and potential compromise of a system component or cardholder data.

Now, multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. For the initial PCI DSS compliance, it is not required for the completion of 4 quarters of passing scans be if the assessor verifies that the most recent scan result was a passing scan or that your organization has documented policies and procedures requiring quarterly scanning. However, follow-up annual PCI DSS reviews must document 4 quarters of passing scans.

 

PCI DSS Requirement 11.3

This requirement entails that your organization implements a penetration testing methodology that includes industry-accepted testing and coverage from both inside and outside the network to validate any segmentation and scope-reduction controls. Penetration testing techniques will differ based on the organization. The type, depth, and complexity of penetration testing will depend on the specific environment and the organizations risk assessment. The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate an environment. This allows an organization to better understand the potential network attack exposure and develop a strategy to defend against said attacks.

 

PCI DSS Requirement 11.4

This requirement specifies the use of intrusion detection/prevention techniques that are used to monitor traffic at the perimeter of the cardholder data environment (CDE) and alert personnel to suspected compromises. Intrusion detection/prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known signatures (behaviors) of thousands of types of compromise and send alerts to information security teams to stop the attack attempt from continuing. Without integrating proactive approaches to unauthorized activity detection by complying with requirement 11.4, attacks on your CDE could go unnoticed altogether.

 

PCI DSS Requirement 12.10.5

Compliance with PCI DSS requirement 12 entails annually testing for a system breach via the development of a response plan that outlines tasks for each role, specific actions for different threats/alerts. This plan must cover critical systems and data backup, legal requirements for reporting, including notifying major card brands of said data breach. Organizations must ensure they set up monitoring systems with the focus on identifying and taking quick action to prevent a potential breach of cardholder data. Companies must include alerts from security monitoring systems that include intrusion-detection/prevention, firewalls, and file-integrity monitoring systems. The combination of observation and review of these processes will allow incident responders to detect unauthorized wireless access points and respond to alerts more effectively.

 

Closing Thoughts

Complying with PCI DSS Requirement 3 allows you to develop a data retention and storage policy that strictly limits storage amount and retention time. The cost of non-compliance to businesses now runs an average of $14.8 million annually (a 45% increase since 2011) while the cost of compliance averages roughly $5.5 million (a 43% increase since 2011). If your organization is currently in non-compliance with PCI DSS, it is crucial that you uncover and resolve any points of non-compliance to ensure the long-term health of your organization stays strong.

 

 


 

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.

Exit mobile version