Archive for the ‘security’ Category

HostedPCI vs Smart Virtual Terminal review

Thursday, September 1st, 2011

I received a cold call from a representative of HostedPCI so I decided to review what they offer. HostedPCI sales pitch is to offer an quick and easy way to become PCI DSS compliant by offering an interface to your existing applications. Basically, their ‘vault’ receives the payment information, tokenizes it, and from that point, only the token is used for processing payments., regardless of the connection interface such as authorize.net.

The core services are currently call center and checkout express. The call center application changes the customer over to a secure payment call session where the consumer enters their card information. Then the operator gets a pop up on the screen with the token ID which can then be used for processing. This removes the operator from hearing the card information, improving security, and also making it easier to comply with regulations regarding recording payment information over the phone. Is this a one time use token? Is the customer told their card data is being stored? How long is it stored for? Whether they exist now or later, there are certain to be new regulations coming regarding the rules for storing, even with a secure token.

The company 2138617 Ontario Inc., dba HostedPCI appears to be Canadian, though it’s not entirely transparent since there is no address on the web site.

It is not a gateway and the salesperson said you’d still need one to accept payments online. I have to wonder, what is the real value of this application vs our Smart Virtual Terminal?

Tokenization – Yes, they both have it. HostedPCI tokenizes every transaction.  Our Smart VT only tokenizes data if there is a need for a repeat sale, and the merchant can issue an approval form for signature, perfect for B2B needs. There are so many other benefits for ours vs theirs (see our token billing page), there is really no comparison. Winner: Smart Virtual Terminal.

Call center - HostedPCI wins hands down because we don’t offer any voice related services. However, you can explore 3rd party options that already exist and if it makes business sense, we’ll integrate.

Gateway- HostedPCI integrates with gateways, ours Smart VT replaces them, eliminating gateway fees. Winner- open to interpretation.

Shopping cart integration- Hosted PCI Checkout Express uses an iFrame and also offers an API, same as our Smart VT. Hosted PCI has ready made API’s for Drupal and Magento;  We’ve never had a customer ask for this so we haven’t made one specifically for this purpose yet. Winner: open to interpretation.

Reporting: HostedPCI doesn’t mention any and our Smart Vt is more robust than anything else on the market. There is no comparison. Winner: Smart Virtual Terminal.

Flexibility: HostedPCI is developing new applications. Smart Virtual Terminal is ready today for Kiosk, EBPP, ecommerce, web payments, mobile, and retail POS and accepts loyalty, credit/debit, check, check guarantee, ACH and other payment methods. Numerous ground breaking features are in the works. Winner” Smart Virtual Terminal.

With prices that start at $.30 per transaction for HostedPCI, if you have an ecommerce PCI Compliance problem and spend less than $100 per month in gateway fees now,  then HostedPCI may be a viable option for you. If you have a call center, check the legal requirements in your state on what’s allowed, including phone script requirements. Smart Virtual Terminal provides significantly more value for mid size merchants at competitive prices (non-published).

PCI standards for phone call recordings of payments over the phone

Wednesday, August 17th, 2011

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset 0 in /home/merch3d/public_html/blog/wp-includes/shortcodes.php on line 257

Does your company record calls for quality assurance or other purposes? The PCI Security Standards Council has issued supplemental guidelines “Protecting Telephone-based Payment Card Data” for you to maintain PCI DSS ( Payment Card Industry Data Security Standards) compliance. The intent is to provide supplemental guidance, and does not replace or supersede PCI DSS requirements.
Why Telephone Card Payment Security is Important
In face-to-face and e-commerce environments, risk-mitigating technologies have helped significantly reduce fraud rates, resulting in a shift of card fraud towards the Mail Order / Telephone Order (MOTO) space. Additionally, a number of regulatory bodies are requiring some companies to record and store telephone conversations in a range of situations. The Payment Card Industry Data Security Standard (PCI DSS), however, stipulates that the three-digit or four-digit card verification code or value printed on the card (CVV2, CVC2, CID, or CAV2) cannot be retained after authorization, and full primary account numbers (PANs) cannot be kept without further protection measures.

As such, there is a risk that organizations taking customer payment card details over the telephone may be recording the full cardholder details to comply with various regulatory bodies, thereby causing them to be in contravention of PCI DSS requirements and potentially exposing cardholder data to unnecessary risk.

