The Payment Card Industry Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS)


The Payment Card Industry Data Security Standard (PCI DSS)

PCI DSS meaning: PCI DSS is a cybersecurity standard backed by all the major credit card and payment processing companies that aims to keep credit and debit card numbers safe

Companies can demonstrate that they've implemented the standard by meeting the reporting requirements laid out by the standard; those organizations that fail to meet the requirements, or who are found to be in violation of the standard, may be fined.

The Payment Card Industry Data Security Standard (PCI DSS) is required by the contract for those handling cardholder data, whether you are a start-up or a global enterprise. Your business must always be compliant, and your compliance must be validated annually. It is generally mandated by credit card companies and discussed in credit card network agreements.

The PCI Standards Council (SSC) is responsible for the development of the standards for PCI compliance. Its purpose is to help secure and protect the entire payment card ecosystem. These standards apply for merchants, and service providers processing credit/debit card payment transactions.

WHAT IS PCI COMPLIANCE?

Payment card industry (PCI) compliance is mandated by credit card companies to help ensure the security of credit card transactions in the payments industry. Payment card industry compliance refers to the technical and operational standards that businesses follow to secure and protect credit card data provided by cardholders and transmitted through card processing transactions. PCI standards for compliance are developed and managed by the PCI Security Standards Council.

THE 12 REQUIREMENTS OF PCI DSS

The requirements set forth by the PCI SSC are both operational and technical, and the core focus of these rules is always to protect cardholder data.

1.?????Install and maintain a firewall configuration to protect cardholder data

2.?????Do not use vendor-supplied defaults for system passwords and other security parameters

3.?????Protect stored cardholder data

4.?????Encrypt transmission of cardholder data across open, public networks

5.?????Use and regularly update anti-virus software or programs

6.?????Develop and maintain secure systems and applications

7.?????Restrict access to cardholder data by businesses need to know

8.?????Assign a unique ID to each person with computer access

9.?????Restrict physical access to cardholder data

10.??Track and monitor all access to network resources and cardholder data

11.??Regularly test security systems and processes

12.??Maintain a policy that addresses information security for all personnel

PCI DSS requirement 1: Install and maintain a firewall configuration to protect cardholder data

This first requirement ensures that service providers and merchants maintain a secure network through the proper configuration of a firewall as well as routers if applicable. Properly configured firewalls protect your card data environment. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by your organization.

Firewalls provide the first line of protection for your network. Organizations should establish firewalls and router standards, which allow for a standardized process for allowing or denying access rules to the network. Configuration rules should be reviewed bi-annually and ensure that there are no insecure access rules which can allow access to the card data environment.

PCI DSS requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

It focuses on hardening your organization’s systems such as servers, network devices, applications, firewalls, wireless access points, etc. Most of the operating systems and devices come with factory default setting such as usernames, passwords, and other insecure configuration parameters. These default usernames and passwords are simple to guess, and most are even published on the Internet.

Such default passwords and other security parameters are not permissible per this requirement. This requirement also asks to maintain an inventory of all the systems, and configuration/hardening procedures. These procedures need to be followed every time a new system is introduced into the IT infrastructure.

PCI DSS requirement 3: Protect stored cardholder data

This is THE most important requirement of the PCI standard. According to requirement 3, you must first know all the data you are going to?store?along with its location and retention period.?All such cardholder data must be either encrypted using industry-accepted algorithms (e.g., AES-256, RSA 2048), truncated, tokenized or hashed (e.g. SHA 256, PBKDF2). Along with card data encryption, this requirement also talks about a strong PCI DSS?encryption key management process.

Many times service providers or merchants don’t know they store unencrypted primary account numbers (PAN) and therefore running a tool like?card data discovery?becomes important. You would note that common locations where card data is found are log files, databases, spreadsheets, etc. This requirement also includes rules for how primary account numbers should be displayed, such as revealing only the first six and last four digits.

PCI DSS requirement 4: Encrypt transmission of cardholder data across open, public networks

Similar to requirement 3, in this requirement, you must secure the card data when it is transmitted over an open or public network (e.g. Internet, 802.11, Bluetooth, GSM, CDMA, GPRS). You must know where you are going to send/receive the card data to/from. Majorly, the card data is transmitted to the payment gateway, processor, etc. for processing transactions.

