Don’t Look Now, But PCI Just Changed Again

March 8, 2017 Alex Woodie

Heads up, IBM i shops: Companies that process any volume of credit card transactions now must send self-assessments to their acquiring banks under the jurisdiction of the Payment Card Industry’s Data Security Standard (PCI DSS). This is a pretty significant change, as previously only merchants processing large volumes were subject to strict PCI DSS requirements.

On January 31, a new PCI provision went into effect that requires Level 4 merchants to submit a Self-Assessment Questionnaire (SAQ) to their issuing banks. Previously, Level 4 merchants, which are defined as processing 20,000 or fewer ecommerce transactions or 1 million total transactions, were exempt from the SAQ requirement. Companies processing more transactions, defined as Level 1 merchants, have even stricter requirements, including annual audits of computer systems and quarterly network scans.

Even so, the SAQ can institute a considerable burden on IT departments that are already cut to the bone. “The Self-Assessment Questionnaire can be up to 500+ questions and take months to complete,” says Ira Chandler, CTO for Curbstone Corp., a provider of IBM i payment software.  “And, an officer of the Company has to sign an Attestation of Compliance in blood that the SAQ is accurate,” he adds, with some exaggeration.

Visa, the credit card company behind PCI, says small companies are being targeted by cybercriminals. “Based on recent forensic investigations, small merchants remain a target of hackers attempting to compromise payment data,” the company says in a January 2016 security bulletin (pdf). “Additionally, investigators have identified links between improperly installed POS applications and merchant payment data environment breaches.”

Level 4 merchants – which includes any company processing credit card transactions for any reason, not just retailers – faced other PCI changes starting January 31, 2017, including the requirements that they work only with POS application and terminal resellers and integrators who are PCI-certified under its Qualified Integrators and Reseller (QIR) program.

“Using organizations that have completed the PCI SSC QIR training program helps improve security by ensuring that payment applications and terminals are installed and integrated in a manner that mitigates payment data breaches and facilitates a merchant’s PCI DSS compliance,” Visa states in the security brief.

Banks are now warning merchants about changing PCI requirements.

Even if a company isn’t processing credit card transactions using IBM i-based software, the company’s entire IBM i infrastructure can fall within the purview of PCI DSS because of the way the regulation was written, Chandler says.

“If you touch the card data on your workstations that also runs a green screen emulator or web-browser access to your network and IBM i, that puts the entire network in ‘scope’ of the security mandates,” Chandler tells IT Jungle via email. “If it is connected by copper or Wi-Fi, it is included. So even if an IBM i order entry operator keys the card into a bank web site for authorization in a web browser, that workstation is in scope and the rest of the infrastructure is also, including the i.”

Making matters worse is the fact that PCI DSS was largely written from the point of view of an auditor who’s familiar with Windows and Linux systems, not an IBM i system, which has a different security model than Linux and Windows systems and is not always easy to translate. This situation has befuddled the big auditing companies that have been asked to audit the big IBM i shops to some extent, and now that security mismatch is set to play out on the smaller stage.

“The big companies have to have a third party perform the audit, and their familiarity with the i is minimal at best,” Chandler says. “Now that the small companies have to self-audit, they are even less prepared to translate the Windows/Linux-centric security questions into 400-ese.”

For example, the PCI DSS requirements demand that anti-virus software be installed on every system. “You try to explain that we do not even have anti-virus products that run against the Library File System,” Chandler says. “Good luck with that.”

Your entire IBM i infrastructure can come under the scope of PCI DSS if your employees key transaction data via a workstation that’s also connected to IBM i.

IBM i security, if properly implemented, is certainly strong enough to pass PCI requirements, and is even overkill for the requirements, Chandler says. But passing PCI muster isn’t a straightforward deal, owing in part to the centralized nature of the IBM i server.

“In the other [X86] world, they expect to have one box to do each individual chore – database, authentication, front-end, Web presentation, etc.” Chandler says. “On the i, we can do everything on one box and the segregation is not as easily demonstrable as it is with 13 individual $1,200 Linux servers connected with Ethernet.”

Log management adds more challenges. “The reporting required to satisfy the PCI regs would require a 3rd party product, like Townsend’s LogAgent and an external target for that traffic,” Chandler explains. “This requires intimate knowledge of security configuration on the box and even more about how the messages are interpreted by external logging software that looks for anomalies.”

Smaller IBM i shops that struggle with the SAQ may have no choice but to hire a qualified security assessor (QSA) to carry out the self-audit for them. The problem is that this costs additional money (although it generally helps the QSA become familiar with the IBM i, so maybe they’ll accept a discount for on-the-job training).

IBM i shops can escape much of this hassle – and qualify for the less stringent SAQ C-VT questionnaire, which has only 81 questions – if they can prove that their core IBM i server is not in scope of the PCI DSS.

Chandler says the PCI DSS is most concerned with isolating three key pieces of data necessary to process credit card transactions: the card number, the expiration date, and the security code. “If there was a way to eliminate the handling of the three sensitive fields of card data . . . from the workstations and the rest of the existing infrastructure, you could take all of that out of PCI scope,” he says.

Companies can lessen the scope of their PCI requirement by distancing their IBM i server from transactions.

Curbstone recommends that IBM i shops do this by purchasing an inexpensive Android tablet to enter the three key pieces of data on, and hooking it up to a dedicated Wi-Fi router. The challenge is that most IBM i shops processing transactions want to avoid double-keying all the other pieces of data that are required by the issuing bank to get the merchant the best rate on credit card authorization, including amount, invoice number, business unit ID, billing address and zip, tax flag, tax amount, destination zip code, and customer P.O. number.

Curbstone developed a Web portal-based solution that uses REST APIs to suck up all that metadata about the transaction, but leaves the three key pieces of data out of the pipe, and requires the operator to enter them manually on the tablet, thereby taking the IBM i server out of scope for the PCI.

It’s a solution that could work for other Level 4 IBM i shops facing the new PCI DSS requirement that went into effect 36 days ago.

RELATED STORIES

Consider Tokenization to Avoid PCI Stress

PCI 3.0 Gets Positive Initial Reviews from Security Pros

Curbstone Revamps Card Payment Software to Avoid PCI Exposure