Don’t take the requirements lightly; the cost of non-compliance could be very steep.

Acceptance of debit and credit cards is a growing requirement for businesses of all sizes. Since 2005, the Payment Card Industry Security Standards Council (PCI) has imposed strict mandates, the Data Security Standards (DSS), to ensure the security of the computer systems that process, transmit, and/or store sensitive credit card data.

Every business that accepts card data in any way is subject to the requirements of the PCI DSS, and the compliance requirements vary widely based on transaction volume, type of business, handling of the card data, and software applications. At the top end, a company could be required to have a third-party Qualified Security Auditor (QSA) who has been certified by the PCI to perform an on-site, extensive analysis of a merchant's operations and systems.

Meeting these ever-intensifying PCI DSS mandates poses unique challenges to companies whose main business system is the IBM i (AS/400, System i, iSeries).

Some aspects of compliance are as simple as never storing magnetic stripe data or the card security code. Others are time-consuming, such as documenting every piece of infrastructure hardware, its firmware revision, and last update, and monitoring the logs of all systems on a periodic basis.

10 Revealing Payment/Order Application Questions

1. Is your payment app validated to the Payment Application Data Security Standard (PA-DSS)?
2. Is a specific person assigned responsibility for handling all of the security compliance?
3. Does your payment app not store magnetic stripe data (track data) or PIN blocks? This storage is strictly prohibited!
4. Does it store primary account numbers (PANs) with strong encryption protection and have all access logged in files that are periodically reviewed and unable to be altered?
5. Does it use a firewall with Stateful Packet Inspection to specifically protect your systems from unauthorized access? Are the logs from the firewall monitored periodically?
6. Does every person have their own unique User ID? Are complex, strong, and unique passwords required to access your systems? Are those passwords forced to be changed periodically?
7. Have all system and software default settings and passwords been changed? And are those changes recorded in a permanent log?
8. Have all unnecessary and insecure services been removed from these systems? Have those changes been logged as they are performed?
9. Have all the systems been patched with all applicable security updates? Is every device in your system being maintained with the latest firmware updates? Are the updates logged as they are performed?
10. Have you provided physical security for the systems and other devices that handle card info, including even fax machines?

If you answered "no" to any of these, you are likely in violation of the PCI DSS! These 10 questions only address two handfuls of the ~270 questions contained in the PCI Self-Assessment Questionnaire Level "D."

The Players

The term "merchant" typically describes the business selling a product or service and accepting cards as payment. If your company accepts debit or credit cards as payment, you are the merchant!

An "acquirer" is the entity that initiates and maintains relationships with merchants for the acceptance of payment cards. They are also referred to as "acquiring bank" or "acquiring financial institution." An acquirer is a federally chartered banking organization that may or may not have brick and mortar branches. Acquirers range from your local corner bank to huge organizations that do nothing but acquire, like TSYS, First Data, or Paymentech. These banks may be aligned with a well-known retail bank, like Paymentech with Chase, or be independent like TSYS.

These are the major acquirers in the U.S.:

• First Data Corporation (First Data Merchant Services, or FDMS) includes CardService International, Wells Fargo, PNC Merchant Services, SunTrust Merchant Services, and Citi Merchant Services
• Chase Paymentech (Chase Merchant Services, or CMS)
• Bank of America Merchant Services (BAMS)
• American Express (through their Centurion Bank)
• Fifth Third Bank
• Heartland Payment Systems
• First national Merchant Solutions (FNMS)
• Elavon/NOVA
• Global Payments

This short list accounts for about 90% of all the card transactions in the U.S. The rest of the acquirers are small, very specialized organizations. Many of the small neighborhood banks resell the acquirer services from these Tier 1 acquirers, though that may not be made clear to the merchant.

Many companies that are not officially banking organizations specialize in vertical markets, such as education or restaurants. They will resell a major acquirer's services to their verticals. These companies are called Independent Sales Organizations (ISOs). You may have a Merchant Agreement with a company that is not on the list above. If that's the case, they are most likely a reseller (ISO) for the services of the Tier 1 Acquirers in the list above.

