Encrypting your cardholder data environment (CDE) is of paramount importance if youre keen on not just protecting your customers card data, but also salvaging your organizations data security. If your company handles any amount of credit card information, it must comply with the PCI DSS (Payment Card Industry Data Security Standards).
Your Cardholder Data Environment (CDE) encryption efforts must fall within the scope of relevant PCI DSS requirements which ensure that company and clientele are protected from a potential data breach. The requirements that are pertinent to encrypting the transfer of card data can be found in PCI DSS requirements 2.2, 2.3, 5.1, 5.2, 5.3, 5.4, 6.7, 8, and 11.5. This article sums up these specific end-to-end encryption requirements and gives your organization a solid overview on encrypting transfer of card data to maintain your high level of data security with or without a cybersecurity provider.
CDE Encryption
Defining your organizations CDE is a necessary step towards minimizing PCI DSS scope through the addition of technological complexities. The PCI Security Standards Council (SSC) states that encrypted data may be deemed out of scope if, and only if, it has been validated by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) that the entity that possesses the encrypted data of a cardholder does not have the means to decrypt it. Entities that must comply with these PCI SSC data encryption standards are those that have a contractual relationship with credit card companies, financial institutions. The agents of these entities are required to provide appropriate compliance validation documentation at the point of contact (POC).
For example, if a merchant encrypts cardholder data but does not possess the means to decrypt it, the cardholder data is, therefore, considered out of scope. Only once it has been encrypted is the cardholder data considered to be in scope. Thus, periodic monitoring of the CDE is paramount to keep unauthorized or rogue wireless devices from compromising the security of the CDE and stealing un-encrypted cardholder data.
If the credit card accepting entities do not have the necessary internal staff to handle the data encryption efforts, they can outsource their encryption key management operations to a third party. Outsourcing CDE encryption to a third party doesnt alleviate the entity from responsibility though. To maintain a high level of security, the entity must have a due diligence processes that ensures all applicable PCI requirements are being met by the third party in their encryption efforts.
When the entity is handling encrypted Primary Account Numbers (PANs) with access to the key, the PCI SSC still defines this data as cardholder data thus meaning that it is in scope and in need of the entity to decrypt the data to remain compliant. When an entity encrypts their cardholder data, they must define the appropriate security policies and operational procedures to ensure optimal CDE security. No matter if the cardholder data is printed, processed, transmitted or stored, entities must extend the same level of security from the wired network to the wireless network and provides specific guidelines as to how to protect point-of-sale data over the wireless network.
Get the low down on how your organization should be handling your cardholder data or sensitive authentication data (SAD) in your CDE:
| 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 | ||
To help your organization secure your CDE and stay in scope with PCI DSS, you should ensure that you are adhering to PCI DSS requirements 2.2, 2.3, 5.1, 5.2, 5.3, 5.4, 6.7, 8, and 11.5. Those requirements are outlined below in varying levels of complexity:
PCI DSS 2.2
Requirement 2.2 is used to develop configuration standards for system components that address all known security vulnerabilities in an entitys CDE. These standards must be consistent with industry-accepted definitions and updated as new vulnerability issues are identified. These standards should be written in documents intended for new and existing individuals who are new to the entitys CDE and needing to the brought up to speed quickly to understand the general technology that they will be working with. These standards allow the systems to be fully hardened and ready for production in an efficient and controlled manner.
It should be noted that system hardening should occur any time you introduce a new system, application, appliance, or any other device into an environment. The goal of hardening a system is to remove any unnecessary functionality and to configure what is left in a secure manner. This hardening process establishes a baseline of system functionality and security to deter the introduction of vulnerabilities on new applications, services, drivers, features, and settings installed or enabled on a system.
PCI DSS 2.3
Requirement 2.3 specifies that entities must encrypt all non-console administrative access such as browser/web- based management tools using strong cryptography methods. Strong cryptography is defined by PCI DSS as industry-recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. Compliance with this requirement doesnt mean that your organization must encrypt all CDE access though. Instead, you would only need to encrypt administrative access.
Non-console administrative access via this requirement also includes those who have remote access to the CDE. If an individual with administrative access to the CDE does not use secure authentication and encrypted communications, sensitive administrative information may be revealed to an eavesdropper or malicious individual. If given the window of opportunity to do so, these malicious individuals will use this sensitive data and information to access the CDE, become administrator, and steal cardholder data.
PCI DSS 5.1
Compliance with Requirement 5.1 entails the development of anti-virus software within the firewall and router configurations to protect cardholder data in the CDE. Once the deployment of anti-virus software is verified, they need to be tested for detection, removal and protection against even the latest of the malwares. Following the anti-virus software deployment, the software must be verified and tested for its ability to defend the CDE against the latest strains of malware.
If a system that holds SAD is found to be susceptible to malware a solution needs to be configured and implemented immediately to prevent an attack and stay compliant with this requirement. These prevention systems should be installed before devices that hold cardholder information to ensure that maximum data protection is provided. Entities must re-evaluate their CDE at least annually to ensure the anti-virus software is adept at recognizing malware that may lead to a CDE data breach if not caught soon enough.
PCI DSS 5.2
Requirement 5.2 is specifically geared towards the auditing of the anti-virus mechanisms mentioned in Requirement 5.1. Compliance with this requirement hedges on the organizations ability to stay current with their anti-virus solution, ensuring that it can actively run and generate audit logs in a sustainable fashion. These Audit logs are a helpful tool for network security teams as they can aid in monitoring the virus and malware activities as well as the response of the anti-virus. This gives the organization a better understanding of whether the anti-virus solution needs to be updated or not to stay in compliance with this requirement.
PCI DSS 5.3
Requirement 5.3 piggybacks on requirements 5.1 and 5.2. To be compliant with this requirement, entities must verify that none of the anti-virus programs running in the background can be disabled or altered by common users. Only authorized personnel with administrative access are permitted to make changes in special case scenarios to the CDE anti-virus software. If for some reason, the anti-virus software needs to be disabled for a very short period of time and for a very specific reason, the approval must come only from management and management must assume the responsibility and understand the risk of vulnerability associated with disabling the anti-virus software might have on the CDE.
PCI DSS 5.4
Requirement 5.4 is specific to every individual in your organization. Compliance is earned through building organizational awareness of security policies and operational procedures that work to ensure maximum CDE protection from malware. Organizational policies and procedures regarding malware data protection must be communicated to employees who, in turn, will implement them in their day-to-day. These procedures should not be generated for the sake of the PCI DSS audit though. To maintain full compliance, your ISA should be familiar with all policies and procedures referenced in these documents while also interviewing staff to ensure that they understand what the policies and procedures are.
PCI DSS 6.7
Compliance with Requirement 6.7 entails outlining security policies and operational procedures for developing and maintaining secure systems and applications within the organizations CDE. This requirement is pertinent for internal personnel as well as third party entities that are subject to the development policies and procedures. Entities are required to have all pertinent documentation readily available to personnel involved in the application development process. All required documentation must stay updated to ensure that personnel maintain full awareness of these requirements always. It is advised that entities conduct annual reviews of this documentation with any changes being communicated and accessible to all the involved personnel at all times. Complying with this requirement is the best way to protect the sensitive data and information within your organizations applications from being susceptible to threats and vulnerabilities.
PCI DSS 8
All sub-sections of PCI DSS Requirement 8 can be utilized for protecting CDE system components:
| Requirement |
Requirement Notes |
| 8.1 |
Assign all users a unique user name before allowing them to access system components or cardholder data. |
| 8.2 |
Employ at least one of these to authenticate all users: password or passphrase; or two-factor authentication (e.g., token devices, smart cards, biometrics, public keys). |
| 8.3 |
Implement two-factor authentication for remote access to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial- in service or terminal access controller access control system with tokens; or virtual private network with individual certificates. |
| 8.4 |
Render all passwords unreadable for all system components both in storage and during transmission using strong cryptography based on approved standards. |
| 8.5 |
Ensure proper user authentication and password management for non-consumer users and administrators on all system components. |
The underlying commentary behind Requirement 8 is that of protecting the CDE via assigning unique identification (ID) to everyone with computer access. Doing so ensures that actions performed on cardholder data can be logged and traced to known users. User ID passwords are recommended to be at least 7 characters in length and feature upper and lower-case letters. Your organization can take this recommendation one step further by requiring longer passwords and adding numbers and special characters into the mix. Passwords that dont check all the boxes of these criteria can put the entire network at risk for a data breach.
It is advisable that entities use strong cryptography methods to render authentication credentials unreadable during transmission and storage on system components. Strong cryptography such as a password, biometric data or PIN must be applied so that every user is uniquely identified and unauthorized users cannot gain access through a shared authentication mechanism.
Accounts must be locked out after six consecutive failed login attempts per PCI SSC. These accounts must stay locked for at least thirty minutes or until a system administrator resets the account. When cardholder data is being accessed, additional authentication must be applied. Proper documentation that describes the authentication process and each system component must be presented to management for authentication purposes. This helps the accounts in the CDE from being used by hackers who have acquired a user ID, but not the corresponding password.
PCI DSS 11.5
Requirement 11.5 specifies that the organization must deploy file integrity monitoring software to alert personnel when unauthorized modification of critical system files has been denoted. Entities must configure the necessary software to perform critical comparisons of files on at least a weekly basis. If a file change comparison shows a spike in the number of file change occurrences compared to previous rates, this could be an indication of malicious activity. These events should be investigated immediately to ensure any problems to the CDE can be remediated quickly.
Closing Thoughts
One of the biggest challenges entities face is reducing the size of their CDE and isolating it from the larger corporate network. Entities can minimize the opportunities for fraud and limit spend on their security and annual PCI DSS assessments by allowing fewer computing resources to have access to real cardholder data. Effectively adhering to PCI DSS requirements 2.2, 2.3, 5.1, 5.2, 5.3, 5.4, 6.7, 8, and 11.5 will significantly minimize data breach threats, thereby streamlining your organizations annual PCI DSS assessment process.
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.
