Which three 3 of these are PCI DSS requirements for any company handling processing or transmitting credit card data select 3?

Publisher Summary

The Payment Card Industry Data Security Standard (PCI DSS) requirement to protect cardholder data covers two elements—protect stored cardholder data, and encrypt transmission of cardholder data across open, public networks. In case of PCI DSS, logging and monitoring requirements are meant to provide auditing, and monitoring for the infrastructure. This key tenet is about knowing who is doing what with the data at any given time, and on being able to prove it via logging, and monitoring. PCI standards dictate that stored cardholder data can be rendered unreadable, such as encrypted, masked, truncated, or tokenized. Encryption will protect the data from being used by the malicious hackers, and thus, the goal of PCI DSS that is to reduce the risk of transactions will be preserved. Only upon failing to protect the data with strong cryptography, PCI DSS allows implementing compensating controls to mitigate the risk if one is unable to meet this requirement directly. PCI DSS mandates certain key management practices, if encryption is a chosen method of rendering data unusable. The document details 12 different items for the proper management of encryption keys.

A Perfect Example of Myth #1 at Work!

PCI DSS is not about storing cardholder data; it is about those who accept payment cards or capture, store, transmit, or process such card data. Want to guess whether most health care providers accept cards? Didn’t think so—the number is probably close to 100.00 percent, as most US readers can attest from their experiences. Indeed, the paper mentioned earlier [2] confirms: “In 2009, virtually all health care providers take credit cards—and virtually none of them are PCI compliant.” Now in 2012, the situation has barely changed. While HIPAA enforcement seems to have increased across Health Care providers, PCI DSS still remains “a big black hole” for many of them. Additionally, most such Health Care providers do not run a compliance program that can accommodate the needs of multiple regulations. They deal solely with HIPAA and adjusting the controls and practices to another regulation becomes fairly hard for them.

NOTE

Question: If I only accept cards from June to August each year and I only use a dial-up terminal, I am “safe from PCI,” right?

Answer: Wrong. Even though your scope of PCI DSS validation is very, very small, you are definitely subject to its rules because you—surprise!—accept payment cards. PCI DSS applies to those who “accept, capture, store, transmit, or process credit and debit card data.” If you do, it applies to you—end of the story. No myths can change that.

Interestingly enough, one of the data elements required to be protected under HIPAA is customer payment information, which often means “credit card data.” This means that HIPAA technically preceded PCI DSS when it comes to cardholder data security! However, this doesn’t stop health care providers from ignoring both regulations in one fell swoop.

NOTE

Question: If I use external tokenization and cardholder information never enters my environment, am I “PCI OK?”

Answer: Possibly! If your merchant agreement does not mention PCI DSS, none of your employees can see the data, and it is not handled anywhere on your systems, your PCI responsibility might be nonexistent.

The reality, as we mentioned earlier is pretty simple: PCI DSS does apply to your organization if you accept payment cards or capture, store, process, or transmit any sensitive payment card data (such as PAN) with no exceptions. If the data touches your systems, they are in scope for PCI DSS assessment and, obviously, your organization has PCI DSS responsibilities. Whether you cure, educate, rent, offer, sell, or provide services doesn’t matter—what matters is whether you charge! If you do, PCI DSS does apply. Hopefully, if you picked up this book while being unsure whether PCI DSS applies to your organization, reading this book convinced you that becoming compliant and secure is indeed in your future if you deal with payment cards.

Admittedly, different things need 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 and so your PCI project will be much, much simpler. 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 a small part of PCI DSS. Specifically, he would be responsible for 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).

Let’s explore this example in more detail. As we covered in Chapter 3, “Why Is PCI Here?,” payment card brands such as Visa and MasterCard label merchants that process fewer than 20,000 e-commerce transactions a year or fewer than 1 million card present transactions as “Level 4.” As you now know, such merchants currently are recommended to validate their PCI compliance using a SAQ.

In addition, as described in PCI DSS standards, if a merchant matches the criteria below, he is considered to be “validation type 1” and needs to fill the SAQ Type A (the shortest). The criteria are as follows:

Merchant accepts ONLY card-not-present (i.e. eCommerce) transactions.

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.

The third-party service providers handling storage, processing, or transmission of cardholder data is confirmed to be PCI DSS compliant.

Merchant retains only paper reports or receipts with cardholder data, and such documents are not received electronically.

Merchant does not store any cardholder data in electronic format.

Explained simply, the aforementioned criteria describe a situation where a merchant accepts credit cards as payment, but does not have any electronic storage, processing, or transmission of cardholder data. Think about it for a moment! PCI DSS doesn’t apply if you do not store, process, or transmit any card data on your premises (or your systems located off your premises such as outsourced, hosted or shared cloud systems) at all! This example highlights that fact that card acceptance is sufficient to make the merchant to fall under PCI.

