Myths of PCI DSS by Dr. Anton Chuvakin

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

1/7

Myths of PCI DSS

Dr. Anton Chuvakin @ Security Warrior Consulting

DISCLAIMER:

Security is a rapidly changing field of human endeavor. Threats we face literallychange every day; moreover, many security professionals consider the rate of

change to be accelerating. On top of that, to be able to stay in touch with such

ever-changing reality, one has to evolve with the space as well. Thus, even though I

hope that this document will be useful for to my readers, please keep in mind that is

was possibly written years ago. Also, keep in mind that some of the URL might have

gone 404, please Google around.

Introduction

Payment Card Industry Data Security Standard (PCI DSS or,, just PCI) has transformed

the way many organizations view information security. While weve heard that

something will take information security from the wire closet to the boardroom many

times before, PCI actually accomplishes this for many organizations both large and

small. While following all of the PCI DSS guidance will not magically make your

organization secure or prevent all incidents, the standard contains many of the common

sense security requirements that are essential for protecting cardholder data.

PCI DSS was unified from card brand individual security mandates such as CISP and

SDP and established to increase the security of card-accepting merchants and thus

reduce the risk of card transactions and resulting fraud. As of today, PCI DSS

compliance includes merchants and service providers who accept, capture, store,

transmit or process credit and debit card data. The above quote from the PCI DSS

document makes it clear that the applicability of PCI is nearly universal.

In this paper we look at common PCI DSS myths and misconceptions. We will also

dispel those myths and provide a few useful tips on approaching to PCI DSS.

Lets get to the myths.

Myth #1 is pretty simple, but, sadly, very common: PCI DSS just doesnt apply to us,

because we are small, or we are a University, or we dont do e-commerce, or we

outsource everything, or we dont store cards, or we are not a permanent entity,

etc. This myth takes over an organization and makes it oblivious to PCI DSS

requirements and, almost always, to information security risk in general.

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

2/7

The reality, as we mentioned above is pretty simple: PCI DSS DOES apply to your

organization if you accept, capture, store, transmit or, process credit and debit card

data with no exceptions.

Admittedly, different things needs to happen at your organization if you have absolutely

no electronic processing or storage of digital cardholder data compared to having anInternet-connected payment application system. The scope of compliance validation will

be much more limited in the former case. For example, if a small merchant does not

store, process, or transmit any cardholder data on merchant premises but relies entirely

on third party service providers to handle these functions he is only responsible for

validating the parts of Requirement 9: Restrict physical access to cardholder data as

well as a small part of Requirement 12: Maintain a policy that addresses information

security for employees and contractors via a Self-Assessment Questionnaire (SAQ)

Type A (13 questions overall).

Overall, the choice is pretty simple: either you comprehend PCI DSS now and startworking on security and PCI requirements or your acquirer will make it clear to you at

some point when you wont have much room to maneuver.

Myth #2 is just as pervasive: PCI is confusing and not specific. This myth seems to

be purposefully propagated by some people in order to muddy the waters and thus to

make PCI DSS seem impossible to achieve and thus worthy of even trying. Namely,

those under its influence often proclaim things like:

We dont know what to do, who to ask, what exactly to change.

Just give us a checklist and we will do it. Promise!

PCI just confuses us we cant do it.

The reality is quite different: PCI DSS documents explain both what to do and how to

then validate it. Apart from people who propagate this myth, you just need to take the

time to understand the why (the spirit of the standard and cardholder data security),

the what (the list of PCI DSS requirements) and how (common approaches and

practices related to PCI).

PCI is actually much easier to understand than other existing security and risk

management frameworks and regulatory guidance. Looking at some of the advanced

information risk management document such as ISO27005 Information security risk

management or NIST 800-30 Risk Management Guide for Information Technology

Systems with their hundreds of pages of sometimes esoteric guidance is a refreshing

reminder that PCI DSS is, in fact, pretty simple and straightforward.

Finally, security cannot and will not ever be reduced to a simple checklist. Even today

some criticize PCI DSS for being a manifestation of checklist security which does not

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

3/7

account for individual organizations risk profile. PCI guidance is as close to a checklist

as we can get without actually leading to increased, not reduced, risk.

The next myth, Myth #3 is closely related to the above: PCI DSS is too hard.

Sometimes it becomes PCI DSS is too expensive, too complicated, too burdensome,

just too much for a small business, too many technologies or even just unreasonable.

The reality is that PCI DSS exemplifies common sense, baseline security practices,

which every organization needs to take into account when planning their IT and

business operations. PCI only seems hard if you were not doing anything for security of

your data before. Still, it might not be easy for a large, distributed organization, but it

clearly much easier than creating and running a well-managed security program based

on a good understanding of your risk.

Still, you can make PCI harder for making the wrong decisions. For example,

developing your own web application complete with credit card processing will increase

your PCI scope likely beyond your ability to handle. On the opposite, using a 3rd partycheckout service will do just the opposite and make PCI and data security easier.

Myth #4 seems mostly driven by the media: it claims that Recent card data breaches

prove PCI irrelevant. I suspect it stems from the fact that reporting failures and other

bad stuff typically draws more listeners, readers and watchers compared to reporting

successes and thus attracts more media attention. However, it encourages some

organizations to develop a negative mindset and thus to perform a bad job with PCI

DSS and data security and then suffer from a devastating data breach.

Again, the reality is exactly the opposite:data breaches remind us that basic security,mandated by PCI DSS, is necessary, not sufficient, but you have to start from the

basics before you can advance in your security education. As you learn more about

security, you usually come to realize that nothing guarantees breach free operation.

Finally, one of my colleagues likes to say that every breach proves that PCI DSS is

even more necessary. PCI DSS is a great start for security, but a really bad finish, as

we discover in the next myth

