Compliance, Compliance Testing and Security

I was recently on a Webinar presented by a major security vendor and one of their points was that executive management is finally starting to realize that compliance does not equal security.  If you read this blog regularly, you know I really do not like the phrase “compliance does not equal security” and I view it as a convenient dodge by those who use it as a way to weasel out of their responsibilities.

But during this Webinar I had an epiphany regarding this topic.  It is the confusion between security, compliance testing and reporting and the act of compliance by your technology, employees and business partners with your organization’s security policies, standards and procedures that is the problem.

I know I am just asking for flame mail with this post, but I am so tired of people looking to blame everyone but themselves about their inadequacies surrounding information security.  As I have done before, to paraphrase Tom Hank’s character in ‘A League of Their Own’, “There’s a reason security is hard.  If it wasn’t hard, everyone would do it.”

Security is not always easy, particularly when upper management does not have buy in.  But even when upper management supports security efforts, I have seen security personnel not take advantage of that fact and get the job done.  Security does not have to be hard, but it does take more than just slamming some firewalls and intrusion prevention gear down, tossing a SIEM into the mix and thinking you are done.  Security is a never ending journey because someone is always coming up with new ways to attack you.

Anyway, to start off, let us take a look at some definitions first so we are all on the same page.

Compliance is defined as:

“Conformity in fulfilling official requirements.”

“Official requirements?”  Could that possible mean your organization’s security policies, standards and procedures?  You bet.  In this instance, we are talking about those that correspond to the PCI DSS, but this also applies to ISO 27K, FISMA, HIPAA, GLBA or any multitude of frameworks and regulatory requirements.

Conformity is defined as:

“Compliance with standards, rules, or laws.”

Based on these definitions, security is all predicated on complying with what are deemed an adequate set of security policies, standards and procedures.  Conversely, if you are not complying with an adequate set of security policies, standards and procedures, then your organization cannot be as secure as it could be.  As a result, compliance has to equal security as long as the security policies, standards and procedures are considered adequate.  Therefore security professionals that quote the mantra, “compliance does not equal security” either have a problem with the compliance side of the equation (most likely) or with the standards/frameworks (the dodge).

Over the years there have been a lot of discussions about the PCI DSS, ISO 27K, FISMA and other security frameworks and whether or not they are adequate.  The important thing to remember is that all of these standards or frameworks are merely ante into the information security game.  They are the bare minimum or a baseline to get to a basic level of security.  Should you being doing more?  Definitely, but what those efforts beyond the standard/framework are depends on what you are trying to secure, your network and application architectures and a multitude of other factors related to your computing environment and how it is used.  Those are factors that cannot be taken into account by any standard/framework because they would start to become impossible for others to follow and implement.  The bottom line here is that if you want someone to tell you exactly what to do to secure your networks and applications, go hire a consultant you trust and they will tell you everything you want to know.

The rub in all of this is that, based on the breach reports from Verizon Business Services, Trustwave, et.al. as well as compliance testing reports I have reviewed, none of you out there are 100% compliant to begin with, let alone even close.  Every organization I am aware has problems complying with the basics, let alone with any advanced security requirements in the published standards/frameworks.  So if you cannot comply with what you already have, explain to me how a different framework is going to change that fact unless it is less stringent than the framework you are already trying to use?  And if that other framework is less stringent, while that may solve the compliance issue (which I seriously doubt), exactly how is a less stringent framework going to make you secure?  The answer is that it will not make you secure.

What security professionals struggle with is that compliance is a never ending, 24x7x365 effort.  Drop your guard for an instant and it can be game over.  But provided your security policies, standards and procedures are appropriate and detailed (the reason why you want to use an appropriate standard/framework), your organization is not as secure as it can be unless your personnel and devices comply 100% of the time with every defined security policy, standard and procedure.  If you want confirmation of these facts, again, just look at the breach analysis reports year after year.  The reason there are breaches is because of non-compliance with one, but usually more, of an organization’s security policies, standards and/or procedures.

