For small merchants, and really for any merchant, PCI DSS compliance can offer any number of difficulties.  For small merchants, though, lack of resources and information about the Standard can have a crippling effect on compliance.  Fortunately, there are now services like ProtectPay that can help small merchants comply with large portions of the PCI DSS with minimal resource investment.  For very small merchants, encryption and tokenization efforts can ensure that cardholder data doesn’t traverse your computer, your equipment, or your network.  (This works well for larger merchants, as well, though more integration may be necessary to ensure coverage for all payment acceptance channels.)  However, the PCI DSS does not apply only to digital data or to the transaction itself.  It applies to “hardcopy” data and to stored data, as well.  How can small merchants help maintain PCI DSS compliance for these types of data?  Here are a few tips.

1) Do not store cardholder data in spreadsheets or other computer files.

It may be tempting to store your customers’ payment information so that you can easily process a payment the next time a purchase is made.  Unfortunately, storing the data on your computer leaves you and your customers vulnerable.  If your computer is compromised, a thief could easily access that information.  Additionally, having cardholder data on your computer, particularly in an unencrypted format, is a violation of PCI DSS.  If you are storing data like that, merely losing your laptop could result in a finding of a data breach, with the attendant fines, fees, and penalties.  Many services, including ProtectPay, allow merchants to securely store customer data, without having to worry about PCI DSS compliance or data security.

2) Do not write down cardholder data, if you can avoid it.

It seems so easy.  Just write the data down and process the transaction when you get home.  However, even written cardholder data can bring companies “in scope.”  That data must be protected, just as electronic data must be.

3) Make sure that sensitive data has a secure storage location.

If you must write down data, you should make sure that you have a safe place to store it.  Leaving sensitive information on desk or otherwise out in the open can leave it vulnerable to misuse.  Large companies often have “clean desk” policies, which require that employees clear their desks of sensitive papers and ensure filing cabinets and desk drawers are locked at the end of the day.  This helps to protect company data as well as customer data.  Small merchants can also adopt this policy to help protect themselves and their customers.

4) Ensure that any data that is written down is properly disposed of when it is no longer needed.

It is a fact of business that you may be unable to completely forgo writing down card numbers.  Whatever the reason, you must ensure that once the data is no longer needed, it is destroyed or rendered unrecoverable by thieves.  “Dumpter diving,” in which a thief goes through trash trying to find personal and financial information, is a popular technique among identity thieves.  Papers that contain personal information, including credit or debit card numbers, driver’s license numbers, social security numbers and other sensitive information, should be shredded before it is placed in the bin.  Crosscut shredders are preferable, as this type of shredding makes recreating the document more difficult.

Certainly there are other practices that can also help protect small businesses, but these four steps can help significantly reduce the risk of a “hardcopy” data compromise.

Dr. Heather Mark, PhD; SVP Market Strategy

We spend a lot of time talking about what to do to prevent a breach of networks or computer systems.  This discussion has been, and continues to be, very valuable.  It is discussions like this that have allowed the payments industry to develop solutions like ProtectPay, ProPay’s secure payment solution.  ProtectPay, for instance, allows merchants to accept payment card transactions without storing, processing, or transmitting payment card data.  The benefit of such a system is tremendous.  Not only does it allow companies to significantly reduce the costs and resources necessary to achieve PCI DSS compliance, but it also reduces the risk associated with a breach.  If a merchant using a properly configured tokenization solution is breached, there is no data there to be stolen.  The merchant has only value-less tokens, not valuable cardholder data.  Unfortunately, tokenization isn’t yet universally employed.  That means that there are quite a few merchants operating today that still have cardholder data in their systems.  And while the conversation about preventing a data compromise is important, an important question still remains: What happens after the breach?

Experian and the Ponemon Institute teamed to answer that question.  The results can be found in “The Aftermath of a Data Breach.” (Registration is required to download the study.)  Of the companies studied, 45% indicated that the company lost bank or credit card information, and 60% of respondents indicated that the data that was stolen was unencrypted.  Additionally, the study found that 34% of breaches studies were the result of a “negligent insider.” This seems to support the notion of using a tokenization solution.    It should be noted that 19% of responding companies suggested that “outsourcing data” was the cause of their breach.  Most tokenization solutions do require the outsourcing of data, so how can these two findings be reconciled?  There are two important concepts that readers should keep in mind.  The first are the statistics and the second is due diligence.