Recap: The PCI SSC FAQ
PCI SSC FAQ 5362 – Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of PCI DSS?
This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).
It is a violation of PCI DSS Requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as WAV, MP3, etc.) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.
Where technology exists to prevent recording of these data elements, such technology should be enabled. If these recordings cannot be data-mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call-recording formats.

stored card data chart

Note: Encrypting sensitive authentication data is not by itself sufficient to render the data non-queriable.
For data to be considered “non-queriable” it must not be feasible for general users of the system or malicious users that gain access to the system to retrieve or access the data. Access to the types of functions listed above must be extremely limited, explicitly authorized, documented, and actively monitored. Additionally, controls must be in place to prevent unauthorized access to these functions.
Other methods that may help to render SAD non-queriable include but are not limited to: a. Removing call recordings from the call recording solution b.    Taking the call recordings offline c.    Vaulting the call recordings d.    Enforcing dual access controls to the vaulted call recordings e.    Allowing only single call recordings to be retrieved from vaults

Before considering this option, every possible effort must first be made to eliminate sensitive authentication data. In general, no cardholder data should ever be stored unless it is necessary to meet the needs of the business. There must be a documented, legitimate reason why sensitive authentication data cannot be eliminated (for example, a legislative or regulatory obligation), and a comprehensive risk assessment performed at least annually. The detailed justification and risk assessment results must be made available to the acquiring bank and/or payment card brand as applicable. This option is a last resort only, and the desired outcome is always the elimination of all sensitive authentication data after authorization.    If technologies are available to fulfil PCI DSS requirements without contravening government laws and regulations, these technologies should be used.

The PCI Security Standards Council (PCI SSC) is not responsible for enforcing compliance or determining whether a particular implementation is compliant. It is the primary recommended source for all merchants to obtain current PCI DSS information.

Download the complete report here
PCI Data Security Standard (PCI DSS) Protecting Telephone-based Payment Card Data

Visa Announces U.S. Participation in Global Point- of-Sale Counterfeit Liability Shift

Tuesday, August 9th, 2011

Visa is announcing plans to accelerate the migration to contact chip and contactless EMV chip technology in
the U.S. The adoption of dual-interface chip technology will help prepare the U.S. payment infrastructure for the
arrival of Near Field Communication (NFC)-based mobile payments by building the necessary infrastructure to
accept and process chip transactions.

Not only will chip technology accelerate mobile innovations, it is also expected to enhance payment security
through the use of dynamic authentication. Chip technology greatly reduces a criminal’s ability to use stolen
payment card data by introducing dynamic values for each transaction. Even if payment card data is
compromised, a counterfeit card would be unusable at the point of sale (POS) without the presence of the
card’s unique elements. By eliminating static authentication, we reduce the value of stolen cardholder data,
benefiting all stakeholders.

Visa’s plan includes merchant incentives to upgrade to EMV chip-enabled terminals, requirements for acquirer
processors to support chip acceptance and the introduction of U.S. liability shift policies.

Specifically, Visa will waive Payment Card Industry Data Security Standard (PCI DSS) compliance validation
requirements to encourage merchant investment in contact and contactless chip payment terminals. Visa will
also require acquirer processors to ensure that their systems support dynamic data acceptance (i.e., chip) and
will institute a domestic and cross-border counterfeit liability shift.

Visa’s Counterfeit Liability Shift Policies

Visa intends to institute a liability shift in the U.S. for domestic and cross-border counterfeit transactions
effective 1 October 2015. Visa’s global POS counterfeit liability shift policies are designed to encourage EMV
chip card issuance and acceptance in participating geographical regions, effectively creating a more secure
environment for transactions within and between each participating Visa region. Note: The liability shift
encourages chip transactions because any chip-on-chip transaction (i.e., a chip card read by a chip terminal)
provides dynamic authentication data, which helps to better protect all parties.

With this type of liability shift, the party that is the cause of a chip-on-chip transaction not occurring (i.e., either
the issuer or the merchant’s acquirer) will be financially liable for any resulting card-present counterfeit fraud
losses. When a transaction occurs using chip technology, any liability for counterfeit fraud, though unlikely,
would follow current Visa Operating Regulations.