This brings me to the rumblings of late regarding a rethinking of defense in depth.  Defense in depth is predicated on using layers of security devices and controls to minimize the risk that a security incident occurs not to completely prevent an incident although you might get lucky.  For example, firewalls are the sledge hammer of security tools.  However, because we need to have ports open for outsiders to access applications, we follow our firewalls with intrusion detection/prevention devices to ensure that no one abuses the protocols used by the ports.  We follow that up with monitoring of log data from the firewalls, IDS/IPS, routers, switches and servers to identify any “sneaky” attacks using the protocols we allow.  The layers are there to cover the various holes we need to have in order to make our networks and applications function.  The tighter and smaller we can make those holes, the more secure we will be, but there will still be some amount of risk.  So we bring in more layers to cover those risks until it is more expensive to address the risk than to accept the risk.  That remaining risk is the residual risk that we therefore manage and control through detection and correction.

The other thing defense in depth relies on is the control triad.  The idea being that, because you cannot entirely prevent every security incident, you need a way to detect the incident so that you can take action to stop or minimize the impact of the incident.  You follow that up with periodic assessments of your control environment to identify and correct any deficiencies or improve your program based on new information regarding security.  The follow up assessments can be activities such as a root cause analysis (RCA) of an incident, an internal audit of user accounts and user rights or brining in a network security team to assess your security architecture and controls.  All of these activities will result in findings and recommendations to make your security systems and controls better.

And that brings us full circle to the PCI assessment.  It is merely a tool used by the acquiring banks, card brands, processors and others to obtain reasonable assurance that your organization is doing what it can to minimize the possibility of a breach of cardholder data.  It is not meant to be, nor could it ever be, an absolute complete assessment of an organization’s security posture and therefore provide absolute assurance that a breach will not occur (even though the PCI SSC and card brands tend to imply that fact).  Compliance assessments are only a snapshot of personnel and device compliance at the time the reports were written.  This is no different than going to the doctor for your annual physical which results in a snapshot of your health at that point in time.  It is not that those compliance reports are worthless; they just need to be referenced and used properly based on the fact that they are a snapshot.  Just as your doctor will tell you to lose weight or stop smoking, compliance reports provide recommendations on where you can make improvements or adjustments in your policies, standards and procedures based on what compliance evidence was found, or not found, during the assessment.

So, what are the lessons to be learned?

• Security is not and never will be perfect; there will always be residual risk that must be managed and controlled.
• Compliance does equal security, at least as best as your preferred standard or framework defines it plus whatever enhancements you have made.
• Compliance assessments and reports point out where your organization was not compliant and needs to do better, not to prove your organization is secure.

Use the tools at your disposal correctly, stay current on threats and monitor your security posture and you will likely live a long, prosperous and secure life.

Keep hiding behind “compliance does not equal security” and you will forever be living off of your “luck” until it runs out (usually sooner rather than later).

How The PCI Standards Will Really Die

Welcome to the new year.  I hope the holidays have been treating you well and the coming year is good as well.

There have been a number of articles written about why and how the PCI compliance process will die.  It is not that I look forward to the PCI standards dying as they have brought a needed visibility to information security and privacy as well as the fact that PCI keeps me gainfully employed.  However if things stay on their current trajectory, the PCI standards will eventually die, but not for the reasons being quoted in today’s articles.  The real killers of the PCI compliance process will be the card brands and the PCI Security Standards Council.  Yes, the very folks that brought us the PCI standards will bring the ultimate demise of their precious set of standards.

The first death knell I see is that it is very easy to issue edicts from on high when you do not have to implement them.  Over the years, clarifications have been issued, quality assurance reviews performed, forensic examinations conducted and a host of other activities have resulted in “enhancements” to how the PCI standards are assessed and enforced.  Do not get me wrong, a lot of what has been done was needed and appreciated.

However, by the same token, some of what has come down has been a nightmare to implement.  Any QSAC not using some sort of automated system to conduct their PCI assessments will find it impossible to meet the current and any future documentation and tracking standards now required by the PCI SSC’s QA process.  Under the current standards, QSACs need to document who they interviewed and what the persons were interviewed about as well as tying documentation and observations to the tests performed.  Without some sort of automated process, these requirements are just too intensive to perform manually.

Documentation received and reviewed needs to have its file name, date of issue and a description of its purpose in the PCI assessment process documented.  The basic PCI DSS has a minimum of around 200 discrete documents that are required for the PCI assessment process.  The average we see for most of our engagements is over 600 documents which also include not only policies, standards and procedures, but configuration files, interview notes and observations such as screen shots, log files and file dumps.  You really have to question any QSAC that tells you they manually manage the process.  They either have an amazing and magically efficient project management process, they have very, very inexpensive staff (i.e., overseas labor) or they are short cutting the processes and producing a work product that does not comply with the PCI SSC QA program and have yet to be assessed by the PCI SSC (the most likely scenario).