The acquirer, large or small, is responsible for handling collection of the payments for all bankcard transactions the merchant processes. Acquirers perform the collection after the merchant "settles" its daily batch through the authorization network, and ensures that the collected money is deposited in the merchant's "deposit account." That deposit account, which is a working bank account of the company, can be in the same bank as the acquirer, or in any other bank.

The per-transaction fee that the acquirer receives for its services is always proportional to the amount of perceived risk taken in handling the transactions for a particular business.

The acquirer establishes and maintains merchant relationships by "boarding merchants," resulting in a formal "Merchant Agreement." The Merchant Agreement is the authoritative document as to any merchant processing card payments; it also covers the merchant's responsibility to adhere to the PCI Security Standards to the satisfaction of the acquirer.

Figure 1: Chain of Enforcement of PCI Standards

The merchant agreement stipulates that the merchant adhere to the current security standards outlined by the credit card companies. If the merchant loses data and is found to not adhere to these standards, the merchant is liable to the card organizations for possible huge fines.

As Visa Threatens…

Here is an excerpt of the security regulations from Visa: "Members (merchants) receive protection from fines for merchants or service providers that have been compromised but found to be [security standards]-compliant at the time of the security breach… Members are subject to fines, up to $500,000 per incident, for any merchant or service provider that is compromised and not CISP-compliant at the time of the incident."

That's right; the fine can be up to half a million dollars per incident!

Merchants must immediately notify the acquirer if they lose data. If a merchant fails to immediately notify Visa USA Fraud Control of the suspected or confirmed loss or theft of any Visa transaction information, the member will be subject to a penalty of $100,000 per incident. This applies to all other card brands, also.

Beyond that, a merchant could also be held responsible for the card re-issuance costs incurred by the card-issuing banks involved. For every compromised card number, a new physical card must be issued to the cardholder. The bank issuing the new card can take the merchant to court to recover those costs; in fact, a nine-figure lawsuit was threatened against a large multi-store retailer for precisely these costs.

The acquirer provides the communications services (either directly or through a subcontractor) for the merchant to obtain real-time card authorizations and deliver end-of-day settlements. Some acquirers, such as Paymentech, also own "authorization networks," while some use a dedicated independent authorization network, like TSYS (aka Vital, aka VisaNet). The services of the communication network (authorization network) are paid transparently by the acquirer as part of the merchant fees.

PCI Mandates

In 1999, Visa USA realized that the proliferation of businesses that use computers, take orders, and store card information presented a great risk to cardholders. Visa hired security consultants to develop a "best practices" document as a guideline for businesses that store credit card information.

On December 14, 2004, Payment Card Industry (PCI) heavyweights American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. together empowered the Payment Card Industry Security Standards Council with the authority to manage payment industry best practices. The Council maintains, evolves, and promotes the Payment Card Industry security standards. It also provides critical tools needed for implementation of the standards, such as assessment and scanning guidelines, a series of Self-Assessment Questionnaires for various categories of merchants, training and education, and product certification programs.

The resulting Payment Card Industry Data Security Standard (PCI DSS) is at Revision 3.0; it is the industry's definitive source of guidance for merchants fulfilling their mandate to secure their credit card information.

Security Breach Enforcement

The PCI DSS is not a legislative law enforced by government. The enforcement of the standard is by the major payment brands (Visa, MC, AmEx, Discover) through fines, sanctions, and more. The goal is to make non-compliance an unacceptable risk to merchants. Possibly the greatest liability of non-compliance is the consequential damages paid to the banks that issued cards to the merchant's customers by non-compliant merchants that suffer a breach. If a security breach exposes card numbers, the issuing bank must issue new cards to its customers, at great expense. In the case of TJX (T.J. Maxx Companies), the company was considered liable for about $120 million in card re-issuance costs. That did not include the fines and penalties from the card organizations, which were also substantial. All of these penalties are enforced based on the terms of the merchant agreement with the acquirer. Read yours!