The statistics are interesting.  The findings tell us that 60% of respondents lost unencrypted data.  That likely means that at least some of the outsourced providers that were cited as a cause of the breach were not securely storing the data.  Another interesting finding is that a full 50% of breaches were caused by insiders (negligent insiders 34% and malicious insiders 16%).  The other concept that one should keep in mind when reading the study is the concept of due diligence.  Outsourcing data is a big decision for any company.  It is advisable to do a significant amount of research into the potential vendor.  For example in the payments industry, companies that store, process or transmit cardholder data on behalf of a merchant is called a service provider or a data storage entity.  Regardless of the terminology, the company must be compliant with the PCI DSS and be registered with the card brands.  Ensuring that potential partners meet these requirements can substantially mitigate potential risk on behalf of the merchant.

The study is a very interesting read and has important lessons for those companies that store sensitive data.  Perhaps the most important lesson is this: If you don’t need the data, don’t store it!

Dr. Heather Mark, PhD; Sr. Vice President Market Strategy

I saw a blog post yesterday that reminded me of complexity and confusion surrounding the relationship between PCI DSS compliance and fraud prevention.  The details of the story are less important than the central idea that the author was communicating –  the notion that merchants should rely on PCI DSS compliance for the prevention of fraud.  The idea behind PCI DSS is of course to reduce the amount of fraud by helping to protect payment data from unauthorized disclosure and use, but it should be noted that the standard is not a fraud prevention program.  It is a data security compliance program.  Understanding the difference between fraud prevention and data security will help to clarify the relationship between the PCI DSS and fraud.

Fraud is the intentional deception for personal gain.  This is a broad definition that includes social engineering as well as the misuse of financial data.  Fraud prevention, then, must be a very broad set of practices and procedures that are put in place to prohibit people from being able to misuse (in this case) payment card data.   All of the major card brands have suggestions and best practices for preventing fraud at the merchant level.  MasterCard Worldwide provides a quick reference guide to help merchants educate their staff on fraud prevention techniques.  Among the suggestions is the notion that staff should be familiar with what a card is supposed to look like.  Valid cards have a number of fraud prevention mechanisms, including embossed numbers and holograms.    (Each of the card brands can also provide a sort of “anatomy of a card” that will keep merchants and their employees current with new card designs and security mechanisms.

Data security is a subset of fraud prevention tools.  Ensuring that the data is adequately protected from unauthorized disclosure (data compromise) helps mitigate the risk of fraudulent transactions.  All of the major card brands require compliance with the PCI DSS with any entity that stores, processes, or transmits cardholder data.  This helps to prevent data thieves from perpetrating fraudulent transactions on a large scale.  Merchants should not rely on the PCI DSS to protect them from fraud schemes.  PCI DSS is designed to help companies protect payment data from thieves, not to protect merchants from fraud schemes.

Dr. Heather Mark, PhD. ; SVP, Market Strategy

Last week, I attended the PCI SSC Community Meeting in Scottsdale, AZ.   The meeting is held every year so that stake holders in the payments industry can get together and discuss the PCI DSS and its impacts.  Each year brings with it new guidance documents, and sometimes new standards.  This year was no exception and the standard mix of new standards and new guidance was supplemented by discussion of new technologies (perhaps new is a bit of a stretch, as one of the “new” technologies under discussion was EMV – a technology that has been around for decades).  Mobile payments and Near Field Communications (NFC) were also hot topics of discussion and reminded of one my favorite topics – weighing the adoption of technology and its attendant convenience with the protection of payment data.

I am an advocate of a careful risk analysis – there are occasions in which a new technology does introduce risk, but that risk is outweighed by the potential benefit to customers and to the business overall.  In those instances, the organization may determine that the risk is acceptable and the technology is adopted.  In other instances, an organization may determine that the benefits are far outweighed by the risks and the technology is not implemented.  The point is that careful deliberation is sought.  Unfortunately, the current state of the market (economically difficult coupled with rapid technological change) may lead some companies to adopt a new technology as a “me too” strategy.  The appearance may be that by adopting new technologies companies are showing progress and leadership, which will lead to a competitive advantage.  Many times, though, the rapid adoption of new technology without proper vetting can introduce the “unknown unknown” into the environment.

The idea of the “unknown unknown” can be nicely summed up by saying that “you don’t know what you don’t know.”  In other words, one doesn’t have enough experience or knowledge about a particular subject to speak definitively about what its potential risks might be.  The concept was famously speared after Rumsfeld made his famous “unknown unknown” speech.  While pundits and comedians alike had a good time poking fun at Rumsfeld for his use of the terms “known unknowns” and “unknown unknowns,”  he is referencing something that risk analysts and philosophers alike have discussed for years. The premise of Nassim Taleb’s  The Black Swan is largely concerned with operating in a world in which we don’t know what we don’t know.  You can mitigate the number of unknown unknowns through analysis, evaluation, and research.

One of the ways that companies can mitigate the “unknown unknown” in terms of payment security is to evaluate new technologies against the standards established by the industry.  The standards are established to counter the known risks in the payment environment.  Any time a new technology is considered, a good practice is to consider how that technology would be integrated into the existing infrastructure and evaluate that result against the standards and against data security best practices )which sometimes evolve at a faster rate than the standards do.  Certainly this will not bring to light all possible permutations of risk that might arise from the adoption of a new technology, but it will help address an organization’s compliance status and may help mitigate the risk associated with adopting a new technology.

