PCI DSS

PCI Isn’t Risk-based! (and other PCI myths)

As an infosec practitioner and QSA, I’ve been deeply involved in PCI since its inception. As a former educator (I taught high school social studies for eight years), I believe in the reductionist method for teaching complex subjects. In these articles I will combine my experience to deconstruct many of the problems – typically rooted in misunderstandings, or myths – I encounter when performing PCI assessments.

Let’s start with the biggest myth of all – PCI isn’t risked-based.

It absolutely is; there is no other single factor more fundamental to solving the PCI compliance challenge. Allow me to explain by paraphrasing a recent conversation with a client:

Client – “I must be compliant in four weeks or I’ll go out of business!”

Me – “So, PCI is mission critical?”

Client – “Yes.”

Me – “OK. That’s a tight deadline, but it’s possible if you know which requirements apply, have the requisite controls in place, and can provide evidence per the test procedures. Are you ready?”

Client – “Yes. We don’t store credit cards!”

Me – “Cool.”

With that statement – “We don’t store credit cards” – the red flag is up.

Scoping rules for PCI are more complicated than that.

The client may not know what he doesn’t know. Just a few more questions and I can confirm – the client is not ready:

• My first questions are for the client point of contact; I need to understand his/her role in the company, and PCI or other data security skills and experience. In this case, I learn the client PoC, the person representing his company and coordinating company resources to prove compliance, is a finance guy. He has no prior experience with PCI, is not an infosec professional, yet is managing a mission critical function. Nobody in the organization has significant experience or training with/for PCI or data security.

• Further questions reveal the organization doesn’t understand the full extent of PCI scope – they did not realize the scope of the assessment must consider much more than storage of cardholder data (CHD). For example, they did not consider their application, which processes and transmits CHD, in scope – consequently they did not apply required controls in all places needed.

• I also ask the client why they’re having a third-party assessment, rather than self assess. As it turns out, the client is a service provider, and their most important customer demanded proof of compliance. The client assumed this meant having a QSA perform the assessment. The salient point, however, is the client is reacting to external pressure rather than adhering to an internal IT security program.

More often than not, these are indicators of deeper, systemic issues. Further inquiry reveals an incomplete and inaccurate inventory of in-scope systems, little understanding of their data flow, no diagrams, no vulnerability scans, no penetration tests, and so on. All they know with certainty is their deadline date. All I see is a client whose IT department doesn’t have the operational capability to implement and maintain a compliant environment.

So, sure. The PCI DSS, the requirements themselves, are not risk-based. (*sarcasm*)

All relevant requirements apply to all in-scope systems, period. This client, however, has not fully appreciated the risk of non-compliance.

A simplified risk model looks at three things:

• Vulnerability – what could happen? (e.g., getting hacked, fired, departure of key personnel, etc.)

• Likelihood – how likely is the vulnerability going to be a problem?

• Magnitude – the impact (e.g., financial loss, system down time, reputation, etc.)

In my client’s case, the vulnerability is being found non-compliant, the likelihood of being non-compliant went way up when their customer demanded proof of compliance. The magnitude, the impact of being non-compliant? According to the client, they’ll go out of business if they can’t satisfy their customer. As a service provider it was inevitable. At least one of their customers would demand proof of compliance.

Too bad they didn’t consider this possibility earlier. Too bad they didn’t consider the risk of going into business as a PCI service provider without the organizational and operational infrastructure needed to understand and meet customer expectations. The ability to implement and maintain compliance is directly tied to organizational capability, which, in turn, is tied to risk. After all, if PCI is mission critical, shouldn’t you have the resources (mainly people) to get there?

So, what’s the solution?

It reduces to a relatively simple equation; the client either:

• Simplifies the environment to suit their organizational capacity, or

• Increases organizational capacity to implement and maintain risk-based infosec policies and procedures

The equation is that simple, but solving it starts with understanding your company’s risk appetite – if it’s low, you simplify. If it’s high then boost capability. How do you determine risk appetite? Basically, that’s another simple concept – how much money will you make? If it’s a lot you would probably have a higher risk appetite, and be willing to invest enough in your people, processes and systems to protect your opportunity.

What does simplify mean? Basically, two things:

• Define business critical functions

• Eliminate non-critical functions, and outsource the rest

What does boost capacity mean? Again, two things:

• People – hire people who can develop, implement and maintain a mature infosec program

• Funding – enable the organization to meet program goals

In summary, let me boil it down even further. If you store, process or transmit credit cards, you are obligated by your merchant bank and the card brands to ensure the security of the cardholder data from receipt to authorization, and post-authorization in some cases. You can meet these obligations internally by building the organizational capacity to do so, or you can outsource responsibility to service providers. If you make organizational decisions of this magnitude without a mature understanding of risk you will likely struggle with PCI compliance.

___________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

Contact us today for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

____________

Written by Steve Pratt

Steve Pratt has been a consultant and assessor since PCI’s inception in 2005. He also served eight years in the US Navy, and did stints as a sportswriter and high school teacher. He holds a master’s degree in history, along with MCSE, CISA, CISSP and QSA certifications.

At SecureTrust, Steve provides IT risk assessment, data privacy and general IT security consulting, in addition to performing PCI assessments. He tends to focus on organizational and business culture issues which, he believes, must be resolved before technological controls can be implemented in a repeatable and sustainable manner.