How IT Professionals Can Navigate PCI DSS Compliance on IBM i

The launch of PCI DSS in 2004 helped expose serious security shortcomings, failures to follow security best practices, and a general lack of awareness of the security threats facing organizations today.

Unfortunately, the recent data breaches at Truist Bank, Ticketmaster, and Roku show that large organizations still struggle with implementing PCI requirements and recognizing the security needs for their unique environments. Any company that stores credit card data, including those that use a third party to store their data, need to be actively working toward compliance with PCI requirements if they have not already.

Failing a PCI DSS audit can result in fines, but IT’s contribution extends beyond avoiding these penalties. Meeting PCI’s standards contributes to your business’s security posture, helping to avoid data breaches and all of their attendant costs: litigation, customer notification and compensation, damage to the company’s reputation, and diminished share value.

It is important to remember that compliance is an adoption of standard practices and does not guarantee that data is inaccessible to someone without authorization.

Threats evolve much faster than data security standards—including PCI DSS—can be updated. Meeting compliance requirements is necessary, but it won’t keep you ahead of cybercriminals. Security efforts shouldn’t stop once PCI DSS compliance is under control. Implementing a multi-layered defense will help minimize security risks. This is a wise approach even if it’s not required by any compliance mandate.

The specifics of every mandate are different, but some basic controls are repeated across most major compliance mandates:

• Identify or inventory critical data, so you know where it resides and can protect it.
• Monitor and prevent unauthorized changes (file integrity monitoring).
• Measure and analyze risks (vulnerability assessment).
• Detect and prevent malware and viruses.
• Create and enforce a security policy.
• Maintain an audit trail.

These security concepts inform PCI DSS and other compliance mandates. With this knowledge, you’ll have an easier time interpreting the details of a regulation or standard—as well as determining how to meet it.

The PCI standard is unique in that, unlike many other regulations, it comes from private industry rather than the government. The first version of PCI DSS was published in 2004 by Visa, MasterCard, and other credit card issuers. Adoption was slow at first, and a series of fines and incentives were put in place to encourage compliance.

PCI DSS consists of 12 main requirements. Many of the general requirements are consistent with the security practices businesses have put in place to comply with Sarbanes-Oxley (SOX) and similar regulations, but PCI was the first to explicitly require encryption. This has proven the most troublesome security control to implement.

Another requirement is a sound security policy that includes, for example, the use of firewalls, access control, and keeping log data for 90 days.

The standard has been updated several times over the years as payment card issuers respond to evolving security threats, and the most recent version, 4.0.1, was released in June 2024. 

PCI DSS 4.0.1, as it relates to PCI DSS 3.2, added a variety of requirements, including:

• Roles and responsibilities for performing activities in all requirements must be documented, assigned, and understood.
• Encrypting Sensitive Authentication Data (SAD) that is stored electronically prior to completion of authorization.
• Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.
• All user accounts and related access privileges must be reviewed as specified in 7.2.4.
• Increasing password length from a minimum of seven characters to 12.
• MFA must be implemented for all non-console access into the CDE.
• And many more

Some new requirements are effective immediately for all v4.0 assessments while others are considered “best practices” until March 2025. A summary of changes from v3.2 to v4.0, and their corresponding date in which they take effect, can be found in the document library on the PCI Security Standards Council’s website.

PCI DSS Compliance Checklist for the IT Professional on IBM i

This checklist focuses on the parts of the standard that are relevant to Power Systems servers (System i, iSeries, AS/400) and their operating system IBM i (i5/OS, OS/400). Fortra commentary (shown in italics) describes the relevant issues, highlights additional exposures that should be secured, and suggests when Fortra can provide a solution.

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

Network security controls (NSCs), such as firewalls and other network security technologies, are designed to control computer traffic allowed into a company’s network from outside, as well as traffic into more sensitive areas within a company’s internal network. All systems need to be protected from unauthorized access from the internet, whether for ecommerce, employee internet-based access via desktop browsers, or employee email access. Often, seemingly insignificant paths to and from the internet can provide unprotected pathways into key systems. NSCs are a key protection mechanism for any computer network.

□ Establish and implement firewall configuration standards that include documentation of business justification and approval for use of all services, protocols, and ports allowed.

IBM i servers allow network access through interfaces such as ODBC, FTP, and Remote Command. Many of the applications that store critical data on the IBM i server were architected when users accessed the system directly from a console and a menu system provided the only way to get to data. Even in the presence of perimeter firewalls, the implementation of protocols like FTP, ODBC, and Remote Command has exposed back doors to download and change critical data stored on the system, including credit card information.

