Myth #1 PCI Doesn’t Apply to Me

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.” More recent versions include “we use tokenization,” “we use EMV” (yeah right!—most of our US-based readers would say) or “we encrypt end to end.” “We outsource everything and thus have no PCI responsibilities” may in fact occasionally be true, but in most cases that is just that—a myth.

This myth takes over an organization and makes it oblivious to PCI DSS requirements and, almost always, to information risks and security requirements in general.

Here is one recent example: a campaign of Norm Coleman for U.S. Senate in 2008 has announced [1] that “If you donated online to Norm Coleman’s 2008 Senate campaign, or his recount efforts, you should call and cancel the credit card you used to make that donation.” The reason? Attackers compromised the site and stole both the credit cards numbers of donors and other private information. From the circumstances disclosed in the media, one can deduce that the information was stored in clear violation of PCI DSS rules.

Another example is more blatant: health care providers have been so busy with HIPAA that many became oblivious of PCI DSS arrival. A recent paper in “SC Magazine” called “PCI-DSS: Not on health care provider’s radar” [2] (notice the incorrectly hyphened “PCI–DSS” in the title…) reports:

 However, since Medicare reimbursement is not at risk with PCI-DSS compliancy, it has been virtually ignored. It doesn’t help that major health care publications are openly misinterpreting the PCI-DSS standards for health care providers, with statements such as: “[Providers] do not have to worry about compliance with PCI standards… they aren’t storing any card numbers”[2].

Myth #2 PCI is Confusing and Ambiguous

Myth #2 is just as pervasive: PCI is confusing and not specific. At first, it might seem like it is true: after all, this whole book is written about it! However, this is actually a myth, despite the fact that people who didn’t invest enough time into learning about PCI compliance might be more than a little confused about it.

In addition, this myth seems to be purposefully propagated by some people to “muddy the waters” and thus to make PCI DSS seem impossible to achieve and thus not worthy of even trying. Said people frequently have something to sell to merchants, something that presumably simplifies PCI compliance to nearly nothing. For example, when confronted with the need to change their business process to avoid storing the card data (simpler task as you now know) or with the need to secure card data (a harder task compared to not storing it), many smaller organizations go into the “ostrich in the sand” mode and try to pretend the problem is unclear, unsolvable, or confusing, instead of tacking it head on.

Namely, those under its influence often proclaim things such as

