Technology

11/17/2009

Tokenization And PCI Compliance


In recent months, as the PCI Security Standards Council has continued to weigh the merits of what they have deemed “emerging technologies,” two terms have been highlighted most frequently. 

The first is end to end encryption, which we’ve written at length about here and here.  The other is tokenization.  As we mentioned in a recent post, these two solutions have quickly become the favorites among all other emerging technologies.

Tokenization is an attempt to mitigate the risks inherent in storing credit card data.  In the same way that end to end encryption helps to protect data in transit, tokenization helps to protect data at rest.  With data in transit is increasingly targeted by nefarious hackers (and making big headlines), it is easy to overlook the fact that data at rest can be equally prone to theft.

As a process, tokenization replaces credit card data with a unique "token" that acts as a reference pointer to that credit card data.  Using this logic, a credit card transaction sends this reference pointer token along the payment chain.  At the processing end of the payment chain, the token is verified and the transaction processed, all without having exposed any sensitive cardholder data to the various networks along the payment chain.  And because tokens are produced for accounts, rather than for specific transactions, stored tokens can be effectively used for scheduled automatic payments as well.

Because the merchant uses a “token,” rather than real credit card data, and relies on the payment processor to assign that token (and to transmit and/or store card data), merchants relying on tokenization decrease their “scope” relative to PCI compliance, transferring the onus of the most critical aspects of PCI compliance to the payment processor.     

Tokenization eliminates the need for actual credit card data to be stored or transmitted by the merchant and, in many cases, allows for an easier PCI SAQ process.  And with some payment solutions offering both tokenization and end to end encryption, the result is an integrated solution that protects data both in transit and at rest.  

Related Posts and Pages:

End-to-End Encryrption Emerges a Winner from PCI SSC Meeting

Tokenization

10/08/2009

End to End Encryption Emerges a Winner from the PCI SSC Meeting

At the PCI Security Standards Council community meeting last week in Las Vegas, end-to-end encryption came out at the top of the list of payment card industry “emerging technologies.”

PricewaterhouseCoopers presented findings of an independent study (which the PCI Security Standards Council enlisted them to do) that examined twelve technologies on the market that potentially could help merchants satisfy PCI compliance mandates like PCI DSS and PA-DSS.  After initial research, the study narrowed its focus to end-to-end encryption, tokenization, virtual terminals and magnetic stripe imaging. 

While it may yet be too early to declare end to end encryption (E2EE) the clear leader among these emerging technologies, as Dan Kaplan from SC Magazine wrote:

Based on their findings, PwC determined that end-to-end encryption, which encrypts data from point-of-sale at the merchant across the processor's network, may have the most success at reducing PCI compliance scope for merchants.

While most people tend to associate credit card data theft occurring when that data is stored but not sufficiently protected, the hackers at the front of the data security battle are increasingly intercepting data while it is being sent across networks, relying on packet sniffing malware and SQL injection attacks to breach networks large and small.

Most of the emerging technologies PwC researched seek to address the vulnerability of such data in transit.  End to end encryption helps protect data in transit by ensuring that cardholder data is fully encrypted, across all networks, from card swipe through bank processing.  PCI Requirement 4, the current PCI requirement that relates to data encryption, mandates that merchants and software vendors “encrypt transmission of cardholder data across open, public networks.”  Clearly, though, data is at risk across all networks which the most recent breaches have proven.    

Since current PCI standards were crafted prior to this trend of shifted risk, PCI requirements could very well change as a result of the current review.

Related Posts and Pages:

Tokenization and PCI Compliance

06/22/2009

Penetration Testing and PCI Compliance

One area where merchants and software providers struggle with PCI compliance relates to PCI DSS Requirement 11.  Here’s a breakdown of the requirement.

PCI DSS Requirement 11 is comprised of seven sub-requirements and 14 testing procedures.  It mandates that any business handling credit cards “regularly test security systems and processes,” a requirement that is intended to secure the network environment in which most merchants and software providers operate.

