The Harsh Reality Of Security

Chris Skinner has a blog entry that asks the question, “Why does the card securities council not care about card security?”  What concerns me is the title of the article as it again implies that the PCI standards do nothing to secure cardholder data.  As a result, I thought I would take a shot at answering this question.

Mr. Skinner points to a number of technologies that he feels the PCI SSC is ignoring as potential solutions to securing cardholder data.  These solutions include tokenization, end-to-end encryption (E2EE) and Chip & PIN (EMV).  I recently posted a blog entry on all of these technologies, so I will not go into all of these here.  The bottom line on all of these is that, individually, they do not solve the security problems we face.  However, used in conjunction, they will create a much more formidable barrier to breaches.  I can tell you that the Council is not ignoring these technologies; they are only doing proper research to ensure that whatever guidance they issue is not flawed resulting in a recall or wholesale rewriting of a standard.  Want to lose credibility?  Issue a standard that you have to later heavily modify or replace.  Do I have to remind everyone about Wired Equivalent Privacy (WEP)?

Then we have the dynamics of the card brands.  Just because Visa writes a whitepaper on some technology does not mean that the other four card brands have bought into Visa’s analysis.  Visa may be the 800 pound gorilla of the card brands, but as anyone in business knows, the 800 pound gorilla does not always get its way regardless of how boisterous or how much chest pounding it may do.  A prime example of this was in the late 1970s when IBM (then the 800 pound technology gorilla) tried to force System Network Architecture (SNA) down the International Organization for Standardization’s throat as the Open Systems Interconnect (OSI) model.  What happened was that the rest of the technology companies in the world banded together and created the OSI seven-layer model that we have today.  While it has a lot in common with SNA, it also has numerous differences.  The bottom line is that there are certain dynamics between the card brands that will preclude the Council from always following Visa’s lead, regardless of whether Visa’s analysis is right.

How about the cost of any change?  Merchants do not live on thick margins.  Most are lucky to retain 1% to 4% of total sales as their profit margin.  If you are Wal-Mart or Target, margins can be huge numerically, but still not enough to fund the kind of wholesale changes Mr. Skinner is suggesting.  Unfortunately, most merchants are nowhere near the size of Wal-Mart, so they need to be even more judicial with their expenditures.  As a result, any change that requires a significant investment is going to be tough for any merchant to swallow and will take time to get rolled out.  After all, we are in the midst of a recession, so there is even higher sensitivity to expenditures that do not enhance the bottom line.

But for a number of merchants, the cost is not so much theirs to bear as much as it is their merchant bank’s cost.  That is because a lot of merchant banks provide the entire cardholder processing environment to their merchants.  As a result, the bank will have to absorb the cost and possibly increase fees should new terminals or software be necessary.  Banks are not necessarily doing well either, so they too are avoiding any expenditures that are not going to positively influence the bottom line.  Since security is an intangible, banks are going to be very reluctant to spend on cardholder infrastructure that does not drive up revenue.  After all, in the United States and United Kingdom, the banks were bailed out by the government and are now being watched very closely by the various regulators and the regulators are holding the purse strings.  Unless the regulators come on board, there will be no expenditure on what they will consider a frivolous expense on new terminals or software.

All of these parties are intimately involved in the PCI Security Standards Council as stakeholders.  All of the card brands and a number of larger financial institutions are on the Council’s board and various work groups.  Given the economic environment and the predisposition of these parties, is it any wonder why the Council appears to not be moving forward?

Not to mention that the changes Mr. Skinner is suggesting do not eliminate the problem of security breaches, they just shift the risks.  Granted the risks get reduced, but by how much is anyone’s guess.  But in the end, there are still going to be risks.  As I always like to remind people, security is not perfect.  Yet that seems to be what the card brands and Council seem to want people to believe.  That if everyone followed the PCI standards, breaches would not occur and that is simply not true.  Breaches would still occur, they just would not necessarily occur every week releasing thousands or millions of accounts.  It would be more like a release every month of tens or hundreds of accounts.

I too would like to live in a perfect world.  But the real world is always far from perfect.  Decisions get made only when the wheel is so squeaky that it needs to be replaced.  We can rant and rave all we want, but we will only get action when we can either show (i) a measurable business benefit, such as an increase in profit or improved efficiency, or (ii) someone else is doing it and they now have a competitive advantage.  Unfortunately, I see neither of these conditions satisfied at this time nor any time in the near future.  As long as the status quo remains, no one is going to move.

