There is an editorial in the June 2010 issue of Digital Transactions magazine entitled “How to Beat the Traps Hackers Set in Software” that brings up this point and suggests a way to address the problem. If you do not think this is a potential issue, think again and read this article. I think you will change your mind. The biggest problem with this issue is that it is not yet viewed as an issue by most organizations.
In case you have missed it, software is everywhere these days. Most people fail to recognize that almost everything, from flat panel televisions to furnaces, rely on some amount of software to function. As these devices get connected to networks, the risk that backdoors or “sleeper code” are used to obtain surreptitious access to these devices becomes huge. And do not think it is not happening, appliance manufacturers are connecting their products to the Internet; automakers are putting cellular wireless access points in vehicles so that the occupants have access to the Internet. All of this connectivity was driven home for me last year when the Air France Airbus went down in the Atlantic and it was reported that the aircraft had issued a number of messages back to Air France’s maintenance base indicating that problems with the aircraft were occurring. The bottom line is that all of these ”innovations” put homes and businesses at risk to attack or fraud. But this is not a new problem. As long as there have been computers, the issue of backdoors and sleeper code has existed. It is just that in our networked world, the problem has larger ramifications than in the past.
For PCI, I have always had a problem with the fact that card terminals do not have to comply with PA-DSS. When I was at ETA a year ago, I toured the exhibition floor and took in all of the sophisticated card terminals that were on display. I spoke to a number of vendors that pointed out that their terminals were running embedded Linux or Windows and had Software Development Kits (SDK) for them to further customize their terminals. Yet, according to the PA-DSS on page vii, the PA-DSS does not apply to hardware terminals, or as the PA-DSS states, “also called dumb POS terminals or standalone POS terminals,” if all of the following are true.
- The terminal has no connections to any of the merchant’s systems or networks;
- The terminal connects only to the acquirer or processor;
- The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
- The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.
Time and again we find out that unencrypted PANs are stored on the device, typically until the end-of-day (EOD) function is run. Granted, the terminals will not print out a list of the PANs, but anyone with the administrator code can scroll through the PANs line-by-line. When I have approached terminal vendors with questions regarding why their terminals are not PA-DSS complaint, they throw this back at me and say they do not have to comply because it is a “dumb” device. Because terminals have multiple models depending on application, i.e., standalone, integrated POS, etc., they all have the same software; it is just configured specifically for the application. However, it appears that the terminal vendors use the lowest end of their product line to say that the terminal does not have to comply with the PA-DSS, even though the entire product line has the same software. And when you bring this issue up under the PCI DSS, you are told by the terminal vendor that you are being too strict in your interpretation of the standard.
Then we have open source applications. This is probably the most problematic situation. If you are using open source, how do you know that the application you are using is not for example rounding numbers down and depositing the difference in the developer’s account or sending a copy of all credit card transactions to a system controlled by the developer? For most, they will not know. While network monitoring would likely reveal the copying of transactions to another computer, the transfer of rounding could be hidden inside a company’s normal ACH or other banking traffic making it almost impossible to find.
As software becomes even more pervasive, the integrity of that software is going to have to be proven. How does one know that any application does not contain sleeper code or backdoors that leave any system running that application open to infiltration or fraud? That is the problem we all face. We can no longer just trust that software does not have backdoors or sleeper code. We will have to extensively test and certify software to ensure that software is as “clean” as possible. However, as the Digital Transactions editorial points out, that will still not be proof positive that the software is necessarily safe.
We are entering a very brave new world and need to be very careful until we get a handle on what we are creating. Until we do get control, we need to be very skeptical and careful about the software we use.
PCI Guru 