PCI Standards Enforcement

The banks that sign up merchants for processing accounts are now requiring varying levels of proof that the merchant's systems and applications are validated against the PCI DSS standard. For those merchants with substantial quantities of card processing, the standards must be evaluated, on premises, by certified, independent Qualified Security Auditors (QSAs) and must be re-validated annually. A list of QSAs is available at the PCI site.

To most effectively enforce the new regulations, the standards were first most rigorously enforced toward the merchants that processed the most transactions. In recent years, those standards have been applied to progressively smaller merchants.

Figure 2: Merchant Activities Within the Scope of PCI Standards

Examples of infrastructure that should be considered "in scope":

Store: Retain cardholder data (in any way) in non-volatile storage

• Write data to disk in physical files
• Write data to disk IFS root file system files

Process: Handle cardholder data (in any way) in volatile storage

• Accept keyed card data into a screen on any workstation
• Accept swiped mag stripe data into a screen on any workstation
• Accept card data in a browser screen generated by your software/server

Transmit: Send cardholder data from any system to any other

• Send cardholder data from an e-commerce server to your IBM i
• Send data from any workstation to your IBM i
• Send data to an authorization network for validation

If you do any of these, all of your infrastructure systems are "in PCI scope."

Scope can be narrowed with the use of network segmentation, which isolates the cardholder data environment from the remainder of an entity's network. Narrowing of scope can lower the cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS controls, and reduce risk for the entity. Realize that the PCI segmentation suggestions assume a Windows or Linux environment, not a fully-integrated System i. For more information on scoping, see PCI DSS Appendix D: Segmentation and Sampling of Business Facilities/System Components.

Why Comply with PCI Security Standards?

Why should you, as a merchant, comply with the PCI Security Standards? At first glance, especially if you are a smaller organization, it may seem like a lot of effort, and confusing to boot. But not only is compliance becoming increasingly important, it may not be the headache you expected.

Compliance with data security standards can bring major benefits to businesses of all sizes.

Compliance with the PCI DSS means that your systems are secure, and customers can trust you with their sensitive payment card information:

• Trust means your customers have confidence in doing business with you.
• Confident customers are more likely to be repeat customers and to recommend you to others.

Compliance improves your reputation with acquirers and payment brands—the partners you need in order to do business.

Compliance is an ongoing process, not a one-time event. It helps prevent security breaches and theft of payment card data, not just today, but in the future:

• As data compromise becomes ever more sophisticated, it becomes ever more difficult for an individual merchant to stay ahead of the threats.
• The PCI Security Standards Council is constantly working to monitor threats and improve the industry's means of dealing with them through enhancements to PCI Security Standards and by the training of security professionals.
• When you stay compliant, you are part of the solution—a united, global response to fighting payment card data compromise.

Compliance has indirect benefits as well:

• Efforts to comply with PCI Security Standards will better prepare you to comply with other regulations, such as HIPAA, SOX, etc.
• You'll have a basis for a corporate security strategy.
• You will likely identify ways to improve the efficiency of your IT infrastructure.

But if you are not compliant, it could be disastrous for your company and for those entrusted, directly or indirectly, with risk management:

• Compromised data negatively affects consumers, merchants, and financial institutions.
• Just one incident can severely damage your reputation and your ability to conduct business effectively, far into the future.
• Account data breaches can lead to catastrophic loss of sales, relationships. and standing in your community, and depressed share price if yours is a public company.

Possible expensive, negative consequences also include these:

• Lawsuits
• Insurance claims
• Reputational damage
• Cancelled accounts
• Payment card issuer fines
• Government fines

Intrusion/Penetration Scans: Not PCI Compliance