In the end, the PCI SSC does care about security.  It is the politics that slow things down and those politics are not going to go away any time soon.  That is the harsh reality of business and security.

UPDATE: Forrester Research has published a great white paper titled ‘How To Market Security To Gain Influence And Secure Budget’ that explains how to avoid the common mistakes that most security people commit and, as a result, why security professionals do not get the resources that they need to get the job done.

Advertisement

Advice To Merchants

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can.  That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.  According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.  So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.  These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.  Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.  A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep.  If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.  I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

An Open Letter To Acquiring Banks

Get with the program people!

The PCI standards have been around for almost four years now and you would think with all of the press that has been given the PCI standards that the key participants in the standards would be intimately knowledgeable with these standards.  However, the more and more I talk to acquiring banks, the more I am amazed that most acquiring banks still are not with the program.  It is time for all acquiring banks to get a clue about the PCI standards and their responsibilities regarding the PCI standards.

Acquiring banks have many responsibilities under the PCI standards.  The first of which is to understand and support the PCI standards.  However, it is painfully obvious from trying to work with acquiring banks that most are clueless about the PCI standards, let alone do they understand their responsibilities.  Card brands and the PCI SSC have focused on educating QSAs, merchants and service providers in the PCI standards to the detriment of educating acquiring banks.  I cannot tell you how many conversations I have had with acquiring banks where they have no idea of what their responsibilities are regarding the PCI standards let alone regarding knowledge of the PCI standards themselves.  What I dearly love are those acquiring banks that tell me that they have no responsibilities in regards to the PCI standards, that it is a merchant program.

This is not just a problem in the United States, this problem is worldwide.  This is a very big issue in Asia where acquiring banks seem to be totally clueless about the PCI standards.  It is a bit better in Europe, but because European acquiring banks have been brainwashed to believe that Chip and PIN gives them a security edge, the acquiring banks there are not aggressively promoting PCI compliance.  But at least the European acquiring banks seem to have a basic understanding of the PCI standards and some of their responsibilities.

Another responsibility of acquiring banks is to be the final arbiter between merchants or service providers and their QSAs.  According to the card brands, if a merchant or service provider is at loggerheads with their QSA over whether a PCI requirement has been met, the acquiring bank is supposed to be the final arbiter of that dispute.  Yet in the handful of instances where I have been involved in such disputes, the acquiring bank has provided limited or no assistance with the dispute.

An even bigger problem is with small merchants that are trying to decide which Self-Assessment Questionnaire (SAQ) to file.  Again, the card brands have stated that the decision regarding which SAQ to file is the responsibility of the acquiring bank and no one else.  Yet time and again, our small merchant clients contact my Firm because the acquiring bank has told them it is up to a QSA to determine the SAQ to file.

Then there is the acquiring banks’ responsibility to follow the PCI standards.  Yet time and again, I run into instances where the acquiring bank is transmitting cardholder data insecurely to or from the merchant or service provider.  The number of acquiring banks that use FTP or electronic mail for the transmittal of cardholder data is just staggering and after four years of the PCI standards existence is unacceptable.  Yet, when you bring this issue up, a lot of the acquiring banks will tell you that PCI standards are for merchants, not for them.  The other excuse I hear is that the acquiring bank is working on securing their transfer of cardholder data.  Again, after four years of the PCI standards, you are just now getting around to securing the transmission of cardholder data?  Unbelievable.

This year we started receiving calls from banks and credit unions that drive their own ATM networks that had been requested by their ATM network interconnection provider such as NYCE and Pulse to obtain a PCI Report On Compliance.  What a wakeup call.  In a number of cases, the institution was shocked that the PCI standards applied to them and questioned us extensively to confirm that they really had to go through the process.

As a QSA out in the field, these attitudes are just no longer acceptable.  The PCI program flounders in part because one of the key constituents is not on board.  It is time for the PCI SSC and the card brands to educate the acquiring banks and get them engaged.

Why The PCI Standards Exist

After another spate of articles and speeches about the PCI DSS and why it is worthless, I thought it might be a good idea to explain why the PCI standards came to exist.

In 1999, Visa USA began to work on what became the Customer Information Security Program or CISP.  The first official version of the CISP was issued in the summer of 2003 with Visa asking select merchants to comply with the CISP as soon as they could.  The original impetus for the CISP was a response to increasing chargebacks that were the result of the fraudulent use of credit card accounts.  An analysis of these chargebacks had started to paint a picture of merchant employees that were increasingly using their access to point of sale (POS) and accounting systems to obtain credit card numbers and then using those numbers to commit fraud.

