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.
March 20, 2007
You are disabling UAC. Cancel or Allow?
So, about a week ago, I used Vista for the first time (in case you haven't heard, Vista is this new thing they have out now that's supposed to be all that and a bag of chips when it comes to security.)
Oh wait, maybe I should start earlier than that. So, a few months ago, while fast-forwarding the TiVo, Diana and I came across the Apple "I'm a Mac" where there's the "Vista dude" (my short-lived hero) who kept asking the PC "cancel or allow" for everything that he did. And, while I thought the commercial was humorous, I put the underlying message in the same place where I put Apple's "no malware for Mac" message; namely in that part of my brain reserved for obviously-biased marketing spin (I think this one fell somewhere inbetween the Oracle "Unbreakable" campaign and Richard Nixon's "I am not a crook" speech.) In other words, I disregarded it.
Fast forward to using Vista again. So, I'm clicking around and doing stuff, installing software, changing settings, and so on. And boy-howdy if Apple wasn't right on the money. Install software - "cancel or allow," apply patches - "cancel or allow," change the theme - "cancel or allow," delete a shortcut from the start menu - "cancel or allow." Man, what a pain in the neck! Needless to say, I did what any sane security professional would do - disabled UAC. Because it was killing me... Next on the agenda was the box that kept asking me (I'm paraphrasing now) "
Now, you might say that disabling these features is a step in the wrong direction... after all, shouldn't we be pushing forward into the great new frontier of the OS asking me permission before the CPU executes an instruction? No. Well, at least I don't think so. Look, asking the user is the wrong approach in a security context; it hasn't worked with browsers and it won't work here. Don't believe me? To illustrate it is true, I need cite only the highly-scientific "Simon Says" series experiments. OK, so I'm being snarky. But isn't it really the same thing? "Simon Says"... "Duck-Duck-Goose"... "Mother May I'... All of these are games founded on the principle of habituation - namely, that people when asked to perform the same activity over and over again start to perform it without awareness of the differences of the event. Look, I guarantee you that if you show me the same dialog box 100,000 times that I'll stop reading it and just click "yes." I've actually gotten pretty good at still ignoring the dialog when the buttons are reversed (viz WinZip's shareware "register winzip" dialog.)
So, here's my question. What exactly are we trying to prevent? Can't we have it where the unusual behavior prompts the dialog box rather than the things we do all the time? Like maybe if deleting the shortcut from the desktop didn't give me the "cancel or allow" box but sending my banking password to a site in lithuania did (no offense to lithuanians... just grabbed a far-off sounding place from the top of my head.)
Anyway, now back to your regularly-scheduled rant-free day.