Some of the sub-requirements contained within PCI DSS Requirement 11 require validation by a Payment Card Industry Security Standards Council Approved Scanning Vendor (ASV).   Others, like sub-requirement 11.3, require no validation by an ASV or Qualified Security Advisor (QSA).  Sub-requirement 11.3 can be met using a “qualified internal resource,” leaving merchants and software vendors free to go it alone.

A closer look at PCI DSS Requirement 11.3 reveals that it requires businesses:

“Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).”

Such penetration testing, also referred to as ethical hacking (or in some cases white hat hacking) is a PCI DSS requirement mandated by sub-requirement 11.3 (and clarified by PCI SSC in supplemental information). 

The reality is that many small businesses do not have a “qualified internal resource.”  Among merchants especially, many businesses end up paying an external third party to perform penetration tests.

As with any security standard, of course, performing more diligence than the minimum requirements is generally the best way to stay digitally secure.  This is why we perform multiple penetration tests instead of merely the one required by PCI DSS to our entire network every year.

Related Element Payment Services Pages:

PCI DSS Requirements
PCI DSS Compliance Level

05/18/2009

PCI Compliant Hosting

Stifled by the technical and financial expense of compliance, an increasing number of merchants and software providers are looking to an emerging market, PCI compliance hosting, for help.

Merchants and software vendors who receive, transmit, or store sensitive credit card information are expected to be fully compliant with PCI DSS and/or PA-DSS.  Of course, merchants and vendors who don’t receive, transmit, or store sensitive information are considered “out of scope” of these standards.

Element Payment Services, well-versed in both PCI DSS and PA-DSS, now offers PCI compliant hosting whereby software providers never receive, transmit, or store sensitive data, eliminating the need for conventional compliance.

The onus of compliance in such an arrangement then falls on Element, eliminating a great deal of expense, for the software provider, from the normal compliance process.  This comparison between PA-DSS certification and PA-DSS hosted payments indicates that hosted payments are by far the more affordable option for software providers concerned with compliance.  It should be noted, however, that PA-DSS certification is still relevant for software providers who have a business case for storing cardholder data within their applications. 

Hosted payments, though, is a method by which the responsibility for PA-DSS compliance is shifted from vendors to a payment processing providers such as Element.  By collecting only non-sensitive data from customers, and allowing a payment processing firm like Element to handle all sensitive data, vendors do not receive, transmit, or store sensitive data, and are thus freed from the burden of complicated, and expensive, PA-DSS compliance requirements. 

As PCI DSS requirements and PA-DSS continue to evolve, so too do the companies charged with developing the processes that implement these security standards.  Merchants , software providers, and payment processors alike are faced with an ever-shifting competitive and procedural landscape; fortunately, companies like Element are at the forefront, making PCI compliance as manageable and affordable as possible.  

Related Posts and Pages:

Cost of PCI Compliance

03/02/2009

Remote Credit Card Data Storage Facilitates PCI Compliance

PCI DSS requires businesses to protect their customer’s credit card information.  And as the growing number of data security breaches attests, the need to carry out this requirement is greater than ever for merchants. 

Remote Credit Card Data Storage

A smart first step towards protecting customer credit card information is remote storage of the data.  In other words, if the data is not present, what is there to steal? Some progressive payment processing companies, including Element Payment Services, offer off-site credit card data storage for their customers along with their payment processing system.  

After a credit card transaction, the customer’s card data is sent to a PCI DSS compliant remote storage facility and removed from the merchant’s location.     

Access to Off-Site Credit Card Data

But what if your customer needs to pay for a large purchase over a period of time or on a subscription basis?  What if a return needs to be made? 

While the data is securely stored off-site, a merchant still has access to it through a unique identifier that “points” to the data in the storage facility.   Using this unique identifier, the merchant can utilize tCredit card data storagehe cardholder data for recurring billing or to resolve transaction questions, but a hacker cannot access it even if they break through the security barriers at the merchant site.  The merchant receives approval response details in the same way as if they had processed the full card number themselves, only without the sensitive cardholder data.

 


Reduction of PCI DSS Scope with Off-Site Storage 

When a merchant eliminates the presence of their customer’s credit card data through off-site storage, they are also easing the process of PCI DSS compliance.  A business that outsources their data storage is able to fill out a shortened version of the annual PCI DSS assessment, the PCI SAQ, as we blogged about in our PCI SAQ Made Easy post previously.  The length of the self-assessment questionnaire can be cut in half, from 31 to 16 pages. 

01/20/2009

As Hackers Get Smarter, Data at Rest Increasingly Vulnerable

Do PCI DSS Requirements Need Strengthening?

Under the umbrella of the Payment Card Industry Security Standards Council (PCI SSC), the major credit card brands have developed security requirements for all businesses that handle payment cards.  The three major standards PCI SSC has created are PCI DSS, PA-DSS and PCI PED.  

Two years after the first standard was announced, the needle towards PCI compliance seems to be moving.  In an update of investigations of cardholder data compromises by consulting company Trustwave, they report:

Fewer and fewer compromised organizations investigated by Trustwave store prohibited data.  More often than not, upon meeting a Trustwave investigator, a representative from the compromised entity will say something akin to, ‘We don’t store track data.’  Working toward the elimination of the storage of prohibited data is progress and deserves recognition.

Increasingly, businesses are using third-party data storage facilities to store important card information, if at all.  But don’t get too excited:

However, because of new attack vectors observed by Trustwave, more work is needed to protect against cardholder theft.  Organizations continue to fall victim to compromise. 

We’ve blogged previously about these new data security attacks, including sniffers and key-logging.  A result of these new attacks is a shift over the last year from theft of credit cardholder data at rest to theft in transit.  This trend gives strong support for encrypting credit card readers

While PCI DSS Requirement 4 calls for encryption of cardholder data across open, public networks (i.e.  the Internet), the requirements do not address the period where data is in transit between the card reader and the point-of-sale device, since this is a closed network. 

This is an important distinction.  In other words, even if a business is fully compliant, they still can fall prey to data compromise.  A merchant could be compromised during this small window—between card reader and POS— by a sniffer. 

Encrypted card readers eliminate this risk by encrypting data from the moment it is captured all the way through to the processing banks.  Though they are not regulated by the PCI DSS yet, business owners would be wise to install them proactively to avoid the high costs of a security breach. 

Here’s the full Trustwave report.

12/12/2008

Support for Credit Card Encryption

This week security consultant Trustwave reported that hackers are stealing credit card information from a merchant even if that merchant uses a secure payment processing system.  The subsequent write up on Digital Transactions News is a solid statement of support for credit card encryption, an issue we blogged about earlier this week, as well as Element's PASS technology

Here's the article from Digital Transactions: 

Fraudsters Moving on from Stored Data to Thefts of Data in Transit

Merchants are getting the message that they should not store credit and debit card data, but that’s turning into yesterday’s issue, according to Chicago-based Trustwave, one of the big card-industry security consultancies. In a report released on Monday, Trustwave says that computer hackers may still be able to steal card data from a merchant even if the merchant uses secure payment-processing software.

The report summarizes findings from Trustwave’s investigations of 443 cardholder data compromises from 2001 through Oct. 29. The good news is that this year breaches involving theft of stored data are down about 10%, Colin Sheppard, forensics practice manager at Trustwave, tells Digital Transactions News. Industry security executives for years have reported that many older point-of-sale payment-processing applications store magnetic-stripe, or track, data, and even PINs, often withoutSecure laptop the merchant knowing it. The card networks, particularly Visa Inc. with its Payment Application Best Practices (PABP) guidelines for secure software, have responded by outlawing the use of insecure software. “[Merchants] no longer are uneducated when it comes to that,” Sheppard says. “We are really seeing people upgrade their systems.”

Improperly stored data is still a big problem—about 80% of the cases Trustwave has investigated worldwide involved it in some manner. But while more secure storage is necessary, it’s not sufficient to prevent data theft. Hackers are now homing in on the fraction of a second during the transaction process when exposed data are transmitted. An example is when hackers place so-called malware onto a merchant’s system that steals data from a computer’s Random Access Memory (RAM), also called volatile memory. According to Sheppard, the nature of existing computers and RAM is such that track data in volatile memory are unencrypted and therefore subject to compromise. “There is always going to be a short amount of time when data is unencrypted with volatile memory,” he says. “Attackers know this.”

The first step in capturing that data in transit is to place RAM-parsing malware onto a card-processing system. The malware captures card data as the computer uses its RAM to interact with the processing software. The information is briefly in unencrypted, plain-text form, and even if it isn’t written to disk or stored, it can still be stolen. “The possibility of parsing track data from RAM has existed for years, but only recently has Trustwave discovered real-world examples of its use,” the report says. It goes on to say that “what’s perhaps most unsettling about the trend” is that theft can happen even if the processing software meets the requirements of PABP, which is now known as the Payment Application Data-Security Standard, or PA-DSS. Other malware variants include so-called packet sniffers and key-logging software that capture unencrypted/plain text track data as they enter or leave a computer system.

Sheppard wouldCredit cards not discuss specific cases or say how many thefts Trustwave has found that involved data in transit. The biggest card breach ever, the hack at retailer TJX Cos. Inc., included the capture of card data flowing over a wireless corporate network, but TJX also had stored numbers improperly and wasn’t in compliance with the Payment Card industry Data-Security Standard, or PCI, at the time. Federal authorities have charged a dozen people in connection with the TJX and other data thefts and some have already struck plea agreements (Digital Transactions News, Aug. 6).

The failure of many merchants to put computer firewalls in place and to fortify their Internet-facing systems makes the placement of malware onto their systems easie raccording to Trustwave. About 75% of the compromises Trustwave investigated in North America included a failure to meet PCI’s Section 10, which addresses remote access to network resources and cardholder data.

The most insecure merchants are small (so-called Level 4 merchants based on their transaction volumes) physical retailers that aren’t sophisticated technologically and use third parties to manage their security systems, according to Sheppard. In North America, 74% of the compromises Trustwave has investigated involved brick-and-mortar merchants; 56% of the merchants were in food service such as restaurants. Some 72% of the North American compromises involved POS software. In 66% of the cases, third parties were responsible for payment-system administration.

Common PCI failures among North American merchants included remote access, which was involved in 17% of compromises that Trustwave investigated; so-called back-door or “Trojan” attacks, also 17%, and perimeter security such as missing or weak firewalls, 15%.

The lesson is that only full PCI compliance, not just strong software that doesn’t store track or PIN data, will minimize the chances of a successful hack, according to Sheppard. “In the last couple years we’ve been concentrating on meeting stored-data [rules], but we’ve moved beyond that,” he says. “The criminals are trying to stay a step ahead.”

And agreed, Sheppard, a thoughtful PCI compliance plan is a must for complete data security. 

12/08/2008

Credit Card Encryption

The increase in financial data compromise, coupled with PCI DSS requirements, has raised new concerns for how to secure transmission of cardholder information.  

Encoded on the magnetic stripe on the back of every credit card is sensitive personal and financial data including the cardholder’s name, account number and security codes.  This information is the prime target of security breaches.  Hackers can use malicious software, called packet sniffers, to intercept traffic—including sensitive cardholder data—passing across a business’ computer network.  Some payment processing platforms transmit cardholder data unencrypted over public data networks, exposing that data to security risks like packet sniffers.  Credit card

State of the art encrypted magnetic card readers scan and encrypt cardholder information prior to performing an electronic payment transaction.  These sophisticated devices use Triple DES Encryption and DUKPT key management technology to encrypt and transmit cardholder data securely over any network. 

DES stands for Data Encryption Standard, a method of encrypting information that was selected as a Federal Information Processing Standard (FIPS) for the United States in 1976.  Triple DES Encryption was developed when DES was shown to be insecure for many applications.  Triple DES applies the DES algorithm three times, making it considerably more secure.  

DUKPT refers to Derived Unique Key Per Transaction.  It is an encryption key management method in which for every transaction a unique key-or piece of information determining the output of an encryption algorithm–is used.   

Using magnetic readers that employ this credit card encryption technology helps businesses comply with PCI regulations for handling cardholder information, particularly PCI DSS requirement 4, encrypt transmission of cardholder data across open, public networks. 

We’ve created a video on end to end encryption - check it out.