As development on the CISP progressed, Visa USA also started to see increasing instances where an e-Commerce site had been compromised and the credit card information stored on the site had been taken by an attacker and then was fraudulently used.  The reason these compromises had resulted in cardholder data being exposed was that application developers had used the same software design models for e-Commerce as those that were used by traditional POS.  This resulted in cardholder data being stored in databases that faced the Internet.

A year or so after the start of Visa USA’s efforts, MasterCard International began development of the Site Data Protection (SDP) standard.  Unlike the CISP, the SDP focused specifically on the security of e-Commerce sites.  MasterCard had monitored the rising fraud rate related to the compromising of e-Commerce sites.  Like Visa USA’s analysis, MasterCard’s analysis of the problem pointed to the fact that most e-Commerce sites were storing cardholder data in databases that faced the Internet and were not very well protected from compromise.  As a result, MasterCard approached the problem with the SDP which specified a basic level of information and network security for e-Commerce Web sites.

As work progressed on the CISP and further statistics on security issues were gathered, Visa USA began to recognize that the on-line payment applications themselves were the biggest problem related to the compromising of cardholder data.  As a result, Visa USA developed the Payment Application Best Practices (PABP) standard.  The PABP was published in late 2004 with Visa USA encouraging software vendors to use it as a benchmark for securing their software.

It has been suggested that the PCI standards were only developed to minimize the losses to the card brands and banks and do nothing for merchants.  However, the PCI standards were meant to protect everyone in the transaction process.  When a breach occurs, the first thing people remember is the name of the card brand(s) involved, the second name is likely the merchant or service provider and the third name is the franchisee if that is the case.  The card brands, service providers and franchisers discovered that their reputations were highly at risk, even though it was typically the franchisee merchant that actually created the problem.  Regardless of who caused the breach, the card brands further discovered that what people really remembered from breaches were the card brands’ names and everything else was forgotten.  As a result, the card brands became determined to protect their brand names and reputations.

There was another recent suggestion that the PCI DSS was not needed because market forces would resolve the security issues inherent in the conducting of credit card transactions.  The first problem with that idea is that most merchants and service providers are unconvinced that they are responsible for securing cardholder data, even after they might have suffered a breach.  They believe that it is the card brands’ problem to secure cardholder data because the card brands are the ones that generate the cards.  Unfortunately, the security of cardholder data is mostly outside of the control of the card brands, therefore the merchants and service providers need to be responsible for securing cardholder data as well.  The second problem with that idea is that for every security “expert”, there are a corresponding number of security baselines.  No one agrees on security, because everyone’s view is from their own perspective and the threats that they see or perceive.  As a result, some organizations have very strong and strict security (e.g., banks for example), while others have only marginal security.  The problem with this approach is that security is only as good as the weakest link in the chain.  So those organizations that have weak security practices become targets against the entire process chain.  As a result, in our interconnected world, that puts those organizations with strong security at risk if they are partners to those organizations that have weak security.  As a result, the card brands recognized that a single standard baseline was needed just to provide a basis for a consistent foundation on which to build additional security.

So, that is how we got where we are today.  Hopefully with this perspective you can now understand why the standards exist and their use in providing basic, essential security for cardholder data.

PCI Feels Like Something Is Being Done To Me

The title of this post is from a quote from a research paper published by Forrester titled ‘PCI Unleashed’.  Some of the thoughts discussed by Forrester are so true; I thought I would share a few of them.  If you have an opportunity, this is a paper well worth its cost.

One of the key points of the Forrester paper is that PCI was the result of a failure in corporate governance.  Forrester correctly points out that had organizations focused on keeping cardholder data properly secured in the first place, the PCI DSS probably never would have existed.

I can confirm that corporate governance is a root cause from my own experiences.  We talk a lot to organizations that think PCI is someone else’s problem and that their organization is being singled out.  In a lot of these organizations, security has been given the short shrift and has been perpetually on the back burner.  In these organizations, senior management sees security, and IT as a whole, as a money pit that does nothing for the organization.  This is because senior management is ignorant to what IT and security brings to the table because they have hired security and IT leaders that are mice that are occasionally seen, but certainly never heard.