Since it is an acquiring bank with which you have a Merchant Agreement that is responsible for ensuring your PCI compliance, they typically are only capable of the most cursory understanding of the PCI requirements. They are a bank, not a trained security auditor. The limited extent of their security understanding is illustrated by their, typically, sole requirement for the merchant to perform periodic intrusion scans, usually with a vendor from which the bank receives a commission on the monthly or quarterly service. This may be the sole commitment that the bank asks of the merchant, and if it is, it says far more about the bank's lack of understanding of PCI than the fulfillment of the requirement says about the merchant. Possibly, it is financially preferable to shoulder the costs of poor security and increase the merchant fees than it is to train bank/acquirer employees how to enforce PCI mandates.

Yes, intrusion scanning is one small component of PCI compliance; it satisfies only one section of the PCI DSS: Section 11.2.

PCI DSS 11.2 requires a merchant to run internal and external network vulnerability scans at least quarterly and after any significant change in the network. After passing a scan for initial PCI DSS compliance, an entity must, in subsequent years, pass four consecutive quarterly scans as a requirement for compliance. Quarterly external scans must be performed by an Approved Scanning Vendor (ASV). Scans conducted after network changes may be performed by internal staff.

What about the other 270+ sections?

To be candid, if your bank asks you only for an intrusion scan to satisfy their PCI requirements, they are doing you no favor. Such a demand is a fig leaf that protects neither the merchant nor the bank in any meaningful way. It should cause serious consideration on your part. Read on for a summary of what you need to know.

PCI Documents

Fortunately, the PCI has provided free tools to assist in implementing security enhancements to establish a credit card security baseline. Their superb "best practices" documents are free to the public and have the official PCI stamp of approval. No need exists for you to hire an expensive security consultant and pay for the creation of a set of security guidelines.

If you were to hire a qualified security auditor to create a comprehensive set of "best practices" security standards for your organization, how much would you expect to pay?

Figure 3: Comprehensive Library of Valuable PCI-Provided Documents

Let's say those standards included a comprehensive IT plan, as well as operational guidance for all aspects of the business that are related to the handling of credit cards. Such a service could easily cost $50,000 or more. The PCI provides all of this, and more, for free. Download it here.

PCI Data Security Standard

In a valuable effort to set minimum guidelines for enterprise security, the PCI identified a dozen areas of concern, grouped into six general headings.

Figure 4: The Twelve Commandments of PCI DSS

Guidelines for Cardholder Data Elements

Figure 5: Protection of Card Data Elements

Once you meet the minimum requirements outlined in the PCI documents, you can be comfortable that you have created the proper security environment and that your company will not be held liable for non-compliance, should a security breach occur.

Typical PCI DSS Failures

Figure 6: Few Merchants Are 100% Compliant. PCI Is a Process.

Source: Forrester Consulting: The State of PCI Compliance (commissioned by RSA/EMC)

Figure 7: Risky Business: Violations of Storage Restrictions Are Common.

PCI-DSS for Merchants

The Payment Card Industry's definition of a "merchant" is:

For the purposes of the PCI Data Security Standards (DSS), a merchant is defined as any entity that accepts payment cards bearing the logos of any of the original five members of PCI Security Standards Council (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services....

The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.

Merchant PCI Reporting "Levels"

In addition to adhering to the PCI Data Security Standard, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants.

Figure 8: Visa defines "Merchant Levels" based on transaction volume.

Obtained March 25, 2014: http://usa.visa.com/merchants/risk_management/cisp_merchants.html

"SAQ" It to Me

The PCI publishes a series of Self Assessment Questionnaires (SAQs) that provide a comprehensive analysis tool to document merchant compliance. This is a set of five validation tools intended to assist merchants and service providers in self-evaluating their compliance with the Payment Card Industry Data Security Standard (PCI DSS). The multiple versions of the PCI DSS SAQ vary to meet the needs and characteristics of all merchants, depending on how they make use of credit cards.

The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions. In order to align more closely with merchants and their compliance validation process, the SAQs provide flexibility based on the complexity of particular merchant environments (see chart below). The PCI DSS Self-Assessment Questionnaire Guidelines and Instructions document provides more details on each SAQ type (see www.pcisecuritystandards.org).

Figure 9: The Five Flavors of SAQ

The most commonly used SAQ for most merchants who are using the IBM midrange platform is the SAQ-D. This is because the merchant is typically accepting cardholder data into screens on workstations or browsers that are served by the AS/400, System i, iSeries, IBM i, or the web server. In addition, that data is typically saved in either volatile or non-volatile storage, and sent to other systems. This is a match for the three criteria for being "in scope”, to "store, process, or transmit" cardholder data.

The goal of this document is to help you to clarify the scope for which you qualify and to suggest ways to decrease that scope. This in turn will assist you in reducing, perhaps dramatically, the effort and the costs required to establish, maintain, and document PCI compliance. While network segmentation can reduce PCI scope, more-flexible and more-effective methods must be implemented to reduce efforts and resulting costs to the absolute minimum.

The "for i" Section

So far, we have covered the requirements of the PCI Security Standards. Now we can address some of the issues specific to the IBM i. If you were to read the entire library of PCI documents, you would see that it is decidedly PC-centric. Over and over, they refer to the use of individual PCs (systems/servers) to have individual tasks, like one for web server, one for database, one for payment application, one more for order entry. And further, they assume that the link between all of these systems is TCP/IP and that the liberal use of routers and firewalls with Access Control Lists (ACLs) can provide the segregation that they require between the various components.

One of the best features of a PC-based architecture is that you can just add another little server to the system to expand what you are doing. One of the biggest curses of a PC-based architecture is that you can just add another little server to the system to expand what you are doing.

Figure 10: Typical PC-Based Orientation in PCI Concepts

Every server added is a huge management responsibility, and if you are using Windows, heaven forbid, you have that additional issue of virus protection, constant updates, and stability.

We all know better. One central machine with all of the abilities built in to the operating system is superior and much easier to manage.

Figure 11: IBM Midrange Incorporates All Servers Internally

The biggest benefit of the IBM midrange is that all of the components are fully integrated to the IBM i operating system. The biggest challenge of the IBM Midrange is that all of the components are fully integrated to IBM i operating system.

How do you accommodate the perceived request from PCI for a firewall between each functional component when all of the components are built into the operating system? How do you provide the ACL to control access between components that do not use TCP/IP to communicate?

Authoritative Security Book

For an in-depth dissertation on this subject, we suggest you and your administrators study the comprehensive book by Carol Woodbury. The author's company provides a copy of this book to all of their customers as an integral part of the mandated "PCI Implementation Guide" that is audited by their QSA.

Figure 12: The Industry's Best Book on Security

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
• The DSS Standard
• Supporting Documents
• Approved Assessors and Scanning Vendors
• Navigating the DSS Standard
• Self-Assessment Questionnaire
• Glossary
• Approved QSAs

­

Ira Chandler is the founder of Curbstone Corporation and has been programming communications software since 1981. Ira wrote the first commercial credit card processing software for the IBM AS/400 in 1993.

 

Currently, more than 300 companies, universities, and government entities have selected the IBM i operating system and Curbstone Card, Ira's company's PCI-security-validated payment server, including MIT, Harvard, WW Norton Publishing, Fisher Scientific, Campbell Hausfeld, Sunbelt Rentals, AdoramaCamera.com, Penn State University, Beneteau Yachts, Hornady, and the U.S. Space & Rocket Center.

 

While Curbstone software is primarily written in RPGLE, Curbstone was the first to publish a commercial PHP application for the System i, the Shopping Cart Pipeline, and remains committed to the PHP language.

 

Ira Chandler can be contacted at 888-844-8533 or This email address is being protected from spambots. You need JavaScript enabled to view it. (Curbstone.com).

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR