There are three principles to securing online payment transactions:
- Protect user payment account identity
- Securely express user intent
- Detect fraud
The next sections summarize considerations for addressing each principle.
Protect User Payment Account Identity
Magnetic stripe cards aren’t cutting it from a security perspective: see the recent incidents involving Target, Home Depot, and PF Chang’s. It’s time to move to chip cards (also known as smart cards). Phones can act like a chip card, as Apple Pay has recently reminded us.
However, using a static password to protect your phone account, or accounts with PayPal or AliPay, is no better security than handing your mag-stripe credit card over to every merchant you encounter. Strong authentication is the only way. (See SmartUtil.)
Securely Express User Intent
The larger the electronic transaction, the more important it is to ensure that the computer is acting on behalf of the user, and has not been compromised with the root kit, pass the hash, or other advanced persistent threat. This is especially true for B2B (business to business) transactions, where the B2C (business to consumer) PCI (Payment Card Industry) and government loss limits don’t apply.
It’s in the interest of the account holder to lockdown the client computing environment in order to limit theft. By enforcing device security and compliance from the hardware up through the browser, we prevent the computer from pulling a HAL and initiating transactions unauthorized by the user. (See StrongNet.)
Detecting fraud is as much about protecting the business from malicious trusted insiders as it is about protection from external fraudsters. It is straightforward to model the computer audit of an activity that is expected from a given data center environment under “normal” conditions. The model consists of such detail as: what objects – computers, users, security groups – are expected to show up. (See StrongInsight.)
For additional protection, also model when certain activities are expected, with what frequency, and in what combinations. Then, any deviation from that model must be flagged for follow-up. For each such incident there are three possible outcomes:
- It’s real; you found a rogue actor and need to chase it off the network
- False positive; you need to update the model
- Neither of the above: it’s exceptional but authorized