The card brands have never been shy about why they generated the PCI standards; it was to protect their brands.  After all, when a breach occurs, it is almost always reported by the media as, “X number of Visa/MasterCard/American Express/Discover credit cards were disclosed by ABC Company.”  The card brands are always called out first, followed by the company and, if the company is a franchise operation, sometimes the franchisee is named.  The problem is that the general public typically only remembers the card brand names, sometimes the company name, and usually never remembers the name of the franchisee.  Want proof of this, just look at how badly TJ Maxx, HomeGoods, Marshalls and the like suffered after their parent, TJX Companies, incurred one of the largest breaches in history two years ago – NOT!  In a public relations coup, TJX Companies got the media to use TJX as the name of the breached organization which protected the brand names of their actual retail outlets.  As a result, sales at their retail outlets were only slightly affected by the breach news.

Another point that Forrester brings up is that naysayers point to the fact that PCI compliant companies have been hacked, therefore the PCI standard must not be effective.  As I have argued time and again, PCI compliance is not a one time, annual thing.  Compliance requires consistent execution of all of the PCI DSS requirements in order to remain compliant.  Consistent execution is a struggle for even the most diligent organizations.  It requires constant commitment by employees and management to the importance of doing security right all of the time.  The problem is that we are all human and humans are fallible.  So lapses will occur in any organization.  This is why all security frameworks are built on the concept of overlapping controls so that should a control go out of compliance, the whole house of cards does not come down.  What differentiates a good organization from a bad organization is that a good organization does not have so many lapses at once that entire control structures fail.  If you read the reports from TrustWave and Verizon Business Services on breaches they have investigated, a significant portion of those breaches were the result of systemic failures of the control environment.

Related to the previous point is another good point made by Forrester that the PCI standards are just a baseline and that organizations must go beyond the PCI standards to be as secure as they can be.  The PCI DSS is just the ante to be in the game.  If you want to be certain, you need to go beyond what the PCI DSS requires.  Why?  Because new flaws are discovered in software or new techniques are developed that make prior security methods obsolete or no longer as effective.  As a result, your security systems must adapt or new security methods need to be developed to detect and circumvent these new threats.  The PCI standards may address these new threats in a future version, but it is your organization’s responsibility to deal with them first.  This is also why most security experts say that security is a journey, not a destination.

One point of contention I have with this report is that they state, “Companies that already have robust security policies, processes, and technology do not have difficulty with PCI.”  Having worked with a number of organizations that meet these criteria, I can attest that this is not necessarily the case.  A lot of them have very robust security policies, processes and technologies; however, the day-to-day consistent execution was haphazard at best.  Management believed that they were in pretty good shape for meeting the PCI standards.  As we pealed the onion on their security environment, it became obvious that all management was seeing was a facade of security.  Security people said all of the right things and their policies and procedures said all of the right things, but the actual execution was not even close to consistent.  As they like to say, “They talk the talk, but they do not walk the walk.”  As a result, these organizations have struggled to change ingrained cultural issues and “bad habits” that can be much tougher to deal with than implementing new policies or technologies.

Finally, the next time you hear someone say that they feel PCI standards are not fair or they are impossible to comply with, ask them if they think they can afford a breach?  The best tidbit offered by this Forrester report is their estimated cost per account of a breach.  Forrester estimates that a breach costs between $90 and $300 per account breached, excluding lawsuits and any remediation efforts.  A modest breach of say 100 accounts carries an estimated cost of $9,000 to $30,000, excluding:

• Legal representation – you know that your organization will be sued or threatened to be sued over a breach and that will require your lawyers to go into action.  If you think lawyers are cheap, thing again, particularly when they are fighting a lot of battles;
• Public relations – just as in politics, your organization will have to put the best face on such an incident.  If your organization does not, the media will provide that “face” without you and it likely will not be a “good face”;
• Investigation – the card brands will require a forensic examination to be performed.  If you think lawyers are expensive, the costs related to a forensic examination will make you believe your lawyers are cheap;
• Remediation – there will be changes required to better ensure security and some of those changes will likely have a cost associated with them.  Only the lucky get away with policy or procedural changes with a minimal cost; and
• Loss of sales – your organization will lose customers over this lost of trust and future sales may also be affected if you did not adequately address the public relations aspect.

There are likely other events that will result from such an incident that will also cost your organization time and money.  The bottom line is that this is something your organization should avoid at all costs because, in my experience, most organizations do not survive such an incident.