The exact scope of its validation as covered by SAQ Type A is shown in Figure 17.1.

The merchant needs to validate part of Requirement 9 and part of Requirement 12. Specifically, sections of Requirement 9 cover the storage of physical media (printouts, receipts, etc.) that has cardholder data. For example, quoting from PCI DSS SAQ Type A [3]:

9.6 Are all paper and electronic media that contain cardholder data physically secure?

9.7 Is strict control maintained over the internal or external distribution of any kind of media that contains cardholder data?

9.8 Are processes and procedures in place to ensure management approval is obtained prior to moving any and all media containing cardholder data from a secured area (especially when media is distributed to individuals)?

9.9 Is strict control maintained over the storage and accessibility of media that contains cardholder data?

9.10 Is media containing cardholder data destroyed when it is no longer needed for business or legal reasons?

All of the above deal with the physical media such as printouts that may contain card data. The merchant is also subject to one section of Requirement 12, which covers the merchant’s relationship with service providers that actually handle data (again, see PCI DSS SAQ Type A [3]):

12.8 If cardholder data is shared with service providers, are policies and procedures maintained and implemented to manage service providers, and do the policies and procedures include the following?

12.8.1 A list of service providers is maintained.

12.8.2 A written agreement is maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

12.8.3 There is an established process for engaging service providers, including proper due diligence prior to engagement.

12.8.4 A program is maintained to monitor service providers’ PCI DSS compliance status [3].

All of the above deal with the responsibilities of the third party that handles processing, storage, and transmission of data.

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.

A subtle point brought to life by an increasing use of EMV Technologies needs to be clarified: payment card brands may relax some of the PCI DSS validation requirements if the merchant uses new (and presumably more secure) payment methods, however merchants will still be required to maintain PCI compliance at all times.

Payment Card Industry (PCI)

The payment card industry (PCI) data security standard (DSS) provides protection of consumer credit card data and information. The standard was created to reduce the incidents of credit card fraud by increasing the amount of security controls around cardholder data. Qualified security assessors (QSA) use the twelve PCI DSS requirements to evaluate the security and compliance of a particular information system. These requirements and the six control objectives they are categorized into are listed in Table C-7 in Appendix C. To effectively comply with these requirements, organizations can use the Risk Management Framework by replacing the controls selected in phase 2 of the RMF with those required by PCI DSS, allowing this flexible framework to be used to ensure PCI compliance.

Publisher Summary

Payment Card Industry Data Security Standards (PCI DSS) has many requirements that mandate ongoing actions with varying outcomes. Some requirements have documentation outputs that are reviewed during an annual assessment, and other requirements actions are in fact the compliance activity. Finally, some requirements do not have an actual maintenance requirement, but there is documentation that must be updated before an assessment. One of the requirements that need some kind of action was updated for PCI DSS version 1.2. Requirement 1.1.6 formerly required a quarterly review of all firewall, and router rules, and configurations. In version 1.2, the requirement is changed to every 6 months, which means that when an annual assessment is due, one should have documentation from at least two of these reviews. The reviews should be detailed enough to show that an engineer checked every item and validated that it was still needed. Requirement 3.1 mandates creating retention requirements for cardholder data. It has a quarterly requirement to purge old data by way of manual review or automated disposal process.

Publisher Summary

The Payment Card Industry Data Security Standard (PCI DSS) Requirement 10 directly addresses logging. The requirement itself is called “Track and monitor all access to network resources and cardholder data” and is organized under the “Regularly monitor and test networks” heading. Specifically, Requirement 10.1 covers “establishing a process for linking all access to system components to each individual user. Section 10.5.1 of PCI DSS covers the confidentiality. Section 10.5.2 of PCI DSS mentions that one needs to protect audit trail files from unauthorized modifications. Many pieces of network infrastructure such as routers, and switches are designed to log to an external server, and only preserve a minimum of logs on the device itself. Thus, for those systems, centralizing logs is most critical. Requirement 10.5.4 of PCI DSS states the need to “copy logs for wireless networks onto a log server on the internal LAN.” The final Requirement 10.7 deals with log retention. It mandates to “retain audit trail history for at least one year, with a minimum of three months online availability.”

Summary

PCI DSS data protection requirements are among the most challenging parts of PCI as they deal with technology subjects such as encryption algorithms. Many organizations are still not compliant, and risk fines and data breaches as a consequence.

Here is a deceptively simple answer to your encryption worries: don’t do it! If only you eliminate data storage, you eliminate the need to protect data at rest, which takes care of a massive amount of complexity in Requirement 3.

Similarly, if you eliminate the movement of card data over insecure networks, Requirement 4 will become simpler. With the proper preparation and execution of your plan, you can protect the information you have been entrusted with.

Payment Card Industry Data Security Standard Compliance