The policy assigns liability for counterfeit fraud to the party that has not made the investment in EMV chip cards
(issuers) or terminals (merchants’ acquirers). The policy encourages wider deployment of EMV cards and
terminals.

EMV chip implementation is accelerating globally. Today, excluding the U.S., 44 percent of all cards are EMV
chip cards, and 74 percent of all terminals are EMV chip-capable, with 62 percent of cross-border transactions
conducted with a chip card at a chip terminal.

U.S. Participation Introduced in Global Counterfeit Liability Shift Policy

Visa plans that effective 1 October 2015, the U.S. will be included in the Global POS Liability Shift Policy, which
will apply to all issuers and merchants’ acquirers in the U.S., with the exception of transactions at Automated
Fuel Dispensers (AFDs). Transactions made at AFDs will be excluded from the liability shift for a period of two
(2) years due to the challenges faced by the petroleum industry in upgrading terminals to accept EMV chip
cards. Similarly, effective 1 October 2017, transactions made at AFD terminals will be included in the Global
POS Liability Shift Policy.

Note: This liability shift policy change excludes counterfeit fraud at U.S. ATMs. Visa will continue to evaluate
the potential for an expansion to include ATMs.

Preparing for Payment Technology Evolution

As the U.S. point-of-sale payment infrastructure continues to evolve from the static magnetic stripe to intelligent
devices such as EMV chip cards and Near Field Communication (NFC) mobile phones, this liability shift policy
change will help ensure that the acceptance infrastructure is ready. It will also allow acquirers, merchants and
issuers to invest in new technology to ensure that cardholders can continue to make secure and frictionless
transactions across all channels.

Thieves Found Citigroup Site an Easy Entry for customer data

Wednesday, June 22nd, 2011

NY Times reports Hackers get into Citigroup via their customer credit card account management web site. In 2008, the underground market for the data was flooded with more than 360 million stolen personal records, most of them credit and debit files. That compared with 3.8 million records stolen in 2010, according to a report by Verizon and the Secret Service, which investigates credit card fraud along with other law enforcement agencies like the Federal Bureau of Investigation. As a result, the price of data is going up and hackers abound.

 

Do I need SSL if using secure iFrame to accept credit card payments online? http form post to https?

Saturday, June 4th, 2011

Can I put my form on HTTP and target my form to post to  HTTPS and still be secure? No.

  • An attacker can utilize JavaScript code to steal data before the user submits it.
  • Even if you post a notice, users will be less trusting. If a company can’t afford to invest in a security certificate, why would you trust them with private data?
  • Website users should stick with one URL to login and form URL and the target URL should be over SSL.

Can I put a secure iframe for payments collection on http? Technically yes, however, this will not achieve desired security or consumer confidence since there will be no ‘lock’ on the consumer web browser for your domain. There are also limitations which I won’t get into here. This would not follow best practices and is therefore not recommended. Wherever you accept information that you want secured, the domain should have an SSL certificate.

Prevent theft with Visa tips on merchant security at the point of sale

Friday, May 6th, 2011

Increasingly, criminals with sophisticated tools are actively targeting vulnerable merchant  point-of-sale (POS) terminals to steal payment card data and PINs for counterfeit fraud purposes. Criminal gangs worldwide are illegally accessing active POS terminals and modifying them by inserting an undetectable electronic “bug” that captures cardholder data and PINs during normal transaction processing.

Visa has released an excellent bulletin all brick and mortar merchants should read.

Point-of-Sale Terminal Tampering (pdf download)
Is a Crime . . .
and You Can Stop It

 

Fraud Risks and methods to identify and prevent credit card fraud

Thursday, May 5th, 2011

Results from the 2010 LexisNexis True Cost of Fraud study show that 20% of merchant fraud losses are attributed to friendly fraud, 42% to lost or stolen merchandise, 18% to identity fraud, and 20% to  fraudulent requests for a return/refund. Friendly fraud occurs when a consumer purchases an item online and receives the product but claims not to have received it, requesting a refund
or chargeback from the merchant or delivery of a duplicate item.

Prevention holds the greatest impact in minimizing fraud losses.

Fraud Loss by Company Size, Product Type, Channel and Industry, 2010 Company Size

