For a couple of months spanning the first and second quarters of this year, Integrated Solutions For Retailers surveyed its subscribers — hundreds of retailers from many segments, ranging the gamut from small and regional chains to tier-one enterprises — on their perceptions of the PCI DSS (Payment Card Industry Data Security Standard). The survey results surprised us. Respondents exuded nearly equal parts confidence, confusion, dismay, and ignorance. Some gloated. Some swore.

Some very interesting comments here, some of my favorites:

• From a regional grocer: “We’ve devoted no effort. PCI certification is an impossible-to-hit, moving target.”
• Only 23.9% of retailers surveyed indicated that they’re “very familiar” with the PCI DSS.
• 59.6% say fear of a breach is their motivation for achieving compliance.

Read it here.

As a Payment Switch there are times ( especially in development / testing ) that you will want to log or see what the switch is sent from a terminal or POS system, or sent and recieved from an authorization end-point. This feature is very handy during integration to new end-points, different message formats, changes with additional data elements and initial testing and certification efforts in test environments. In Production this is very, very bad, because raw messages contain card-numbers, Track Data, CVV2 Data, PIN Blocks, and all of the other “Bad” stuff one is prohibited to store according to PCI. OLS.Switch by default has this feature turned off, and recommends its use as a last resort for troubleshooting production problems.

Let me rip the introduction paragraph and a few bullets from our PABP Implementation Guide:

Secure Troubleshooting Procedures

OLS.Switch is configured to use various techniques to either protect or wipe sensitive cardholder and authentication data to prevent storage of prohibited data, or to use encryption to render the card number unreadable.

There may be instances in which sensitive cardholder information or sensitive authentication data needs to be viewed for troubleshooting purposes. Sensitive authentication information must only by collected when needed to solve a specific problem. The following are secure troubleshooting procedures designed to allow limited controlled access for troubleshooting purposes, all steps must be followed. You must be authorized and approved to make these system configuration changes.  Furthermore, it is recommended that your internal company’s Change Management and Problem Management policies and procedures are followed in conjunction with these procedures.

x.     Determine if troubleshooting can be performed on test environment with test card numbers.  Perform troubleshooting in that environment first.

….

x.     Only collect the limited amount of information needed to solve the specific problem. Only collect enough data in the troubleshooting log that is required to address the specific problem  

…

(There are lots of other steps and controls to verify that any changes are set back to default, appropriate destruction of captured data is handled, etc, etc, etc.)

Logging raw messages is a dangerous feature and much care needs to be taken with it, and is rightfully heavily scrutinized with knowledgeable PCI Auditors, while not an issue in a test environment using test card numbers, a system misconfiguration or human mistake or “forgotten” changed setting in production could prove disastrous. OLS has added some “controls” around this feature.
Previously there were columns in our TranLog that were called REQUEST and RESPONSE, in order to enable this type of logging an entity such as a store or specific terminal (Terminal ID) would need to be configured and enabled to do so, and would need to follow all of our “user controls” and recommended procedures (including preventive and detective controls) in our PABP guide. For the record non of our clients on our production system have any data in the REQUEST and RESPONSE columns of the TranLog in production environments. I’m happy that it is not a widely used feature in production.

With the new release we now have a single related table called raw_request that has a relationship with a transaction in the TranLog - a much cleaner and normailzed approach. In addition to this, there is a system-wide parameter called auditTrace for each OLS.Switch module that must be enabled by setting the value to true, it is defaulted to false. These system wide parameters are based off of configuration files, and we recommend that our clients use File Integrity Monitoring to detect and alert on any changes to application configuration files.  Once the system-wide parameter for the modules are enabled, a specific store or terminal needs to be configured and enabled; It is a two step process. In addition, This approch also makes it easier to detect if the system is configured in a “non-compliant” fashion - we have monitoring tasks and alerts that scan the raw_message table, and alerts if the row count is non-zero. Also if there is any Database replication or archiving, moving this data to a separate table, ensures that troubleshooting data remains and isn’t disseminated.

