Myths Of Pci Dss By Dr. Anton Chuvakin

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 DSScompliant 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.