Small Company avg <$1M revenues Medium Company Avg $5M revenues Large Company Avg >$50M revenues
Average annual fraud 

amount ($)

$2,145 $104,000 $6,767,000

For the complete study, get it free by registering at the Lexis Nexus web site:  2010 LexisNexis True Cost of Fraud.

Comments:

Friendly fraud- A small business owner was able to successfully defend against consumer claim that box was delivered empty by showing Fedex records of the weight. The difficulty with this going forward is that new rules have a 180 day chargeback period. Make sure your shipping company keeps those records for as long as you need them.

Identity fraud- Unless there is an issue of verifying ownership, such as when a customer is picking up a car left for repair, merchants cannot ask for a drivers license or other identification for a standard transaction. However, there are many other ways to prevent this type of crime. In the brick and mortar world, a mandatory check for the last 4 digits is a simple and effective way to block cloned credit cards. Due to the global nature of our society, requiring the zip code would frequently result in too many declines. However, you can add additional filters with our payment processing platform that sits in front of your existing processor. Essentially it is your fraud protection dashboard where you control in real-time the level of risk you’re will to accept either by blocking specific transactions entirely, or by sending automated email alerts to managers who then can assess the situation. This works very similar for online transactions.

 

2011 Data Breach report insider theft credit card processing

Tuesday, April 26th, 2011

In this first article of a series we explore insider theft, related to data breaches,  based on key elements of the Verizon 2011 data breach report.  The number of 2010 data breaches exploded in companies with 11 to 100 employees. A key commonality is simply the opportunity was there.

The 2011 Data Breach Investigations Report (DBIR) is a study conducted by the Verizon RISK team in cooperation with the U.S. Secret Service and the Dutch High Tech Crime Unit.

Who is behind the data breaches?

  • 92% external agents
  • 17% implicated insiders
  • < 1% business partners
  • 9% involved multiple parties

How do breaches occur? ?

  • 50% involved some sort of hacking
  • 49% incorporated malware
  • 29% physical attacks
  • 17% from privilege misuse
  • 11% employe social tactics

What commonalities exist?

  • 83% were victims of opportunity
  • 92% were not difficult
  • 76% of all data was compromised from servers
  • 86% discovered by a third party
  • 96% were avoidable through simple or intermediate controls
  • 89% of victims subject to PCI-DSS had not achieved compliance

End of excerpt. Continue reading for blog author comments.

healthcare company stores credit card data on servers, unencrpyted. Their excuse? It’s not connected to the actual credit card processing and access is restricted so it’s not a PCI Compliance problem.  See related article Shocking lack of payment processing security in healthcare industry. No data breach yet, but statistically, the company is at great financial risk, including up to  $1.5 million fine for violating the HITECH ACT.

Employees at a car dealer tape passwords next to their computer and in the first unlocked drawer of their desk. Their excuse?  It’s too hard to remember the password and they don’t acknowledge it’s a security issue.

Employees at a retail rental shop have a file folder in plain view of anyone entering the shop containing copies of drivers licenses and the front and back of credit cards. Their excuse? They didn’t know they couldn’t do it and didn’t know of an alternative method that would meet their needs to bill customers if they never returned with the goods.

Think these are exceptions? Businesses everywhere have these problems in some fashion. As each of these examples illustrate,  employee training is essential. Industry wide, merchants are completing  PCI Compliance Security Standards data worksheets. At that point in time, the merchant can be certified PCI Compliant. But without internal enforcement and training, the merchant is generally not compliant when a data breach occurs and thus is fully liable for all the associated fines, fees and damages.

In conclusion, the establishment of training procedures and distribution of data security expectations to employees is essential. Most employees are honest, right? But when companies have lax security policies, it presents an OPPORTUNITY for good employees to break the law.

Here’s three things you can do to mitigate internal employee risk:

  1. Create a data security training checklist for all employees handling sensitive data. Update the training and content quarterly or at least once per year. The employee cannot accept credit cards or any sensitive data until they’ve completed training, plus sign and date the checklist.
  2. Make data security a formal part of employee performance reviews. Require annual checklist review and signature at the time of performance reviews.
  3. Implement a reward system for identifying vulnerabilities of real life practices- whether people, software, or hardware.

Bonus: Implement a hosted payment processing solution with extensive tools to prevent internal fraud. Call for information.