PCI DSS was developed by leading credit card companies to help merchants be secure and follow common security criteria to protect sensitive customers’ credit card data. Before that, every credit card company had a similar standard to protect customer data on the merchant side. Any company that does transactions via credit cards needs to be PCI compliant. One of the requirements to be PCI compliant is to test security systems and processes regularly. This can be achieved via vulnerability assessment. Small companies that do not process a lot of transactions are allowed to do self-assessment via questionnaire. Big companies that process a lot of transactions are required to be audited by third parties.2

Quick overview of PCI requirements

Now it is time to briefly run through all 12 PCI DSS requirements, which we cover in detail in the rest of this book.

PCI DSS version 2.0 comprises six control objectives that contain one or more requirements:

Build and maintain a secure network.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Protect cardholder data.

Requirement 3: Protect stored cardholder data.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Maintain a vulnerability management program.

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs.

Requirement 6: Develop and maintain secure systems and applications.

Implement strong access control measures.

Requirement 7: Restrict access to cardholder data by business need to know.

Requirement 8: Identify and authenticate access to system components.

Requirement 9: Restrict physical access to cardholder data.

Regularly monitor and test networks.

Requirement 10: Track and monitor all access to network resources and cardholder data.

Requirement 11: Regularly test security systems and processes.

Maintain an information security policy.

Requirement 12: Maintain a policy that addresses information security for all personnel.