Even using simple SharePoint or Lotus Notes solutions are not cheap when you consider the cost of the server(s) and the storage of all of documentation collected, which can be around 5 to 10GB per project, as well as all of the requisite system maintenance.  Servers and storage may be cheap, but it all adds up, the more clients you assess.  And speaking of the storage of documentation, the PCI SSC requires that documentation related to PCI assessments be stored for at least three years.  For those of us with electronic work paper management systems, this is not a problem.  However, given the amount of paper generated by these projects, those QSACs using the traditional paper filing methods will find a lot of shelf space taken up by their PCI engagements if they are truly following the procedures required by the PCI SSC.

All of this drives up the cost of a proper PCI assessment, more than I think the card brands and the PCI SSC are willing to admit.  It is not that I think the card brands and PCI SSC do not care about this situation, but more related to they do not have an understanding of the operational ramifications of their edicts.  The card brands and PCI SSC tread a very fine line here and to this point they have been heavy handed in the issuing of their edicts.  Going forward, the PCI SSC needs to ask the QSACs, Participating Organizations and ASVs to assess the cost and time impacts of these edicts so that they can be weighed against their benefits versus what is done now which is more of a procedural and proofing review.  If this is not done, there will soon come a point where merchants and service providers will push back hard and refuse to go through the process due to the cost and the amount of time involved to be assessed.

The next death knell is the inane process that is called the PCI Report On Compliance (ROC).  When the PCI SSC did not have access to the QSACs’ work papers, the current ROC writing process made some sense as there was no other way for the PCI SSC or the processors and acquiring banks to know if the QSACs had really done the work they were saying they had done.  However, all of that changed a number of years ago when the PCI SSC required QSACs to add a disclaimer to their contracts stating that the PCI SSC had the right to review all work products.  Yet even with this change, we continue to have to write an insanely detailed ROC, typically numbering in a minimum of 300+ pages for even the most basic of ROCs.

Unfortunately, there are QSACs out there that apparently have not been through the PCI SSC QA process and that dreaded of all states – Remediation.  As a result, they have much lower costs because they are not documenting their assessment work as completely as they need to and are not sampling, observing or interviewing like QSACs that have been through the QA process.  In addition, based on some work products we have seen, they also do not care about the quality of the resulting ROC as it looks entirely like a ‘find and replace’ of a template and makes no sense when you read it.  In talking to other large QSACs that have been through the QA process multiple times, the PCI SSC has indicated that they are monitoring the large QSACs more than the little QSACs because there is more risk with the large QSACs.  While true to an extent, we have encountered a number of smaller QSACs that perform assessments for large clients due to their much lower cost structure and their willingness to ‘overlook’ compliance issues.  If the PCI SSC does not go after these QSACs soon, there will likely be a number of breaches that occur due to the QSACs’ lack of diligence in performing their assessments.

I know of a number of QSACs that would like to see Bob Russo and the representatives of the various card brands to actually work as staff on a few PCI assessment engagements so that they can better appreciate the inordinate amount of work involved in generating a ROC.  I think they would be shocked at the amount of work effort they have driven into a process that is already too complicated and prone for error.

As it stands today, the ROC writing, review and proofing process is probably 50% to 60% of a good QSAC’s project costs.  To address this, the PCI SSC QA group tells QSACs to develop one or more templates for writing the ROC which, from what we have seen from some other QSACs, means a lot of mass ‘find and replace’ to speed the ROC writing process.  For the last few years, a number of QSACs have brought the ROC writing process up at the Community Meetings.  However the card brands continue to shoot down any sort of changes to the process.  As a result, the cost of producing a ROC is driven by the size and complexity of the merchants’ or service providers’ cardholder data environment (CDE).  These costs will only continue to rise as long as the PCI SSC does not allow QSACs to mark items as ‘In Place’ with only a check box and rely on the QSAC’s work papers versus the verbosity required now.  If this sort of process can work for financial auditors, it can work here as well.

