A Canadian merchant wrote in to ask:

We are looking at integrating with Moneris for payment processing. Moneris would have a DLL on the merchant computer.

We would pass the amount of the transaction to the Moneris DLL. The DLL would communicate with the pinpad to get the cardholder data and pass up to the processor (Moneris). Once the transaction has been approved we would get a message back from the DLL indicating success or failure. At no point in the process do we ever see cardholder data.

Why does the merchant need to pass the PCI DSS? The payment provider is the only code that ever touches the cardholder data.

Well, in addition to posting this to the forum, where you could get everyone’s opinion… here’s mine. The reason you need to be PCI DSS compliant is because you “store, process, or transmit” cardholder data. Remember that compliance and validation are different.

The rules state ’store, transmit, or processes’ but more importantly, even if a company does store, transmit, or process they are required to comply and not to validate unless they fall into the validation scope. As a Level 4b merchant you are not required to validate in Canada and certainly not required to complete an SAQ.  Check out the validation rules as posted on the Visa Canada website.

Popularity: 26% [?]

So you might have read the recent Visa (USA) timeline for migrating to more secure point-of-sale (POS) technology. Or maybe you are looking at your aging systems and wanting to take the plunge and upgrade to a sexier, and more secure, system.

Here are a few things to consider before taking out the check book and laying new infrastructure.

1. Ask your acquiring bank if your prospective POS is a known vulnerable payment application. As the deadlines loom for payment application security some vendors may be looking to exploit a loophole in the system. You may notice that in 2008 companies cannot board new merchants using known vulnerable payment applications, so some of them may try to offload that technology before the end of 2007. The kicker being that in 2009 those companies may have to upgrade again to remove those known vulnerable systems. (More importantly, you may be installing a system known to make your environment non-PCI compliant.)
2. Confirm that your prospective POS vendor and version number is listed as a validated payment application. Visa publicizes a list of validated payment applications. If the integrated POS (IPOS) is not on that list — caveat emptor — regardless of what the vendor may tell you to the contrary. (This process is to be taken over by the PCI SSC in the coming years [PDF].)
3. Ask your payment application vendor or reseller for the Implementation Guide (or Implementation Documentation).  So you purchased and installed a validated payment application — you may be safe and you may not.  Each validated payment application comes with an instruction manual for configuring that app in a secure manner.  Without this Rosetta stone you may be living in a false sense of security.  It is a requirement that vendors and resellers provide this to you and educate you about it, but sometimes these things are overlooked.  Make sure you read and understand this document.
4. Encrypt data from the POS to the back-end systems.  Even though the payment application may be securing the data on the system itself, many are still transmitting the track data across the network to the back-end systems for authorization.  It is not a PCI requirement to encrypt this data, but recent compromises have shown that hackers are using technologies such as MPACK to sniff track data from the POS to the back-end systems.  Choosing a POS that has the ability to encrypt this data puts you one step ahead of the hacker.
5. Keep your POS network (and retail systems) segmented from the rest of the network (and from the Internet).  Network segmentation sounds like a monolithic task for some companies, but I’m only going to discuss two types here: segmenting one store from another, and within each store the cardholder data from all other systems.  It is well known that if you have stores directly connected to the Internet instead of a totally private network then you are a higher risk for compromise.  Also, if an attacker can compromise the wireless in-store network you want to make sure they cannot use that vulnerability to compromise cardholder data or any other retail store.

Knowing how the attacker thinks will help in defending against their most common attacks.  There is no way to have zero risk but we can limit it enough to have the hacker go elsewhere.

Know their weak points in the same way they know yours.

Popularity: 52% [?]

I just got back from speaking at the American Petroleum Industry’s IT Security Conference in Houston, TX. I presented on the impact of PCI on the petroleum industry and the main focus was on the point of sale (POS) environment.

You may or may not know but many of the petrol stations (gas stations) are independently owned and operated. This would seemingly reduce the risk for large organizations as they do not have to worry about the security of such small operations that have independent processing agreements with their banks.

The problem with this is two fold:

1. To ignore franchise operations is to ignore the potential brand damage when one of them is compromised.  When a small 3 location chain of petrol stations is compromised you can be sure that the New York Times and Wall Street Journal will carry the name of the parent company as the victim.
2. Potentially more important is the message the parent company sends to the franchise operations when influencing their operational processes. If the parent company even recommends a POS platform that does not securely store and manage credit card data they could be liable if the merchant is compromised.  This issue exists for any recommendation passed down from the parent company to the franchise operation.  Most companies that operate in this manner should consult their acquirer and the list of validated payment applications and notify their franchise operations accordingly.

Popularity: 42% [?]

In early September the PCI SSC added the PIN Entry Device (PED) standard to its dossier of oversight items. Then at the end of September they announced the success of the first ever Community Meeting for Participating Organizations.

