Secure Transactions: A PCI DSS & PA-DSS Overview and Compliance Checklist

With the advent of the Internet in the late 1990s, credit card fraud surged. Though credit card companies came out with their own individual security programs, merchants accepting multiple types of credit cards had difficulty meeting multiple standards. Eventually, credit card companies banded together to create the Payment Card Industry Data Security Standard (PCI DSS), which was introduced by card service operators worldwide in 2004.

What is PCI DSS and PA-DSS?

PCI DSS is administered by the Payment Card Industry Security Standards Council and focuses on the supporting networks, systems, and other payment card processing equipment. It has gone through significant revisions over the years, moving all retailers (and other industries) who use credit/debit cards into stronger and more predictably tested security postures, dramatically reducing card fraud.

A wide selection of infrastructure configuration settings and security policies initially were only recommended, shifting over time into suggested, until they eventually became mandated. By December 2019 PCI DSS version 3.2.1 has moved all critical requirements to mandated. The latest PCI DSS updates went into effect March 2022 with version 4.0 to better address emerging threats and technologies.

Payment Application Data Security Standard (PA-DSS) has a similar structure, but focuses on payment card applications, and how they collect, process, and transfer card data to support payments securely. Initially created in 2008 by VISA, this standard migrated into its latest form in 2016 as PA-DSS version 3.2.

What are the challenges of PCI DSS and PA-DSS certifications?

PCI DSS and PA-DSS are repeating and ongoing recertification process chains to prove to your credit/debit card processing supplier(s) worldwide (e.g. VISA, DISCOVER, AMEX, and others) that card data is handled correctly and securely, and that your IT and business operations can be audited.

The structure of both standards is listed in pages and pages of tabular form, and PCI “assessors” commonly use automation tools, test teams, and spreadsheets to check off audit results. PCI compliant infrastructures and applications must pass each and every requirement and must be reverified at least on an annual basis, or more often if card processing equipment or software is substituted in your company. In some cases, compensatory controls are accepted by PCI and your card service provider, but these exceptions are rare and must be reviewed on a regular basis.

PCI testing can be rigorously intrusive to business as usual, and appropriate tests must be carried out at each location where credit/debit card processing of any kind occurs. The PCI Council is working on lifecycle management of both change and audit as it frames future editions of its standards to reduce impact on your business and make audit more cost effective.

Though certification and recertification can be rigorous, these processes are critical challenges to take on. Since following PCI mandates is so vital in ensuring security, failing PCI certification carries the threat that card services providers can instantly withdraw their transaction processing service, which can cripple your ability to trade with your customers and business partners.

Who do PCI standards and compliance requirements apply to?

PCI processing standards and audits apply to anyone who accepts credit/debit cards for any product or intangible offering worldwide, including:

Services in retail stores or other physical locations
Online services
Phone or online chat-based call centers
Any specialist financial services companies that carry out PCI processing on your company’s behalf
Your credit/debit card issuing bank, credit union or other institution (e.g. branded airline credit cards)

Special attention is drawn to shared service centers in the latest version 3.2.1, outlining the need for clear separation and security of service for each individual company, partitioning card services for every company that they provide services for.

Does PCI DSS compliance ensure security for all credit card transactions?

It is possible to be PCI Compliant and still suffer a data breach of customer data. With a laser focus on processing credit/debit card data alone, PCI compliance is no guarantee your IT systems and business processes won’t be attacked in other ways. Your IT Environment as a whole must also be assessed and protected.

Additionally, since PCI is only focused on card data handling PCI compliance is not a legal proof that your systems and application infrastructure will pass other compliance regimes like Sarbanes Oxley (SOX), your industry regulations, or national/state data protection legislation. However, mandatory encryption of credit/debit card information hopefully will constrain hackers or thieves from reusing your card data elsewhere.

What are the next steps towards becoming PCI compliant?

Now that we’ve explained the basic concepts behind PCI DSS and PA-DSS, you can start considering what steps your organization must take to become PCI compliant. The following checklist will help simplify this process, providing you with the full list of requirements for both PCI DSS and PA-DSS, as well as suggestions on how to meet them. For help meeting PCI requirements specifically on the IBM i OS, see our guide to navigating PCI DSS on IBM i.

PCI DSS & PA-DSS Compliance Checklist

Find out what each requirement of PCI means and how Fortra solutions can help you comply in the table below or by downloading the PDF version of the checklist.

