Unlocking the Future of Payment Security: Implementing PCI DSS Version 4.0 in Trendyol

Are you looking to protect your customers credit card information and maintain a secure environment for your business? Then you need to know about PCI-DSS, the Payment Card Industry Data Security Standard. This set of security standards ensures that all companies that handle credit card information are held to a high level of security. The latest version, PCI-DSS v4.0, includes exciting updates and innovations that can help you protect your business against cyber threats. At Trendyol, we’re committed to maintaining PCI DSS compliance and meeting the March 31, 2024 deadline to transition to version 4.0. Don’t wait until it’s too late — start planning and taking action now for a smooth and successful transition to PCI DSS v4.0.

Countdown to Compliance: A Timeline for Implementing PCI DSS Version 4.0

A Timeline for Implementing PCI DSS Version 4.0 is a roadmap that outlines the necessary steps for organizations to transition to the latest version of the Payment Card Industry Data Security Standard. This timeline provides a clear and concise overview of the key milestones and deadlines that organizations must meet to achieve compliance with the new standard. It also includes practical guidance and best practices to help organizations navigate the complex requirements of PCI DSS 4.0 and ensure that their systems and processes are secure. By following this timeline, organizations can plan and execute a successful transition to PCI DSS 4.0 and protect their customers’ sensitive payment card information.

Source: PCI council website

Here is a summary of the important implementation timeline dates for PCI DSS v4.0:

• PCI DSS v4.0 was released on March 31, 2022.
• The transition period is from March 31, 2022 to March 31, 2024. Transition period is the period during which an organization’s Cardholder Data Environment (CDE) can be evaluated using PCI DSS v3.2.1 or v4.0.
• PCI DSS v3.2.1 is being retired on March 31, 2024. After this date v4.0 is mandatory.
• New future requirements are mandatory after March 31, 2025.

Discovering the Innovations: An Overview of the New Developments in PCI DSS Version 4.0

The main difference between version 4.0 and 3.2.1 of the PCI-DSS standard is that version 4.0 is more focused on security as a continuous process and emphasizes the need for organizations to implement a risk-based approach to security.

The framework of PCI DSS v4.0 maintains the core structure of the 12 PCI DSS requirement sections, but it brings forth significant improvements. Redesigned requirements provide clearer security intent and more detailed guidance on implementing security controls. The latest version stays in step with evolving technology and systems and addresses the latest challenges from scoping to cloud computing. Overall, PCI DSS v4.0 is a comprehensive and updated set of standards that are designed to help businesses enhance their cybersecurity posture, reduce risk, and protect sensitive data.

There are four major reasons for the changes:

• Continue to meet the security needs of the payments industry.
• Promote security as a continuous process.
• Increase flexibility for organizations using different methods to achieve security objectives.
• Enhance validation methods and procedures.

PCI-DSS v4.0 within its numerous changes lie the significant updates concerning Customized Approach and Risk Assessment. Let’s explore them further;

👉🏻Customized Approach is a new validation method introduced in the PCI DSS 4.0 version. It allows organizations to customize their approach to meeting certain requirements, as long as they can demonstrate that their solutions effectively meet the intended objective of the requirement. This provides more flexibility and encourages innovation in security solutions while still ensuring that security standards are met.

Compensating Controls, on the other hand, is a concept that has been present in previous versions of the PCI DSS standard. It allows organizations to use alternative security measures to compensate for areas where they may not be fully compliant with a particular requirement. Compensating Controls are typically used when it’s not feasible or practical to fully comply with a requirement, but they still need to implement controls to ensure security.

The main difference between Customized Approach and Compensating Controls is that Customized Approach allows organizations to customize their security approach within the framework of the PCI DSS standard, while Compensating Controls are used as a way to compensate for not fully meeting a requirement. Customized Approach provides more flexibility and encourages innovation, while Compensating Controls are a fallback option when full compliance is not possible.

👉🏻Risk Assessment is a crucial component of PCI DSS 4.0 version, and it plays an essential role in ensuring the security of payment card data. A risk assessment involves identifying, evaluating, and managing potential security risks and vulnerabilities to the payment card data that a business processes, stores, or transmits.

In PCI DSS 4.0, the importance of risk assessment has been further emphasized, and the requirements have been expanded to require more frequent and detailed risk assessments. The updated version focuses on a continuous approach to risk management, which means organizations must conduct risk assessments regularly and ensure that risks are assessed and mitigated continuously, rather than only once a year.