Now in early November they start the transition of the Payment Application Best Practices (PABP) from Visa and rename it the Payment Application Data Security Standard (PA-DSS). This follows the heals of the recently released Visa Payment Application Security Mandates.

It is important to focus on this area as it shows a strong push towards the security of smaller merchants (i.e. Level 2-4). It is widely known that many small merchant use similar point of sale (POS) technology and that the greatest risk to those merchants is from the compromise of those systems that store sensitive authentication information.

By turning the best practice document into a standard and then enforcing it with hard deadlines for compliance, the industry is delivering a 1-2 punch to the insecure systems and helping eliminate fraud in the smaller merchant arena.

Popularity: 58% [?]

Someone wrote in to ask about a small merchant who uses a stand alone hardware terminal (i.e. EFTPOS machine) to accept credit card transactions.  This is not an IPOS (integrated point of sale) but simply a terminal that has dial-out only, via a dedicated phone line, to the merchant bank.

In this case, does the merchant have to be PCI compliant and what do they need to focus on?

The answer is, YES they need to be PCI compliant because they accept credit cards, but because their scope is so small they may only need to focus on a select number of areas:

• Are paper receipts ever printed with the full credit card number (PAN)?  If so, these need to be protected as per PCI DSS 9.6 and 9.10.
• Is your EFTPOS on the list of approved PIN entry devices?
• Do you accept credit cards through any other channels? (i.e. e-commerce, mail order, telephone order, etc.)

In any event, it can never hurt to read through the Self-Assessment Questionnaire and make sure all of your bases are covered.

Popularity: 32% [?]

These days many large (Level 1) and medium sized (Level 2) merchants are working towards compliance deadlines, but so are the smaller (Level 4) merchants for reasons of security. Probably one of the most critical things to the security of a Level 4 merchant is the security of their point-of-sale (POS) environment. To address this we would like to remind you of several facts relating to the Payment Application Best Practices (PABP).

The PABP is a qualification, much like the PCI DSS, but structured for payment applications. Hap Huynh, of Visa, noted that in April 2007 155 products across 80 vendors have been validated by qualified assessors. Hap was speaking at CardTech SecurTech 2007 when he said, many more applications are in the process of being reviewed for PABP and two major payment processors require that merchants use validated payment applications.

Here’s some more information about the PABP so you can better prepare your company to implement a secure POS or other payment system:

• Currently, the PABP is managed by each Visa region independently. To find a list of qualified payment applications in your area please see the lists: Visa USA, Visa Europe, and other Visa regions.
• The current version of the standard can be found here.
• If you have a POS that you purchased, you should not perform the validation. Instead you should have your software vendor perform the review and verify their application meets these industry accepted standards.
• If you purchased your application through a reseller or directly and your application is already on the list of validated systems, make sure they gave you a copy of the “implementation documentation”. This is a document that tells you how to implement the application in a PCI compliant manner.

If you are uncertain about any of this, be sure to ask your acquirer, gateway, or IT person to help explain more. Ask them some or all of the following questions:

• Does my POS enable me to be PCI compliant?
• Does my POS remove ’sensitive authentication data’ (track data, PIN block data, or CVV2 data)?
• Does my POS encrypt credit card data?

The answer to all three should be ‘YES’!

Popularity: 36% [?]

According to Digital Transaction News, Visa USA is ready to introduce account-level processing (ALP).

“Visa claims ALP will allow smoother transitions to new cards for cardholders, and will let merchants, in partnership with issuers, design more effective rewards programs.”

Sounds good so far, but wait there is more.

“The key change is the switch from managing transactions through the six-digit bank identification number (BIN) within a card’s 16-digit number and instead using the full account number.”

Wait a minute, did we read that right? Did they say what we thought they said? Yes they did. To paraphrase, the key change is the switch from using the six-digit BIN (3.3 compliant) and instead using the full PAN. This will just add fuel to the fire over storing the full PAN.

And it just keeps getting better.

“The new process affecting Visa-branded consumer cards will allow a credit cardholder to keep the same account number even if his issuer upgrades his card”

Yes, that is right, not only do we now encourage storing the PAN, but we are going to allow the PAN to remain the same even when the card changes. This just sounds like a way to generate even more replacement card numbers.

Does anyone think that encryption will not be critical to managing this situation? How many organizations are handling encryption properly right now? Some, but not enough. Think this will just make things worse? Probably, at least in the near term. Think the “bad guys” will take advantage of this new capability? Without a doubt.

The article goes on to say that this new approach will likely cause merchants a POS software upgrade headache to support ALP. POS software will have to be able to insert a field code, known as 62.23, in the authorization message. This field code will be a single alphabetic code that indicates the card product that was presented for the transaction.

As of October 2007, Visa will require all acquirers to be able to receive the new field code in the authorization message. Acquirers will use the code to determine the correct interchange, chargeback rights and other characteristics such as loyalty points to be accrued for each individual transaction.

Popularity: 61% [?]

