Auditing PA-DSS 1.1.1

[rushm0re]

Hey folks,

The new draft audit procedures for PA-DSS 1.1.1 mentions using "forensic tools and methods (commerical tools, scripts, etc...)" to examine application output in order to verify that magstripe/track data is not being stored under any circumstance.

Does anyone audit payment applications against PABP or tried complying with the proposed PA-DSS audit procedures? I'm not entirely sure Visa is using the word "forensic" correctly, as it appears they're trying to embody the spirit of due diligence rather than actual bit-stream imaging and forensic analysis of physical blocks or clusters of the operating system (which are IMO apples and oranges...) My questions regarding this are:

1) Does anyone have any suggestions for forensic tools and/or methods for going about this auditing?

2) Pushing aside my own ideas for the time being, do folks believe this application testing should be invasive or evasive (i.e.- running the application, shutting down the O/S and analyzing the file system or running a tool that searches for track data while the system is up, respectively, OR something I haven't mentioned...)

Comments or ideas?
cheers

[andrewj]

Hi,

1) Does anyone have any suggestions for forensic tools and/or methods for going about this auditing?

We have created our own tools that examine hard disks at the bit level, and specifically look for card data. We use this in both QSA audits, and for PA-DSS reviews, and it is _highly_ effective. With regards to PA-DSS reviews, it is easy enough to take a fresh install of the application, run some test payments through it, and then either image the disk at the bit level using DD or something similar, or phsysically extract the HDD for examination.

2) Pushing aside my own ideas for the time being, do folks believe this application testing should be invasive or evasive (i.e.- running the application, shutting down the O/S and analyzing the file system or running a tool that searches for track data while the system is up, respectively, OR something I haven't mentioned...)

Yes, based on the results we have had, I would say that such testing is absolutely necessary. In fact, in my comments on the PA-DSS draft I have suggested that the use of the term 'forensic tools' is clarified to include the examination of non-volatile storage at the bit level.

It is important to note that it is _not_ necessary to shut down a PC to image the hard disk. There are windows ports of DD that will do this while the OS is still running, and therefore there can be no argument that the fact that such data is not necessarily visible in the filesystem provides protection.

It would be interesting to hear from someone (CMark?) who has information on whether any compromises have occurred that exploit data not visible at the filesystem level. Certainly, I for one am convinced that it is a very serious potential problem that will become more and more important as the more obvious storage locations of CHD are removed.

[lyalc]

I tend to think of forensic tools as including going beyond bit-level analysis of the storage media.
For example, searching through all the logs (application, OS and associated services), database tables and other files created by the application.

grep or perl and regular expressions for finiding card numbers is one low cost way to start (may not be the most automated). 'Seed' a know card number into the application, then search for for it.

lyalc

[lyricAKP]

The new draft audit procedures for PA-DSS 1.1.1 mentions using "forensic tools and methods (commerical tools, scripts, etc...)"

Where can one find this new draft version? The only version of PABP that I've run across on Visa's site is the 1.4 version dated January 2007 and it doesn't say anything about forensics in section 1.1.1. And are PABP and PA-DSS being used interchangeably now?

[wconway]

The draft PA DSS document is available for comment to the representatives from participating organizations in the PCI Security Standards Council. If your firm is a member, check with your representatives. If not, you'll probably have to wait until the final document is released to see it.

[cmark]

How does this handle store and forward type scenarios? In certain industries (restaurants, for example) there is a legitimate need to have the ability to store and forward data in the event of a network outage. Does this new language suggest that having the ability to 'store and forward' is now prohibited???

[wconway]

Wouldn't "store and forward" be treated as pre-auth data in the case of network outage, and therefore allowed as we learned in Toronto?

BTW, I would be curious to know what apps (or IPOS systems) actually have/need a mag stripe store and forward capability (e.g., restaurants, as I remember, don't actually store the stripe but do a pre-auth for an amount in excess of the check (to allow for tip), then the final amount goes in the clearing message.). POS terminals, which can store and forward, are not in PA DSS.

Have I got this right?

[cmark]

Walt,
The store and forward is allowed under the PCI DSS but I am concerned that the PA DSS requires QPASPs to ensure the app does not store mag stripe data. It often has the nee to support this function for offline transactions.

Many restaurants using IPOS systems rely on store and forward in the event there is a network outage. The pre-auth issue is not store and forward it is simply the way they auth/clear in a standard model.

The challenge comes when they have a restaurant full of people and the network goes down. They don't want to let everyone eat for free so they will 'store and forward' the transactions. In this scenario there is a large amount of pre-auth data that is retained. The issue is that the IPOS system may very well have a need to allow this functionality but it looks like under the new PA DSS it cannot.

[ztranger]

It will be interesting to see the final version. I really hope there will be room for store and forward scenarios, otherwise a lot of business will have to set up secondary network connections to POS terminals to get acceptable uptime.

A secure way of storing the pre-auth data is to encrypt it with a public key on the POS before storing it so even if the POS is breached, they can't decrypt the pre-auth data. The private key necessary for decryption is much easier to secure on the server side.