Entries tagged with “Payment Security”.
Did you find what you wanted?
Nov 13 2012
Posted by hmark
Data Breaches, PCI DSS
Recent reports indicate that small businesses tend to overlook the threat of a data security breach. Controlscan, a company that specializes in assisting small and medium sized businesses with PCI compliance issues, recently completed a study in cooperation with Merchant Warehouse. The findings indicate that close to 80% of the surveyed merchants felt that they had little to no risk of a breach. What’s more, according to ControlScan’s CEO Joan Herbig, close to half of the merchants surveyed hadn’t even heard of the PCI DSS. These findings indicate a serious lack of communication between ISOs and Acquirers and their small merchants.
Since 2006, all organizations that store, process, or transmit cardholder data have been required to comply with the data security requirements contained within the Payment Card Industry Data Security Standard. In fact, the Payment Card Industry Security Standards Council has even created a microsite dedicated to educating small merchants on the PCI DSS and their obligations under that standard. The ramifications of non-compliance are many and can be overwhelming even for large merchants. Should a breach occur, the fines, fees, and penalties can quickly add up and in many cases have put companies out of business.
This post could easily take on an alarmist tone. Some might say that it already has. Regardless, though, small merchants must comply with the same set of standards to which large companies are beholden. How can one do that with comparatively limited resources? By trying to limit the places in the merchant system that store, process, and transmit cardholder data. Using a solution that processes payment card transactions using point to point encryption (P2PE) and tokenization can serve two objectives – making the data more secure, and reducing the burden of complying with the PCI DSS.
If you are a small merchant and you haven’t heard about PCI DSS or aren’t sure what you should do, reach out to your ISO or Acquirer. They can explain what the standard requires and how you can achieve compliance.
Aug 16 2012
When it comes to PCI DSS there is no secret that there is a lot of confusion. Surprisingly, one of the most confusing aspects seems to be who is responsible for enforcement of the standard. Is it the acquiring bank, the PCI SSC, or the card brands? Do state level governments get involved? What about federal? It’s not uncommon to hear merchants ask the question “why are you making me do this?” Here, hopefully, is an explanation that can help clear up some of the confusion.
The Payment Card Industry Data Security Standard, commonly referred to as PCI DSS, is managed by the Payment Card Industry Security Standards Council (PCI SSC or simply “the council”). The Council is responsible for working to create and manage the standards, ensure that they are disseminated appropriately and for training and accrediting Qualified Security Asessors, or QSAs. The Council does not conduct assessments, nor do they enforce the standards. While they play a critical role in the industry, they do not determine the consequences of non-compliance.
Acquiring banks or merchant banks are often cast in the role of the enforcer, but this is an oversimplification of the complex nature of the industry. The acquirers, just as merchants, are bound to adhere to all card brand operating regulations. Part of those rules require the banks to ensure that their merchants are also in compliance with the card brand rules, including the PCI DSS and related standards. Fines for non-compliance are passed through acquirers to the merchants. In other words, the card brands impose fines on the acquirer for non-compliant merchants. The acquirer then passes that fine on to the merchant.
Ultimately, though, it is the card brands that are responsible for the enforcement of the PCI DSS. Each of the major card brands has their own security programs with different process for dealing with non-compliant entities and with entities that have suffered a breach. Here are the links to each of the programs
It is important to note, though, that some states have passed laws mandating PCI DSS compliance. As of January 2010, all companies that collect or transmit payment card data in Nevada have been required to comply with the PCI DSS. Penalties for non-compliance include civil action, paying restitution and even injunction. In 2010, the state of Washington also passed a law requiring PCI DSS compliance. Minnesota has codified portions of the PCI DSS in its Plastic Card Security Act. As of yet, the federal government has not passed a law along these lines, but various regulations and the charter of the FTC mean that, in the event of a breach, the federal government may be involved as well.
The best defense against these regulatory headaches is simply this – to the extent possible don’t store the data. For those that need to facilitate payments, there are solutions that would allow you to do so while minimizing the amount of data that is stored, processed, or transmitted. Merchants are well-served to investigate these solutions in order to minimize their liability, and in some cases even to reduce their costs.
Aug 2 2012
“When good people…cease their vigilance and struggle, then evil men prevail.” - Pearl S. Buck
When I was learning to ride a motorcycle my instructor gave me one piece of advice that always stayed with me. He said “keep your head on a swivel.” In other words, while I had to make sure that I was doing everything I should be doing, I also had to make sure that I was constantly looking out for what other people may be doing. That way I could correct my course, or at least take some action to ensure that what the other people were doing wouldn’t put me in danger. While this is certainly good advice for riding motorcycles, it is also good advice for data security. It may seem like a stretch, but bear with me.
In securing our customers’ payment data, we have a guideline (actually a set of fairly stringent requirements) in the form of the Payment Card Industry Data Security Standards (PCI DSS). To learn more about these standards visit this site. Following these guidelines ensures that we are doing what we “should” in terms of protecting the data. But that doesn’t mean that others won’t be taking action to put you (and your data) in danger – in the form of data compromise. That means that you have to stay vigilant for what others might be doing – “keep your head on a swivel” – to ensure that you are addressing newly identified risks and vulnerabilities that may not be addressed by the guidelines.
Recent trends indicate that small merchants are increasingly becoming targets of data thieves. In a recent interview, Vantiv Vice President David Mattei stated, “…now we’re seeing an increase in the number of breaches in which smaller numbers of cards are compromised. Small, independent merchants are being targeted because of the ease with which fraudsters can compromise those payment systems.” That means that as small merchants, even if we are PCI DSS compliant, we must remain vigilant against potential attack. One way to foil the fraudsters in this case is with the use of a P2P Encryption and tokenization solution. In this instance, the data is removed from the merchant system and replaced with “tokens,” or abstract representations of the cardholder data. While merchants can still use the data to run reports, issue refunds or fight chargebacks, data thieves would find the tokens to be worthless.
The lesson in all of this is that we must remain on guard against new threats, even if we are doing everything “by the book.” Leveraging secure technologies like tokenization can help ease the burden of compliance and render you and your customers more secure in the long run.
Sep 27 2011
Posted by hmark
Data Security, PCI DSS, Risk/Fraud
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
Aug 11 2011
Last week, an article was published on CNN that indicated that online security was a bit (okay – more than a bit) of a misnomer. In fact, the article said that the notion of cybersecurity was a myth. The article states that “attackers will find a way in one way or another even if you integrate security in a product from the outset.” The news of the past several months seems only to reinforce this notion. Organized groups of ideological hackers, sometimes referred to as “hacktivists,” have taken aim at some very high profile targets. (A list of recent high-profile breaches can be found here.)
Not to be a scaremonger, but data thefts have become a fact of business over the past several years. So how does a company, and a small company at that, operate in this threat environment while balancing the potential for data theft? I’ve long told anyone that would listen, “if you don’ t need the data, don’t store it.” This is especially true of businesses that use sensitive payment data in their daily operations. There is a tendency to fall into the “just in case” trap – the idea that while I may not need the data right now, I might one day so it’s a good idea to just hang onto it. Fortunately, there is a way to 1) protect your business from data theft while 2) hanging on to that data “just in case.” Then answer – tokenization.
Tokenization is a method of data replacement in which sensitive data is “anonymized.” For example, payment data may be replaced with a token, or abstract representation of the data in question. In this way, the merchant can still process payments, conduct reporting and analytics and perform other related functions without replicating sensitive data throughout their environment. The merchant never stores, processes, or transmits cardholder data thereby reducing the risk attendant with data compromise. The data is instead stored with a trusted third party. If the merchant is compromised, there is no data for hackers to steal.
In an era when even data security professionals are beginning to express doubts as to the level of protection that can be afforded to sensitive data, businesses are well-served to investigate methods of mitigating their risk. As Richard Thieme, speaker at the Black Hat Conference 2011, stated “Only when companies and agencies begin to speak truthfully about their limitations — both internally and externally — can they start to address the real-life challenges that face them.”
Dr. Heather Mark, PhD; SVP Market Strategy