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.

1. Myths of PCI DSS
Dr. Anton Chuvakin @ Security Warrior Consulting
DISCLAIMER:
Securityisa rapidlychangingfieldof humanendeavor.Threatswe face literallychange everyday;
moreover,manysecurityprofessionalsconsiderthe rate of change to be accelerating. On topof that,
to be able to stay intouch withsuchever-changingreality,one hastoevolve withthe space aswell.
Thus,eventhoughI hope thatthisdocumentwill be usefulfortomy readers,please keepinmindthatis
was possiblywrittenyearsago.Also,keepinmindthatsome of the URL mighthave 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.

2. 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 bysome people inorder 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

3. account for individual organization’s risk profile. PCIguidance 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 PCIDSS exemplifies commonsense, baseline securitypractices, 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 securityeducation. 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”

4. 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 mentionabove, 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.

5. 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 withPCIDSS 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

6. 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 authorbio,added to thepaperat thetime of reposting in 2009.

7. Dr. AntonChuvakin(http://www.chuvakin.org)isarecognizedsecurityexpertandbookauthor.He isan
author of books"SecurityWarrior"and "PCICompliance"andacontributorto "Know Your EnemyII",
"InformationSecurityManagementHandbook","Hacker'sChallenge 3","OSSECHIDS" andothers.
Antonhas publisheddozensof papersonlogmanagement,correlation,dataanalysis,PCIDSS,security
management,etc- see all paperslinkedfromhisportal http://www.info-secure.org).Inhisspare time,
he also blogsat http://www.securitywarrior.org Inaddition, Antonhaspresentedandtaught
tutorialsatmany securityconferencesacrossthe world. Hisrecentengagementsinclude speakingat
eventsinthe UnitedStates,UK,Singapore,Spain,Canada,the Netherlands,Poland,CzechRepublic,
Russiaand othercountries. In addition,Antonalsoworkswithstandardsorganizationsonemerging
securitystandardsandservesonthe advisoryboardsof several securitystart-ups.
At thistime,Antonisbuildinghissecurityconsultingpractice,focusingonloggingandPCIDSS
compliance forsecurityvendorsandFortune 500 organizations.Dr.AntonChuvakinwasformerlya
Directorof PCICompliance SolutionsatQualys.PriortoQualys,AntonworkedatLogLogic,where he
heldthe title of Chief LoggingEvangelist,taskedwitheducatingthe worldaboutthe importance of
loggingforsecurity,compliance andoperations. Before LogLogic,Antonwasemployedbyasecurity
informationmanagementvendorinastrategicproductmanagementrole. AntonholdsaPh.D.degree
fromStonyBrook University.