Furthermore, the updated version requires organizations to document their risk assessment methodology and report on any changes made to their risk management program. The updated version also emphasizes the importance of third-party risk assessments, ensuring that businesses conduct thorough assessments of their vendors and service providers that handle payment card data.

The differences between risk assessment in PCI DSS version 3.2.1 and version 4.0 are significant. While the previous version required an annual risk assessment with little detail provided, the updated version requires a more detailed and continuous approach to risk assessment. Organizations must now conduct more frequent risk assessments, identify potential risks and vulnerabilities, evaluate their likelihood and impact, and develop appropriate risk mitigation strategies to minimize the risk of a data breach. By implementing a continuous approach to risk management, businesses can ensure that they are always aware of the risks associated with their payment card data environment and take appropriate measures to mitigate them.

Get ready to dive deep into the exciting world of PCI-DSS v4.0 as we explore the 12 major requirements and their latest modifications;

📍Requirement 1

Requirement 1 in PCI DSS version 4.0 focuses on maintaining a secure network and systems.The first change you will notice in Requirement 1 is the term “network security controls”.It does away with the requirement for an exhaustive definition to keep up with technology and enables us to transition to a safer framework for our own environment. Previously, the PCI DSS wording focused specifically on defining firewalls, routers, etc.

📍Requirement 2

Requirement 2 That vendor-supplied defaults for system passwords and other security parameters should not be used.Before setting up a system on the network, we were required by PCI V3.2.1 to update ALL vendor-supplied default passwords and eliminate pointless default accounts. applies to all security setups for devices, not only those with vendor-provided default usernames and passwords for PCI V4.0. At the same time, the roles and duties of those who conduct Security Configurations must be established.

📍Requirement 3

Requirement 3 of PCI DSS version 4.0 focuses on protecting stored cardholder data. One of the significant changes in this requirement is the emphasis on the use of strong cryptography to protect sensitive data.

Requirement 3.2.1 — The new version of Requirement 3.2.1 replaces Requirement 3.2 in PCI DSS version 3.2.1. In the previous version, it was recommended to try to encrypt or protect sensitive authentication data (SAD) if it was stored before authorization, but it was not mandatory.

However, in PCI DSS version 4.0, if SAD is stored prior to authorization, it must follow data retention and disposal policies, procedures, and processes, which should be established and documented by the organization. This change aims to ensure that any stored sensitive data is protected and disposed of properly, reducing the risk of data breaches and unauthorized access.

Requirement 3.3.2 –The new requirement is that SAD, stored electronically before authorization is complete, expects it to be encrypted using strong cryptography.

Requirement 3.4.2-This is a big update for all of us and it can be complicated to apply to our environments.When using remote access technologies such as VPN, SSH, Remote Desktop, Cloud Virtual Workstations, etc., copying and/or relocation of the PAN must be prevented for all personnel except those with a defined job need, there must be a technical control.

Requirement 3.5.1.1- In PCI DSS version 4.0, Requirement 3.5.1.1 replaces Requirement 3.4.1 in PCI DSS version 3.2.1. If a hash is used to make the Primary Account Number (PAN) unreadable, it must be included in the key management processes and procedures, which must detail how the hash algorithm is used, in what processes, and what restrictions are applied. This means that the organization must have a key management process that governs the hashing process and monitors the key management requirements. Additionally, the hash function must be approved based on industry standards, and the hash value must be unique to each cardholder.

Requirement 3.5.1.2-This can only be used on removable electronic media if there is no disk-level encryption to render the PAN unreadable. This means that stand-alone disk- or partition-level encryption can only be used to secure removable media such as flash drives, external hard drives, etc. If it is used in non-removable electronic media, we need to make it unreadable, so just making an encryption on the disk surface will not be enough. It states that disk or partition level encryption should be used to make the PAN unreadable on non-removable environments. It must also include a secondary mechanism listed in Requirement 3.5.1. At this stage, the hash may contain interrupts or tokens.

📍Requirement 4

Requirement 4 is the part about transmitting, receiving or sending card data over the internet. PCI v4.0 now focuses on the use of “strong cryptography” to protect the transmission of cardholder data. There are 2 requirement changes in this section.

Requirement 4.2.1-To protect PAN during transmission over public networks, it requires certificates used to be valid and not expired or revoked. And further, the protocol used must support only secure versions or configurations, and not backup or use of unsecured versions, algorithms, key sizes, or applications, and the encryption strength must match the encryption methodology used.