Dr. Heather Mark, PhD; SVP Market Strategy

In August, the PCI SSC released an updated version of its Wireless Guidelines.  The updates were not drastic, rather they were designed to bring the Guidelines into accordance with the PCI DSS v. 2.0 and to provide updates for Bluetooth technology, which was not contemplated in the original document.  This guidance document is important for companies seeking to achieve compliance for a number of reasons. Primarily because there is some disagreement as to whether an organization can be compliant if it uses a wireless network.  The short answer is “Yes, it can.”  However there are some caveats.  Those caveats will be briefly discussed here.

The first thing that one should know about wireless networks is that they are inherently more difficult to secure.  Therefore, while compliance with the PCI DSS is possible with a wireless network, it is not necessarily easy.  For instance, the network must support encrypted communications.  Further, that encryption method cannot be WEP, which was proved insecure several years ago.  In fact, the PCI SSC specifically states that WEP “must not be used” and was prohibited as of June 30, 2010.  Organizations using wireless networks must use WPA (Wifi Protected Access).  The guideline document further details specific protocols for the WPA encryption method, depending on the environment (SOHO, enterprise, etc).

Additionally, there is a tendency on the part of organizations to overlook the physical security of wireless access points.  This is particularly true if a company is using a fairly common access point, such as those that can be purchased at office supply stores.  However, these access points usually have common default passwords and are easily reset.  If an access point is left unattended, it would be a trivial matter for a criminal to hit the reset button on the access point and use those default credentials to access the corporate wireless LAN.

It may be easy, then, to subscribe to the notion that simply not using a wireless network is the easiest way to achieve compliance, and that may be true.  In fact the PCI DSS itself states, “Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only for non-sensitive data transmission.”  It should be noted, however, that an organization should still be aware of the possibility of the “rogue access point.”  These are defined by the PCI SSC as those devices that do not have proper authorization.  According to the document, “A rogue AP could be added by inserting a WLAN into a back office server, attaching an unknown WLAN router to the network, adding a Bluetooth base, or by various other means.”  For that reason, PCI DSS Requirement 11.1 mandates that organizations scan for the presence of wireless access points on a quarterly basis.  This way, even companies that may not be running a wireless network can detect unauthorized devices that may impact the security of their network.

In short, companies should carefully evaluate the need for a wireless network in their environment.  In making this decision, it is highly suggested that the Wireless Guidelines be used to help determine the right forward for each individual company.

Dr. Heather Mark, PhD.  SVP, Market Strategy