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

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

Is it any surprise that actual Payment Card Industry (PCI) Data Security Standard (DSS) assessments by Verizon’s team of Qualified Security Assessors (QSAs) shows growth of compliance is stagnant? Even worse, organizations that suffered data breaches were much less likely to be compliant than a normal population of PCI clients? About 20 percent of organizations passed less than half of the DSS requirements, while 60 percent scored above the 80 percent mark. For all those merchants sounding off about an annual PCI Compliance Fee, the evidence is clear that merchants still have a long ways to go. 100% PCI DSS compliance is the only acceptable statistic.

Organizations struggled most with the following PCI requirements:

• 3 (protect stored cardholder data)
• 10 (track and monitor access)
• 11 (regularly test systems and processes)
• 12 (maintain security policies)

The first two of these can easily be resolved with our hosted payment processing technology, CenPOS. If you’re going to store cardholder data, it needs to be encrypted. One of the major problems with this has been ready access to solutions for storing cardholder data for variable billing. Most gateways have a PCI Compliant solution to store encrypted card data for recurring billing,  charging the same amount on a fixed schedule. However, CenPOS is unique to offer storing card data for billing a variable amount, token billing. Additionally, it is the only technology this writer is aware of that also includes interchange optimization, of major importance to companies trying to control credit card processing fees.

Requirement 10 (Tracking and Monitoring) is a major component of CenPOS. Every user has a unique login and management can micro manage permissions. Where others create a few tiered levels of permission such as cashier, finance, and administrator, CenPOS offers a plethora of options, plus management tracking and research tools.

• User Permissions: Control precise transaction types allowed, set maximum thresholds, set alerts based on responses, amounts and other criteria. Extensive Permissions enable maximum merchant protection from lower level employees, plus there are tools for secondary oversight at the admin level to mitigate risk of high level employee fraud.
• Tracking and Monitoring: The requirement calls for the tracking and monitoring of all access to network resources and cardholder data, the main objective is to maintain system logs and have procedures that ensure proper utilization, protection, and retention. According to the Verizon Report, this has historically been one of the most challenging, but is critical to forensic investigations if needed. CenPOS logs everything related to the payments process including user ID, time stamps and every other element of interaction with the system. Merchants must have their own internal logging system for their network.

Requirement 11 (Regular Testing) had the least compliance in the Verizon report. “Organizations continue to have difficulty meeting the sub-requirements regarding network vulnerability scanning (11.2), penetration testing (11.3), and file integrity monitoring (11.5).”  Our recommendation is that merchants hire a qualified outside vendor to assist them with this requirement. We have no direct affiliation with such companies but know several with good reputations should you need a resource.

Requirement 12 (Security Policies) While the best laid written plans may exist, there is still the human factor. Weaknesses identified include poorly written policies, including so long that they are stuffed in a desk never to be read again, and those that are too vague. Note that the requirements are directly related to the services in scope of the organization’s PCI DSS. The more the merchant reduces their scope, the more the burden is on their service provider instead of their internal personnel. CenPOS reduces the merchant scope in several ways, including but not limited to:

• Web payments on a hosted pay page, not the merchants web page
• Electronic Bill Presentment and Payment- same as above.
• Storing all card data, encrypted, on CenPOS servers, eliminating file drawer and merchant stored data

Learn more about how CenPOS can help you with PCI DSS Compliance.

 

 

 

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.

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

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

 

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.

 

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.

A 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.

Does PCI Compliance allow you to save the track data until you process the card? For example someone gives you a card to process in the beginning of next month, can the track data be stored until then? JL

The answer is yes, but with limitations.

Track data is the information encoded in Track 1 and Track 2 within the magnetic strip, or chip, on the back of a credit card which is read by an electronic reader within the terminal or point-of-sale (POS) system. Track data contains information about the card and the cardholder.

What track data can be collected? When a credit or debit card is swiped, the track data may include customer name, credit card number, expiration date, CVV number, and information used as part of PIN encryption/decryption if a debit card.

What track data can be stored? Merchants may securely store ONLY the customer’s name, credit card number, and expiration date to PCI Data Security standards if desired.

How and where will you store the track data? This is the crux of PCI Data Security and should be your most important consideration. Do you use POS software? Do you know if it is PCI Compliant? Some are, some are not. Even some very big software companies are not, but are ‘working on it’.

A technology solution that I sell ( I work direct for the company) is CenPOS. The data is encrypted, stored off site, meets all current data security standards and the solution is fully PCI Compliant.

Article on prohibited Cardholder Data Storage from Visa.

Visa’s Top Five Data Security Vulnerabilities Identified for merchants (click for PDF download).  Why are there so many data breaches? To promote compliance with the Cardholder Information Security Program (CISP) and the Payment Card Industry Data  Security Standard (PCI DSS), Visa has identified the top five vulnerabilities detected in compromises. It’s a great quick list for you to check your own compliance.

When your read their press release, their is barely a hint that any harm occurred.  But what the press release doesn’t spell out is the data that has been compromised and how it was compromised.

Visa and MasterCard received reports of fraudulent card use by their issuing banks last November and subsequently notified Heartland, according to a Washington Post report. Heartland didn’t even realize they had a problem.

The problem was internal. It was not an external attack, but the result of spyware being placed within their own internal systems.  Heartland’s CEO says a piece of spyware stole payment card data as it passed through the company network. Everyone passes encrypted data to their processor, but what happened to the data once it reached Heartland? Why is this an important difference? We like to think our databases our secure from certain outside hacker attacks into companies that have installed specific systems and software solutions for protection. If an outsider can hack into a secure system that has done everything correctly, then the world of data security is lost.

You really have to read between the lines to figure out what was compromised. Their press release is all about what wasn’t lost. Those behind the breach intercepted and stole the so-called Track 2 data from the magnetic stripe on the back of cards, which is all that’s needed to create counterfeit cards.

IMPLICATIONS FOR CONSUMERS:

If you visited a merchant who uses  Heartland for payment processing, and you have no way of knowing this, your card data may have been compromised. Your card could be cloned and presented for payment to other merchants. Identity theft is not expected to be an issue. Watch your statements for improper activity or replace your card. Heartland has over 250,000 merchants, many of whom are restaurants and hotels. Consumers have no financial liability.

IMPLICATIONS FOR MERCHANTS:

Merchants have no financial liability. Merchants may have to download a software update, though there has been no release of any information related to this from Heartland yet. It’s possible there may be none. If a download is needed, this could be a nightmare with so many merchants needing to simultaneously update. Since many use third party solution in the restaurant industry, the burden shifts to those third party suppliers in some cases.

Do merchants have an obligation to notify customers? No, the data breach is not theirs and they would have no way of knowing personal information about their shoppers.

Should merchants change processors. That’s a personal decision. Read the next section.

IMPLICATIONS FOR HEARTLAND:

What will it cost? If a merchant is non-compliant at the time of a breach, merchants can be fined up to $500,000 per incident and face remediation costs between $90 and $302 per card. With over 100,000,000 transactions monthly, there are probably at least that many cards exposed- do the math. The cost could be astronomical unless they are protected by safe harbor.

Safe Harbor

Visa defines safe harbor as the following:
“Safe harbor provides members protection from Visa fines and compliance exposure in the event its merchant or service provider experiences a data compromise. To attain safe harbor status:

1. A member, merchant, or service provider must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation.

2. A member must demonstrate that prior to the compromise their merchant had already met the compliance validation requirements, demonstrating full compliance.”

If they are protected by Safe Harbor, they still must pay to replace all cards.

If they are not protected by Safe Harbor, can they afford the fines and costs? If not, what will happen to the merchants processing with them?