Myth #5 is probably the scariest one: PCI is all we ever need to do for security.

People in the grasp of this myth would proclaim dangerous things such as:

We have PCI handled - we are secure now

We worked hard and we passed an audit; now we are secure!

Or even, in its more extreme form,

I filed my PCI compliance documents; now I am compliant and secure

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

4/7

It often leads organizations to focus on pleasing the auditor and then forgetting that a

happy assessor does not mean that your organization is protected from information

risks.

This myth is actually wrong on multiple levels! First, validating PCI DSS via an

assessment or self-assessment does not mean that you are done with PCI DSS (sinceyou now need to maintain compliance) and it certainly does not mean that you are done

with security. In addition, it doesnt mean that you are secure, just that you validated

PCI compliance and hopefully made an honest step towards reducing your risk!

The reality is again different. As we mention above, PCI is basic security; it is a

necessary baseline, a lower watermark, which was never meant to be the end state of

guaranteed secure data. No external document, even well-written and followed with

utmost diligence, can guarantee that, just as excellent police work can never guarantee

crime-free environment.

Finally, PCI is about cardholder data security, not the rest of your private or regulatedinformation, not your organization intellectual property, not identity information such as

SSNs, etc. It also covers confidentiality, and not availability of such data. These quick

examples show that there is a lot more to data security than PCI DSS and there are

clear areas where PCI does not focus.

Thus, you are certainly not done with security even if you maintain ongoing PCI

compliance. For example, one of notable PCI QSAs likes to say that you likely need

PCI+ or even PCI++ to deal with risks to your data today.

The next myth, #6, is the opposite of myth #4: PCI is easy: we just have to sayYes on a questionnaire and get scanned. As merchants become more familiar

with PCI DSS, some start to feel that PCI is not that scary, because they succumb to

misconceptions such as:

What do we need to do - get a scan and answer some questions? Sure!

PCI is about scanning and questionnaires, right?

For smaller merchants, PCI DSS compliance is indeed validated via external

vulnerability scanning and self-assessment questionnaire (SAQ). However, it is

worthwhile to mention that there is some work involved before many of the merchant

can truthfully answer yes to those question AND would be able to prove this, ifrequested.

A slightly simplified reality is that a typical small merchant which processes cards online

would at least need to do the following:

a) Get a network vulnerability scan of the external systems, resolve the

vulnerabilities found and then rescan to verify that.

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

5/7

b) Do the things that the SAQ questions refer to and maintain evidence that they

were performed; then answer the questions affirmatively

c) Keep doing a) every quarter and b) every year until you no longer wish to accept

credit cards.

In other words, achieve PCI DSS validation and then maintain PCI DSS compliance foras long as you plan to accept cards. You can only answer yes if you have ground for

saying yes on the questionnaire and can prove it, even with no auditors or acquiring

banks looking over your shoulder.

Specifically, even on the vulnerability scanning side, a typical perception that get a PCI

scan and you are done is essential misguided. PCI DSS requires you run both Internal

and external network vulnerability scans at least quarterly (in reality, twice a quarter

since youd need to fix the vulnerabilities and then rescan to confirm it!) as well as after

every major network change. Internal scans can be run by in house security staff, while

the external scans must be performed by an Approved Scanning Vendor (ASV), and arethen used to satisfy your PCI Validation Requirements and are submitted to your

acquiring bank. By default, all Internet-facing IP addresses are in-scope.

Myth #7 is in believing that yournetwork, application, tool is PCI compliant with the

resulting conclusion that this achieves compliance for your organization. This myth

manifests itself in statements from merchants such as My payment application vendor

said this tool is PCI compliant or They put together a network and it is PCI compliant.

However, no tool can make you compliant. In fact, people often confuse PA DSS

certified application with PCI DSS compliance, which literally have little to do with each

other, even though both come from PCI Council.

In reality, there is no such thing as PCI compliant tool, application, configuration or

network, PCI DSS compliance applies to organizations only. You can struggle toward,

achieve and validate PCI DSS compliance only as an organization. Using PA DSS-

compliant application is only a small piece of the whole puzzle.

Moreover, PCI DSS combines technology, process, policy, awareness and practices as

wel. For example, Requirement 12 covers security policy, incident response practices,

security awareness and other non-technical safeguards and controls.

For example, I was once asked the following: if we connect this server to this other

servers and have a firewall in between, is this PCI compliant? The only genuine

response is that one cant tell. What if those servers have blank passwords? What if

there is no logging? There is no way to judge PCI compliance on just isolated servers.

Myth #8 is simply a view that PCI DSS Is Toothless. This myth shows a completely

wrong worldview of PCI DSS and security; a dangerous delusion which is wrong on

several levels. First, it embodies the view that data security can only happen due to

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

6/7

8/14/2019 Myths of PCI DSS by Dr. Anton Chuvakin

7/7

Anton has published dozens of papers on log management, correlation, data

analysis, PCI DSS, security management, etc - see all papers linked from his portal

http://www.info-secure.org). In his spare time, he also blogs at

http://www.securitywarrior.org In addition, Anton has presented and taught

tutorials at many security conferences across the world. His recent engagements

include speaking at events in the United States, UK, Singapore, Spain, Canada, theNetherlands, Poland, Czech Republic, Russia and other countries. In addition,

Anton also works with standards organizations on emerging security standards and

serves on the advisory boards of several security start-ups.

At this time, Anton is building his security consulting practice, focusing on logging

and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr.

Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Prior

to Qualys, Anton worked at LogLogic, where he held the title of Chief Logging

Evangelist, tasked with educating the world about the importance of logging for

security, compliance and operations. Before LogLogic, Anton was employed by a

security information management vendor in a strategic product management role.

Anton holds a Ph.D. degree from Stony Brook University.