March 23, 2007
Putting the ass in assessment, redux
(Today's topic brought to you by Dave Newell.) So, I don't know if you've read it, but the PCI assessment standards manual makes for some fantastic reading. Not. It's kind of like reading a John Grisham thriller, but without all the fast-paced action and interesting plot. Anyway, so to tee up today's ranting, take a look at the following from the PCI DSS Assessment Procedures:
12.7 Inquire of Human Resource department management and verify that background checks are conducted (within the constraints of local laws) on potential employees who will have access to cardholder data or the cardholder environment. (Examples of background checks include pre-employment, criminal, credit history, and reference checks)
OK, pretty standard stuff, right? But here's a question that we've been struggling with over the past few weeks. What's the level of expectation that firms do credit check as part of on-boarding and what criteria should firms use for evaluating when using credit history as a factor? The "first blush" temptation in looking at this is to say "it says example, chump... obviously it's not required at all”. OK. But the self-assessment checklist specifically includes credit check but not references or pre-employment:
Is a background investigation (such as a credit- and criminal-record check, within the limits of local law) performed on all employees with access to account numbers?
So, is Visa (assume whenever I say Visa that I mean "the PCI Security Standards Council") more interested in credit check vs. other types of checks? And who cares after all, right? Well, there are some complexities in running people’s credit; there’s the fact that it subjects the firm to FCRA (Fair Credit Reporting Act) restrictions and the fact that it opens up the whole “can’t discriminate because of bankruptcy” issues as well. So, clearly, it matters. But the open question is, what is the intent and what implementation is satisfactory? Which is where my beef comes in (queue the ranting. )
Visa's stock answer to this question is (I know because I've asked) that the audit process is inherently subjective and that it's up to the individual assessor to evaluate the intent and rigor of the requirement and make a determination as to whether or not the controls in place meet the standard. OK, fair enough. That's the same with any audit, right? But there’s a rub with PCI that isn’t a factor in other audit contexts; which is that typically the standard you are auditing against is either generic (meaning that it specifies the desired outcome but not the method for getting there) or specific (meaning that it specifically identifies the implementation details with less/no emphasis on the end-state.) Here’s what I mean:
Example 1: ISO 27001. This standard is an example of a generic standard. For example, clause A.9.2.2 says “Equipment shall be protected from power failures and other disruptions caused by failures in supporting utilities.” It doesn’t tell you *how* to protect the equipment, what equipment is in scope, or what protection is “good enough.” As the auditor, it is your determination to decide if what they have is sufficient to meet the intent of the requirement.
Example 2: DITSCAP. DITSCAP is an example of a specific standard. Meaning, the standard (“reg” in the parlance) says you must use a FIPS 140-2 approved cryptographic module. You as the auditor (“accreditor” in the parlance) must conclude if the audited party does or does not employ one. You don’t get to interpret whether or not their cryptography is “good enough” for the particular purpose – it either is approved or it isn’t (OK, you do get to speculate about whether it is or isn’t a cryptographic device, but let’s not complicate the issue.)
Anyway, my point is that the DSS provides desired end-state in some places and desired methodology in others – which in practice leads to confusion. In cases where, for example, they’re specific about the methodology and vague about the goal, the assessor may have to attempt to interpret whether or not a control (potentially at odds with what their different specifically-referenced control) meets their (implied, unstated, and/or otherwise vague) overarching intent. Let’s go back to 12.7 to illustrate what I mean.
12.7 says, “Screen potential employees to minimize the risk of attacks from internal sources.” Seems pretty clear on the surface, but when you start trying to audit against that objectively, the stated goal of “minimizing the risk of attacks from internal sources” is vague. What kind of attacks? If I interpret “attacks” to mean “physical violence”, my screening process might include a personality profile or psych evaluation. But clearly that’s not what they mean. The context suggests they mean either mean financial attacks (fraud) or technology attacks (hacking) – furthermore, the controls they suggest (credit check, references, etc.) are clearly targeted at one of the latter two types of attacking. Knowing that, I attempt to audit to my own internal “paraphrase” of this objective which includes things like fraud and hacking; but of course that gets me in trouble when someone builds a (perfectly legitimate) case for why a control (that maybe doesn’t address fraud but addresses some other type of “attack”-related issue) meets the intent. How do you argue that? Especially if the actual intent has to be deduced through a careful “read between the lines” of the standard.
Anyway, I’m tired of whining about PCI for now…. Back to work.