OLS.Switch on PA-DSS Validated Payment Applications List

A while ago I wrote this post: PA-DSS Validated Applications Published. Where I noted that our software application was on a PABP List but not on the PA-DSS List. Well we made it – it took the PCI Co a while to invoice us for inclusion on the list, but we received the invoice and promptly paid, and here we are:



* Well other then the "Validated by PA-QSA" is currently incorrect: we used K3DES.

Link to PA-DSS Validated Payment Applications:


Link to PABP Validated Payment Applications:


Compliance != Security – the Titanic illustration


Dr Anton Chuvakin points us to NEWS FLASH! Titanic Was Compliant a post on The Guerilla CISO located here.

The theme of the post is that compliance is not security. Do yourself a favor and read the full post for yourself. It is about someone questioning how a failure could occur "even after smart people put their heads together and try to deal with the problem before facing a crisis" The example of the RMS Titanic is perfect:



I told her that the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind.

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

Did you get that ?  The Titanic was compliant to the current safety standards of the time.

Think of this when you are reading through your SAQ or PCI DSS Audit Procedures – and understand that the PCI Standard is a baseline of controls to follow to protect cardholder data, you may need to go above and beyond these. Don’t feel that you are "secure" because you are PCI compliant, and don’t be surprised that PCI compliant entities can still have security incidents.  Your Risk Management program and practices should include addressing compliance, but compliance should not be your goal for "security."

PA-DSS Validated Applications Published

I read that the PA-DSS Validated Application List has been published by the PCI Council. This is expected as PABP is now know as PA-DSS and the PCI Council is taking ownership of the program.The PA-DSS List of Validated Applications is viewable here:


We are Visa PABP compliant, ( see the VISA PABP List and screen capture below  ) but I am a little disappointed in the PCI Council, because we are not listed on that list…  looks like it is time to make a few phone calls to see why and rectify the issue.  I know the the PCI Council now grants us the opportunity to pay $1250 a year to be listed, but we have not received any communication or such invoice from the PCI Council.

I’ve also asked our auditor and received this reply:

"You are not the only one to be affected by this. When I looked at the list, there were only 85 applications listed out of the many hundreds that were listed on the Visa PABP site. So it appears to me that the PCI SSC has not completed their migration"


LastPass.com asks to store CVV2 code for Automatic Form Filling

I’ve been enjoying LastPass for generating and secure storing and synchronization of passwords between web browsers and my machines. LastPass also has a feature called Automatic Form Filling,  I was a little surprised when I saw a spot to store the following information:

Look at the "Credit Card Number" Section:

12-2-2008 8-28-50 AM


Notice the spot for Security Code ?   PCI considers the Security Code (CAV2,CVC2,CVV2,CID) Sensitive Authentication Data, and does not permit the storage of Sensitive Authentication Data, even if it is encrypted.  This is PCI DSS requirement 3.2:  also see this "PCI Data Storage Do’s and Don’ts"

So if a user enters in their Security Code and saves it in their "Form Fill Profile" the encrypted Security Code in stored in encrypted format on your computer (when you log-in to Lastpass.com),  the LastPass.com servers and Amazon S3 (where LastPass stores its backups). [1]  Interesting.

