PCI BACKROUND CHECK = IS IT A CAKEWALK

PCI Background check – Lot of ‘GROUND’ to be covered

Let us take this sub requirement regarding background check of employees. I read the sub requirement and seems to be one of those seemingly blink of an eye compliance requirement. Is it really so? Also looks like an innocuous requirement but that perception, if there, should change as one reads through. If it is over looked, then PCI compliance is like food without salt or sweet without sugar - the whole purpose and all efforts of PCI compliance would be defeated.

The Requirement

Screen Potential Personnel Prior to Hire to minimize the risk of attacks from Internal Sources.

(Examples of background checks include previous employment history, criminal record, credit history and reference checks)

Thought on the note in the standard: For those potential personnel to be hired for certain positions such as store cashiers who have access to only one card number at a time when facilitating a transaction, this requirement is a recommendation only.

The testing procedure provides that compliance of this is to be done by inquiry with the human resource department to confirm that background checks are conducted (Within the constraints of local laws) prior to hire, on potential personnel who will have access to card holder data or the cardholder data environment

The first question that should arise is this one standalone requirement or is it linked/dependent on other requirements. Readily the answer is that it is linked at least to requirement 7 and to some extent requirement 8 relating to access control based on need to know and least privileges.  So it is a pre requisite that HR department should be fully aware of the accesses allowed to various applications, servers, desktops and so on for each role for which they are recruiting whether it be a cashier, data base administrator, CFO or CEO to decide whether there is a need for background check from a PCI perspective. Is the HR department aware of it?

The PERSONNEL INVOLVED

Now let’s come to the term “Personnel” in the requirement. It refers to full time and part time employees, temporary employees, contractors and consultants who are resident on the entity’s site or otherwise have access to card holder data environment.

I think the QSA community should come in the consultants’ clause and based on the reading of the standard, this requirement should be applicable to them. Is it being addressed for compliance or treated as taken care of otherwise is left to the judgment of the readers.

Even vendors could get covered in this since contractors are included and the definition of “Personnel” is of wide import as it says “On site or otherwise have access to the card holder data environment”. How one is going to ensure compliance with background checks of a specific or a set of employees of contractors/vendors who will have access to Card holder data on site or remotely. We can push this to take cover under requirement 12.8.3 but considering the stringency in the standard it should be firmly believed that word “due diligence” used in that requirement is broad enough to cover background check. In essence there is no escape.  I am not touching the cases of Cloud environment and leaving the readers to ponder on the same with reference to this requirement

Once a Saint Always a Saint

Once A Saint Always a Saint is what is hinted by the requirement since the background check is to be conducted once prior to hiring. It is guessed that the standard assumes that once recruited credit history, conduct over time etc. gets monitored in the various employee appraisals that might be a part of the HR policy, of course outside the scope of PCI. So if a breach/fraud is committed by an employee six years after initial employment background check, there may not be any PCI compliance violation at least of this sub requirement. It must be pertinent to point out here that an employee gets complete exposure to the sensitive information and systems only after recruitment

The transfer Stigma

How does an organization deal with an existing employee transferred from a role not involving access to Card holder data to a role involving access to card holder data. Will there be a background check required before transfer. Technically as per requirement “NO” and live on the cover laid out in the para on “once a saint always a saint”. Having said that, the moot question is, should it not be part of the Risk Assessment saying “Employees transferred to CHD have not been subjected to Background Checks”. Yes it should be very much a part of RA but what is happening at the implementation and certification level is left for the fraternity to ponder.

So it is best to do the background check when inducting anyone into the cardholder data environment.

The Level unlevelled

“The company has a uniform policy that reference background checks will be conducted for potential employees likely to be recruited in roles with access to more than one card number at a time. “

If this policy is implemented is it OK, adequate and effective?

Yes prima facie it is OK so long as we don’t worry much about its adequacy and effectiveness.

From a risk perspective the policy is far from OK and some in the fraternity could go to the extent of treating it as non-compliant. The reason is that such a uniform policy is not effective Obviously the extent and gravity of back ground check for privileged users should be more stringent than for an ordinary user Same gets extended to more rigorous checks being laid out for “C” level employees Unless the background check policies are designed based on likely level of exposure/control over card holder data and is implemented as such the compliance to this requirement would be merely mechanical than real

  
The Note Paradox – Thought on the Note in the Sub Requiement

The note on the re commendatory nature of this requirement is intriguing. Store cashiers access to one card number at a time means access to several card number over time What is the fine distinction between access to several card numbers at a time and several card numbers over time with reference to this back ground check requirement is not readily understandable in terms of exposure. We also need to appreciate the fact that the store cashier has access to hard cash as well besides cards since he will be accepting cards and cash as payment modes. Cash is as sensitive if not more than the cards. Then why this waiver.

Again the access to one card number only at a time depends on the application that is used to handle card mode payments from customers The application may have scrolling facility to view more than one transaction post completion or the application may not be truncating the card number post the transaction. Least of all the HR department cannot decide or assume in the light of the above that the store cashier role means one card number access at a time. From a risk and compliance perspective the note needs a relook and introspection before allowing waiver for store cashiers or anyone waiver from this requirement

The Scoping Confusion

Technically since as per PCI DSS requirement development and test environment has to be segmented from Production and perceived to be out of scope of PCI,(although wrongly),there will be no need for background check for these staff as per the PCI requirement under discussion since there will be no access to card holder data and its environment by the development/test environment

But we cannot forget and keep aside the fact the developers are the key to application both in terms of functionality and security. One need not go far to imagine the risk if a hacker developer finds his way into the organization developing sensitive, application with this requirement of background check skipped from a compliance perspective

The missing Note

On a strict reading of the requirement 12 as a whole there is no requirement for operational procedures for at least this sub requirement or for that matter most of the sub requirements in 12 as the all pervasive requirement found at the end in all the 11 requirements is not there
But the discussion above for such a small requirement clearly spells the need for a detailed operational procedure for compliance with this requirement covering-

• All Personnel on site
• All Personnel off site
• Consultants
• Checking methods for Normal users
• Checking methods for Privileged users
• Checking methods for C level employees
• Transfer case employees
• Addressing on going checks over time and so on

 I leave it to the imagination of the readers to guess the time for implementation of this requirement and of course checking its compliance to the core

To conclude

After thinking on what is written above, I said that it is time to flip through the PCI requirements and into the sub-requirements. Little did I realize that it enveloped one within the other sub-requirements numbered to more than 240

Reading, understanding and ensuring compliance of the same at and off the floor of a single sub requirement, should take how many minutes or hours  is not an easy guess being conditioned by several factors like size, complexity, model and so on. Of course, from a compliance perspective one is not looking at each sub requirement individually.

The discussion on background checks is ample evidence for the same

Just for discussion if one assumes that if it takes about an hour to ensure final compliance of a sub requirement, it should take about 240 hours on an average which is effectively about 30 calendar days assuming an 8 hour day. This obviously excludes the ROC work and the AOC and other marketing documentation like Certificate of compliance etc.

At least I am convinced that there is no requirement which can be complied with the speed of a blink of an eye. It also depends when and how you are convinced of the compliance of the sub-requirement given the procedures to be followed

Happy implementation ,Assessment and Quality Certification ! and a very Happy Diwali