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 
One other problem with open source software is the responsibility issue if a vulnerability is found. Who is responsible to make sure it’s corrected? How can a user be sure it will be? where is the agreement/sla aso…
When it comes to the PA DSS and the POS terminals my guess is that PCI-folks are working on guidance for EMV and that your concerns are discussed and implemented in that work.
You say: “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?”
What surprises me is this: Why are you singling out the open source? Just because you pay for a software to a commercial vendor does not make the probability of a “sleeper code” any lower. If any thing, in the open source case, there is likelihood of more eye balls seeing it than in the case of the commercial software! In case of proprietary code, since the source code is NOT available to the public, if any thing, the risk is more. This is exactly the problem with proprietary code for voting machines. The unwillingness of the commercial vendors to make the code public all the more confirms the risk in case of commercial software.
The problem is NOT of open source or otherwise but that of all software and the possibility of existence of “malicious/sleeper code”.
The issue is simply of reliability and in case of hardware reliability, polling results from two independent devices/components is an old solution. When you can not provide assurance of reliability of software, polling from two independent sources exactly practiced in hardware seems to be a viable solution.
Using the criteria of PCI DSS standard to test the assurance of reliability seems to be approaching the problem from the wrong end. The reliability and assurance should be ensured from first principles and not through PCI DSS as it exists to day!
This is a research problem that is beyond the scope of PCI DSS QSA auditors to find a solution. They are simply not equipped to even define the problem in the most rigorous way leave alone find a solution which can stand the review of other researchers.
Open source is much more problematic than closed source software because anyone can be contributing and what, if any, sorts of background checking or otherwise was done to make sure that the contributors have integrity. Granted, this does not provide complete assurance, but it is better than nothing which is what a lot of open source projects are providing.
The best example of this I have is Metasploit and the contributors of exploits. I know for a fact that a lot of attackers were contributing Metasploit code examples for people to use for testing. As a result, a lot of people unwittingly compromised their own systems in an attempt to make them more secure. Pretty ironic. Now with Metasploit being handled by Rapid 7 as a commercial tool and open source ala Red Hat/Fedora, hopefully that practice will end.
If you read the editorial, what is being proposed to address this problem is two separate teams that deliver solutions to the same set of specifications so that they can be tested to determine that they both produce the same results. Such an approach would require both teams to collude the same way which is highly unlikely. If implemented, that will also mean that the cost of software will increase by at least a factor of two. Let alone the likelihood that delays could result by having two teams working on the same project and one finishes and then waits for the other to finish. However, if you want to ensure the safety of your software, I do not have any better ideas to ensure its safety.