Cybercriminals can potentially access cardholder data when it’s transmitted across public networks. Encrypting cardholder data prior to transmitting using a secure version of transmission protocols such as TLS, SSH, etc. can limit the likelihood of such data getting compromised.

PCI DSS requirement 5: Use and regularly update anti-virus software or programs

This requirement focuses on protection against all types of malware that can affect systems. All systems including the workstations, laptops, and mobile devices that employees may use to access the system both locally and remotely must have an anti-virus solution deployed on them. You need to ensure that anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.

Ensure that anti-virus mechanisms are always active, using the latest signatures, and generating auditable logs.

PCI DSS requirement 6: Develop and maintain secure systems and applications

It is important to define and implement a process that allows to identify and classify the risk of security vulnerabilities in the PCI DSS environment through reliable external sources. Organizations must limit the potential for exploits by deploying critical patches in a timely manner. Patch all systems in the card data environment, including:

  • Operating systems
  • Firewalls, Routers, Switches
  • Application software
  • Databases
  • POS terminals

Apart from this, it requires you to define and implement a development process that includes security requirements in all phases of development.

PCI DSS requirement 7: Restrict access to cardholder data by businesses need to know

To implement strong access control measures, service providers and merchants must be able to allow or deny access to cardholder data systems. This requirement is all about role-based access control (RBAC), which grants access to card data and systems on a need-to-know basis.

Need to know is a fundamental concept within PCI DSS. Access control systems (e.g. Active Directory, LDAP) must assess each request to prevent exposure of sensitive data to those who do not need this information. You must have documented list of all the users with their roles who need to access card data environment. This list must contain, each role, definition of role, current privilege level, expected privilege level, and data resources for each user to perform operations on card data.

PCI DSS requirement 8: Assign a unique id to each person with computer access

According to requirement 8, you should not use shared/group users and passwords. Every authorized user must have a unique identifier and passwords must be adequately complex. This ensures that whenever someone accesses cardholder data, that activity can be traced to a known user and accountability can be maintained. For all non-console administrative access (remote access), two-factor authorization is required.

PCI DSS requirement 9: Restrict physical access to cardholder data

This requirement focuses on the protection of physical access to systems with cardholder data. Without physical access controls, unauthorized persons could gain access to the installation to steal, disable, interrupt, or destroy critical systems and the cardholder data.

It requires use of video cameras/electronic access control to monitor entry and exit doors of physical locations such as data centre. The recordings or access logs of personnel movement should be retailed for minimum 90 days. You need to implement an access process that allows distinguishing between authorized visitors and employees. All removable or portable media containing the cardholder data must be physically protected. It is necessary to destroy all media when the business no longer needs.

PCI DSS requirement 10: Track and monitor all access to network resources and cardholder data

The vulnerabilities in physical and wireless networks make it easier for cyber criminals to steal card data. This requirement requires that all the systems must have the correct audit policy set and send the logs to a centralized Syslog server. These logs must be reviewed at least daily to look for anomalies and suspicious activities.

Security Information and Event Monitoring tools (SIEM), can help you log system and network activities, monitor logs, and alert of suspicious activity. PCI DSS also requires that audit trail records must meet a certain standard in terms of the information contained. Time synchronization is required. Audit data must be secured, and such data must be maintained for a period no shorter than a year.

PCI DSS Requirement 11: Regularly test security systems and processes

Vulnerabilities are being discovered continually by malicious individuals and researchers Therefore, all systems and processes must be tested on a frequent basis to ensure that security is maintained.

Following periodic activities are required:

  1. Wireless analyzer scan to detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
  2. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.
  3. An internal vulnerability scan?must be conducted at least quarterly.
  4. All external IPs and domains must go through an exhaustive?Application penetration test?and?Network penetration test?at least yearly or after any significant change.

File monitoring is a necessity, too. The system should perform file comparisons each week to detect changes that may have otherwise gone unnoticed.

?PCI DSS Requirement 12: Maintain a policy that addresses Information Security for all personnel