Requirement 4.2.1.1- To ensure that your certificates are valid and not expired, it is now desirable to keep an inventory of SSL certificates and trust keys used to transmit card data over the internet.

📍Requirement 5

Requirement 5 defines and understands processes and mechanisms for protecting all systems and networks from malware.Vulnerability management is the process of systematically and continuously finding weaknesses in payment card infrastructure systems.

Requirement 5.2.3.1- For PCI v4.0, it must be analyzed that any system component is not at risk in terms of Malware. It was expected not to use antivirus for mainframe and linux-based servers before, it is something that is expected to be used here a little more. There should be risk analysis, if there are systems that do not take precautions, we need to decide and document whether or not to install antivirus as a result of risk analysis. For periodic malware, the institution needs to determine a frequency based on its own risk analysis.

Requirement 5.3.3- Removable media such as USB and flash disks need to be configured in order for the antivirus to automatically scan if they are inserted into the devices. Although USB ports are expected to be closed, USB can be used, when they are plugged into the device, there should be automatic scanning.

Requirement 5.4.1-The process for phishing attacks is waiting to be activated. In this sense, a combination of fake attacks, training, blocking of mails, and solutions is desired. We need to remove the combination of manual processes on the one hand and automated processes on the other.

📍Requirement 6

Application security was the main focus of the old PCI Standard. The focus of PCI v4.0 has grown to include keeping secure software and systems.

Requirement 6.3.2- It is waiting for the inventory, which includes the APIs and libraries of outsourced applications for Vulnerability and Patch Management, to be made. This requirement is both very high value added and requires serious effort to be made and a process setup needs to be created. This requirement requires early planning and work without waiting for 2025.

Requirement 6.4.2- In PCI DSS 3.2.1, a web application firewall was required to protect developed web applications, or a process to perform code reviews. WAFs were previously proposed but not specifically defined. In PCI v4.0, a product that can predict web application firewalls (WAFs), block and warn the relevant units should be positioned in front of all publicly available web applications.

Requirement 6.4.3- In the previous version, payment scripts could be discussed outside the scope of PCI DSS as they were not an “application” in their own right; However, with the new focus on software, this argument cannot be justified in version 4.0. An inventory of all scripts loaded and executed in the client browser is expected to be maintained on the payment pages. These scripts need to be verified and ensure that they are not modified in an unauthorized way. Software component analysis (SCA) products should now be used here.

📍Requirement 7

Requirement 7 is the clause that directs us to restrict access to cardholder data by business need-to-know. Systems and processes should be in place to limit access based on need to know and job responsibilities to ensure that critical data is only accessible to the authorized person.

Requirement 7.2.4 — Version 4.0 states that you must have an ongoing user account and access review process. Every six months (semi-annually), you must ensure that user accounts and access continue to be available for business functions. In other words, all user authorized accounts are requested to be reviewed at least once every 6 months. We expect you to request and keep an administrative consent record to prove that access is available to users.

Requirement 7.2.5 — This requirement now specifies that application and system account access must be least privileged; this means that access to service accounts is granted only with the least privileges necessary for system or application operation.

Requirement 7.2.5.1- The difference between requirement 7.2.5.1–7.2.4 and this requirement is that we can define the frequency with which this review is performed in a targeted risk analysis. All accesses and related access privileges by application and system accounts should be reviewed periodically (as defined in the risk analysis). Ensure that access is still available, that inappropriate access is being addressed, and that account administrators agree that access is appropriate.

📍Requirement 8

Processes and mechanisms for identifying Requirement 8 users and verifying access to system components are described.There are new important requirements within Requirement 8 in version 4.0.

Requirement 8.3.4- The number of unsuccessful authentication tries increases from 6 to 10, and it should be locked after the maximum of 10.

Requirement 8.3.10.1- New requirement for service providers only- Passwords should be changed at least every 90 days if passwords are the only authentication method used for customer user access. If account security analysis is performed, real-time access to resources should be determined automatically based on the results.

Requirement 8.3.6 — Password lengths are now required to be 12 characters minimum.It’s worth starting to check now to see if there are any systems in use on your CDE that might have difficulty with this future requirement.

Requirement 8.5.1 — Every system that offers MFA capabilities used in Requirement 8 must comply with this additional requirement. We must make sure the MFA systems are secure against intrusions and rigorously regulate any administrative overrides.Replay attacks shouldn’t be possible against the MFA mechanism. Any user, including administrative users, shouldn’t circumvent MFA systems unless it’s clearly stated in a document and given management approval for a very short period of time. Use of two or more distinct authentication factors is required.

Requirement 8.6.1 — Managing accounts with interactive access is now necessary. There are six things you ought to do. This criterion is meant to expressly restrict access and permissions for accounts that require interactive login when they are utilized by systems or apps.

• Interactive use should be prohibited unless necessary for an exceptional situation.
• Interactive use should be limited to the time required for exceptional circumstances.
• For interactive use, the business justification must be documented.
• Interactive use must be expressly approved by management.
• The individual user ID must be confirmed before access to the account is granted.
• Every action taken must be attributable to an individual user.

Requirement 8.6.2 — Passwords for the system and application accounts you use for interactive logons shouldn’t be stored in the source code. Especially for system accounts.

Requirement 8.6.3 — Passwords used for system and application accounts should be reviewed on a regular basis. In the risk analysis, it ought to be mentioned. It is important to note that all application and system account credentials are secure.

In general, shorter, simpler passwords should be updated more frequently. Long and complicated passwords can be updated more regularly.

📍Requirement 9

Requirement 9 focuses on physical security requirements. In version 4.0, DSS now defines three different areas covered; sensitive areas, CDE and facilities.

Requirement 9.5.1.2.1 — This new requirement requires periodic review of physical point of interaction (POI) devices. We are expected to define the frequency of these reviews through risk analysis.

📍Requirement 10

Requirement 10’s audit logs address system components and cardholder data. While specified as “audit trails” in PCI-DSS 3.2.1, it has now been replaced by “audit logs” for clarity. There are four new requirements in Requirement 10.

Requirement 10.4.1.1 — The first change in this section is expected to use automated methods for reviewing log records. A method like SIEM becomes mandatory.

Requirement 10.4.2.1 — Change controls of logs received in PCI-DSS 3.2.1 were required daily. With the update, periodic review periods for less risky systems within the scope were specified as changeable according to the risk analysis of the institution. For example, Firewall could be daily, WAF daily, antivirus weekly. With every “periodic” requirement, we must define this frequency in a targeted risk analysis.

Requirement 10.7.2 — Failures of critical control systems have to be detected and alert security personnel.his used to be only required for service providers, but has now been extended to everyone.

Requirement 10.7.3 — Failures of critical safety control systems are expected to be addressed promptly. Detailed guidance is included in the requirement statement. Here, instead of describing the process with stand-alone document. it can be included in the existing Incident Response plan.

📍Requirement 11

Requirement 11’s the definition and comprehension of methods and techniques for frequently testing the security of systems and networks.

Requirement 11.3.1.1 — Any vulnerabilities in your vulnerability scans that are not classified as high or critical risk now need to be addressed periodically. The frequency should be defined in a targeted risk analysis.

Regarding the closure of the findings, if it is revealed as medium or low in the vulnerability scan, it directs us to prefer closure/closure according to the risk analysis. In the risk analysis, we need to justify.

Requirement 11.3.1.2 — Authenticated vulnerability scanning is now a requirement. The subject of credential had not been described before. While unauthenticated (gray box) tests can still be valuable, we can get more accurate findings through authenticated scanning as the scanner is now able to perform actual checks on the devices. Suggestion: If possible, the user you will define should have high authority so that we can find more vulnerabilities. In cases where we are technically unable to scan with a credential, we will need to document this again.

Requirement 11.6.1 –Changes to web pages (header, javascript utilized or content, etc.) from which payment is received must be validated and alerted by the organization in order to counteract e-commerce skimming attacks. This can be done immediately or once a week. It might not always be automatic; it could also be manual.

📍Requirement 12

Requirement 12 in PCI DSS version 4.0 is focused on policies and programs that support information security. This requirement includes new criteria, making it the requirement with the most new criteria in the updated standard. PCI DSS version 4.0 emphasizes that compliance is not just a one-time inspection but a continuous process, and management is key to ensuring the ongoing effectiveness of information security policies and programs. The new criteria in Requirement 12 reinforce the need for continual processes to ensure the ongoing effectiveness of information security policies and programs. This requirement is intended to ensure that organizations have a comprehensive and proactive approach to managing and maintaining the security of cardholder data.