This feature is a necessary evil that most of our customers ask for or have in other Payment Switches (we do have the ability to remove the raw_message table and functionality completely). We hope that further adding preventive controls (Making it harder to enable, user controls to use dual control and have secure troubleshooting policies and detailed secure troubleshooting procedures to follow), detective controls (user controls to detect application configuration changes and monitor row counts of the raw_message table) ensure that it is an intentional change on the customer’s part to enable this functionality.

Also: the following paragraph by Andy shows off our different biases:

One follow-up to this Release Note:  I asked Dave how we should set ‘auditTrace’ in production – my thought was to set it to ‘true,’ thinking we’d be at the ready to turn on tracing without a service re-cycle.  Dave strongly disagreed and stated: OLS.Switch ought to be “Secure by Default” in production.  I really liked that.

Dave = Security Focused.
Andy = Operations and Timely Troubleshooting.

Key points were:

1. Long Holiday Weekend IT engineers were off on holiday and took time to address the issue.
2. Fire Department wouldn’t allow access to the building or operation of backup generators
3. Article raises concerns on the backup data center:

Of more concern is the question of a back-up data center. Authorize.net states that they were approaching capacity of their current backup data center and they were in the midst of transitioning to a new one: a true “hot” site (in other words, real-time synchronization), so that the Authorize.Net platform could be switched from one data center to the other “on the fly.” When the fire took out the primary data center, they attempted to fail over to the new, still-in-testing backup data center and encountered “a number of unanticipated errors.” They offer no explanation as to why they tried to fail over to the new backup data center rather than the old (presumably well-tested) one.

4. Authorize.Net did not have “out-of-band” communication methods and eventually opened a twitter account to communicate with customers.

Download the list here: http://www.visa.com/isolisting

Visa is offering a series of one-day Visa Key Management Training sessions as well as a three-day Visa PIN Security Compliance Validation Training session that will provide up-to-date information on the secure management of cryptographic keys used in ATMs, point-of-sale (POS) PIN pads, encrypting PIN pads and hardware security modules. These sessions are for staff involved in the management or operation of devices that accept PINs, and for personnel who need practical knowledge about the elements of Data Encryption Standard (DES) cryptography and the management of secret encryption keys. In addition to the material covered in the one-day Visa Key Management Training session, the three-day Visa PIN Security Compliance Validation Training session offers an in-depth review of the Payment Card Industry (PCI) PIN Security Requirements, providing internal and external assessors with the tools necessary to complete a PCI PIN security compliance review.

Should be fun.

I had a friend “tweet” me a payment using twitpay this afternoon. I remember twitpay from earily in the year, but unlike my experiences with OboPay and Amazon Payments, sending a txt message or using a website to initiate a payment seem to be the easiest, thus I never signed up with twitpay, I also believe that it was in a early beta as the time as well, and honestly I thought it was silly, why would I use twitter to send payments when there are other working models that I’ve used. But with me being in the payments space and some what of an early adopter, I think I’l give it a shot the next few times I need to pay friends back for lunch.

twitpay uses the Amazon Payments Infrastructure, so you need to create an Amazon Payments Account and link your DDA and or Credit/Debit Cards Numbers to it. As a user of Amazon Payments as an alternative to using Obopay (I found it cheaper and there was less nagging verification) I didn’t need to perform this step.

How to use twitpay. It is easy — just tweet:

@dbergert twitpay $5.00 for lunch money

This would pay the user dbergert (this is me btw) $5.00 with a comment of “for lunch money”

In order for the recipient to claim their payment, they need to be a twitter user, and first follow the twitpay user, and then “Claim” your twitter account, which will result in a PIN that is DM’ed (Direct Messaged) to you from twitpay. then you can see what amounts your are owed, and then you also have the ability to send payments as well. When you want to settle up ? which doesn’t appear to be automatic, you click on the settle-up button to initiate the funds transfer from your Amazon Payments Account to the Recipients Amazon Payments Account. twitpay charges a nickel for transactions over $1.00 to settle.

Give it shot, It is a neat unique way of quickly paying a friend for something, I’m not sure if it works with DM’s so you should note that any payment that you make currently with twitpay are public to those who can read your twitter updates.