This final requirement of PCI compliance and it is dedicated to the core PCI DSS goal of implementing and maintaining an information security policy for all employees and other relevant parties. The information security policy must be at least a yearly reviewed and disseminated to all the employees, vendors/contractors. Users must read the policy and acknowledge it.

This requirement also requires you to perform:

  1. An annual, formal risk assessment that identifies critical assets, threats, and vulnerabilities.
  2. User awareness training
  3. Employee background checks
  4. Incident management

What does it mean to be PCI DSS compliant?

PCI DSS compliance comes from meeting the obligations laid down by these requirements in the way best suited to your organization, and the PCI Security Standards Council gives you the tools to do so. The RSI security blog breaks down the steps in some detail, but the process in essence goes like this:

  1. ?Determine your organization's PCI DSS level. Organizations are divided into levels (more on which in a moment) based on how many credit card transactions they handle annually.
  2. Complete a self-assessment questionnaire. These are available from the PCI Security Standards Council website, and there are various questionnaires tailored to how different companies interact with credit card data. If you only take card payments online via a third party, you'd fill out Questionnaire A, for instance; if you use a standalone payment terminal connected to the internet, you'd go with Questionnaire B-IP. Each questionnaire determines how well your organization adheres to the PCI DSS requirements, tailored as appropriate by the ways in which you interact with customer credit card data.
  3. Build a secure network. The answers you give on your questionnaire will reveal any weak spots in your credit card infrastructure and requirements you fail to meet, and will guide you in plugging those holes.
  4. Formally attest your compliance. An AOC (attestation of compliance) is the form you use to signal that you've achieved PCI DSS compliance. Finishing your questionnaire with no "wrong" answers means that you're ready to go

PCI DSS levels

As noted, the PCI DSS standard recognizes that not all organizations have equal risk factors or equal capability to roll out security infrastructure. The specific requirements for meeting the standard that your organization will need to meet will depend on your company's level, which is in turn determined by how many credit card transactions you 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.

PCI DSS 4.0 Introduces Transformational Change: New Risk Analysis, Governance Requirements and Alternative Customized Approach

On March 31, 2022, the Payment Card Industry Security Standards Council released version 4.0 of its Data Security Standard (PCI DSS 4.0). The new version—which brings major changes to the payments ecosystem—places an increased focus on targeted risk analysis, organizational maturity and governance. It also makes PCI DSS compliance a continuous effort, rather than an annual snapshot exercise, and introduces a customized approach to PCI assessments, enabling businesses to implement alternative technical and administrative controls that meet the customized approach objective.

Merchants, service providers, issuers, acquirers, and any other businesses that store, process, or transmit payment cardholder data should begin planning for PCI DSS 4.0. Implementing PCI DSS 4.0 will require structural changes that go beyond tweaking security controls. Businesses will also need to prepare for the increased legal risks of PCI DSS 4.0’s obligations. PCI assessments under version 4.0 will require more security documentation, risk analysis and affirmative statements than before, exposing the company’s security posture to greater scrutiny.

Because of the complexity of the new requirements and the time required to implement structural changes, companies should begin addressing and internally validating compliance in advance of an assessment by their qualified security assessor (QSA). Businesses should consider whether to involve legal counsel and other consultants (under privilege) in this assessment and other aspects of their transition to PCI DSS 4.0, including for purposes of encouraging full and open communication and consideration of risks and exposure.

WHAT’S NEW IN PCI DSS 4.0?

PCI DSS 4.0 is an extensive change to the previous version of PCI DSS; some of the significant changes are included below.

Increased Requirements for Yearly Diligence for Merchants and Service Providers

?PCI DSS 4.0 increases the requirements for periodic diligence of merchants and service providers by adding several new controls. These include:

  • At least every 12 months and upon a significant change, document and confirm the PCI DSS scope of the in-scope environment (PCI DSS 12.5.2) with additional documentation requirements for service providers (PCI DSS 12.5.2.1-2);
  • Target risk analysis for any controls that use the customized approach at least every 12 months with written approvals by senior management (PCI DSS 13.3.2);
  • At least an annual risk analysis for any controls that have flexibility for the frequency of controls (PCI DSS 13.3.1, Best Practice until 2025);
  • At least an annual review of cipher suites and protocols (PCI DSS 12.3.3, Best Practice Until 2025); and
  • At least an annual review of hardware and software technologies in use with a plan to remediate outdated technologies approved by senior management (PCI DSS 12.3.4, Best Practice Until 2025).

