3 PCI DSS Fallacies Demystified

tiny-people-businessman-with-shield-protecting-data-laptop-data-privacy-information-privacy-regulation-personal-data-protection-concept-bright-vibrant-violet-
Post Published On:

Author: Praveen Joseph, FIP, CISSP, CIPM, CIPP/E, ISO 27k1 LA, ISO 31k LA, CPISI, ex PCI QSA; Principal – Cyber Security and Privacy Services at Ingram Micro

Introduction

PCI DSS is one of the most granular information/cyber security standards in the world. Develop with the broad intention of protecting cardholder data and sensitive authentication data associated with credit/debit cards, PCI DSS has gained widespread adoption across countries and industry sectors.

Broadly organized across 12 main requirements and more than 300 sub requirements PCI DSS prescribes a veritable program for comprehensive security across an organization’s cardholder data environment (CDE). Fully compliant organizations are considered synonymous with a very high benchmark of information security within their environments.

Given its deep technical focus, there is a lot of scope within PCI DSS for misinterpretation. These can prove to be costly errors for organizations seeking to be compliant. In this article we will explore common fallacies associated with the standard and seek to demystify them.

Myth 1: “I don’t allow Wi-Fi in my CDE. I am exempt from the wireless scanning requirement.”

Requirement 11.1 of PCI DSS prescribes, “Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.”

The intention of this requirement is to detect and weed out any rogue wireless access points within the CDE. Rogue access points may be set up by employees themselves, or by cybercriminals. In most cases, they seek to facilitate exfiltration of sensitive data.

When reviewed through this perspective, it is evident that even if the organization by policy does not use or permit any wireless networks within the CDE, the purpose of requirement 11.1 will still apply. Quarterly scanning must be mandatorily executed for any rogue access points within the CDE.

Myth 2: “We have highly restricted access to cardholder data. Hence we don’t encrypt it.”

Some organizations tend to perceive encrypting cardholder data a burden, as it adds an additional layer of complexity to time-sensitive card data transactions.

Requirement 3.4 of PCI DSS states, “Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs)”.

On reviewing the PCI DSS prescriptions for “compensating controls”, we note that they are alternative security controls that may be deployed when PCI DSS controls (like Requirement 3.4 above) cannot be complied with for legitimate reasons. PCI DSS conditions for compensating controls specify that they cannot be the same as other applicable PCI DSS requirements. This dispels the applicability of regulated access control as a suitable compensating control for Requirement 3.4, as it is already another PCI DSS requirement (Requirement 7, 8). In fact, it has been evidenced that compensating controls, although they may seem alluring as a shortcut to PCI DSS compliance, tend to be more expensive to implement according to the rigors of the standard.

Myth 3: “We have outsourced all our card processing activities. PCI DSS does not apply to us.”

The implications of this statement must be distilled through the scope of the engagement between an organization and a service provider – i.e what has been outsourced and who is responsible for what. Consider the case of a call center providing outsourced services to a telecom company. The call center company will receive customers’ calls, collect card data for payment transactions, feed them into various applications and provide end-to-end support for the callers.

From the above scenario, it appears that PCI DSS would not apply to the telecom company. However, a deeper dive into the layers reveals a different story.

  • Card numbers are fed into an application.
  • Who is managing the application?
  • Who developed it?
  • Where is it hosted?
  • Does it generate any logs? Are these logs fed into a SIEM tool?
  • What happens in the event of a security breach?
  • Will the call center agency notify the client if they detect it first?
  • If the client detects it first, what are the call center’s SLAs and obligations on support and mitigation?
  • Are calls recorded?
  • Are card numbers captured in the recordings?
  • Where are the recordings hosted?
  • Who reviews the recordings?

Even in the event of outsourced card data processing activities, it is very important that lines of accountability are clearly defined and agreed upon for each PCI DSS requirement, between organizations and service providers.

Misconceptions exist when it comes to PCI DSS requirements. Ingram Micro Cyber Security is here to help you. Talk to us. Our team consists of former PCI QSAs who will help you navigate the standard and achieve compliance.