Myths of PCI DSS

Dr. Anton Chuvakin @ Security Warrior Consulting

DISCLAIMER:

Security is a rapidly changing field of human endeavor. Threats we face literally

change 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 we‘ve 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.

Let’s get to the myths.

Myth #1 is pretty simple, but, sadly, very common: “PCI DSS just doesn’t apply to us,
because we are small, or we are a University, or we don’t do e-commerce, or we
outsource “everything”, or we don’t 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.
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 an
Internet-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 start
working on security and PCI requirements or your acquirer will make it clear to you at
some point when you won’t 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 don’t 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 can’t 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
account for individual organization’s 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 party
checkout 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”

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 (since
you now need to maintain compliance) and it certainly does not mean that you are done
with security. In addition, it doesn’t 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 regulated
information, 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 “say
Yes” 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, if
requested.

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.
 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 for
as 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 you’d 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 are
then 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 your network, 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 can’t 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
regulatory pressure. This myth is often used to justify not doing anything about data
security with examples like these:

• “Even if breached and also found non-compliant, our business will not suffer.”
• “We read that companies are breached and then continue being profitable; so
why should we care?”

Second, in addition to it being a wrong mindset, it is also simply wrong. PCI DSS packs
a lot of bite which includes fines, possible lawsuits, mandatory breach disclosure costs,
investigation costs, possible card processing rate increases, cost of additional security
measures and cost of victim credit monitoring. To top it off, a victim merchant can be
labeled “Level 1” and thus subjected to an annual QSA audit - at their own expense.
Admittedly, not every breach will incur all of the above, but some are simply
unavoidable.

Overall, it is much more useful to think of customer and cardholder data protection as
your “social responsibility” and not as something you do because of some scary “PCI
teeth” somewhere!

Conclusion: Eight Common PCI Myths – All Wrong!

Here are all the myths again:

• PCI just doesn’t apply to us, because…we are special.

• PCI is confusing and not specific!
• PCI is too hard
• Recent breaches prove PCI irrelevant
• PCI is easy: we just have to “say Yes” on SAQ and “get scanned”
• My network, application, tool is PCI compliant
• PCI is all we need to do for security!
• Even if breached and then found non-compliant, our business will not suffer

Now that you know what the myths are and what the reality is, you are one step closer
to painless, effective PCI DSS program as well as to secure and compliant organization
which cares about its customers by protecting their data.

ABOUT AUTHOR:

This is an updated author bio, added to the paper at the time of reposting in 2009.

Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert and

book author. He is an author of books "Security Warrior" and "PCI Compliance" and
a contributor to "Know Your Enemy II", "Information Security Management
Handbook", "Hacker's Challenge 3", "OSSEC HIDS" and others.
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, the
Netherlands, 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.