?These additional annual diligence requirements will take time and effort to establish. Additionally, merchants and service providers may want to experience building these new processes well in advance of having to rely on them for PCI DSS compliance through their report Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) processes and QSA oversight. Starting sooner rather than later will be key to pragmatic results by allowing at least one practice cycle of these assessments prior to relying on them for PCI DSS compliance.

?New Customized Approach:

When merchants and service providers could not meet the prescriptive controls of PCI DSS 3.2.1, they would need to propose a compensating control and justify it with a risk assessment and a compensating control worksheet (CCW). In PCI DSS 4.0, this option still exists, but there is also a new option for a customized control approach. This customized approach still retains the requirement to evaluate risk, but it allows for a more strategic pathway to meet a control. Instead of compensating for the lack of a control, the customized approach allows the merchant or service provider to document a different control based on the objective of the control that is being customized. This customized control will then be assessed by the assessor in place of the control that is being substituted, allowing for a long-term customization rather than a shorter-term “compensating” control. (Note: Not all controls are eligible for the customized approach; notably, PCI DSS 3.3.1 prohibits storage of sensitive authentication data (SAD) after authorization.)

Expanded Risk Analysis Guidance:

PCI DSS 4.0 has also provided expanded guidance on conducting risk analysis. Risk analysis has always been a part of PCI DSS, significantly used as part of the compensating control worksheet. In this new version, there is a Sample Targeted Risk Analysis Template (PCI DSS Appendix E2). While this is not required to be used, the template provides more information on how the PCI Security Council expects a risk analysis to be carried out.

Clarifications to “Significant Change” Standard:

PCI DSS 4.0 has clarified some key PCI DSS concepts, including a more fulsome description of a “significant change” which was not specifically defined in prior versions in PCI DSS. While there is not an exact definition in this latest version, PCI DSS does provide descriptions and examples of what a significant change is (PCI DSS, 7 Description of Timeframes Used in PCI DSS Requirements). This is important because of the many interim changes, adaptations and updates (especially in the mobile payments industry) in the United States and in other countries (such as India).

?

WHEN DOES PCI DSS 4.0 TAKE EFFECT?

PCI DSS 4.0 will remain optional until March 31, 2024, when PCI DSS v. 3.2.1 will be retired. Assessments performed after that date must be under version 4.0. Companies will be able to opt-in to version 4.0 in the coming months once the self-assessment questionnaires and other supporting documents are released.

Several of the new requirements added for version 4.0 will not become mandatory until March 31, 2025. Until that date these requirements are considered “Best Practice” for entities that opt-in to version 4.0 early.

WHAT ARE THE LEGAL RISKS?

The increased focus on risk assessments in PCI DSS 4.0 means that entities are likely to disclose more information about their security program to QSAs than they would under version 3.2.1. Given that PCI security assessments are not conducted under privilege, businesses should be prepared for the assessment papers to be scrutinized in the wake of a security incident. This will be increasingly significant because the widespread adoption of chip transactions in the US has reduced the viability of card cloning, reportedly causing credit card fraudsters large and small to target card-not-present (CNP) transaction data and increase cyber risk to a wide variety of companies.

Statements made in risk analyses should be accurate, verifiable and consistent with other disclosures. Security documentation should reflect actual, provable and current practices. Customized controls should defensibly meet the defined customized approach objectives.

The transition to PCI DSS version 4.0 will prove challenging and time-consuming to many companies. Companies should begin their transition planning promptly. An initial step in the transition should be an assessment against the PCI DSS 4.0 standard to identify compliance gaps and opportunities to implement a customized approach. Engaging outside counsel to help oversee the conduct of the internal assessment or other aspects of transition planning can mitigate risk and contribute to a successful transition.



要查看或添加评论,请登录

社区洞察

其他会员也浏览了