Doing Our Part to Contain Point-of-Sale Data Theft
You see it in headlines just about every month—another major retailer has discovered that thousands of its customers’ credit cards and personal information have been stolen. According to research conducted by Cisco, point-of-sale systems are one of the fastest-growing targets of exploit-kit families in 2014.
It’s easy for us as software developers and testers to dismiss these intrusions as the fault of network security professionals or inadequate network defenses. The reality is that there is a lot we should be doing as well on the software side to prevent these kinds of attacks.
It is relatively easy to get credit card numbers and CVV2 security codes; this data is enough to allow thieves to make online purchases. The ease of obtaining this information is reflected in the black market online sales price of the data: roughly ten cents to five dollars per card.
The much more valuable data, called track 2 data, allows criminals to physically clone cards that provide access to brick-and-mortar stores and even ATMs. This data sells online for up to a hundred dollars per card, reflecting the difficulty in obtaining it. Fortunately, obtaining this data requires physical access to the credit card, as it is stored on the magnetic strip. It is here where we as software professionals can play a role in minimizing risk.
At a high level, credit card data is most vulnerable when it is unencrypted. This occurs right when the card is swiped at the point of sale. As a result, malware that reads track 2 data from point-of-sale memory or intercepts it as the card is swiped has become the favored method of stealing this data. But how does this malware get installed? Point-of-sale terminals should not be connected to the Internet, which leaves software vulnerabilities as the primary means of compromising the sale.
Penetration testing should always be part of any solid QA process. Unescaped SQL commands, old cryptography functions, outdated libraries—any combination of items such as these—can lead to gaping holes in your software. Even if you’re not writing software targeted at retail or financial functions or markets, your software could easily wind up running on a machine that does perform these functions, and the system is only as secure as its weakest link.
Don’t let that weakest link be your code. Network security can be good at detecting and responding to threats, but the best way to stop these threats is with a solid QA team that understands where these vulnerabilities tend to exist and has the expertise and tools to thoroughly test the code you are shipping.
The implementation of new, more secure types of payment technology should help make things more difficult for thieves, but I recommend you look for penetration testing tools you may be able to introduce into your QA process.
Jennifer Bonine is presenting the tutorials What’s Your Leadership IQ? and Innovation Thinking: Evolve and Expand Your Capabilities at STARWEST, in Anaheim, CA, October 12–17, 2014.