Requirement 12.3.1- It compels targeted risk analysis for any requirement, as we’ve seen with most of the new requirements.The risk analysis should be as follows;

• Identification of protected assets.
• Identifying the threat(s) that the requirement protects.
• Identifying factors that contribute to the probability and/or impact of an actual threat.
• Consequence analysis that specifies and justifies how often the requirement should be met to minimize the likelihood of the threat occurring.
• A 12-month review to determine if results are still valid or if an updated risk analysis is required.

Requirement 12.3.2 -We must carry out a targeted risk analysis for any requirements for which you selected a customized approach over the prescribed approach. This is a new feature in PCI DSS 4.0. A compensating control differs from a custom approach.

Requirement 12.3.3 — Maintaining an inventory of all covered cryptographic cipher suites and protocols is expected of us in PCI-DSS v4.0. The inventory should include cipher suites and protocols in use, including their purpose and where they are used. The new requirement requires monitoring to ensure that new known vulnerabilities in cipher suites and protocols can be quickly remedied.

Requirement 12.3.4 — PCI DSS inventory is now defined to include hardware and software technologies.Except for the patch and vulnerability management that was followed, there was no written rule in PCI regarding a product that has come to an end of life. Control should be applied at least once a year for the products that have reached the end of life.

Requirement 12.5.2- PCI DSS coverage is expected to be documented and approved by the organization at least every 12 months and when coverage changes.

Requirement 12.5.2.1- PCI DSS coverage is expected to be documented and approved by the organization for service providers only at least every six months and when there is a significant change in the in-scope environment.

Requirement 12.5.3 — Requirement 12.5.3 in PCI DSS version 4.0 requires a review of the impact on PCI DSS compliance and control applicability for significant changes in organizational structure. This review must be documented and communicated to senior management to ensure compliance efforts are not compromised. The purpose of this requirement is to identify any gaps in compliance and take necessary actions to address them in cases of mergers, acquisitions, or divestitures.

Requirement 12.6.2- The Security awareness programs must be reviewed at least every 12 months, and the training must be updated as necessary to address new threats and vulnerabilities in the payment area.

Requirement 12.6.3.1 In addition to 12.6.2, awareness programs ought to cover dangers and weaknesses that can imperil the CDE’s security. As they are the most frequent, this will also need to contain phishing and social engineering attempts.

Requirement 12.6.3.2 — To again expand on 12.6.2, the security training should also point out the responsibilities.

Requirement 12.10.4.1 — In version 3.2.1, training for incident response (IR) personnel was required annually. This new requirement allows us to define the optimal period for our organization. The period should be documented in a targeted risk analysis.

Requirement 12.10.5 — Incident response plan needs to be updated to include commands for alerts from security monitoring services and their response process. It should include change-and tamper-detection mechanisms for payment pages that will be included in our IR plan.

Requirement 12.10.7 — Card data disclosure is waiting for notifications and identifications regarding its copying. Incident response procedures should be in place to be initiated, especially upon the detection of a credit card stored in an unexpected location.

To obtain a thorough and detailed understanding of the modifications made to PCI DSS between version 3.2.1 and version 4.0, we recommend consulting the Summary of Changes document, which can be found in the PCI DSC Document Library.

Document Library

An Overview of the PCI DSS Version 4.0 Compliance Process for Trendyol

Although the process for the transition to PCI-DSS v4.0 seems very long, the changes are quite extensive. In addition to extensive changes, as Trendyol, we have a very broad structure that is constantly developing. We began our work to adapt to these changes and to make the transition go smoothly. Teams will need to re-evaluate their evaluation processes as they adapt to changes towards a more continuous approach, but for now the focus should be on our work towards a result. To ensure the necessary preparation, you can review the list below:

Source:made by Author in Canva

In conclusion, implementing PCI DSS Version 4.0 is an essential step towards securing payment transactions and protecting sensitive data from breaches. It provides a comprehensive framework for organizations to establish and maintain a strong security posture and stay up to date with the latest threats and technologies. By adhering to the requirements and best practices outlined in the standard, businesses can build trust with their customers, reduce the risk of data breaches, and safeguard their reputation. As the payments industry continues to evolve, it is important to stay vigilant and adapt to new challenges to ensure the security and integrity of payment transactions.

We’re building a team of the brightest minds in our industry. Interested in joining us? Visit the pages below to learn more about our open positions.

Trendyol jobs