The reality is quite different: PCI DSS documents explain both what to do and then how to 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 most other existing security and risk management frameworks and regulatory guidance in spite of its length and breadth. Looking at some of the advanced information risk management documents (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.

Most of the gray area talk you hear about PCI DSS typically comes from companies that are trying to find creative ways not to do anything to their business or their technology or take risky shortcuts with other peoples precious data. Most of these can be solved by removing the emotion from the situation, and logically laying out the costs and risk associated with making a change versus staying in violation of the rules until caught and punished.

Let’s compare what PCI says and what some other guidance documents say:

PCI DSS in Requirement 5 states:

 “5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

 5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

 5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.”

ISO27002 states [4]: “Precautions are required to prevent and detect the introduction of malicious software, such as computer viruses, network worms, Trojan horses, and logic bombs.”

NIST 800-53 document “Recommended Security Controls for Federal Information Systems,” itself a 174 page tome, states [5] “The information system implements malicious code protection.” Additional NIST documents, such as 800-83 “Guide to Malware Incident Prevention and Handling: Recommendations of the National Institute of Standards and Technology,” do provide useful additional guidance on malware protection, but that is another 101 pages to read (!).

The aforementioned example demonstrates that even though PCI DSS needs some focused attention from the merchants, it is not confusing, but more specific than other industry security guidance. While the original PCI creators had BS7799/ISO17799 in mind, their standard ended up being much simpler than its ISO-created inspiration, but lost of few things that people consider important (e.g. all the security project management requirements).

Still, there are definitely areas in PCI security guidance that can be made more specific. For example, when PCI DSS document was updated from version 1.2.1 to version 2.0, the updated document contained several dozen clarifications and explanations, brought up during the review phase (see the PCI DSS v2 Summary of Changes document available on the PCI Council website for details).

As PCI DSS grows up, all the remaining ambiguity should be reduced through the efforts of participating organizations and by adopting to the needs and requirement of the merchants as well as the evolution of the threats.

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.

Myth #3 PCI DSS is Too Onerous

The next myth, Myth #3 is closely related to the above: PCI DSS is just too hard. Sometimes, it becomes too expensive, too complicated, too burdensome, just too much for a small business, about too many technologies or even simply “unreasonable” and “too much security.”

Sometimes this myth is close to reality, but not for reasons people think. “PCI is too hard” becomes true if merchants are treating their card data in a particularly negligent way. Think giant text files with unencrypted PANs on a website or payment terminals allowing remote access open with no password!

For example, we introduced a concept of “flat network” in Chapter 4, “Building and Maintaining a Secure Network.” To remind, it means a network that is not segmented by firewalls or filtering routers into zones or segments. Such network design means that if a single system handles card data, the whole network is in-scope for PCI DSS. Yes, that means all servers, all desktops, all network devices and everything else connected to it becomes subject to all PCI DSS requirements! Such situation, even if relatively rare nowadays, has been known to happen at large and medium merchants and thus make PCI DSS compliance very hard as the scope grows from a single system or a handful of systems to hundreds or thousands of systems. Every such system will need to be scanned for vulnerabilities, have its security configuration verified (these include the password length and complexity, use of encryption, etc.), have logging enabled and monitored, etc. In this case, “PCI is hard” will not be a myth, but PCI DSS guidance will not be the reason to blame: the operators of such a network will be.

Similarly, if a simple change in a business process will lead to removal of stored cardholder data, continuing to operate without such change and engaging in attempts to protect such data, rather than remove it will be shortsighted and lead to PCI being indeed “too hard.” As we say in the book “delete the data—and then secure what you absolutely CANNOT delete.”

On the other hand, the reality is that PCI DSS exemplifies common, 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 the security of your data before; hopefully this book will help to make PCI DSS easier and actually useful for your organization. PCI might not be easy for a large, distributed organization, but it is clearly much easier than creating and running a well-managed security program based on a good understanding of your risk across all types of data.

As observed by one of the authors, people who complain about PCI DSS being too hard and emitting loud calls for “Make PCI Easier!!!” are often split into two camps:

As you can guess, the organizations that fit into the first camp and those that fit into the second camp are very different. While some in the first will miss the joke in ScanlessPCI (a joke site set up by a band of security experts to poke fun at some of the organizations that ignore security), the second camp is often concerned with relating their “risk-focused” approach to PCI’s mostly “control-focused” approach.

It is possible to make PCI easier even for those in the first camp, those people who just “want it gone:” make doing the right thing easier for them (while making doing the wrong thing harder): not storing card data, outsourcing processing, using tokenization, etc. For example, a lot of merchants store card data because they are under the mistaken impression that such data falls under the “Financial Rule of Thumb” of storing financial records for seven years. Such actions are making PCI DSS much more difficult or, in the case of storing CVV2 or other prohibited data, impossible. Even for chargebacks, which obviously don’t go back seven years, storing the PAN and other sensitive data is just not needed today.

On the other hand, while in the second camp, one sometimes hears things like “we have a good security program and we manage our risk well!—why should we spend time on that PCI thing? We are probably in good shape already!” These organizations are likely doing a good job with security and want to use all that to quickly “prove compliance.” In this case, making PCI easier will include making it easier to assess, validate, and prove compliance and overall make the whole “assessment experience” a little less painful. Still, it will not be harder than building that risk management program that they already have built.

So, as we mentioned, you can make PCI harder for yourself by 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 third-party checkout service will do just the opposite and make PCI and data security easier. Review the previous section on Myth #2 and notice that not touching the cards will make your PCI experience so much easier—without going into the application security esoterics such as OWASP guides, SQL injection, cross-site request forgery, and other things better be left to those who enjoy writing books about PCI DSS compliance.

Myth #4 Breaches Prove PCI DSS Irrelevant

Myth #4 seems mostly driven by the media: it claims that “Recent card data breaches prove PCI irrelevant.” We 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. Note how much press time the catastrophes, corrupt politicians, weather anomalies, and various technology failures get; and the bigger the better!

However, it encourages some organizations to develop a negative, destructive mindset and thus to do a bad job with PCI DSS and data security. As a result, they would suffer from a devastating data breach, which is more than a little ironic because they were trying to “focus on the breaches, not on compliance.” Breaches of organizations that validated their PCI compliance should get more people to focus on security as well as on maintaining compliant and secure state, not the other way around. If a similar organization to you was breached, you now need to do a better job to not end up like them.

It is worthwhile to mention that QSAs carry part of the blame as well: cases where blatant security mistakes, severe configuration weaknesses, forbidden data storage, and even compromised systems were missed by the “easy grader” assessor who focused much more on writing a report quickly enough to make his margin and not enough on actually collecting the data for the report. In selecting a QSA—your “mandatory security consultant”—it helps a lot to focus on value delivered to an organization and not simply on price. Try to squeeze every penny of valuable security advice during that face time in the assessment process. In some cases, you can “get your own QSA”—have somebody from your organization certify as “ISA”—a new Council certification for internal security assessors.

Again, the reality is exactly the opposite: data breaches remind us that basic security mandated by PCI DSS is necessary but not sufficient. 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. Let’s pick a few examples from PCI DSS and check whether they are a good idea as well as whether they guarantee the absence of breaches. Table 17.1 shows excerpts from PCI DSS as well as their relation to data protection and data breach prevention.

Table 17.1 PCI DSS Requirements for Data Security

Table 17.1 allows us to conclude that PCI DSS controls are necessary to prevent card data loss and theft, but few of them can be considered sufficient.

Finally, one of the authors’ 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 PCI is All We Need For Security

Myth #5 is probably the scariest one of all: PCI is all we ever need to do for security. People in the grasp of this myth would proclaim things that will shock every security professional; for example:

The above maxims remind the authors of how many executives in the 1990s proudly proclaimed, “I have a firewall, I’m secure” and then refused to pay attention to “overblown” security concerns. At the very least, a firewall might block some suspicious connections, while report on compliance paperwork on its own does not provide any protection—and in fact only introduces additional risk of fire.

Recently, one of the authors was shocked to read the following on what purports to be a security blog post that talked about the now-infamous Heartland Payment Systems data breach: “Is complying to PCI not enough anymore?” It seems that even security professionals can somehow fall victim to this myth. Another common manifestation is an organization that doesn’t pay much, if any, attention to data security is being suddenly jabbed by PCI DSS requirements. More often than not senior management will “make” IT do “that PCI security thing.”

It often leads organizations to focus on “pleasing the assessor” and then forgetting that a happy assessor does not mean that your organization is protected from information security risks.

Moreover, 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 as you now need to maintain compliance—something that needs to happen daily (!). Also, it certainly does not mean that you are done with security. In addition, it also doesn’t mean that you are secure, just that you validated PCI compliance and hopefully made an honest step towards reducing your risk; now you need to maintain your compliant status and data security! As a reminder, while your QSA validates your compliance and is responsible for the Report on Compliance, merchant is solely responsible for maintaining compliance status between assessments.

Again:

Validating PCI compliance via on-site assessment or self-assessment does NOT mean that:

The reality is again different: PCI just mandates minimum security, not maximum or optimal. And PCI validation attests that such minimum security was present at the time of assessment (an astute reader will make a note that the word “present” needs to be replaced with “shown to or identified by a QSA”, but we will not succumb to such cynical urges).

PCI is basic security; it is a necessary baseline, a low watermark, which was never meant to be the “end state” of guaranteed secure data. No external guidance document, even well-written and followed with utmost diligence, can guarantee that—just as excellent police work can never guarantee “crime-free” environment. People don’t expect police, prosecutors, and laws to “end crime”—so why do some people think that QSAs, approved scanning vendors (ASVs), security vendors, card brands, and PCI DSS document will end cybercrime? This is a useful thought to keep in your head as you are finishing that PCI validation.

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, not the availability or fewer Internet-facing services or employee productivity. It only covers confidentiality, and not availability of cardholder 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—for a good reason.

Specifically, perfect PCI DSS compliance and validation will not:

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 systems and data today.

Myth #6 PCI DSS is Really Easy

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—it is about getting a mysterious “scan” from an entity called “an ASV,” then answering “Yes” to a bunch of lengthy questions and paying an “outrageous” fee of $8.95 with their monthly merchant account bill. Given that their view of PCI DSS as “annoying but tolerable” such merchants have fully succumbed to this myth. Their misconceptions are expressed in claims that PCI is about getting a scan and answering some questions or that it is a paperwork exercise or even that it can be bought for $8.95 monthly compliance fee (or, occasionally, a $100/year noncompliance fee)…

For merchants and service providers that don’t have to go through an on-site QSA assessment, PCI DSS compliance is indeed validated via external vulnerability scanning by an ASV and via filing an SAQ consisting of 13-220+ questions. However, it is worthwhile to mention that there is some work involved before many of the merchants can truthfully (!) answer “yes” to those questions and would be able to prove this, if requested by their acquiring bank.

Here is an example: Requirement 1.1.2 mandates a “current network diagram with all connections to cardholder data, including any wireless networks.” We show a few examples of such diagrams in Chapter 4, “Building and Maintaining a Secure Network.” Answering “Yes” to this question entails:

Clearly, this takes more than reading a book (we suggest “PCI Compliance”, 3^rd edition!) or clicking “Y” on a computer. This is what turns minutes into months and simple tasks into projects.

A slightly simplified reality is that a typical small merchant who processes cards online would at least need to do the following:

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 grounds for saying “yes” on the questionnaire and can prove it, even with no assessors or acquiring banks looking over your shoulder.

Specifically, even on the vulnerability scanning side, the typical perception that “get a PCI scan and you are done” is essentially misguided. PCI DSS requires you to 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 ASV, and these 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.” For larger businesses, companies can work with their QSA and ASV to reduce the scope of that external footprint if certain controls are in place and enforced.

Furthermore, the specific requirements placed on the depth of such scans. There is also a requirement to remediate all vulnerabilities, scored higher than 4.0 with CVSS for external scans or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved for internal scans. In essence, this is not “scan and done,” but “scan-fix-maintain” lifecycle.

Myth #7 My Tool is PCI Compliant Thus I Am Compliant

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 his 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 compliant organization, which literally have little to do with each other, even though both come from PCI Council. PCI DSS 2.0 states that “Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide provided by the payment application vendor (per PA-DSS Requirement 13.1).”

Just to remind you, PCI DSS is a “multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.” (PCI Council website [6]) On the other hand, PA-DSS is “to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS.” (PCI Council Web site [6]) The former applies to an entire organization while the latter applies to a payment application only.

In reality, there is no such thing as “PCI compliant tool, application, configuration or network,” regardless of what a vendor’s marketing department says. 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 entire puzzle.

Despite that, the authors have been asked multiple times by various industry colleagues about certain pieces of IT infrastructure being PCI compliant. Here is one recent example—Figure 17.2.

Figure 17.2 was shown to one of the authors with the question of “Is this PCI compliant?” Even though some people will start debating this with crafty arguments for “yes” and “no,” the immediate (and correct!) response was “no way to tell.” There are simply too many things that can make or break PCI DSS compliant status of an organization. For example:

The above lists only a few of the reasons for why the above pictured environment might or might not be part of a PCI DSS compliant organization.

Thus, “no way to tell” is the only genuine response. There is no way to judge PCI compliance on just isolated servers, pictured on a diagram.

Answering the question is only possible “in bulk,” considering all the conditions, criteria, and requirements, and the only way to achieve this is to follow your own path through the PCI DSS requirements. The “PCI DSS Prioritized Approach” lists the recommended, risk-derived order for following the requirements that can be helpful on your journey. The document can be found on the PCI Council Web site [6]. Figure 17.3 shows an example from the PCI Council document called “Prioritized Approach to PCI” [7].

As we mentioned, PCI DSS combines technology, process, policy, awareness, and practices as well. For example, Requirement 12 covers security policy, incident response practices, security awareness, and other nontechnical safeguards and controls. Don’t focus on isolated pieces; rather, build the big picture, track a path, and move ahead towards PCI DCC compliance and data security.

Myth #8 PCI is Toothless

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 that is also wrong on several levels.

First, it embodies the view that data security measures are only deployed due to regulatory pressure, such as from PCI DSS, and not from genuine need to reduce risk to information and transactions. This myth is often used to justify not doing anything about data security with merchants believing—erroneously that if even they are breached and then also found noncompliant, their business will not suffer. Similarly, people read the popular media and then ignorantly claim that companies are breached and then continue being profitable so they should not care about PCI and security. Just ask that question of a recently fired CSO and see what he says about “no impact on an organization.” Finally, they claim that compliance costs more than noncompliance without doing any research into this subject, which then leads to faulty decision making.

Honestly, such views are often held by merchants who are used to just accepting the risk of card data theft—until their businesses are no more (in some cases). In fact, in the pre-PCI era it made good sense to accept such risk because it was not the merchant’s loss, but the issuing banks that would need to reissue the stolen cards. Here is a commonly utilized conceptual risk formula¹:

If we apply it to this situation, we’d realize that before PCI the merchant’s risk was indeed exactly 0 and absolutely didn’t depend on threats that the merchant faced, as well as vulnerabilities his environment had. PCI DSS transferred the risk back to where it should belong—wherever the data is lost or stolen. Thus, one can say that PCI DSS created the risk for merchants to motivate them to protect the data as well as educate them about Data Security.

Second, in addition to being a wrong mindset, it is also simply wrong. PCI DSS noncompliance and resulting loss of cardholder data 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. It is really not only about the fines; among the above “teeth” the following were actually frequently observed:

To top it off, a victim merchant can be labeled “Level 1” and thus subjected to an annual QSA assessment—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! The companies talk about corporate social responsibility (CSR),² but often forget that caring for the private data of their customers that was entrusted it to them due to the current predominant paradigm—use of a payment card with a magnetic stripe – is the simplest form of corporate social responsibility. What more fits the definition of “embracing responsibility for the impact of their activities on the environment, consumers, employees, communities, stakeholders, and all other members of the public sphere,” than caring for those precious bits and bytes from the magnetic stripe?

Case Study

Next, we present a case study that illustrates what is covered in this chapter.

Summary

Here are all the myths again:

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 that cares about its customers by protecting their data.

Remember that PCI is basic security; stop complaining about it – start doing it! By focusing on immediately useful parts of PCI DSS, you can start towards a full-scale risk management program, backed up by implemented and maintained controls. Then, after validating that you are compliant, don’t stop: continuous compliance and security is your goal, not “passing an assessment.” For example, remember that compensating controls are usually temporary controls, not excuses to never do the right thing.

Overall, it is much more useful to develop “security and risk” mindset, not “compliance and assessment” mindset. Just as there is no true guaranteed “job security” today, there is no “guaranteed information security;” there is only one thing: doing the best you can do and being above average, so that attackers leave for greener pastures.

REFERENCES

1. Web site <www.kare11.com/news/news_article.aspx?storyid=542102>; 2011 [accessed 12.07.11].

2. “PCI-DSS: Not on health care provider’s radar” in “SC Magazine” online. <www.scmagazineus.com/PCI-DSS-Not-on-health-care-providers-radar/article/138783/>; 2011 [accessed 12.07.11].

3. PCI DSS SAQ. <www.pcisecuritystandards.org/saq/index.shtml>; 2011 [accessed 12.07.11].

4. ISO/IEC 27001:2005.

5. NIST 800-53. Recommended Security Controls for Federal Information Systems and Organizations. <http://csrc.nist.gov/publications/drafts/800-53/800-53-rev3-FPD-clean.pdf>; 2011 [accessed 12.07.11].

6. PCI Council. Website <www.pcisecuritystandards.org>; 2011 [accessed 12.07.11].

7. The Prioritized Approach to Pursue PCI DSS Compliance. <www.pcisecuritystandards.org/education/docs/Prioritized_Approach_PCI_DSS_1_2.pdf>; 2011 [accessed 12.07.11].