Does your company accept credit-card payments? If so, you're responsible for Payment Card Industry (PCI) mandates.

Just because you run the world's most secure and reliable computing platform (the IBM i, System i, iSeries, AS/400), you're not exempt from the requirements of the international security council that dictates merchant security. Although the many best practices we employ on the IBM midrange platform generally keep the system out of the news, you still must be compliant with the industry standards.

We will refrain from listing the recent data breaches, knowing that you're aware of the risk you take when you store cardholder data. So, in this short article, we will address the following questions:

• Who must comply?
• What are the levels of compliance?
• Where are the i-specific resources?
• Is this an ongoing process?
• How do I get started?

Who Must Comply?

If you touch credit card account numbers in any way, you are required to be PCI-compliant. Your other clue is that your organization has a formal "Merchant Agreement" with a bank and an acquirer, a network, or a processor. The federally-chartered bank that is in the background handling your transactions may be hidden by an agreement with an "Independent Sales Organization," many of which specialize in industry verticals. But that bank is there, and it's shouldering the risk of your cardholder data-handling practices. We generally refer to the entity with which you have the agreement as the "acquirer," as it acquires the transactions from you, then acquires the funds from the card-issuing bank of your customer, and finally deposits those funds, minus their fee, into your "merchant depository account."

Regardless of the bank's responsibilities, if you have a Merchant Agreement to allow you to submit card transactions for payment, you are, by the content of the Agreement, responsible to be PCI-compliant. The level of compliance is technically controlled by the acquirer, and you must at least do what they require.

Regrettably, some acquirers require only a bare minimum from their merchants. Since this author is not a lawyer or a PCI Qualified Security Assessor, the following opinions should be validated independently. Suppose a merchant follows only the minimal requirements of the acquirer and suffers a data loss. If they cannot document that they are adhering to the Industry Best Practices, as defined in the PCI Data Security Standard (current Version 3.0), they are certainly ethically negligent. The documents can be found here.

Understand, the PCI Data Security Standard (DSS) is accepted as the definitive best practices documentation and is a shield behind which merchants can defend their IT operations. Were you to attempt to have the standards written for you by an independent security auditor, you would be spending many tens of thousands for something the PCI provides for free. More on that later.

Figure 1: These are the PCI's 12 mandates.

Of particular interest in the table of mandates is number 10, requiring that merchants track and monitor all access to cardholder data. That means that just encrypting the cardholder data is not compliance. This dovetails with the other details not shown in this high-level chart, which require you to monitor the systems that touch the cardholder data.

Additionally, according to the PCI and the banking industry definition, if you "process, store, or transmit" credit card data, you are "in scope" and required to be PCI-compliant. Note the use of the "or." If you do any one or more of the three, you are in scope. And the word "process" refers to the handling, in any fashion, of the card data—meaning if you key it into a green-screen app, if you swipe it into a green-screen Point-of-Sale program, or if you key it into a browser application. All handling of the card data, in any way, is considered "processing."

What Are the Levels of Compliance?

To insure that the PCI has the greatest impact on security in the real world, the organization has targeted the highest-volume merchants with the most stringent requirements. The following table shows the Visa merchant levels that are generally accepted as the governing standard.

¹ - Compromised entities may be escalated at regional discretion 
² – Merchant meeting Level 1 criteria in any Visa country/region that operates in more than one country/region is considered a global Level 1 merchant. Exception may apply to global merchants if no common infrastructure and if Visa data is not aggregated across borders; in such cases merchant validates according to regional levels.

Note that at level 4, the very minimum for any merchant, an Annual Self-Assessment Questionnaire (SAQ) is recommended. Would you want to be standing up in court after a data loss and defending your decision to not perform an Annual SAQ when it is clearly "recommended"? Would it cast doubt on you and your organization that you chose to not adhere to the Industry Best Practices? Do you think you could make a compelling argument that ignoring that recommendation had nothing to do with your data loss?

Where Are the i-Specific Resources?

In the previous topic, we referred to the Annual Self-Assessment Questionnaire. Two authoritative documents are the basis for your compliance effort. They're available here.

• PCI DSS V3.0
• PCI SAQ "D"— The SAQ "D" is provided in a Word doc format so you can fill it in and use it to establish your compliance on the 300+ items it covers.

PCI is smart enough to provide multiple SAQ versions, based on your actual involvement with the card data. The "D" in the second item above indicates an assumption that you touch the card data in a workstation, over your network, and/or on your servers. The full delineation of SAQ appropriateness is available here. Check that document to determine the one that covers your specific card data handling methods. For this article, we will continue with the assumption that you handle the card data in your infrastructure that is connected to the System i.

Now, to the meat of the issue. If you completely read the documents from the PCI, you will find them surprisingly PC-centric. Yes, most of the world is grappling with security on the insanely insecure Windows, and many are on the only incrementally more secure Linux. Luckily, we are on a "real" computer. However, in our experience, we find that many iSeries/System i/IBM i shops don't take full advantage of the security that runs in the veins of our fabled platform.

Often, very basic rules of PCI DSS are violated in common practice. If you think that merely encrypting a card number in your Order Entry system is adequate, think again. Using a group UserID is prohibited, for instance. Password security must be enforced, and periodic change enforced. In fact, there are so many things we could write a book about it. But, why reinvent the wheel? Luckily, Carol Woodbury, one of the original architects of security in i5/OS, actually did write a book about it. Our company has incorporated it into our formal "PCI Implementation Documentation" and included a copy with every purchase of our software. This document, incorporating her book, has been approved by multiple QSAs over the course of our nine years of distributing a secure credit card application.

