PCI-DSS: Protecting your card data
Historical background
The rise of digital banking and credit card transactions has opened up an innovative, forward-looking, but also dangerous dimension that has quickly become an integral part of our everyday lives, both for its convenience and practicality. Today, it is almost impossible to imagine life without online shopping, PayPass, ATM cash withdrawals, but at the beginning of the millennium, the service trend was just taking off.
With the continued growth and development of services, security has not received the attention it deserves, so in 2006, in order to bring the security of card purchases to an appropriate and equal level, MasterCard, Visa, JCB International, Discover Financial Services and American Express established the PCI-SSC (Payment Card Industries Security Standards Council) to ensure that the data of their branded cards is only processed in any form by organisations that meet their requirements throughout the lifecycle of the transaction. The main aim of their requirements is to reduce data theft and misuse and to increase the overall protection of card transactions. There are now 15 standards associated with the PCI-SSC, the best known is the PCI-DSS (Payment Card Industries Data Security Standard), which covers the largest slice of the transaction lifecycle.
PCI-DSS
At the heart of PCI-DSS is card data, with requirements for its protection across 6 domains and 12 main requirements within each. Card data is any information that can be used to identify the cardholder. Card data is the cardholder's name, card number, card identification number, card expiry date, card issuer name, magnetic stripe, PIN, chip and CAV2/CVC2/CVV2 code. The handling and storage of these data is subject to strict requirements and restrictions, compliance with which must be demonstrated annually.
The requirements set out in the standard cover the areas of information security, including network security, data protection, vulnerability management, access management, control and monitoring, and maintaining policioes. The requirements of the standard are objective in nature, allowing for multiple approaches, provided the requirements are met. In addition to the requirements, they include control descriptions, which are primarily intended for auditors, but can also help companies to develop better controls by providing an understanding of the control approach. The requirements also set out other supporting points to help understand the relevance, importance and role of the requirement, and list best practices and examples to make implementation easier.
As technology evolves, the standard will continue to evolve, seeking to cover the sources of problems and anomalies arising from innovations by adding new requirements or supplementing existing ones. Changes are always communicated in a new version, so that audits can be carried out on the basis of both the previous and the new version, this flexibility also provides a lead time to allow organisations covered by the standard to prepare for the changes in the new version and, if necessary, to introduce new controls so that they are not caught by surprise during the audit.
4.0
The latest version of the standard, 4.0, came into force at the end of March 2022, while the previous version 3.2.1 is still in force until the end of March 2024. During this period, the organisations concerned can still be audited according to version 3.2.1, but it is worth getting ready for the new edition, as after March 2024 auditors will be obliged to audit the parts, operations and controls of the company covered by PCI-DSS according to version 4.0.
The newer versions of the standard are typically based on the previous editions, the requirements that can provide the minimum level of security will remain unchanged or with minor modifications in the new edition, while areas that were not covered in the previous version but are of major importance will be detailed in the form of new requirements. It is the preparation for these new and amended requirements that requires the most attention in the preparation period for companies that have already been successfully audited; to assess the extent to which current operations and existing controls and practices meet the minimum conditions set by the requirements, to identify those controls that need to be modified or newly established, and to prepare a timetable for the introduction of changes that need to be implemented in line with the corporate culture before the next audit, which will be based on a new version.
Version 4.0 takes a more innovative approach than the previous release, allowing for the cloud to be used, placing more emphasis on protection and detection against phishing attacks, tightening the criteria for authentication processes (stricter password requirements, MFA). It also includes an expectation for automated mechanisms to analyse log files in the area of incident management, in all areas where card data may be involved.
CDE
The standard does not oblige companies to manage card data in a separate office on a separate network, but it expects that the areas where data can be stored, managed and transmitted meet the requirements set by the PCI-DSS standard. It is therefore good practice for companies to establish a separate network for the employees and devices involved in these processes, as well as a physically separate office for employees working with card data, to limit the scope of the standard to those environments, thereby reducing the material and resource requirements for compliance. This separate area is called the Cardholder Data Environment, or CDE for short.
By reducing the area that the auditor has to monitor, a company can make life easier and simpler, but even if it is a small area, the requirements must be met. And there are requirements to have controls in place that need constant attention. For example, repetitive tasks that need to be repeated in continuous quarterly, half-yearly and annual cycles. These include quarterly external and internal vulnerability tests with acceptable results, Rogue AP scans, semi-annual firewall rule reviews, annual trainings, risk assessments, incident management process reviews, conducting penetration tests and recording the results and immediate remediation where necessary. Ongoing log analysis and early detection and remediation of potential incidents is an ongoing task alongside general operations.
PCI-DSS and SOC
Compliance with PCI-DSS is a complex, cross-cutting process that often requires a high degree of fluidity and efficiency. As incident management and maintaining the right level of protection are cornerstones, a Security Operation Center (SOC) can be a great help to your business. Whether it is an external or internal SOC, the efficiency of the tasks can be significantly increased if they are implemented and managed by a dedicated team. Such tasks can include vulnerability management, threat intelligence, incident management and log file analysis with automated mechanisms. Although the core task of a SOC is usually log analysis and incident management, this activity can and typically does expand, of course by agreement between the contracting parties.
The question may arise whether, where a company needs to comply with the PCI-DSS requirements and engages an external party as SOC to perform the tasks, the external party is also bound by the standard? To answer this question, it is worth referring to the definition provided by the standard, which states that "PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE." According to this sentence, since the SOC may affect the security of the CDE in a positive direction, it may be clear that it does. Another factor is that, according to PCI-DSS, any related system that supports compliance with PCI-DSS requirements or provides a security service to the CDE is also in scope.
In summary, PCI-DSS is an innovative, practical and consistent standard that ensures that card data is processed, managed and stored in a secure environment during card transactions. The requirements set out in the standard are reasonable and achievable, but compliance requires significant planning, attention, budget and ongoing operation.