Where Do I Find PCI Information?

This is a common question that comes up.  Where do you find all of the information on the PCI standards?

The first place to go looking is at the PCI Security Standards Council (SSC) Web site.  The PCI SSC Web site has a number of resources that you need to check out.  These include:

• The PCI Data Security Standard (DSS), the Self-Assessment Questionnaires (SAQ), Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)
• Frequently Asked Questions (FAQ)
• Information Supplements
• Locate a Qualified Security Assessor (QSA), Qualified Security Assessor Company (QSAC), Payment Application QSAC (PA-QSAC) or an Approved Scanning Vendor (ASV)
• PCI training

The FAQ is where the PCI SSC posts all of the questions and answers about the PCI standards.  Questions can be asked by anyone accessing the Web site.  The answers come from representatives of the card brands with the PCI SSC staff collecting and publishing the card brands’ agreed to responses.  Answers to questions typically take four to six weeks to obtain an answer.  However, it is not unusual for answers to take quite a while.  For example, in the case of securing pre-authorization data, it has been almost four years and we are still waiting for a response which the PCI SSC has promised they will deliver in the coming year.

Information Supplements are white papers written by various authors (usually PCI SSC staff or the card brands) and approved by the PCI SSC and the card brands that discuss a PCI standard requirement in detail to further explain a requirement and explain how a merchant or service provider can meet the requirement.  Informational Supplements that have been published thus far include:

• Skimming Prevention: Best Practices for Merchants
• Wireless Guidelines
• Requirement 6.6 (Application Code Reviews and Application Firewalls)
• Requirement 11.3 (Penetration Testing)

The PCI SSC has indicated that more Information Supplements are going to be issued in the future instead of updates to the standards.

Locating a QSAC, PA-QSAC and ASV is provided by a PDF list for each type.  Individual QSAs can be looked up by their name so that you can confirm they are in fact QSAs.  The PCI SSC recently sent out a clarification in one of their newsletters to QSAs discussing the fact that once a QSA leaves their QSAC; they need to join another QSAC who applies to have them transferred by the PCI SSC to retain their QSA certification.  If they do not join another QSAC, they are no longer allowed to use the QSA designation.  So, it is important to confirm that the people and firms you are talking with are in fact QSAs and QSACs.

If a QSAC is listed as in remediation does not mean that the QSAC and their QSAs cannot continue to perform PCI assessments, this just means that the QSAC was found deficient in meeting the documentation and reporting standards of the PCI SSC.  Even though the PCI SSC issued a well written release on the meaning of remediation, a number of unscrupulous QSAs are telling prospects that because a QSAC is in remediation, it cannot perform PCI assessments.  This is patently false and any QSA that makes such a statement should be reported to the PCI SSC for telling such a falsehood.

Of course the most obvious thing provided by the PCI SSC’s Web site is the standards themselves.  Unfortunately, without the benefit of the PCI SSC’s training program, interpreting the various PCI standards can be difficult, if not impossible.  However, there are a number of independent resources for people to use to get interpretations of the PCI standards.  One that I have actively participated in is the Society of Payment Security Professionals (SPSP) Forum.  There is also the PCI Knowledge Base that has a large contingent of QSAs and other experts that can provide guidance regarding the PCI standards.  There are also forums provided through Yahoo and LinkedIn as well as other similar services, but I am not as well versed in the accuracy of the information provided through those venues so I cannot recommend them.

So the next time you are looking for information regarding PCI, here are some resources you can use.

PCI Compliance Is Not Enough

In my opinion, Representative Yvette Clarke (D-NY) last week proved President Abraham Lincoln’s statement, “Better to keep one’s mouth shut and keep people guessing, than to open it and remove all doubt.”

Representative Clarke stated, “I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure.  It is not, and the credit card companies acknowledge that.”  I do not know where Representative Clarke’s aides have been, but I have not seen anything from any of the card brands that would indicate that they have acknowledged that PCI compliance is not enough.  To the contrary, based on the quotes from the card brands that I have seen the card brands and in particular, Visa USA believes that PCI compliance is the ‘Holy Grail’ of security.

Do not get me wrong.  Are there ways that the PCI standards can be improved?  No doubt about it.  However, the sort of standard that Representative Clarke is suggesting in her statements would not be workable, let alone implementable.  Moreover, if Michael Jones, the CIO of Michael’s Stores, thinks that the current PCI standards are overly complex, the standards that Representative Clarke is suggesting would probably take him completely over the edge.