Shift4 corporation has made a bold move of providing merchants an alternative approach to POS compliance.  They independently developed a driver for the MICROS POS system, widely used in restaurants, that allows the retail merchant to obtain compliance without a forklift upgrade to their POS software.

I would normally not mention a vendor press release but this is a bold move in that:

1. It allows the merchant another option instead of just petitioning their POS vendor to make a PABP compliant version of their POS application.
2. It introduces their ‘tokenization’ system for handling credit card data meaning that the merchant does not need to worry about securing their data, because it is not actual credit card numbers but a reference number.
3. Did I mention you would not have to upgrade your POS software??

Sure, this does require installing the driver, but it’s free.  And you would have to use the $$$ ON THE NET gateway, but it provides tokenization, so that feature alone might make it worth it.

“Compared with purchasing a complete POS system upgrade and related hardware, the solution from Shift4 is a fraction of the cost,” stated John Mann, Shift4 Vice President of Sales. “For example, when one new client was
faced with a proposal to upgrade his POS system for approximately $33,000, he chose to go with Shift4’s solution at a cost of $1,400. He told us, ‘Shift4 did exactly what MICROS would not,’” Mann added.

This unique driver uses Tokenization technology (invented by Shift4), which replaces the credit card number with a randomly generated unique ID. In the event of loss or a breach, Tokens are of no commercial value. As a result, any such breach may not need to be reported, as no loss of cardholder data would occur.

The driver is being offered for the following MICROS POS systems:

• 3700 version 3.1, 3.2 and higher
• RES 3000 version 4.0 - 4.1
• 8700 version 2.11 - 2.7
• 9700 2.11 - 2.80*, 3.0 and higher (* Currently undergoing PABP validation)

Popularity: 36% [?]

The new sites have been awash this week with reports (here, there, and everywhere) on how the TJ Maxx credit card compromise is shaping up to be the worst ever - just tipping the scales on the CardSystems compromise from a few years ago.

The SEC filing that has inspired these articles has some interesting information on the compromise. Searching for “COMPUTER INTRUSION” will get you to the section that talks about the events prior, during, and subsequent to the event. Quotes that stand out to me (all emphasis is mine):

“We do not believe that customer personal identification numbers (PINs) were compromised, because, before storage on the Framingham system, they are separately encrypted in U.S., Puerto Rican and Canadian stores at the PIN pad“

“For transactions after April 7, 2004 our Framingham system also generally began encrypting (meaning substituted characters for the actual characters using an encryption algorithm provided by our software vendor) all payment card and check transaction information.”

“Further, we believe that the Intruder had access to the decryption tool for the encryption software utilized by TJX.”

“Losses that we may incur as a result of the Computer Intrusion include losses arising out of claims by payment card associations and banks, customers, shareholders, governmental entities and others; technical, legal, computer systems and other expenses; and other potential liabilities, costs and expenses. Such losses could be material to our results of operation and financial condition.“

What does all this mean? It means that the PIN Pads are using banking system encryption (almost certainly 3DES) and key management and the intruders have not been able to compromise this. Therefore, the PIN blocks are safe.

However, the comments imply that the POS system was using custom encryption - or at the very least bad key management - which has been compromised. Remember - PCI DSS requires you to use dual control and split knowledge and proper key management practices to manage your keys, and it also requires you to use good cryptography. Never use custom crypto.

The final comment is for all of you who think that PCI DSS compliance is not worth the cost. TJ Maxx is facing losses that “… could be material to our results of operation and financial condition. ” Is not complying with the PCI DSS requirements worth risking your entire business for?

Update: Ambersail reports it’s all over the BBC as well. This story has hit all corners of the globe, and merchants everywhere should be addressing PCI.

Further Update: Cambridge security labs LightBlueTouchPaper blog has some more news from a British perspective.

Popularity: 52% [?]

I was talking with someone (at this age I forgot who) about compensating controls for file integrity monitoring and they suggested a bootable point of sale (POS) system with read-only access. What an excellent idea, and if it was yours please come and claim your prize.

There are so many PCI controls that must be implemented on each retail register that it is cost prohibitive in many cased to meet the letter of the PCI law. Most retailers use compensating controls for addressing one or more areas of compliance on their POS systems.

If you have a read-only POS system you can reduce maintenance and address the following:

• Storage of cardholder data on the register (requirement 3)
• File integrity monitoring (requirement 11.5, 10.5.5)
• Baseline configuration standards (requirement 2)

I suppose audit logging could be a problem, because you cannot write the logs locally, but you never wanted to do that in the first place anyway.

So I googled for “bootable POS” and received two options:

1. The first from Microsoft, a network bootable thin-client POS system (more info)
2. The Squirrel POS system running Linux, which features a bootable image and RemoteFS

I think when people finally start upgrading their old POS systems they should seriously consider bootable or centralized POS systems to reduce maintenance and compliance costs.

Popularity: 40% [?]