Payment Card Industry Data Security Standard (PCI DSS)
Table of Contents
Description
PCI DSS is a set of security practices administered and managed by PCI SSC (Payment Card Industry Security Standards Council) an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover, and JCB). The standard intends to protect cardholders against fraudulent use of their personal information by optimizing card transaction security.
PCI standards present technical and operational requirements for protecting cardholder data.
These standards are tailored for three communities:
1. Merchants and Processors
2. Software Developers
3. Manufacturers
They address the ecosystem of retail payment devices, applications, card processing infrastructure, and the organizations that execute related operations.
This standard applies to all entities involved in payment card processing, as well as all other entities that store, process or transmit cardholder data and/or sensitive authentication data (SAD). It’s a multifaceted standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures.
However, the standard’s requirements do not apply universally, as they are determined by the number of transactions that merchants process annually :
Level 1: Merchants that process over 6 million card transactions annually.
Level 2: Merchants that process 1 to 6 million transactions annually.
Level 3: Merchants that process 20,000 to 1 million transactions annually.
Level 4: Merchants that process fewer than 20,000 transactions annually.
Each of these levels is associated with specific controls and requirements in order to ensure compliance.
Payment transaction flow
The payment transaction flow consists of 3 steps that occur every time a card payment is made, anywhere in the world:
1. Authorization, time of purchase
1.1 The merchant requests and receives authorization from the issuer to proceed with the transaction and receives an authorization code.
1.2 Merchant’s bank asks the issuing organization (VISA, Mastercard…) to determine the cardholder’s bank.
1.3 Their authorization system validates card security features and approves sending to the cardholder’s bank for purchase approval.
1.4 Approval from both the cardholder’s bank and the merchant’s.
Figure 1: Authorization process – Source: Sonicwall
2. Clearing, usually within one day
2.1 Merchant banks send purchase information to the issuing organization’s (VISA, Mastercard…) network
2.2 Their clearing system validates the information and approves sending purchase information to the cardholder’s bank, which then prepares data for the cardholder’s statement.
Figure 2: Clearing process – Source: Sonicwall
3. Settlement: usually within two days
3.1 Issuer determines acquirer via the payment brand network
3.2 Issuer Sends payment to the acquirer
3.3 Acquirer pays the merchant for the cardholder’s purchase
3.4 Issuer bills cardholder
Figure 3: Settlement process – Source: Sonicwall
What is Tokenization?
The payment transaction flow uses a technique called tokenization in order to avoid sending the cardholder information across the different networks.
Figure 4: Tokenization process – Source: PCI SSC
1. A requesting application sends a Primary Account Number (PAN) to a tokenization system along with the necessary authentication information.
2. The authentication information presented by the requesting application is validated by the tokenization system. If this check fails, the tokenization process fails, and data is logged for future reference. Otherwise, the procedure proceeds to Step
3. Following PCI DSS requirements for PAN storage, the tokenization system generates (or retrieves if one already exists) a token associated with the PAN and records both to the card data vault.
4. The tokenization system returns to the requesting application the token generated or retrieved in Step 3.
PCI DSS Standard Timeline
Since 2010, changes to the PCI standards follow a defined 36-month lifecycle with 8 stages. The new 4.0 version is more of an evolution rather than a revolution. It still carries the 12 main pillars of PCI DSS v3.2.1 but with a revised form.
PCI DSS v3.2.1 will remain active for two years after v4.0 is published. This transition period from 03/2022 until 03/2024 provides organizations with time to become familiar with the changes in v4.0, update their reporting templates and forms, and plan for and implement changes to meet the updated requirements.
As of 31 March 2024, v3.2.1 will be retired and v4.0 will become the only active version of the standard. In addition to the transition period when both versions will be active, organizations have until 31 March 2025 to phase in new requirements that are initially identified as best practices in v4.0.
Prior to his date, organizations are not required to validate these new requirements, but they are highly encouraged to do so.
Compliance process : Defined approach vs Customized approach
The defined approach follows the traditional method for implementing and validating PCI DSS and uses the Requirements and Testing Procedures defined within the standard. The entity implements security controls to meet the stated requirements, and the assessor follows the defined testing procedures to verify that requirements have been met.
The defined approach supports entities with controls that meet PCI DSS requirements as stated. This approach may also suit entities that want more direction about how to meet security objectives, as well as entities new to information security or PCI DSS.
As part of the defined approach, entities that cannot meet the requirements explicitly as stated due to legitimate documented technical or business constraints may implement other compensating controls that sufficiently mitigate the risk associated with the requirement. Any compensating controls must be documented by the entity and reviewed and validated by the assessor and included with the Report and Compliance submission.
The customized approach focuses on the Objective of each PCI DSS requirement (if applicable), allowing entities to implement controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. Because each customized implementation will be different, there are no defined testing procedures; the assessor is required to derive testing procedures that are appropriate to the specific implementation to validate that the implemented controls meet the stated Objective.
The customized approach supports innovation in security practices, allowing entities greater flexibility to show how their current security controls meet PCI DSS objectives. This approach is intended for risk-mature entities that demonstrate a robust risk-management approach to security, including, but not limited to, a dedicated risk management department or an organization-wide risk management approach. The controls implemented and validated using the customized approach are expected to meet or exceed the security provided by the requirement in the defined approach.
PCI DSS Standard structure : 6 Control Objectives, 12 requirements
Control Objective 1: Build and maintain a secure network and systems
1. Install and maintain network security controls
2. Apply secure configurations to all system components
Control Objective 2: Protect account data
3. Protect stored account data
4. Protect cardholder data with strong cryptography during transmission over open public networks
Control Objective 3: Maintain a vulnerability management program
5. Protect all systems and networks from malicious software
6. Develop and maintain secure systems and software
Control Objective 4: Implement strong access control measures
7. Restrict access to system components and cardholder data by business need-to-know
8. Identify users and authenticate access to system components
9. Restrict physical access to cardholder data
Control Objective 5: Regularly monitor and test networks
10. Log and monitor all access to system components and cardholder data
11. Test security of systems and networks regularly
Control Objective 6: Maintain an Information Security policy
12. Support information security with organizational policies and programs
Each and every requirement is followed by best practices methods in order to achieve compliance.
Risks associated with the payment flow
In the world of the Payment Card Industry, companies that don’t execute more than 20,000 credit card transactions annually are classified as level 4 merchants. This specific level contains the fewest standards for compliance, requiring the least amount of work to comply. This group of retailers is also the most susceptible to criminal activity and online threats.
Approximately 71% of hackers target small firms and merchants with fewer than 100 employees, according to the PCI Security Standards Council.
Potential threats :
Point-of-Sale (POS) Intrusions
Web app attacks
Insider misuse
Physical theft and loss
Crimeware
Denial Of Service attacks
Payment Card skimmers
Contributing factors :
Weak remote access security: 28%
Weak passwords: 28%
Weak or nonexistent input validation: 15%
Unpatched vulnerability: 15%
Misconfiguration: 8%
Malicious Insider: 6%
PCI DSS and Cloud Computing Guidelines
There is a common misconception that PCI DSS compliance isn’t compatible with cloud computing. On the contrary, selecting the right cloud services can often facilitate and accelerate the compliance process if done correctly.
Guidelines and Considerations
- AOC (Attestation of Compliance) must be provided by your Cloud Service Provider. This is an important document to keep on file, as PCI DSS requires that businesses annually verify their CSP’s conformity and that it acknowledges its responsiblities.
- Acknowledge that the cloud is a shared environment where unauthorized access is forbidden. All CHD (Cardholder data) should be securely encrypted when stored on a cloud server, as you are trusting a third party with the protection and restriction of your sensitive data.
- Understand your shared responsibilities. When using a CSP, you must consider how their actions may affect your roles and responsibilities.
- Several variables influence the responsibilities between the customer and the CSP for managing PCI DSS controls, these include:
- The reason why the customer is using the cloud service
- The scope of PCI DSS requirements that the customer outsources to the provider
- The service option chosen by the customer (IaaS, PaaS or Saas)
- The scope of any additional services offered by the provider (i.e managed security services)
- Customer: responsible for maintaining and verifying requirements
- Provider: Verifying requirements for its customer
- Shared responsibilities, for example, both parties can be involved in the management of a specific control. Refer to Figure 5 below for more information.
Figure 5: Shared responsibilities model example – Source : PCI SSC
In a nutshell
Assessing and validating PCI compliance is usually an annual process, but PCI compliance is not a one-time action: it is an ongoing and consistent effort to assess and adapt.
As a business grows, its business logic and core processes change, which certainly means changing compliance requirements. For example, an online business may decide to open physical stores or launch a help desk. If these changes require the processing of payment card data, it is a good idea to proactively check whether these have an impact on your PCI validation method, in order to re-confirm your PCI compliance if necessary.
A business, corporation, or any entity that processes card transactions should always keep an eye on this constantly evolving standard and follow a well-defined process that consists of :
Reviewing the policies and enforcing them
Constant review of the standard based on evolution
Constant testing of security controls
If you are running your operation in the cloud, PCI DSS compliance can be achieved by adapting the approach to the cloud environment and following the correct guidelines. Some cloud providers will also make it easier by making the underlying infrastructure comply with certain points of the standard and saving you time and implementation of controls.
For further guidance you can refer to our Cybersecurity services or you might want to get in touch with us.