In this wonderful book are many specific tips to implement to bring you up to Carol Woodbury's "Best Practices" standards. She even provides the rationale as to why to do it and what the considerations are.

Figure 2: This is the industry's best book on i security.

One area that receives way too little discussion is monitoring. The PCI DSS is very clear that we need to not only secure the systems, but also monitor them and then review the monitoring for anomalies daily. Most people fail to perform that part of the process. PCI says that a monitoring system that can detect anomalies is no good unless some human actually reviews the results. Read about the Target breach for a textbook example of this failure. Just having stuff reported to SNMP, SYSLOG, QSYSOPR MSGQ, or elsewhere is not enough.

Luckily, several companies have risen to the challenge and provide excellent monitoring tools that report exceptions. This is a key element of your PCI security strategy. Following are a few of the excellent products available for the task of monitoring and reporting.

Monitoring and Reporting Products

• Arpeggio Software
• bSafe
• Cilasoft
• Enforcive
• HelpSystems/Halcyon Software
• HelpSystems/Powertech
• HelpSystems/Safestone
• KDP Software
• Kisco
• ManageEngine
• NetIQ
• Raz-Lee
• Software Engineering of America (SEA)

To complete this abbreviated list of applications, we want to point out two that are not IBM i-specific, but they're so valuable that they deserve consideration. Splunk and LogRhythm are two analysis tools that allow you to extract meaningful exception reports from huge volumes of otherwise indecipherable data. This means that if your enterprise contains many systems of different platforms, all within PCI scope, let's say, and they all generate monitoring data in different forms (SYSLOG, SNMP, etc.), you can consolidate that data into one system and generate valuable reports. These reports can even contain exception reporting that was automatically identified by the software. These software programs can learn what good data looks like and automatically notify you of data or activity out of the ordinary.

• Splunk—Here's a brief.
• LogRhythm—Here's a brief.

Other i-specific Resources

• Patrick Botz
• Cyberinsurance informative article
• Free, valuable Woodbury webinars

Is This an Ongoing Process?

Yes, just like painting the Golden Gate Bridge. No, they do not paint the bridge from one end to the other and then start again. They use a three-step process to maintain the bridge. They assess the areas that are in need of paint, they remediate the damage with a team of 34 painters applying 10–30,000 gallons of paint, and then they report on what has been completed. The bridge has been painted completely only three times—in 1937 (when built), in 1965, and in the 1980s.

Figure 3: PCI's Continuous Process

And, surprisingly, the PCI specifies the same three-step process.

1. Assess — identifying all locations of cardholder data, taking an inventory of your IT assets and business processes for payment card processing and analyzing them for vulnerabilities that could expose cardholder data.
2. Remediate— fixing identified vulnerabilities, securely removing any unnecessary cardholder data storage, and implementing secure business processes.
3. Report — documenting assessment and remediation details, and submitting compliance reports to the acquiring bank and card brands you do business with.

Once you engage in the process of securing, you will see it requires ongoing work. For instance, on a non-i topic, each piece of hardware in your organization is required to run the latest firmware, and that constant updating must be performed and documented. That is just one great example of the ongoing process. In "i" terms, this could refer to the requirement to keep your operating system up to date by applying PTFs as they are released by IBM. This process must be documented as to who does it, when, and what was updated. Obviously, the initial step is critical, to assess the need to update, based on maintaining a constant awareness of what is available from IBM FixCentral.

How Do I Get Started?

Once you have been sufficiently overwhelmed by the depth and breadth of the SAQ and resolved that there's not enough time in the day/week/year/career to complete it, take comfort in the PCI "Prioritized Approach." That's covered in these two documents:

• Prioritized Approach: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
• Prioritized Approach Tool V3.0: https://www.pcisecuritystandards.org/documents/Prioritized_Approach_v3.xlsx

These two fantastic offerings will guide you through the process of completing the SAQ and generally becoming PCI DSS 3.0 compliant with an emphasis on the tasks that yield the greatest security the fastest. Thank you, PCI.

Reference Materials

• PCI Security Standards Council is the definitive source for up-to-date information on PCI compliance from the source. Formed by the major payment brands to develop standards and guidelines, the Council publishes a wealth of information on the site. This should be considered the authoritative source on any PCI Compliance issues.
• Wikipedia offers a good high-level introduction to the topic of PCI compliance, with substantial background material available through related links and cited references.
• PCI Compliance Guide is an educational site provided by a security software company focused on articles and discussion on PCI compliance issues. While not as authoritative, information on the site is easily comprehensible and accessible.
• Visa Cardholder Information Security Program describes the specific implementation of PCI guidelines mandated by Visa, including current status of the compliance program, deadlines, penalties, and additional reference materials.
• Data Security Webinar: PABP Overview, Tom Pageler, VISA, January 31, 2007
• PCI - The DSS Standard
• PCI Supporting Documents
• PCI Approved Assessors and Scanning Vendors
• PCI Navigating the DSS Standard
• PCI Self-Assessment Questionnaire
• PCI Glossary
• PCI Approved QSAs
• Carol Woodbury IBM i Security book

­