A third death knell is the PCI SSC and card brands continuing to quote that the majority of breaches are the result of organizations not complying with the PCI DSS.  In discussions with a number of the PCI forensic examination companies, I am hearing that the card brands cannot believe the fact that more and more organizations were PCI compliant at the time of their breach.  The PCI SSC and card brands have apparently convinced themselves that the PCI standards are “perfect” and they cannot imagine that an organization could be breached unless that organization was not complying with the PCI standards.  There is no security standard that I am aware that totally prevent breaches.  So while the PCI standards are good baseline security standards, the card brands and PCI SSC seem to have forgotten that security is not perfect and that any security standard only minimizes the damage done when a breach occurs if the standard is truly followed.

And as organizations have gotten the PCI “religion,” the effort required to compromise them from the outside via traditional attacks has increased significantly.  As a result, successful attackers have changed strategy and work on social engineering their way past the bulk of an organization’s security measures.  The PCI DSS only has a little bit on social engineering in requirement 12.6 regarding security awareness training.  And even those organizations with the most robust of security awareness programs will tell you that, even after extensive security awareness training, human beings are still fallible and that some people still do very questionable things that continue to put organizations at risk, sometimes significant risk.  Even when you have the most diligent of employees, they still make mistakes in judgment from time to time.

Until the human element can be totally removed, there will always be a certain amount of risk that will never go away.  Again, the PCI SSC and card brands seem to not want to acknowledge the failings of the human element and appear to believe that technology is the savior based on the focus of the PCI standards.  However time and again, every security professional has seen very sophisticated security technologies circumvented by human error or just plain apathy towards security (i.e., “it always happens to someone else, not my organization” or “we’re too small to be a target”).

Until the PCI SSC and the card brands drop the “holier than thou” attitude toward the PCI standards and stop the public pillory of organizations that have been breached, there will continue to be editorial commentary regarding the pointlessness of the standards and ever more serious push back to complying with the standards.

These are the reasons why the PCI SSC and the card brands will be the ones that will kill the PCI standards.  At the moment, they are so far removed from the process; they do not understand how complicated and expensive the process has become which is why merchants and service providers are complaining about the ever increasing costs and effort related to the PCI assessment process.

The PCI SSC and card brands also seem to have forgotten that QSACs have to make money doing these assessments and, when you pile on clarifications and edicts that do nothing to streamline and simplify the process; you are only driving the costs of the process higher.  And higher costs only make merchants and service providers, who are on thin margins to being with, even more incentivized to use the much lower cost QSACs, driving the diligent QSACs out of the market, thus increasing the likelihood of breaches.

Again, it is not that I want the PCI standards to go away as I think they have brought a real benefit.  However, if these issues are not addressed, the PCI standards will end up going away.  I fear that, with them gone, there will be no carrot to ensure the security of cardholder information and we will end up back where we were before the PCI standards existed.

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.

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.

Throwing Down The Gauntlet

I am having a bad day and just got done with a call with an acquiring bank and their PCI compliance coordinator.

What got me in a really foul mood was their demanding of my client that they take certain actions to better ensure the security of the acquiring bank’s transactions.  I do not know what it was, but their request just hit me wrong and I went on a rant.  However, after I was done, I started to think about it and said to myself, “Why not?”

My rant to this poor person revolved around why the card brands and acquiring banks do not expend their efforts to fix the credit card fraud problem instead of addressing the symptoms?  For the last ten years, the card brands have developed their various security programs that were merged together to form the various PCI compliance standards.  While these standards address the shortcomings of the existing processing environment, my impression is that the card brands are doing little, if nothing, to actually address the real problems.

How about we force the card brands to develop a truly secure credit card and related secure transaction processing?  Given the technology available today, one would think that with the right people involved, a secure credit card could be readily developed and at the same time, a secure transaction processing environment could be designed that does not allow the storage of cardholder data except at those points where it is required.  And at those points where cardholder data needs to be stored, these points are heavily secured, monitored and fortified against attack and the breaching of data.  Those projects alone would probably go so far as to reduce card fraud and breaches by 90% to 95%.

Yes, I know that such changes would not come quickly, but you might be surprised.  If a new, secure process and card was introduced and it provided the benefits that I think it likely would, a lot of merchants might actually have a reason to get on board and spend the money to fix the real problem.

So, how about it card brands and acquiring banks?  Are you up to the challenge?

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.