Representative Clarke went on further to point to Chip and PIN as a salvation for security.  Again, Representative Clarke must not have the ‘best and brightest’ on her staff or they would have seen from a Google search that there are significant security issues related to Chip and PIN.  So while Chip and PIN could be a better solution, it is not the perfect solution Representative Clarke seeks.

PCI compliance is enough IF (and that is a big ‘IF’) a company is consistently diligent in applying the PCI standards day in and day out.  It is not the standard that is the problem; it is the consistent application of the standard every day that is the problem.  Why?  Because humans are involved and humans are fallible.

Representative Clarke misses the fact that there is a human element involved in all security and it is that human element that typically is the biggest problem.  Whether it is the programmer writing the firewall or application software, the person that erroneously configures a security device or a human being that misses or mistakenly responds to a security alert, it is those sorts of human errors that result in breaches.  Therefore, unless Representative Clarke intends to outlaw human beings from the practice of information security, she better own up to the problem and admit that breaches will occur regardless of her outrage.  What proper security will do is reduce the number and frequency of breaches, but it will never eliminate them.

What Representative Clarke also misses is that there is no such thing as perfect security.  If there were, banks would not be robbed as often as they are robbed.  Even with all of the sophisticated security in a bank, they are still robbed and fairly often, I might add.  The only reason bank robbers eventually are caught is that they get sloppy – they are human after all!

At the end of the day, even if a company invests in all of the security appliances, policies, standards, procedures and techniques, there is still a risk (small as it may be) that they could be breached.  In addition, no matter how diligent an organization is, they all get sloppy at certain tasks over time creating even more risk.  It is that risk that the dedicated attackers use to breach systems.  Because a dedicated attacker will do whatever it takes to create a breach no matter what barriers are put in their way.

Chip and PIN

Chip and PIN is back in the news and since I am heading to Europe next week on vacation, I thought I would pass this information along.

In a recent interview, Ms. Ellen Richey, Visa’s Chief Enterprise Risk Officer, indicated that Chip and PIN would head to the United States at some point.  As usual, there was an impression given that Chip and PIN is some sort of magic bullet that will cure all ills.  However, as you will see, Chip and PIN is not the “silver bullet” solution.

For those of you that have not traveled to Europe a little background.  Chip and PIN was developed by the British government to implement the Europay, MasterCard and Visa (EMV) standard for credit cards containing a built-in integrated circuit (IC), also known as the ‘Chip’.  The PIN part comes from the fact that you no longer sign a receipt when you make a purchase, you enter your PIN, just like at an ATM.  The purpose of developing Chip and PIN was to reduce the amount of fraud in face-to-face credit card transactions.  Chip and PIN is a worldwide standard that has only been implemented in Europe.  With the exception of Discover Financial, all of the other major card brands (Visa, MasterCard, JCB and American Express) have adopted various forms of the Chip and PIN technology.

Chip and PIN replaces the swiping of the magnetic stripe and receipt-signing common in the United States.  With Chip and PIN technology, the information contained on the magnetic stripe is also recorded on the Chip contained in the card.  The data stored in the chip is encrypted using either the DES, 3DES, RSA or SHA encryption algorithms.  Rather than swiping the magnetic stripe, the card is inserted into the payment terminal where the chip is read and decrypted and the transaction is submitted for authorization.  If authorized, the payment terminal is given to the cardholder and the cardholder enters their PIN into the terminal, a receipt is generated and the transaction is completed.  Most Chip and PIN terminals also have a magnetic stripe readers – you want the tourists to be able to use their “old” cards.  Chip and PIN terminals can operate over wired, dialup, 802.11 wireless or cellular networks.  In all communication environments, the terminals use secure transmission technology to ensure the privacy of cardholder data.

Looks good so far, but as I have said before, security is not perfect.  While Chip and PIN has significantly reduced fraud in face-to-face transactions, there are a number of issues regarding the security of this technology.  Those issues include:

• The EMV specification is open source and available from a number of sources, including EMV Co.  Because of this, any attacker can obtain the specification to build their own hardware and software for creating and processing Chip and PIN cards as well as creating attack methods to compromise the cards.  This has lead to a number of successful attacks resulting in cloned cards as well as obtaining and computing valid PINs.
• The entry of the PIN can be bypassed by the merchant.  If bypassed, the receipt is generated and signed by the cardholder, no different from a transaction performed with a traditional credit card.  While banks have tried to discourage this practice, this option is still available which does not provide any additional protections against fraudulent transactions.
• Theft of physical credit cards has risen since the introduction of Chip and PIN.  Criminals often hold victims hostage and threaten them with bodily harm until they reveal their PIN, which the criminals can confirm with a simple card reader.  Card readers are very easy to come by as banks sent them to all their customers along with their Chip and PIN cards when they were introduced.
• Banks encourage credit and debit card customers to take their card readers along with them.  The readers require the entry of the PIN in order to get information displayed from the card.  Security researchers found that because of frequent use of these readers, the readers had four more heavily worn keys that reduced the likelihood of guessing a card’s PIN from 1 in 3,333 to 1 in 8.
• Chip and PIN cards connected to PCs can generate authentication tokens, but the standards do not specify how these tokens are to be used in an online environment.  In addition, most e-Commerce sites and many banks have not implemented this capability into their Internet processing environments.  As a result, security of online environments is not always enhanced by using Chip and PIN cards.  In fact, some banks will not allow their Chip and PIN cards to be used online.
• Offline entry of PINs is supported by certain cards in certain countries.  In offline mode, the PIN is not encrypted, so it can readily be retrieved in plaintext from the terminal.
• The introduction of Chip and PIN technology has moved attacks to the merchant terminal or integrated point of sale (POS) solution. In the case of terminals, the terminal is modified by the attacker to record the information on the chip after it is decrypted (skimming).  Since most terminals use some form of high-speed network connection, the compromised terminal periodically sends the captured chip data to an attacker any where in the world. For POS, the attacker compromises the POS station and then obtains the chip data by monitoring the program that processes the Chip and PIN card.  Again, since most POS terminals are on a network, the attacker has their capture program send the captured card data to their computer.A number of incidents involving the skimming of Chip and PIN cards using tampered software or terminals have been documented.  Skimmed cards are typically sold in areas like Asia and the United States where magnetic stripes are still used.  The incidence of compromised terminals and POS systems has risen significantly since the introduction of Chip and PIN technology.

Many European organizations believe that Chip and PIN makes them immune to complying with the PCI standards.  The standards promulgated by the PCI Security Standards Council are worldwide in nature.  So, regardless of the type of card used, all merchants and acquirers are required to comply with all PCI standards.  This is legally enforced through merchant and service provider agreements between these entities and the card brands.  All agreements were updated worldwide over the last three to four years to include addendums that require all parties to be PCI compliant.

While Chip and PIN cards and their terminals are different, the integrated POS and the back end systems that authorize and process transactions are not different.  These systems provide their functionality the same way regardless of the card used.  At a minimum, these back end systems process and transmit cardholder data.  But these back end systems may also store cardholder data.  As a result, these back end systems must comply with the PCI standards.

Chip and PIN terminals are no different than their magnetic stripe swiping cousins.  They require proper configuration to ensure that they mask cardholder data and that they transmit transactions securely so that they comply with the PCI Data Security Standard.  They are also required to comply with the PCI PIN Entry Device (PED) standard.

The bottom line is that Chip and PIN reduces face-to-face transaction fraud, but it does not remove all of the risks involved in the use of a credit card.  As a result, there is still some amount of effort required to ensure that an organization’s credit card processing infrastructure is secure and complies with the various relevant PCI standards.

Update: Bruce Schneier has an interesting post regarding a new flaw in the Chip and PIN card that basically makes the PIN unimportant.

New Scam Out There

Here’s a new twist on an old scam that may be affecting retailers.

The old scam was to get small business owners to purchase office supplies, copier paper, copier toner, etc. at inflated prices and pay exorbitant shipping costs. The scam was driven by unscrupulous distributors that had sales people do the old hard sell on a merchant’s support personnel who didn’t know any better.

The new scam involves an automated calling system that dials the retailer. The message delivered from this automated system is that the retailer’s credit card terminal is not PCI compliant and that the retailer needs to order new terminals to ensure that they meet legal requirements and remain PCI compliant. The automated system then asks the call’s recipient to press a key to order terminals.

At its best case, this may just be another take on the old office supplies scam and is being run by an unscrupulous credit card terminal dealer to jack up sales. In a worst case scenario, this may be an attempt by some form of organized crime to get doctored terminals into the retail stream so that they can collect credit card data for resale.

Either way, the word needs to get out that retailers are being targeted.