The above-mentioned 12 requirements cover a vast spectrum of information technology (IT) areas as well as venture outside of IT in Requirement 12. Some requirements are very technical in nature (e.g., Requirement 1 calls for specific settings on the firewalls), and some are process and policy-oriented (e.g., Requirements 7 and 12) and even go into contract law (some of the subrequirements in Requirement 12 cover the interactions with MSPs.

The detailed coverage of controls makes things easier for both the companies that have to comply with the standards, the auditors (in case of Sarbanes–Oxley Act of 2002 [SOX] or other laws and standards), or the assessors (in case of PCI DSS). For example, when compared with SOX, companies do not have to invent (or pay for somebody to invent) the controls for them; they are already provided. This can also create challenges as compliance initiatives become more prescriptive about their required controls, companies are forced to create a common control set and map them back to all of the individual compliance requirements.

What is interesting is that almost every time there is a discussion about PCI DSS, someone would claim that PCI is too prescriptive. In reality, PCI being prescriptive is the best thing since antivirus solutions invented automated updates (hopefully, you can detect humor here). PCI DSS prescriptive nature simply means that there is some specific guidance for people to follow and be more secure as a result (if they follow the spirit and not only the letter of PCI standards)! Sadly, in many cases, the merchants who have to comply with PCI DSS and who still think it is “too fuzzy” and “not specific enough” are the ones either fighting to comply in the first place, trying to avoid changing anything at all in spite of PCI DSS, or looking for a simple compliance and security to do list or a task list, and no external document that guarantees that your organization will be secure can ever be created.

In particular, when people say “PCI is too prescriptive,” they actually mean that it engenders “checklist mentality” and leads to following the letter of the mandate blindly without thinking about why it was put in place. For example, it says “use a firewall,” so they deploy a shiny firewall with a basic “ALLOW ALL<->ALL” rule—an obvious exaggeration that clarifies the message here. Or, they have a firewall with a default password unchanged, or maybe slightly more secure by allowing all outbound and denying most inbound traffic. In addition, the proponents of “PCI is too prescriptive” tend to think that fuzzier guidance (and, especially, prescribing the desired end state and not the tools to be installed) will lead to people actually think about the best way to do it.

So, the choices to write security-motivated regulatory guidance are as follows:

Mandate the tools (e.g., “must use a firewall”) and risk “checklist mentality,” resulting in both insecurity and “false sense” of security.

Mandate the results (e.g., “must be secure”) and risk people saying “yes, but I don’t know how” and then not acting at all, again leading to insecurity and a wide interpretation of intent.

The author team is of the opinion that in today’s reality #1 works better than pill #2, but with some pause to think, for sure. Although the organizations with less mature security programs will benefit at least a bit from #1, organizations with more mature programs might be able to operate better under #2. However, data security today has to cover the less-enlightened organizations, which makes the #1 choice—embodied by PCI DSS—the preferred one.

As a far as scope of PCI DSS within the organization is concerned, PCI compliance validation may affect more than what you consider the “cardholder environment.” According to PCI DSS 3.0, the scope includes the cardholder data environment as well as anything connected to it. Chapter 4 will help you with the scoping problem including giving you some ideas on how to reduce its impact. If you do not have basic network segmentation controls in place, the scope of PCI compliance validation will cover your entire network. Think about it: if you cannot ensure that your cardholder data is confined to a particular area, then you cannot focus on this area alone, and you have to look everywhere.

Note

Just because a POS system is on the list of compliant payment applications (PA-DSS), it does not mean that your particular implementation is compliant. Also, it definitely does not mean that your entire organization is PCI compliant. Only applications configured and maintained according to their PA-DSS Implementation Guide will be able to operate in a compliant manner. You should work with the application vendor and with your QSA to verify this.

In order for the device to be added to the PA-DSS list, the payment application, online shopping cart, or POS vendor has to show and document the secure method for their application deployment. However, it is ultimately the merchant responsibility to follow the secure and compliant deployment guidance.

For merchants using an integrator or reseller, ensure they are deploying and managing your POS in a compliant manner. If they are doing things properly, they should be on the QIR list.

For the benefit of consumers who may be more familiar with a brand name rather than a parent company (e.g., TJX is the corporate parent of TJ Maxx), PCI compliance validation should always follow the merchant ID. Any transaction processed under that merchant ID, regardless of origin, should fall under that company’s PCI validation process.

You may discover that you are unable to always comply with the strict letter of PCI DSS while striving for its spirit. For example, you may need to temporarily store cardholder data unencrypted for troubleshooting purposes or to use a password of less than mandated minimum length on a legacy system. Another example may include recording certain call-center conversations for customer service purposes. Again, card brands understand that these recordings may contain cardholder data, so accommodations must be made accordingly to protect that data.

In many cases, compensating controls have to be used to achieve compliance when your company cannot exactly meet a given requirement. The important thing to remember about compensating controls is that they have to go beyond the requirements of PCI to provide the same or higher assurance of cardholder data protection. When compensating controls are used you must gather and supply additional documentation about the control. Please see Chapter 14 for detailed coverage of compensating controls.

Password design for PCI DSS: requirements 8.2.3–8.2.6, 8.4–8.6

When PCI DSS was really gaining steam, one big complaint from companies forced to comply was that the password controls were too stringent or could not be supported on the hardware that ran their businesses. Nearly every currently supported system has the capability to comply with the PCI DSS password complexity requirements. If during your compliance efforts you find systems that are unable to comply, check to make sure that it is still supported by the vendor and is not just horribly out of date. To simplify the subrequirements contained within PCI DSS Requirement 8.2, see Table 6.1 that explains everything that your in-scope systems must enforce for password controls.

Table 6.1. PCI DSS Password Complexity Requirements

For these requirements, systems must enforce these controls. Having only a policy that describes the proper procedure for making passwords is not acceptable. All the above requirements can be met by modern UNIX and Windows operating systems. We’ll show you how to accomplish this in the “Windows and PCI Compliance” and “POSIX (UNIX/Linux Systems) Access Control” sections of this chapter.

First-time passwords are often an easy way to compromise an account. For example, when Steve joined his company, he was provided with a cell phone and a laptop. His user ID was his first initial and last name, and his password was “Newuser1.” The initial password was the same for every user and would technically exceed the complexity requirements of PCI DSS. The password is alphanumeric and includes a mixture of uppercase and lowercase letters. But because every user gets the same password, compromising a new account might be a trivial operation with a little bit of social engineering. Requirement 8.2.6 mandates that all new accounts have a unique password that expires immediately after its first use. We’ll cover configuration methods to do these for both Windows and UNIX in the “Windows and PCI Compliance” and “POSIX (UNIX/Linux Systems) Access Control” sections of this chapter.

Requirement 8.4 mandates that you communicate all the password procedures in PCI DSS to the in-scope user base. An in-scope user is a user who has access to cardholder data as a normal part of his or her job. These users must be made aware of the password procedures, and your assessor will randomly sample users and ask them what they know about password procedures. Assessors may do this as a part of an interview for another area of PCI DSS, or they may specifically ask for a list of users and randomly call them for a phone interview.

Requirements 8.5 and 8.6 are relocated from PCI DSS 2.0, but the key message is the same. Do not, under any circumstances, use shared passwords or IDs. Each user or application must be uniquely identified with its own credential to comply with PCI DSS.

Other Considerations for Requirement 1

PCI DSS v1.2 added more granularity to the requirements around routers, specifically taking Requirements 1.1–1.3 and extending them to routers. The one requirement that seemed specifically targeted at Cisco routers and firewalls has been enhanced is Requirement 1.2.2, even though it specifically only mentions routers. If any network device in scope for PCI has the capability to have a different running and startup configuration, this requirement applies and you need something to check to make sure they are actually in sync. No changes should be made to the running configuration without first going through the appropriate change management procedures.

Additional firewall considerations should be taken with regard to wireless networks and mobile or personal computers. Systems with cardholder information must be segregated from wireless networks for Requirement 1.2.3, and those firewall rules limited only to what is necessary for business. Chapter 7, “Using Wireless Networking,” has more information for you on how to get your wired and wireless networks working securely. These units may not always get critical patches in a timely manner, and the personal firewall provides some assurance.