I’ve decided that I can type in my Social Security Number, Credit Card Number, Exp Date and Security on the websites that I frequent :)    (Actually the main card number that I use for e-commerce sites I have memorized anyway.


It should also be noted that PCI 3.2 language states "Do not Store sensitive authentication data after authorization (even if encrypted) — With LastPass.com it acts more like a password manager or eWallet, and does not participate in the authorization process – Also the information in the user’s account is solely the cardholder’s. 


[1] https://lastpass.com/technology.php

IIA GAIT-R to Scope PCI Compliance

I was at my local chapter meetings of a combined ISACA and IIA group. The topic of the meeting was The Institute of Internal Auditors GTAG and GAIT programs that was presented by Hussain Hasan -of RSM McGladrey, Inc., who is also a member for the IIA’s Advanced Technology Committee.

Hussain pointed me to a case study on using GAIT for Business and IT Risk or GAIT-R to assist in with scope of PCI Compliance.

The GAIT-R methodology comprises eight steps:

  1. Identify the business process and objectives for which the controls are to be assessed.
  2. Identify the key business controls required to provide reasonable assurance that the business objectives will be achieved.
  3. Identify the critical IT functionality relied upon, from among the key business controls.
  4. Identify the significant applications where ITGCs need to be tested.
  5. Identify ITGC process risks and related control objectives.
  6. Identify the key ITGCs to test that address identified risk and related control objectives.
  7. Perform a reasonable person holistic review of all key controls.
  8. Determine the scope of the review and build an appropriate design and effectiveness testing program

Here are the two Case Studies of Using GAIT-R to Scope PCI Compliance.

Why is your company storing credit card numbers?

Martin writes a great post titled: Why is your company storing credit card numbers?


Many of the merchants I’ve dealt with keep everything and I do mean everything.  I’ve run into systems that have card numbers in their databases that date back to the first time they opened up an e-commerce site in the late 80’s.  The majority of the card numbers in these systems have long since expired, but the merchant steadfastly refuses to purge any of the data ‘just in case it might be useful some day’.  In most cases, they don’t actually use the stored credit card numbers in any way, shape or form, but they feel the need to have the data just to have the data.  After all, we all know data is valuable, and what’s more valuable than a potential customer’s credit card number?


I have had similar experiences as well, even more so on the development side where "log everything" you never know when you will need it" was the mentality — you should be able to see why this is a problem.  


What Martin writes about is something that you *should* be doing anyway per PCI 3.1 — If you look at the testing procedures however, there is no test to tie the retention period documented in the policies to the actually data that is retained.

10-14-2008 2-13-56 PM

Fun with Card Readers and Encoders/Writers

I received a MSR505c Card Reader/Writer in the mail today. I use and have a need to create test cards that have magstripes for a variety of purposes; The main one being a way to test/demo our issuer based products from Point-of-Sale (POS) systems and payment terminals.


I thought I create a short screencast to show how this works, which is provided below:

Some considerations to note:

It is extremely easy to "clone" a payment card using a device such as this, and the entry point from a cost and availability perspective is low (~$300 range). In a follow-up blog post, I’ll write about Maktek’s MagneSafe and MagnePrint products to detect card cloning at a magstripe level.

Picture 19

ATM reprogramming arrests.

tranax-1500 I guess it has been almost two years now, that a news story and security researcher blog post, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to "PCI requirement #2 – Do not use vendor-supplied defaults for system passwords and other security parameters" with a few brands of ATM machines ( generally the smaller standalone ATM’s you see in convenience stores and sold by ATM ISO’s and their agents ) whose service manuals were accessible online, and ATM operators failing to setup the ATM’s in a secure manner.  I remember googling and finding the default passwords and instructions for these. With the service manual and passwords, a person was able to reprogram the value of the ATM cassettes. telling the ATM Machine that the $5 cassettes had $20’s and doing a withdrawal


Today – Wired notes that the first bust for ATM Reprogramming Scan netted its first two arrests.

It took a high-speed chase and some gunplay, but two men in Lincoln, Nebraska, are the first to face felony charges for using default passcodes to reprogram retail cash machines to dispense free money.

Jordan Eske and Nicolas Foster, both 21, are in Lancaster County Jail pending an October 1st arraignment. They’re each charged with four counts of theft by deception, and one count of computer fraud, for allegedly pulling cash from privately owned ATMs at four stores in the area. The pair allegedly reprogrammed the machines to believe they were loaded with one-dollar bills instead of tens and twenties. A withdrawal of $20 would thus net $380.

PCI SSC to release PCI DSS version 1.2 in October 2008



Council to evolve PCI DSS with enhanced clarity on technical requirements, improved
flexibility and greater management of evolving risks and threats

Using feedback provided by this community, including more than 2,000 questions submitted to the Council since its formation in 2006, version 1.2 of PCI DSS:
• Incorporates existing and new best practices
• Provides further scoping and reporting clarification
• Eliminates overlapping sub-requirements and consolidates documentation
• Enhances the frequently asked questions and glossary to facilitate understanding of the
security process.


It will be interesting to see what the “new best practices” are and what new requirements will be based on “evolving risks and threats”

Stay tuned…