Requirement	What It Means
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.	Use Penetration Testing to prove there aren’t any gaps in firewall rules. Use Intermapper to discover device interconnections and network maps.
1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network.	Use Intermapper to discover device interconnections and network maps.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
2.1 Always change ALL vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This includes wireless devices that are connected to the cardholder data environment or are used to transmit cardholder data.	Use Penetration Testing to prove defaults have been changed to unique values.
2.2 Develop configuration standards for all system components that address all known security vulnerabilities and are consistent with industry-accepted definitions. Update system configuration standards as new vulnerability issues are identified.	Use Core Privileged Access Manager (BoKS) to define system roles and accounts. Mandate and require by policy that the solution automatically changes default operating system passwords and SSH keys as each system is provisioned. Use Event Manager to document and audit the security configuration standards of your systems.
2.3 Using strong cryptography, encrypt all non-console administrative access such as browser/web-based management tools.	Use Core Privileged Access Manager (BoKS) to enforce encrypted communications to servers.
2.4 Maintain an inventory of system components that are in scope for PCI DSS.	Use Event Manager to document and audit the security configuration standards of your systems.
2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data.	Use Core Privileged Access Manager (BoKS) to define separate systems, clearly visible system groups and accounts for PCI service companies. Use Core Privileged Access Manager (BoKS) to enforce system/app separation for shared PCI infrastructures.
Requirement 3: Protect stored cardholder data.
3.2 Do not store sensitive authentication data after authorization (even if it is encrypted).	Use Core Privileged Access Manager (BoKS) to enforce encrypted server security policy.
3.5 Document and implement procedures to protect any keys used for encryption of cardholder data from disclosure and misuse.	Use Core Privileged Access Manager (BoKS) to enforce key access for users and application accounts. Register keys in the database; manually added keys cannot be utilized.
3.6 Fully document and implement key management processes and procedures for cryptographic keys used for encryption of cardholder data.	Use Core Privileged Access Manager (BoKS) to define key distribution policies.
Requirement 4: Encrypt transmission of cardholder data across open, public networks.
4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.	Use Core Privileged Access Manager (BoKS) to define cryptography standards for key usage. Utilize GoAnywhere MFT to provide full end-to-end encryption of cardholder data, including data-in-transit and data-at-rest.
Requirement 5: Protect all systems against malware and regularly update antivirus software or programs.
5.1 Deploy antivirus software on all systems commonly affected by malicious software.	Deploy Powertech Antivirus to protect your Linux, AIX, and IBM i systems from malicious software. Force virus scanning of files prior to entry into the environment using GoAnywhere MFT’s file transfer automation and integration capabilities.
5.2 Ensure that all antivirus mechanisms are kept current, perform periodic scans, generate audit logs.	Powertech Antivirus automatically updates with current virus and malware definitions. The solution scans and reports outcomes on configurable periods or events.
5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.	Deploy Powertech Antivirus and ensure operating system accounts and roles that “own” the A/V solution are protected from normal users. Ability to modify standard behavior should be controlled jointly with change management solution and integrated to Core Privileged Access Manager (BoKS).
Requirement 6: Develop and maintain secure systems and applications.
6.3 Develop internal and external software applications including web-based administrative access to applications in accordance with PCI DSS and based on industry best practices. Incorporate information security throughout the software development life cycle. This applies to all software developed internally as well as bespoke or custom software developed by a third party.	Use Core Privileged Access Manager (BoKS) to ensure pre-production accounts cannot be deployed into production systems. Use Event Manager to ensure pre-production accounts are not deployed into production systems. Use Vulnerability Management with an application security solution to scan, assess, and prioritize vulnerabilities . Use Penetration Testing to verify security of applications.
6.4 Follow change control processes and procedures for all changes to system components.	Deep enterprise application integrations (such as with change management systems and trouble ticketing systems) allow Tripwire Enterprise to initiate workflow activities within those systems and applications – rapidly notifying of change detection and anomalies, speeding resolution, and offering remediation guidance.
6.5 Prevent common coding vulnerabilities in software development processes by training developers in secure coding techniques and developing applications based on secure coding guidelines – including how sensitive data is handled in memory.	Use Core Privileged Access Manager (BoKS) to enforce appropriate security standards for those application processes that use account based keys. Use Vulnerability Management with an application security solution to scan, assess, and prioritize vulnerabilities . Use Application Penetration Testing to verify security of applications.
Requirement 7: Restrict access to cardholder data by business need-to-know.
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.	Use Core Privileged Access Manager (BoKS) to define and map appropriate users and user group access cardholder data at the operating system level. Those accounts, groups, and permissions are auto-provisioned. Use Event Manager to report on requirements to business owners and audit that the enforcing solution continues to meet PCI standards, and has not been subverted.
7.2 Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.	Use Core Privileged Access Manager (BoKS) to enforce automatic least privilege and deny all policies by default on Linux/UNIX platforms. Use Event Manager to report on requirements to business owners and audit that the enforcing solution continues to meet PCI standards, and has not been subverted.
Requirement 8: Identify and authenticate access to system components.
8.1 Define and implement policies and procedures to ensure proper user identification management for users and administrators on all system components. Assign all users a unique user name before allowing them to access system components or cardholder data.	Use Event Manager to monitor user inactivity to help ensure inactive accounts are removed/disabled within 90 days. Event Manager can prevent repeated access attempts by locking out the user ID after not more than six attempts.
8.2 Employ at least one of these to authenticate all users: something you know, such as a password or passphrase; something you have, such as a token device or smart card; or something you are, such as a biometric. Use strong authentication methods and render all passwords unreadable during transmission and storage using strong cryptography.	Use Core Privileged Access Manager (BoKS) to mandate strong authentication for all users utilizing an MFA token where passwords are used inside a PCI cluster.
8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication. This requires at least two of the three authentication methods described in 8.2 are used for authentication. Using one factor twice (e.g. using two separate passwords) is not considered multi-factor authentication. This requirement applies to administrative personnel with non-console access to the CDE from within the entity’s network, and all remote network access (including for users, administrators, and third-parties) originating from outside the entity’s network.	Use Core Privileged Access Manager (BoKS) to protect your PCI cluster from remote PCI service and support staff. In this case MFA must be used, and BoKS can automatically enforce MFA authentication for sessions starting outside the cluster.
8.5 Do not use group, shared, or generic IDs, or other authentication methods. Service providers with access to customer environments must use a unique authentication credential (such as a password/passphrase) for each customer environment.	Use Core Privileged Access Manager (BoKS) to mandate policies where each iteration of PCI services provision of customer requirements, unique IDs are automatically generated, with unique authorization credentials. Where an end-customer ALSO is required to carry out remote administration into shared infrastructures an additional unique MFA strong authenticator must be associated with the account when it is generated.
8.6 Use of other authentication mechanisms such as physical security tokens, smart cards, and certificates must be assigned to an individual account.	Use Core Privileged Access Manager (BoKS) to require that unique strong credentials are assigned to unique user accounts. For operating system “owned” application installation accounts (e.g. like “Oracle” owning the database files and executables) the use of SSH User Certificates can be mandated to meet A-to-A strong authentication.
Requirement 10: Track and monitor all access to network resources and cardholder data.
10.1 Implement audit trails to link all access to system components to each individual user.	Deploy standard Core Privileged Access Manager (BoKS) audit and log generation functionality to generate event and audit logs, with user ID and user group fields in each log record. Use Event Manager reporting features to provide lists of all login failure events and privilege escalations. Additionally, the reporting can provide detail into any actions taken, including any changes, additions, or deletions to any account by a root or administrator user.
10.2 Implement automated audit trails for all system components.	Deploy standard Core Privileged Access Manager (BoKS) to generate operating system security policy change logs, as well as access and authentication logs for day-to-day user account access. Use Event Manager reporting features to provide lists of all login failure events and privilege escalations. Additionally, the reporting can provide detail into any actions taken, including any changes, additions, or deletions to any account by a root or administrator user.
10.3 Record audit trail entries for all system components for each event, including at a minimum: user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component or resource	Deploy standard Core Privileged Access Manager (BoKS) to generate operating system security policy change logs, as well as access and authentication logs for day-to-day access. Deploy Event Manager to log and create audit trail alerts and generate reports.
10.4 Using time synchronization technology, synchronize all critical system clocks and times and implement controls for acquiring, distributing, and storing time.	Use time synchronization in Core Privileged Access Manager (BoKS) to ensure Linux/UNIX OS IAM logs are effective and accurately reported. Use Event Manager to monitor and alert on any unscheduled time and date changes.
10.5 Secure audit trails so they cannot be altered.	Deploy standard Core Privileged Access Manager (BoKS) to monitor the generated security logs, such that they cannot be tampered. Deploy Event Manager to transmit all logs to central management for alerting and redundancy.
10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.	Use Event Manager to report on PCI related security events, and where appropriate generate alerts of suspicious activity for immediate Security Operations center action.
10.7 Retain audit trail history for at least one year; at least three months of history must be immediately available for analysis.	Use Event Manager to define and implement log retention periods of at least a year inside its database.
Requirement 11: Regularly Test Security Systems & Processes.
11.3 Develop and implement a methodology for penetration testing that includes external and internal penetration testing at least annually and after any upgrade or modification.	Use Vulnerability Management to scan, assess, and prioritize vulnerabilities to find the most urgent weaknesses and measure remediation efforts. Deploy a standard Penetration Testing solution to define boundaries and process the above requirements. Deploy a standard Penetration Testing solution to execute all permutations of penetration testing in this requirement. Utilize third party Security Consulting Services for red teaming efforts.
11.4 Deploy a change detection mechanism (for example, file integrity monitoring tools) to alert 24 personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files or content files. Configure the software to perform critical file comparisons at least weekly. Implement a process to respond to any alerts generated by the change-detection solution.	Use Tripwire Enterprise to monitor file integrity events, including any unauthorized modification (changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Use Event Manager to prioritize these events and alert appropriate personnel of these changes.