A solution like Powertech Exit Point Manager for IBM i from Fortra monitors and secures internal network traffic to IBM i servers using exit programs. With Exit Point Manager, you can establish rules that limit access to only those users that have been preauthorized. All others can be excluded by default.

Requirement 2: Apply Secure Configurations to All System Components

Hackers (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and are easily determined via public information.

□ Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. (This applies to ALL default passwords.)

Most system profiles on IBM i begin with the letter “Q," such as QSECOFR and QPGMR. Check profiles on a regular basis to ensure that the password is not set to default, which means it’s the same as the user name.

Powertech Compliance Monitor for IBM i is a Fortra solution that provides the capability to run regular audit reports to monitor the security compliance status of IBM i systems. For example, one of the default reports included with Compliance Monitor is “User Profiles with Default Passwords.” In addition, it also includes a predefined filter specifically for IBM i system profiles.

While a password validation program can provide additional restrictions beyond the operating system’s own controls, the existence and function of such a program should be monitored as it is a way to collect passwords as they are changed. Compliance Monitor reports on the compliance of password system values against a policy to quickly determine if all of the values are set as expected and event log reports will identify the source of any deviation.

□ Encrypt all non-console administrative access using strong cryptography.

IBM i provides the capability to secure Telnet and other common sessions to the system with SSL. Connections that are not secured can be rejected.

Requirement 3: Protect stored account data.

Encryption of account data is a critical component of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable. PCI rules also control the storage of elements of the account data in order to limit risk.

□ Render the primary account number unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using either one-way hashes, truncation, index tokens and pads, or strong cryptography associated with key-management processes and procedures.

Two-way encryption relies on mature, proven technology, and is one of the most effective means of preventing information disclosure. Powertech Encryption for IBM i is a solution that protects cardholder data using strong encryption, integrated key management, and auditing. Its intuitive features make encrypting database fields, backups, and IFS (integrated file system) files quick and effective. Powertech Encryption also includes comprehensive auditing, with audit log entries stored in secure IBM journal.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks.

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

□ Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

An option to consider is GoAnywhere MFT™, which protects transmissions over public and private networks using secure protocols and provides strong authentication schemes using a combination of user IDs, passwords, keys, and/or certificates. This software is an enterprise-ready managed file transfer (MFT) solution that streamlines and encrypts the exchange of data between your systems, employees, customers, and trading partners. GoAnywhere adds an extra level of security with a DMZ gateway that prohibits direct public access from the internet to any systems in the private network.

Requirement 5: Protect All Systems and Networks from Malicious Software

This requirement ensures that systems are protected from current and evolving malicious software threats. Configure IBM i security system values to prevent restoration of malicious programs and to verify the authenticity of digital signatures of signed objects.

□ Deploy anti-virus software on all systems commonly affected by malicious software, including servers.

□ Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

□ Ensure that all anti-virus mechanisms are kept current, perform periodic scans, and generate audit logs that can be retained for at least a year.

Powertech Antivirus for IBM i, powered by the Trellix scan engine, provides native virus protection for your Power Systems servers running IBM i and should be considered a requirement for any server that uses the integrated file system (IFS). Support for Linux, AIX, and IBM Domino extend the investment in Powertech Antivirus beyond the normal boundaries of IBM i.

Powertech Compliance Monitor for IBM i can report on the system values that define the state of the anti-virus controls for IBM i and analyze event logs to determine the cause of any deviation.

Requirement 6: Develop and maintain secure systems and software

Security vulnerabilities in systems and applications may allow criminals to access cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches. In addition, secure coding practices for developing applications, change control procedures, and other secure software development processes should be followed.

□ Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Deploy critical patches within a month of release.

You should have a process in place for applying system OS and PTF (program temporary fix) updates in a timely manner.

□ Follow change control processes and procedures for all changes to system components.

Change control processes are a key component of complying with this requirement, and numerous commercial applications exist to aid the promotion of application programs into a production environment.

Powertech Authority Broker for IBM i, privileged user management software from Fortra, allows you to monitor and control who can make changes to system components through powerful user profiles and special authorities. It controls the elevation to privileged user profiles and maintains an audit log of user activities.

Powertech Database Monitor for IBM i is a database security monitoring solution that can monitor for changes to critical data and send real-time alerts when critical events occur.

Requirement 7: Restrict access to cardholder data by business need-to-know.

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Access” or “access rights” are created by rules that provide users access to systems, applications, and data, while “privileges” allow a user to perform a specific action or function in relation to that system, application, or data.

□ Limit access to computing resources and cardholder information to only those individuals whose job requires such access.

□ Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Exit Point Manager allows you to limit access to only those individuals who need access to data for business reasons. Fortra recommends exclusion-based security where rules in Exit Point Manager are used to grant network access to data to only those users with a demonstrated need. All others are excluded by default (set *PUBLIC access to *EXCLUDE).

Authority Broker audits and controls the access that users have to sensitive data through the special and private authorities associated with their user profile.

Database Monitor monitors database access in real time at the record and field level. Powerful workflow capabilities provide notification, authorization, and reporting capabilities for regulatory compliance.

Command monitoring software like Powertech Command Security for IBM i helps monitor and secure the use of IBM i commands. Using Command Security, identify which commands to monitor, specific conditions under which commands should be secured, and maintain a complete audit trail of powerful IBM i commands, including those issued by privileged users.

Powertech Policy Minder for IBM i aids in establishing and enforcing security configurations across your IBM i. Policy Minder produces exception-based reports that assist in identifying misconfigurations such as profiles with excessive authorities. Policy Minder can also be configured to automatically remediate any exceptions to policy. 

Requirement 8: Identify and authenticate access to system components.

Assigning a unique identification to each person with access ensures that each person is accountable for their actions. Putting this accountability in place ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

□ Assign a unique ID to each person with computer access.

Powertech Compliance Monitor for IBM i provides comprehensive reporting of all audit information on IBM i servers. This includes events related to users accessing the system, such as:

• Invalid login attempts
• Default passwords
• Expired passwords
• Password and sign-on system values
• Powerful user accounts (root-level access)

Users can also customize their own specific reports.

□ Immediately revoke accesses of terminated users.

□ Remove inactive user accounts at least every 90 days.

Powertech Compliance Monitor for IBM i includes a report that makes it easy to track and report on inactive user profiles.

Powertech Policy Minder for IBM i can be configured to automatically remove or disable profiles that have been inactive for a customizable number of days. 

□ Enable accounts used by vendors for remote maintenance and monitor their use only during the time needed. IBM i profiles can be placed on activation schedules.

Powertech Compliance Monitor for IBM i allows you to quickly and easily identify these accounts.

Powertech Authority Broker for IBM ienables administrators delegate elevated privileges for limited periods of time and at a scheduled cadence, eliminating the need for special authorities in staff members’ everyday profiles. Authority Broker also monitors and records the activity of users while they are in a state of elevated authority.

□ Limit repeated access attempts by locking out the user ID after not more than six attempts.

IBM i includes system value settings that make it easy to implement this access control:

• QMAXSIGN=6
• QMAXSGNACN=2

Settings like these often result in more users getting locked out of their accounts, which can overwhelm help desk staff. A solution like Powertech Password Self Help for IBM i makes a more restrictive password policy more manageable by enabling users to reset their own IBM i passwords—no assistance from the help desk required.

□ Set the lockout duration to 30 minutes or until administrator enables the user ID.

□ If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal.

Implement this control with IBM i system value setting QINACTITV=15.

QINACTMSGQ should be set to a message queue monitored by Exit Point Manager Secure Screen.

Or, alternatively, place restrictions on the Windows systems that are used to access the IBM i server.

Ensure proper user authentication and password management for non-consumer users and administrators on all system components:

□ Encrypt all passwords during transmission and storage on all system components.

□ Verify user identity before performing password resets.

Powertech Password Self Help for IBM i enables users to reset their own passwords using challenge-response questions to validate their authenticity.

□ Require a minimum password length of at least seven characters. (Most other standards recommend only at least six characters.)

Powertech Compliance Monitor for IBM i reports on password length as well as other password requirements.

Powertech Policy Minder for IBM i identifies and resolves password policy exceptions across your IBM i.

The IBM i platform provides multiple options for meeting these requirements:

• IBM i system value setting: QPWDMINLEN=12 or via QPWDRULES=*MINLENnnn
• Additional settings for QPWDRULES:
  • *ALLCRTCHG
  • *LMTPRFNAME
  • *LTRMAXn
  • *LTRMINn
  • *DGTMAXn
  • *DGTMINn
  • *SPCCHRMINn
    • OR *REQANY3 will require 3 of these 4 attributes Upper, Lower, Digit or Special Character

□ Use passwords containing both numeric and alphabetic characters.

To achieve this control, use IBM i system value setting QPWDRQDDGT=1.

□ Change user passwords at least every 90 days.

To achieve this control, use IBM i system value setting: QPWDEXPITV=90.

□ Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

To achieve this control, use IBM i system value setting: QPWDRQDDIF=8 (LAST 4).

□ Set first-time passwords to a unique value per user and change immediately after first use.

Powertech Compliance Monitor for IBM i can report on user profiles using default passwords.

Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication.

□ Incorporate multi-factor authentication for all local/internal network access into the cardholder data environment for personnel with administrative access.

Powertech Multi-Factor Authentication is a Fortra solution that allows multi-factor authentication to be deployed across your organization, including IBM i systems.

□ Incorporate multi-factor authentication for all remote network access originating from outside the network.

This includes user and administrator access, as well as third-party access for support or maintenance.

□ Document and communicate authentication policies and procedures to all users.

□ Do not use group, shared, or generic accounts/passwords.

Use IBM i system value setting QLMTDEVSSN=1 to limit users to a single device session.

Powertech Compliance Monitor for IBM i includes a report that will identify out-of-compliance profiles.

□ Control the addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Powertech Compliance Monitor for IBM i makes it easy to monitor this activity and document compliance with this requirement.

□ Restrict all access to any database containing cardholder information. This includes access by applications, administrators, and all other users.

Powertech Authority Broker for IBM i supports user restrictions to sensitive data, while enabling emergency access with user auditing and reporting.

Powertech Database Monitor for IBM i can monitor data access from any method. Workflow features enable optional filtering of access made by trusted sources.

Powertech Command Security for IBM i restricts the use of database commands.

Powertech Policy Minder for IBM i makes it easy for administrators to identify and correct exceptions to security policy, such as excess access privileges to sensitive databases. 

Requirement 10: Log and monitor all access to network resources and cardholder data.

Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.

Operating system-level security auditing allows you to turn on detailed auditing for system objects, including creation and deletion of the objects. Fortra software simplifies the management and interpretation of these logs through regularly scheduled reporting, allowing audit data to be saved and backed up to central servers.

• IBM i system value settings: QAUDCTL, QAUDLVL, QCRTOBJAUD
• Use the CHGOBJAUD command to turn on auditing for specific files and objects

Powertech Compliance Monitor for IBM i provides comprehensive reporting capability of all audit information on IBM i servers, including events such as:

• Invalid login attempts
• Creation and deletion of objects
• Authorization failures
• System value changes
• Changes to audit settings
• Authority changes to objects

Powertech Database Monitor for IBM i tracks record- and field-level database changes regardless of the source of the change. Detailed logs can be filtered and used to alert on anomalous database activity.

□ Establish a process for linking all access to system components (especially those done with administrative privileges such as root) to an individual user.

Powertech Authority Broker for IBM i enables the elevation of privileges while maintaining a detailed audit log of user activities. Logs are tied to the originating user.

□ Implement automated audit trails to reconstruct the following events for all system components:

□ All individual user accesses to cardholder data.

Powertech Compliance Monitor for IBM i reports on IBM i objects accessed by users, while Exit Point Manager audits network requests.

Powertech Database Monitor for IBM i provides real-time reporting and notification of access to critical files.

□ All actions taken by any individual with root or administrative privileges.

Powertech Authority Broker for IBM i oversees temporary privilege escalation and reporting on user actions. Comprehensive screen capture facility enables visibility into the use of powerful system utilities that IBM i cannot audit— including interactive SQL, DFU, SST, and QSH.

□ Access to all audit trails.

□ Invalid logical access attempts.

□ Use of identification and authentication mechanisms.

□ Initialization of the audit logs.

□ Creation and deletion of system-level objects.

Powertech Compliance Monitor for IBM i includes user-friendly reports that make it easy to track compliance with these requirements.

□ Record at least the following audit trail entries for each event for all system components:

□ User identification

□ Type of event

□ Date and time

□ Success or failure indication

□ Origination of event

□ Identity or name of affected data, system component, or resource

Operating system captures native events with necessary information.

In the QAUDLVL *SECURITY *AUTFAIL values will log changes to user profiles and system values.

Powertech Compliance Monitor for IBM i reports on native events.

Exit Point Manager audits and reports on network-initiated events.

□ Synchronize all critical system clocks and times.

□ Secure audit trails so they cannot be altered, including the following:

□ Limit viewing of audit trails to those with a job-related need.

Powertech Compliance Monitor for IBM i has a comprehensive authority model so that viewing audit trails is limited only to those with a job-related need.

□ Protect audit trail files from unauthorized modifications.

IBM i contains a custom tamper-proof repository, the security audit journal QAUDJRN.

□ Promptly back up audit trail files to a centralized log server or media that is difficult to alter

Powertech Compliance Monitor for IBM i uses an innovative log aggregation approach that backs up log data to a centralized consolidation server where it is stored in a secure database.

Security monitoring solutions like Powertech SIEM Agent for IBM i can send event information in real time to a syslog server where it can be archived along with logs from other enterprise servers.

□ Copy logs for external-facing technologies onto a log server or media on the internal LAN.

□ Use file integrity monitoring/change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

The IBM i security audit journal repository is tamper-proof and cannot be altered.

System value changes on IBM i are also considered when auditors evaluate file integrity monitoring on IBM i.

□ Review logs for all system components at least daily.

Note: Log harvesting, parsing, and alerting tools can be used to achieve compliance with Requirement 10.6, which requires regular review of logs and security events so that anomalies and suspicious activity can be identified.

Compliance Monitor can harvest logs to a centralized repository.

Powertech SIEM Agent can parse the complex IBM i audit journal data into a simple-to-read event, and escalate it to external monitors such as a security information manager (SIM).

□ Retain audit trail history for at least one year, with a minimum of three months immediately available (e.g., online, archived, or restorable).

Powertech Compliance Monitor for IBM i can harvest logs to a centralized repository.

Powertech SIEM Agent for IBM i can parse the complex IBM i audit journal data into a simple-to-read event, and escalate it to external monitors such as a security information manager (SIM).

Requirement 11: Test security of systems and networks regularly

Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and through changes.

While IBM i servers don’t have a published vulnerability list like the Windows and UNIX platforms, Powertech Compliance Monitor for IBM i enables the regular review and assessment of the servers. Compliance Monitor includes a number of reports that users can run on a regular basis to monitor the security settings on their systems. System values are compared against a policy. Compliance Monitor ships with a default policy based on best practices, which companies can customize for their environment and specific systems. Scorecard reports also provide specific metrics that assess the security settings against best practices.

Powertech SIEM Agent for IBM i exports security-related events from the IBM i server to a syslog format that can be read by many security information management solutions.

Powertech Database Monitor for IBM i monitors database access in real time and contains powerful notification features.

OS-level security auditing allows you to turn on detailed auditing for critical files. Compliance Monitor provides for regular auditing and reporting on any activity related to these files.

□ Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis. Typical methods are wireless networks scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.

□ Implement internal and external methodologies for penetration testing. Conduct testing at least annually and verify that exploitable vulnerabilities are corrected.

Fortra offers professional security services, including Penetration Testing. Our team of experienced security consultants can identify IBM i security vulnerabilities, attempt to exploit those vulnerabilities, and deliver a detailed report that explains the risks to data on the system.

□ Use network intrusion detection systems and/or intrusion prevention systems to monitor all traffic at the perimeter of the cardholder data environment, as well as at critical points inside the cardholder data environment, and alert personnel to suspected compromises. IDS/IPS engines, baselines, and signatures must be kept up-to-date.

□ Deploy a change detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files. Configure the software to perform critical file comparisons at least weekly.

Critical files are not necessarily those that contain cardholder data. For file integrity monitoring purposes, critical files are those that do not change regularly, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come preconfigured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the merchant or service provider.

In IBM i, auditing can be turned on for specific objects and user profiles. Compliance Monitor provides full audit reporting over all object access, including object reads, changes, deletes, and moves. The reports can be filtered by objects and users. Database Monitor allows you to perform real-time database monitoring and receive notification of changes to selected fields. IBM’s intrusion detection system defends against network-initiated attacks, and Exit Point Manager manages and audits network access to critical files.

Requirement 12: Support information security with organizational policies and programs

A strong security policy sets the security tone for the whole company, and lets employees know what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.

Fortra recommends that your information security policy should specifically address your IBM i systems. The Compliance Guide included with Powertech Compliance Monitor for IBM i contains a wealth of useful information that provides guidance on creating a security policy for IBM i servers. Compliance Monitor can compare security configuration against an IBM i-specific policy. Fortra also makes available an open source security policy containing baseline security standards that you can use as is, or modify for your organization.