PCI DSS

PCI Isn’t Risk Based – And Other PCI Myths Debunked

If I were king, I would command my PCI Council minions to re-order the 12 requirements of the PCI DSS. Case in point – I’m convinced, after 15 years as a PCI assessor and consultant, the risk assessment should be the first step on the path to PCI compliance. Yet, the risk assessment doesn’t appear until requirement 12.2! It’s crucial, but buried under 11 sections of other stuff. The PCI Council understands its importance; risk assessment is listed as a priority one requirement in the v. 3.2.1 Prioritised Approach Tool.

Why risk assessment first? In a previous article I discussed how an inadequate understanding of risk led to an assessment fail. In this post I will point out a number of requirements for which you will have to establish a standard. For example, req. 9.9.2 requires “periodic” inspections of card readers to detect tampering. Does “periodic” mean daily? Weekly?

That’s for you to decide based on risk.

Let’s review quickly the basic elements of risk analysis:

1. Vulnerability – the potential attack. Most card readers, for example, are vulnerable to skimmers.
2. Likelihood – how likely is a successful attack against a given vulnerability? A card reader in an unattended location (gas station, parking lot, etc.) is a more likely target than one in retail store with readers built in to the PoS register.
3. Magnitude – what is the impact of a successful attack. Often, impact is measured in dollars, but in the PCI space a breach can also result in elevation of merchant level to level one, which requires a QSA assessment (very few self-assess merchants pass their first QSA assessment). Breaches anymore cause people to lose their jobs. You could be required to comply with the Designated Entities Supplemental Validation; service providers could lose critical contracts.

You can use this formula to set internal standards where the DSS doesn’t provide them. For example, an unattended card reader in an airport parking lot should, perhaps, be inspected daily based on the increased likelihood of an attack on an unattended device and the volume of transactions, which could number in the thousands, or more, thus elevating the potential magnitude of a breach. In contrast, for a similar unattended device in a small surface parking lot doing far fewer transactions perhaps a weekly inspection is sufficient. 

Your QSA will expect you to have established these standards prior to the assessment.

He or she will first review your policies and procedures, then test adherence to those policies and procedures when out in the field. Failure to do this will activate the QSA’s spidey senses, which generally does not bode well.

Here’s a selective list of other requirements for which you’ll need an internal standard:

1. Crucial – Req. 3.1 pertaining to data storage and retention. Any entity can store cardholder data post-authorisation, and still be client, but only if they can fully articulate why they store cardholder data, explain their reasoning for their defined retention period, and demonstrate how and when expired data is expunged. I look for a risk-informed decision. There’s a lot of latitude here, though, so it’s easier to point out examples of uninformed decisions – “we’ve always done it this way,” or “finance says we have to store cardholder data for seven years to comply with tax law.”
2. Technical – Req. 2.2 addressing configuration standards – virtually every element of this requirement and its sub-requirements require internally developed standards focused on reducing the potential attack surface for systems in your specific environment. Industry-accepted hardening guides list all of the configuration options, and provide suggested settings based on criticality of a given system. But, these are only suggestions; you have to choose which settings you’re going to use based on risk-informed decisions.
3. Administrative – Req. 12.7 addressing background checks – the requirement simply says “screen potential personnel prior to hire….” While it provides suggestions, what specific checks employed is up to you. Again, you must choose – your QSA will test against your policy.

All of the requirements in the PCI DSS are intended to mitigate the risk of a data breach, so decisions on how to meet those requirements should be based on risk-informed decisions.

___________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

Contact us today for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

___________

Written by Steve Pratt

Steve Pratt has been a consultant and assessor since PCI’s inception in 2005. He also served eight years in the US Navy, and did stints as a sportswriter and high school teacher. He holds a master’s degree in history, along with MCSE, CISA, CISSP and QSA certifications.

At SecureTrust, Steve provides IT risk assessment, data privacy and general IT security consulting, in addition to performing PCI assessments. He tends to focus on organizational and business culture issues which, he believes, must be resolved before technological controls can be implemented in a repeatable and sustainable manner.