By Scott Henry
VeriFone
Do the terms flexibility and security seem mutually exclusive to you? It's easy to think of data security as a stranglehold on what you, as ISOs and merchant level salespeople (MLSs), and your merchant customers can or cannot do with transaction systems.
Payment security should be impenetrable to disreputable types, but it does not need to be inflexible in terms of management. Making sure you maintain flexibility for future adaptation to changing needs should be priority number one.
Let's take, for example, the Payment Card Industry PED (PCI PED) requirements. In point of fact, there are two types of PCI PED certifications you should pay attention to: POS-A and POS-B. With POS-A devices, the PED original equipment manufacturer is the only entity able to modify the prompts and controls for cardholder data entry, according to the PCI Security Standards Council (SSC) requirements. The end-user, acquirer, or reseller cannot modify the PED's firmware or payment application to make changes to the device's prompts or PIN entry controls.
So what does this mean to the feet on the street? If, for example, you or your merchants want to prompt the cardholder to enter a ZIP code, you would not be able to do so unless that function is built into the device operating system.
Without built-in coding, in order to offer ZIP code entry, the manufacturer would either have to add the prompting to the firmware (operating system), or an application running on the device would need to be certified by a PCI SSC-approved audit firm. Neither solution is flexible or easy to accommodate.
With POS-B, in contrast, the PED is shipped with secure mechanisms for controlling the PED display, which the acquirer can employ to unlock the PED for updates of the prompts. Even the reseller or end-user, if authorized by the acquirer, may update the display and prompts using appropriate security processes.
Let's look at another possible hurdle with POS-A. If you want to develop or offer a third-party gift card application and want to prompt users to manually enter the gift card number, forget about it. If the prompt leads to numeric input and is under control of the firmware, that's a POS-A restriction.
Unless the prompt and numeric input are already built into the device operating system, or are driven by a PCI-validated application, you may very well be in violation of the PCI PED requirements. To avoid such a violation with a POS-A system, you'll need to get the manufacturer to modify the firmware, which can be time-consuming and costly.
How do you know if equipment is POS-A or POS-B? The information is listed on the PCI SSC Web site, www.pcisecuritystandards.org/pin/pedapprovallist.html.
Today's PCI PED-approved terminals are designed with physical security features including special tamper detection measures, which can render a terminal inoperative by erasing the encryption keys if it is attacked.
Tamper-resistant features should also make it unfeasible for unauthorized third parties to obtain personal cardholder information or financial data by attempting to access the internal electronic components of terminals or PIN pads.
Software security features should provide a flexible architecture that offers both ease of management for the ISO or MLS who originally deploys the terminal (terminal sponsor) as well as sophisticated application protection capabilities to help prevent the execution of unauthorized software on the terminals and unauthorized download or application deletion.
File authentication technologies require applications to be digitally "signed" by a trusted party within the distribution chain for the application to properly execute on the terminal. This digital signature security is the same technology employed by secure Web sites on the Internet.
Even though the target benefit of this technology is to prevent rogue applications from executing on the terminal to collect sensitive cardholder data, a positive byproduct is that competing organizations cannot use your terminal for their purposes because their applications are not properly signed for it.
Flexible security solutions should also provide a second layer of security to protect unauthorized downloading and clearing of applications through password protection.
This can be accomplished through password protection. Simple password schemes based on merchant specific data (for example, the first three numbers of a merchant's account plus the date the merchant was originally set up) make it easy for an organization to maintain but difficult for competitors to crack.
Such a dual-layer approach to application security will provide great protection against criminal misuse and thwart competitors trying to appropriate your merchant accounts. To ensure maximum flexibility, application security should also provide a simple, but highly secure, method of releasing merchants remotely without requiring terminals to be sent into the deployment center for unlocking.
Retailers do not want to discover they've bought into a system that prevents them from adding revenue-producing features. That's the quickest way to ensure your merchant customers will look for an alternative when their contracts expire.
With the right architecture, flexibility and security can coexist in a manner that provides assurance that your systems are compliant with requirements, while also giving you the ability to adapt to changing market needs.
Scott Henry is Director, North America Product Marketing, for VeriFone. He can be contacted at scott_henry@verifone.com.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