I’ve sent a few friends varying amounts between .50 and .75 this evening to see how useful it is, Honestly I’ll probably just use Amazon Payments txt or website interface, but who knows, let’s see how the experiment goes!

Photo by davethelimey

Ellen Richey, Chief Enterprise Risk Officer for Visa, Inc said the following at the Visa Global Security Summit

"As we’ve all read, the company had validated PCI compliance. But it was the lack of ongoing vigilance in maintaining compliance that left the company vulnerable to attack. Based on our findings following the compromise, Visa has taken the necessary step of removing Heartland from its online list of PCI DSS compliant service providers."

I remember someone asking me when news of this breach first hit the news –  "But weren’t they PCI compliant ?" "How could they have been breached, weren’t they secure" ? 

I’ve discussed this here before here (PCI Compliant Control Breakdown) and here (Compliance != Security - the Titanic illustration).

I really think the the Heartland Breach is the linchpin event to people of these three important concepts:

1. PCI is a baseline of minimum controls that need to be implemented to generally reasonably protect data across the broad spectrum.
2. Security goes "above and beyond" the minimum required for compliance and should use a risk based approach specific to your business and operating environment.
3. Maintaining compliance must be a ongoing process, it is not a once a year thing.

Case in Point: - a sales professional that I work with, attended the Prepaid Expo USA recently and shared this from his notes on one of the sessions on Prepaid Card Processing:

PCI is NOT enough. It is an ongoing process and we are all playing the "catch up game" much like the anti-virus world.

Over the last few months there has been various webEx, gotoMeeting, Live Meeting, etc of product demonstrations that I’ve been a part of as a participant.

Some General Thoughts:

• If you are showing a web based application use a SSL Certificate and https:// If you are going to show a web-interface that you log in with a username and password or shows account numbers please do this- you can used a self-signed cert, but I get nervous about demo’s without this- It is just sloppy not to do.
• Mask Account Numbers when they are displayed. I get really nervous about this type of stuff and question your security posture.
• Don’t use account numbers and PIN as authentication method, (although there are certain instances where this is acceptable) don’t make this the default option.
• If you are showing a payment system - understand what PABP and PA-DSS are - and if you have customers that are "PCI Complaint" running it, this isn’t the same to me.
• Show a finished product, links that go to "Not yet completed" or pages that are not consistent in look and feel confuse me.
• When I ask how many ‘Live Customers’ use this product, I want to know about in production, not in the sales pipeline.
• If it is a MS Windows/SQL Server based product, don’t list Windows Std. Edition and MSSQL Standard Edition as required software - We need enterprise level software, there is a huge delta in TCO in licensing fees.

Things to do right:

• Simulate a live transaction against a simulator or other tool showing that it is a real system and is functional.
• Walk me through the life-cycle of certain processes that I care about.
• Be able to explain "how you would implement X" or modify Y, or how your system deals with "Z"
• I know that a product won’t solve all of my needs, so I’m looking for synergies with your team to be partners with a relationship to get your product to fit my needs.
• Be able to speak my language, and have a few competent people driving the demo.
• Show me how "someone would use this" application in the real world.

Not a real good design, in my opinion, to display the entered card security code

I read about a new Anti-Skimming device for ATM readers here

In a matter of seconds, criminals can place a skimming device on an ATM card reader that blends in with the machine’s appearance and does not interfere with its operation. A small wireless camera, concealed near the ATM fascia, is also used to capture the user’s personal identification number (PIN) as it is entered. Information from the device and camera is sent wirelessly to the criminal’s laptop computer. The ATM user typically has no idea that his or her information has been compromised.

…

To help reduce ATM skimming, the ADT solution is installed inside an ATM near the card reader, making it invisible from the outside. The technology helps prevent card-skimming attempts by interrupting the operation of the illegal card reader. The solution also detects the presence of foreign devices placed over or near an ATM card entry slot, without disrupting the customer transaction or operation of most ATMs. For effective, layered ATM security, the ADT solution can trigger a silent alarm for command center response and can coordinate video surveillance of all skimming activities.

Look interesting.