Implementing a priority PCI compliance process is crucial for businesses that handle sensitive customer information.
To begin, identify all systems and networks that store, process, or transmit cardholder data. This includes servers, databases, and any third-party vendors.
Regular vulnerability scans and penetration testing can help identify weaknesses in your systems.
A risk assessment should be conducted annually or after any significant changes to your systems or processes.
PCI Compliance Process
The PCI compliance process involves several key steps. To establish a process for documenting and assigning responsibility, organizations need to have a defined list of documents and a detailed RACI (Responsible, Accountable, Consulted, Informed) assignment matrix, which dictates teams or individuals responsible for aspects of the documentation for a given requirement.
Organizations must also document policies, such as an inventory of equipment, software, and employees that have access to cardholder data, as well as logs of accessing cardholder data. This documentation is crucial for attestation of compliance.
To meet the semi-annual access control review requirement, organizations need to review user accounts and access privileges at least once every six months, ensure user accounts and access remain appropriate based on job function, and address any inappropriate access. This review can be done using identity management software, and organizations should keep correspondence between teams requesting verification, evidence of any changes, and compare approved access against implemented access within the organization's access control databases.
Here are the 12 requirements for PCI compliance:
- Use of firewalls
- Encryption
- Antivirus software
- Network monitoring
- Access controls
Establish Process Documentation and Responsibility
Establishing process documentation and assigning responsibility is a crucial step in the PCI compliance process. This involves creating a defined list of documents and a detailed RACI (Responsible, Accountable, Consulted, Informed) assignment matrix for each High-Level Requirement.
Organizations need to assign teams or individuals responsible for aspects of the documentation for a given requirement. For example, Requirement #1, Installing and Maintaining Security Controls, may have a RACI matrix that looks like this:
This matrix shows that the Network Admin and Firewall Admin are responsible for installing and maintaining security controls, while the Application Teams and Platform Teams are accountable for ensuring that network security controls are configured and maintained.
Smaller organizations may only have one individual in the role of Network and Firewall Admin, but they still need to create a RACI matrix to document their responsibilities.
It's worth noting that many organizations already have some level of documentation and process in place, but they may need to update and formalize their processes to meet the new requirements of PCI 4.0.
POI Inspection Frequency
POI Inspection Frequency is a crucial aspect of maintaining PCI compliance. Organizations must perform a Targeted Risk Analysis to establish a frequency for examining POI devices for tampering or overlay skimmers.
This frequency can be reduced in certain scenarios, such as keeping the POI device off the front counter or placing it in a cradle that prevents overlays. Most organizations assessed by Intersec have already established a frequency using similar processes.
Merchant Levels
Merchant levels play a crucial role in determining the risk associated with a business's transactions. There are four categories of merchant levels, each based on the number of transactions a merchant handles annually.
Level 1 merchants process over 6 million transactions a year and are typically multinational corporations or organizations with substantial volumes of transactions. They must undergo a PCI assessment performed by a Qualified Security Assessor (QSA) who issues a Report on Compliance.
Level 2 merchants process between 1 million and 6 million transactions a year and are required to complete a Self-Assessment Questionnaire (SAQ) annually. They may also have to submit quarterly audits by an Approved Scanning Vendor (ASV).
Level 3 merchants process between 20,000 and 1 million annual transactions and are also required to complete an SAQ. They might have to undergo quarterly network audits.
Level 4 merchants process 20,000 or fewer annual transactions and are the smallest merchants. They must complete an annual SAQ and might have to conduct quarterly network audits.
Here are the merchant levels in a concise table:
Versions
The PCI Compliance Process has undergone significant changes over the years.
The first version of the PCI DSS guidelines was released in 2004, which included the original 12 PCI DSS requirements.
Since then, there have been three more full versions of PCI DSS: version 2.0, released in 2011, and version 3.0, released in 2013.
Version 2.0 included minor language adjustments to clarify the meaning of the 12 requirements, and reinforced the need for thorough scoping before an assessment.
Version 3.0 introduced new requirements for methodology-based penetration testing to verify proper segmentation of the merchant cardholder data environment (CDE) from other IT infrastructures.
Here's a quick rundown of the major versions of PCI DSS:
- PCI DSS 1.0 (2004): Original 12 PCI DSS requirements, with a focus on security policies and procedures.
- PCI DSS 2.0 (2011): Minor language adjustments, thorough scoping, and effective Log Management.
- PCI DSS 3.0 (2013): Methodology-based penetration testing, inventory of CDE components, and strong access control measures.
- PCI DSS 4.0 (2022): Multifactor authentication, phishing and e-commerce standards, and increased flexibility and customization for organizations.
The most recent update, PCI DSS 4.0, was released in March 2022 and requires organizations to assign roles and responsibilities for each of its requirements.
A vs A EP
If you're a merchant dealing with cardholder data, you might have come across the terms SAQ A and SAQ A-EP. These refer to different types of Payment Card Industry Data Security Standard (PCI DSS) Self-Assessment Questionnaires (SAQs).
SAQ A is for card-not-present merchants who have completely outsourced all cardholder data functions.
There are 22 questions in SAQ A, which is significantly fewer than the 195 questions in SAQ A-EP.
If you're using a PCI DSS-compliant Service Provider for all your cardholder data functions, you can use SAQ A.
SAQ A-EP, on the other hand, is for partially outsourced e-commerce payment channels.
Here's a quick comparison of SAQ A and SAQ A-EP:
Your organization's systems should never store, process, or transmit cardholder data, but you may store, process, and transmit tokens to your provider to avoid scope.
When to Fill Out a D as a CNP
As a card-not-present organization, you'll need to fill out an SAQ D if you store cardholder data in plaintext, which is a no-no for PCI compliance.
Storing plaintext cardholder data requires a lot of security measures, including encryption and secure storage, but it's still a risk.
If you're a brick-and-mortar that hasn't implemented point-to-point encryption, you'll need to fill out an SAQ D as well.
Service providers processing under a certain threshold also need to fill out an SAQ D.
You can avoid filling out an SAQ D by using a tokenization provider, like Basis Theory, to maintain SAQ A or SAQ A-EP eligibility.
This way, you can keep a unified payment experience without storing cardholder data in plaintext.
Implementation and Configuration
To ensure a solid foundation for PCI compliance, proper implementation and configuration of multi-factor authentication (MFA) systems is crucial.
MFA systems must be implemented in a way that prevents replay attacks and cannot be bypassed by users, including administrative users, unless specifically documented and authorized by management.
At least two different types of authentication factors must be used, and the success of all authentication factors is required before access is granted.
Here are the key requirements for MFA system implementation:
Organizations should also ensure that multi-tenant hosting companies allow customers to perform external penetration testing of their systems, as required by PCI DSS 4.0.
Best Practices Implementation
To implement best practices for PCI-DSS compliance, it's essential to obtain and review the new PCI DSS 4.0 carefully, paying attention to updates to the 12 requirements.
Organizing a project team to complete PCI DSS 4.0 compliance is a crucial step, as it will help ensure that all aspects of the standard are met.
A self-assessment questionnaire is a useful tool to gauge how the organization does against new compliance standards, and it should be completed as part of the compliance process.
Vendor tools can be used to ensure compliance, but it's also important to consider using qualified third parties to confirm compliance.
To manage software components, organizations will need to create a standard template to capture and document specific application components and services utilized by an application.
This inventory should include application components, third-party components, application dependencies, internal or external API integration, and authorized payment page scripts.
Organizations will also need to invest in tools capable of alerting on component vulnerabilities to meet Requirement 6.3.3.
Updating and maintaining open-source or third-party libraries should be a high priority for any DevOps team, as failure to do so can result in an assessment failure and missed timelines.
To avoid the risk of employees putting credit card information in unencrypted fields, organizations should implement proper processes for accepting credit card information and train employees on meeting PCI Compliance.
Accounting software or programs used for storing card data should provide encrypted databases, and a secure, paper-based locked file system of account numbers is not a sufficient solution.
Implementing a proper system will require the transfer of all credit card information into a secure database, and finding a system with consultants who are knowledgeable in this area will help make the set-up and data migration process go smoothly.
Here are some essential steps to implement best practices for PCI-DSS compliance:
- Obtain and review PCI DSS 4.0 carefully
- Organize a project team to complete PCI DSS 4.0 compliance
- Complete a self-assessment questionnaire
- Use vendor tools and qualified third parties to ensure compliance
- Create a standard template to capture and document software components
- Update and maintain open-source or third-party libraries
- Implement proper processes for accepting credit card information and train employees on meeting PCI Compliance
- Use accounting software or programs with encrypted databases
By following these best practices, organizations can ensure that they meet the requirements of PCI-DSS standards and protect sensitive cardholder data.
Cryptographic Cipher Management
Cryptographic cipher management is a crucial aspect of implementation and configuration. It's not just about following a simple policy, but rather a complex process that requires careful attention to detail.
Organizations will need to document an up-to-date inventory of all cryptographic cipher suites and protocols in use, including their purpose and where they're used. This can be a challenging task, especially for larger organizations with multiple application implementations.
Active monitoring of industry trends regarding the continued viability of cryptographic cipher suites and protocols in use is also required. This means staying on top of the latest developments and updates to ensure that your organization's ciphers remain secure.
A documented strategy to respond to anticipated changes in cryptographic vulnerabilities is also necessary. This will help your organization stay ahead of potential threats and prevent security breaches.
Here are some key steps to consider when implementing cryptographic cipher management:
- Reverse engineer application implementations to identify used cipher suites and protocols
- Use vulnerability scanners to report specific protocols and ciphers in use
- Use NMAP's ssl-enum-ciphers script to list ciphers in use
- Establish an authorized cipher and protocol list
- Begin cleaning up deprecated ciphers
Keep in mind that this process can take a long time, especially for larger organizations with multiple systems and configurations. It's essential to assign ownership and establish policies and procedures to proactively manage cipher changes going forward.
Hardware and Software Maintenance
Hardware and software maintenance is a critical aspect of ensuring your organization's security and compliance with PCI DSS standards.
Regularly reviewing and maintaining hardware and software technologies is essential to prevent security issues and ensure compliance.
You should review your hardware and software technologies at least once every 12 months to ensure they continue to receive security fixes from vendors promptly.
This involves analyzing whether the technologies support and do not preclude your organization's PCI DSS compliance.
You'll also need to document industry announcements or trends related to a technology, such as when a vendor has announced "end of life" plans for a technology.
A plan to remediate outdated technologies, approved by senior management, is also necessary.
Some key points to consider when maintaining hardware and software technologies include:
- Analysis that the technologies continue to receive security fixes from vendors promptly.
- Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.
- Documentation of any industry announcements or trends related to a technology.
- Documentation of a plan, approved by senior management, to remediate outdated technologies.
Firewalls and anti-virus software require regular updates to ensure they continue to provide effective protection against unauthorized access and malware.
Updating software is especially important for devices that interact with or store cardholder data, as it helps to prevent vulnerabilities and protect against security threats.
In addition to regular updates, it's essential to maintain a software component inventory to ensure that all third-party components and services are properly documented and secured.
Best Practices for Meetings
To make the most out of your meetings, it's essential to have a clear agenda that outlines the topics to be discussed and the expected outcomes.
Setting clear goals and objectives before a meeting can help ensure everyone is on the same page and working towards the same goals. In fact, research has shown that meetings with clear objectives are 25% more productive than those without.
A well-prepared agenda should include a clear start and end time, a list of attendees, and a detailed list of topics to be discussed. This helps keep the meeting on track and ensures that all necessary topics are covered.
Having a designated note-taker can also help keep track of action items and decisions made during the meeting. This can be especially helpful in large or complex meetings where it's easy to lose track of details.
In meetings where decisions need to be made, it's a good idea to have a clear decision-making process in place. This can include setting a deadline for decisions and having a clear plan for implementing any new ideas or plans.
Security Measures
To achieve priority PCI compliance, it's essential to implement robust security measures. Regular updates to software and systems, including firewalls and anti-virus software, are crucial to prevent vulnerabilities. Most software products include security measures, such as patches to address recently discovered vulnerabilities, in their updates.
To protect cardholder data, encryption is a must. Card data must be encrypted with certain algorithms, and encryption keys must also be encrypted for compliance. Regular maintenance and scanning of primary account numbers (PAN) are necessary to ensure no unencrypted data exists.
Implementing multi-factor authentication (MFA) is another key security measure. According to Requirement 8.5.1, MFA systems must be implemented to prevent replay attacks, bypassing, and must use at least two different types of authentication factors. Success of all authentication factors is required before access is granted.
Here are some essential security measures to prioritize:
- Regular updates to software and systems
- Encryption of card data and encryption keys
- Regular maintenance and scanning of PAN
- Multi-factor authentication (MFA) implementation
- Regular vulnerability scans and vulnerability testing
Multi-Factor Authentication Implementation
Multi-Factor Authentication Implementation is a crucial security measure that helps protect sensitive information from unauthorized access.
To implement MFA correctly, a system must not be susceptible to replay attacks, meaning an attacker cannot reuse a previously valid authentication attempt to gain access.
MFA systems must also be designed so that users, including administrative users, cannot bypass them unless specifically documented and authorized by management on an exception basis, for a limited time period.
At least two different types of authentication factors must be used, such as something you know (like a password), something you have (like a smart card), and something you are (like a biometric).
All authentication factors must be successful before access is granted to the system.
3.2.1
Data retention and disposal policies are crucial for keeping account data to a minimum. This includes covering all locations of stored account data and limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
Specific retention requirements for stored account data should define the length of retention period and include a documented business justification. This ensures that data is only stored for as long as necessary.
Data should be securely deleted or rendered unrecoverable when no longer needed per the retention policy. A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable is also necessary.
Here are the specific requirements for pre-auth storage of Sensitive Authentication Data (SAD):
- Coverage for all locations of stored account data.
- Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization.
- Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
- Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
- Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
- A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.
Automated Phishing Prevention
Automated Phishing Prevention is a top priority for organizations due to the high risk and success of phishing campaigns. Intersec has assigned a higher priority to this control, and it's recommended that organizations implement solutions immediately to prevent phishing e-mails.
Many third-party services are available to perform this service, as well as proxy and reputation services that can prevent users from being exposed to phishing e-mails by default. These controls should have been added years ago, but fortunately, many QSAs have applied existing controls to Application and Service accounts.
Organizations that have already identified and documented application system accounts informally will need to formally document these accounts and wrap processes around them to support new controls. This will involve reverse engineering various automated processes and applications to identify and document all application system accounts in use.
To manage application and system accounts effectively, organizations should follow these best practices:
- Assign access privileges based on the least privileges necessary for the operability of the system or application.
- Limit access to the systems, applications, or processes that specifically require their use.
- Periodically review and update access privileges to ensure they remain appropriate for the function being performed.
- Prevent interactive use unless needed for an exceptional circumstance, and limit interactive use to the time needed for the exceptional circumstance.
- Document business justification for interactive use and obtain explicit approval from management.
- Confirm individual user identity before granting access to an account, and ensure every action taken is attributable to an individual user.
Detect and Prevent Covert Channels
Detecting and preventing covert channels is a challenging task for many organizations. Covert channels are intended to be hidden, making them difficult to detect.
Intrusion-detection and/or intrusion-prevention techniques can help detect, alert on, and prevent covert malware communication channels. This is especially important for service providers, who must implement these controls at critical points in the network.
Previous breaches have shown the successful use of covert channels. For example, a large retailer had data removed through DNS queries, and a large credit bureau lost millions of records due to a misconfigured DLP gateway.
Intersec recommends testing for a combination of the following controls to prevent covert channels:
- Egress traffic from the CDE must be strictly enforced.
- DLP solutions must be deployed and maintained at a minimum on user endpoints and/or organization gateways configured with a sub-CA certificate to decrypt outbound TLS traffic.
- Organizations must implement DNS Filtering / Secure Internet Gateway to block outbound connectivity to known or suspected malicious sites.
- Ingress and Egress access from third parties must be strictly limited to ports and protocols required.
The effectiveness of these controls will depend on an organization's resources and ability to react to alerts suggesting a covert channel has been identified.
Updates to Incident Response
Regular updates to your software are crucial to maintaining a secure environment.
Firewalls and anti-virus software will require updates often, so be sure to schedule these updates regularly.
These updates often include security patches that address recently discovered vulnerabilities, adding an extra layer of protection.
In addition to firewalls and anti-virus software, it's also a good idea to update every piece of software in your business.
This includes software that interacts with or stores sensitive data, such as cardholder information.
Security Awareness Training
Security Awareness Training is a crucial aspect of any organization's security measures. It's essential to ensure that all users in PCI scope receive regular training to stay aware of the latest threats and vulnerabilities.
The security awareness program should be reviewed at least once every 12 months and updated as needed to address new threats. This includes awareness about phishing and related attacks, as well as social engineering.
Security awareness training should include awareness about the acceptable use of end-user technologies, in accordance with Requirement 12.2.1. This means that organizations must update their Security Awareness Policy to include annual review and updates based on rising threats and vulnerabilities.
QSAs will be reviewing the organization's Security Awareness Training deck to verify it contains the required information. This includes transcripts from recent trainings, which demonstrate that all users have received training as required.
Here are some key requirements for Security Awareness Training:
- Review the security awareness program at least once every 12 months.
- Update the program as needed to address new threats and vulnerabilities.
- Include awareness about phishing and related attacks.
- Include awareness about social engineering.
- Include awareness about the acceptable use of end-user technologies.
Organizations should work with their QSA to verify that updated content meets the required subjects, and then distribute the training to in-scope users, track completion, and prepare transcripts.
Encrypt Transmitted Data
Encrypting transmitted data is a must for protecting cardholder information. This includes encrypting data sent across multiple ordinary channels, such as payment processors, home office from local stores, etc.
Cardholder data must be encrypted whenever it is sent to known locations. Account numbers should never be sent to unknown locations.
PCI SSC emphasizes the importance of encrypting transmitted data through their guidelines. In 2013, they published "PCI Mobile Payment Acceptance Security Guidelines for Merchants as End-Users" which highlighted the risks associated with credit card data transferred via mobile devices.
To ensure the security of cardholder data, encryption keys must also be encrypted. Regular maintenance and scanning of primary account numbers (PAN) are necessary to ensure no unencrypted data exists.
Here are some key requirements for encrypting transmitted data:
- Cardholder data must be encrypted with certain algorithms.
- Encryption keys must also be encrypted.
- Regular maintenance and scanning of PAN are necessary to ensure no unencrypted data exists.
By following these guidelines, organizations can ensure the security of cardholder data and protect against potential security breaches.
Vulnerability Scan
Regular vulnerability scans are crucial for identifying potential security threats. This type of scan helps detect weaknesses in software and systems.
All software products, including firewalls and anti-virus software, require updates to stay secure. These updates often include security measures like patches to address vulnerabilities.
Regular scanning of primary account numbers (PAN) is necessary to ensure no unencrypted data exists. This is especially important for devices that interact with or store cardholder data.
Vulnerability scans should be performed regularly to catch potential security threats before they become major issues.
What Is AEP
AEP is a type of SAQ that applies to card-not-present transactions and organizations that have outsourced their payment processing to a PCI DSS-compliant third-party service provider.
You play some role in directing the customer's payment information to the service provider, which can happen through a merchant-controlled checkout or a transparent redirect service.
This means you're not storing the plaintext value on your servers, but you're still creating additional system risk, which requires more questions and controls to be validated for PCI compliance.
In situations like this, you need to be extra careful with your security measures to avoid any potential vulnerabilities.
Frequently Asked Questions
What is the prioritized approach in PCI?
The Prioritized Approach in PCI is a method that focuses on six security milestones to protect against high-risk factors and escalating threats. It's structured around six core best practices that help organizations prioritize their security efforts effectively.
What are the PCI compliance requirements?
To achieve PCI compliance, you must implement robust security measures such as firewalls, antivirus software, and encryption, while also ensuring proper password management, data access restrictions, and software updates. By following these requirements, you can safeguard sensitive cardholder data and maintain a secure payment environment.
What are the 6 major principles of PCI DSS?
To ensure the security and integrity of cardholder data, the 6 major principles of PCI DSS include building a secure network, protecting cardholder data, maintaining a vulnerability management program, implementing strong access controls, regularly monitoring and testing networks, and maintaining an information security policy. By following these principles, organizations can effectively safeguard sensitive payment information.
Sources
- https://www.intersecworldwide.com/pci-dss-transition-plan
- https://www.digitalguardian.com/blog/what-pci-compliance
- https://www.imperva.com/learn/data-security/pci-dss-certification/
- https://www.techtarget.com/searchsecurity/definition/PCI-DSS-compliance-Payment-Card-Industry-Data-Security-Standard-compliance
- https://blog.basistheory.com/pci-dss-saq-self-assessment
Featured Images: pexels.com