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.

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) " is attempting to establish a connection. Block Once, Block Always, Unblock." Painful.

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.

One minor point that I would make is to point out that "security" should probably be represented somewhere on both lists. In my opinion, it should be on the best list because of the fact that Apple does have a track record of reduced malware (and you can't argue with success) but also on the worst list for a few reasons:

- It takes them longer to publish security fixes than any other OS vendor
- The disingenuous marketing (i.e. the Vista "shades" commercial)
- Encouraging users to not take security seriously on OS X

Anyway, I found it interesting that security wasn't represented on either list - especially since there's so much buzz about it in the press (and in the marketing) nowadays...

There's also an accompanying tagline from Apple: "114,000 Viruses? Not on a Mac. Mac OS X was designed for high security, so it isn't plagued by constant attacks from viruses and malware like PC's. Likewise, it isn't plagued by never-ending security dialog boxes like those in Vista. So you can safely go about your work - or fun - without interruption." Here it is so you can see I'm not lying:

Now, before I start in on this... remember that I'm a Mac user. Actually, I'm using my iBook to type this post. I'm also not one to arbitrarily make the claim that Vista is a secure platform. (Well, OK - some press folks did report me as saying that, but what I actually said had a bunch of qualifiers that didn't make it into the story.) Anyway, my point is the same one I've made all along (remember, as a Mac user); specifically, that Apple's current line of advertising (entertaining though it is) is problematic to Mac users in the long term. Why do I say that? Let's break it down:

1) The subtext is untrue. Apple says "Mac was designed for high security..." (implied subtext is that Vista and other OS'es were not.) Aside from it arguably not being a fair representation of Microsoft's approach to Vista, the statement is meaningless. I mean, it has an implied logic that doesn't hold up under scrutiny. For example, "it's designed to be secure, therefore it doesn't have malware" is crap. How about "the Titanic was designed for seaworthiness, ergo it didn't really sink?" Same logic - does it make sense there? No. Trying to make the case that users should take a vendor at their word based on a statement of their intent at the time of development is ludicrous.

2) Asking the user. Sometimes you have to ask the user for a decision. For security decisioins, you're more likely to have to ask the user for input. My Mac asks me to make security decisions all the time - like whether I should enter my root password when I'm installing new software.

3) It does down the earpiece. Respect the earpiece. I won't see it defamed in this way.

4) (and now the real reason this tweaks me...) Security is more than malware. Some of us Mac users happen to think that the current dearth of Mac malware has more to do with percentage of population and user base rather than inherent features of the Mac. If that's true, defining the Mac as being "secure" because it has less malware short-circuits Apple's position in the long term. Why? Because if they hope to become the dominant platform, they will have malware too. If they get us to buy-in that lack of malware equals security, aren't we going to view them in the same light that we view MSFT today? Not a good idea...

Anyway, I love these commercials. But I also want Mac to succeed. And they're not helping themselves in that regard.

Anyway, my beef with the training is probably that I feel, as a QDSP, under-prepared for how Visa expects me to interpret the requirements of the standard. But that is not because the class wasn't as good as it could be; instead, I think it's because of the way the standard is implemented and assessors are qualified. Now, why should I be interpreting the requirements of the standard, you ask? Because, unlike the majority of other regulatory guidance, PCI is prescriptive. For example, PCI says that companies need to have a firewall. And they say that you have have to have anti-virus software, application-level firewall software (new version), etc. It's up to the assessor to interpret if they have done it and if it is done appropriately. To contrast, I just went through the ISO-27001 auditor training, and the auditors are not expected to evaluate the quality of a given implementation; for example, there's an example in there about damage to documents caused by a leaky roof (there's a requirement that documents be legible, retained appropriately, locatable, etc.) Anyway, the example asks if it's acceptable from the point of view of the standard to put those documents in Tupperware containers; now, if you were to judge qualitatively, you would say "that's crazy - fix the damn roof." But that'd be the wrong answer... because the standard does not define what you need to do technologically so long as the core issues are met.

So, I guess my frustration is with the fact that we, as assessors, are signing off on something that we are being asked to interpret. It's subjective and we're not being given guidance from Visa. But that's not the fault of the class, and it was inappropriate of me to imply that it is. So, sorry again to those guys.

1) How are you protecting the network?
2) How are you protecting applications and data?
3) How are you protecting systems?
4) How do you know how you are doing?

Now, these are useful in the context of vendor-client interaction. However, within the enterprise itself, I am oftentimes surprised at the questions that practitioners don't ask themselves. Like:

1) What does the business I support do? And how do I know when they do something that impacts security?
2) Who are my vendors and how do I make sure they handle security appropriately?
3) Where does the data come from and where does it go?

And so on. Very often, I meet individuals in industry tasked with protecting data, tasked with securing resources, and tasked with protecting assets who don't have answers to these questions. Although I'm not sure that it's appropriate for a vendor to ask them (and therefore probably not appropriate for inclusion in Ross' list), I do think somebody should be asking these things.

But I don't think it's because practitioners in industry have a high moral standard that precludes them from working on vulnerability research; I also don't think it's because they fundamentally believe that vulnerability research contributes to the problem of patch mania and/or increased exposure to the enterprise. Not that Pete is saying any of those things, mind you. However, one could. Instead, I think that vulnerability research and industry do not go hand in hand for a totally different reason - I think it's about time and incentive.

In actuality, vulnerability research is a very time-intensive process. And the truth is that the majority of enterprise IT departments do not reward employees for finding bugs. Now, if you work for a product company (eEye, ISS, etc.), you might be rewarded for finding bugs. Even if you participate in a pay-for-research venue where you can actually sell your bugs, what are you going to earn? A thousand dollars? If it takes weeks to research and write up a bug and go through the rigmarole with the vendor (say conservatively 200 hours), you're talking about 5 dollars an hour. Oooooo, sign me up (not.) However, product companies that use vulnerability research as *marketing* have an entirely different perspective. How much is the front page of google news worth to them? Enough to incent their employees to look for bugs? You bet...

Her story:

- A school has content filtering software installed, but they don't maintain the license, so it stops working
- A schoolmarm visits a hair-styling website which has advertising content
- Schoolmarm's machine receives a piece of spyware that downloads arbitrary ads
- Advertisements for pornographic websites are displayed on the screen
- Children see pornographics ads

Their story:

- She's an evil schoolmarm; a particularly nasty breed that gets their sick jollies by showing kids pictures of naked people

Clearly showing little kids pictures of couples copulating is totally unacceptable. Now, I have to admit that I'm biased in that I happen to believe her story; of course, there could always be facts that aren't in the press that establish her guilt beyond question. In other words, there could be more to it and it could be that she is a sicko. Either way, though, I'm astonished that this conviction took place. Specifically, even if the woman is a sicko, I don't understand how a jury could hear both the above stories (phrased differently, of course) and come to the conclusion that she is culpable for this. Part of establishing that she is culpable is expert testimony on the part of the prosecution that her active involvement was required to bring up the images. Now, most of us with a familiarity with spyware could debate the veracity of this, but again we don't have the facts in this case. Maybe her involvement was required. Without information about what expert testimony (if any) was on the defense side or what the details of the forensic evidence (if any) there was, it's all up in the air from our point of view. But what if... What if her story is the real one? What if the defense was underprepared and couldn't refute the expert testimony of the prosecution? What if she really didn't do it on purpose?

So this is all titillating and stuff, but there's really a reason that I'm bringing it up. Specifically, I've made the point in the past that the legal community and the information security community are being drawn more and more closely together. The FRCP, Zubulake, breach disclosure laws, and so on are all making it so that information security professionals have to understand something about the law and lawyers have to understand something about information security. And if they don't? Then you get cases like this... or maybe this teacher's just a sicko. Could go either way.

So, I came across, via the Spire blog, the followup commentary from Noam Eppel to his Security Absurdity: The Complete, Unquestionable,
And Total Failure of Information Security article.

In case you don't remember the original article, the premise was that information security as a discipline has already failed, and the follow-up is more of the same. The argument is predicated on the observation that there are demonstrable failures of security in the world - quite a bit of them as a matter of fact. In other words, his argument is that security (as the applicable discipline) has failed and that we (as practitioners therein) have also failed because of the vast number of security breaches, security issues, and snafu's that occur on a day to day basis. Fraud? We've failed. Phishing? Failed again. Lost luggage? Depends on who lost it, but if it's the TSA - probably our fault.

Now the point that I made the first time around was that it's not productive to define success/failure based on whether or not incidents occur or even by whether or not it's possible for incidents to happen. For example, traffic accidents occur - does that mean that the traffic laws in this country have categorically failed? Could be... or not depending. But folks would never get away with saying this (at least with anyone taking them seriously) until/unless you could prove that the laws were directly related to the number of accidents. In other words, that there was a demonstrable cause and effect between these two things *and* that the particular success criteria used to define "success" (in this case, less accidents) is both relevant and applicable.

In the traffic safety example, the success criteria might be having a low number of accidents. Once you define what it means to be successful, it's possible to measure how people stand up to the yardstick. For example, by comparing the percentage of increased accidents in one area vs. another area with different laws, you can extrapolate as to whether or not the laws in area A are more able to satisfy a given goal vs the laws in area B (for example, maybe there are less accidents.) In this case, the success criteria is whether or not there are incidents; well, if you take a risk management approach, aren't incidents unavoidable? In other words, if I'm only going to spend money protecting resources commensurate with the value of the resource, isn't it implied that there are going to be areas that are less protected than others? For example, if I have ADT in my home, and somebody comes and hits the mailbox with a bat, did ADT fail? *Should* I hire an armed guard to protect the mailbox? Probably not. But if you define success as living in a world where punks can't hit the mailbox, it's a failure.

Maybe we should define success or failure based on something provable and something that works within the context of risk management. Well, I'll stop going down this road, since I covered it all in the original reaction, but I thought it was useful to point out that when you say somebody failed you have to say "what at?" Did the security industry fail at making the world risk free? Unquestionably. Is that the primary goal that we as an industry should be after? Not in this lifetime. How about "reduce the number of incidents to the point that customers are well-served, that money spent by the organization protects resources commensurate to their risk and value, and that we spend enough to ensure that our personal safety is ensured in contexts where it's applicable?" I think that's a pretty good goal... I'm going with that one.

Now I saw that this Apple bug thing was going on and I didn't write about it 'cause I figured "ho-hum"... and then came the wall of controversy. Thomas Ptacek weighed in early, saying that there's no reason for a "bug a day" release schedule.

HD Moore to Dark Reading: “[A MOXB scheme] seems to be the answer to a ton of denial and hubris about whether Apple products are more secure than any other vendor.” It’s hard to criticise HD; he’s both nicer and smarter than me. But, here goes: “denial and hubris” about Apple security is not a problem that we need HD Moore to correct...
There are arguments to be made in favor of publishing exploits. There are arguments for going public with a finding immediately. What’s the argument for a bug-a-day release schedule?

To be fair, there was a well drawn-out argument in the above (where the ellipsis is) that he uses to justify the point; it's worth reading if you're interested in debating the usefulness of the MOAB (month of apple bugs), but too verbose to include it all here. Then Ross Brown weighed in too; both about the MOAB and about the reaction to it:

Having a hard time seeing the point of this exercise, but it seems somebody wasn't held enough as a child. Thomas isn't tied to vendors and asserting it just makes the whole project a lot sillier.

So, two folks who don't see how this is useful. Is it? First, let's get the elephant in the room out of the way. Which is that the ONLY reason there could possible be for doing a "month of xxx bugs" is to get attention... in other words, for the press. The press loves this stuff, they are sure to cover it, and you can use any ol' bug you find to fuel it. In terms of "bang for the buck" to get media attention, there's absolutely nothing better you can do. So the question becomes not "what's the point of the month of Apple bugs", but "what's the point of drawing press attention to Apple bugs?" And that's where I disagree with both Ross and Thomas. Because I think there is a point.

Specifically, I've argued all along that Apple's marketing does a disservice to Mac users. They put out a strong pro-security marketing message, and there's nothing wrong with that. However, one could argue that some of their marketing could lead users to believe things about the Mac that aren't entirely true. For example, one could interpret the Apple marketing to claim increased resistance to security vulnerabilities. If that were the case, it would put users in a dangerous position - they might be less inclined to apply updates or they might be less inclined to monitor their systems for intrusion. So, is that the case? Do Apple users have the perception that there are less bugs?

Take a look at the comments from Mac users in response to this article about the relative security of Mac and Windows;

- You can "believe" all you want about the Mac OSX having security flaws, but that won't make it so. Keep dreaming.
- If you talk with hackers, they'll tell you that at this point the Mac is considered THE prize, because everyone keeps claiming that it can't be done. Still, they don't succeed.
- What you need to do next is apologise for your ignorance and complete lack of understanding as to what makes a Mac (and by extension any Unix-based operating system) so much less vulnerable than any flavour of Windows.
- Arguing that gaping flaws like this are equivalent to as yet undiscovered flaws in Mac OS X is simply unsupportable.
- So, hackers *are* trying to crack the Mac, they just suck at it.

Need more? I got bored after page 3; feel free to have a gander yourself. There are pages and pages of Mac users saying that Mac doesn't have vulnerabilities. Not saying that there are *fewer* vulnerabilities... not saying that *maybe there are less*... saying that there are none...

So, is it useful for someone to get the press to point out that Apple has vulnerabilities? In general, I would prefer to know the truth about something rather than believing a lie. For example, as a Mac-owner (which I am one), I would rather know that there are Mac bugs so I can take action and be vigilant as opposed to not knowing about them and getting burned. Now, even if it is less likely that I'd get burned vs. somebody else, that's small consolation if it happens and it was avoidable had I known the facts. But maybe that's just me.

Now, I'm usually pretty calm about stuff like this. They're just doing their job, right? And all of this stuff has a security benefit, so it's worth it, right? Um... Well, maybe not. Now, you all have had to hear me gripe about why this stuff doesn't do anything for security - like why it's "good marketing" for TSA to put on a show of checking for stuff when the security benefit it provides is basically nil. I've had countless conversations with security folks, the majority of whom believe that the TSA security measures are useless. And now yet another respected news outlet is saying it too. And you know what? He's totally right. The security measures are a show... And underneath the show? Continued incompetence.

Incompetence like the fact that they have yet to fix the problems with the Watch List. Now, you might say that inconveniencing a few thousand people is worth the price of increased security; and maybe you'd be right - if this watch list did anything. But it doesn't - in fact it does the opposite. It wastes money that could be spent efficiently on terrorism prevention, it wastes cycles that could be spent on doing something productive, *and* it makes travel more painful all around thereby accomplishing the terrorists' original goal of disrupting our way of life. Wanna get pissed off? Take a look at the TSA fact sheet for 2006 where the DHS lists their "highlighted" accomplishments for 2006. Accomplishment number one is this BS about the liquids... They "trained over 40000 people" and "conducted extensive explosive testing" (all at taxpayer expense) for a threat that we all know isn't feasible. And when TSA finally clued in to the fact that it's bogus? They "proved their flexibility" by "modifying the ban". And what did that cost us, the taxpaying public? Hundreds of millions that could have been spent on developing automated approaches to baggage screening that won't leave innocent travelers with wrinkled clothes and no belt.

Now that's progress.

P.S. If your network has more than a thousand machines and you think you don't have NT 4.0 in some dusty nook and cranny... It's there - you're not looking hard enough.

The one island of stress in an otherwise unbroken island of relax-itude was when my father asked me for help setting up his new laptop. You see, my dad doesn't have Internet connectivity. So when the time came to install all that new shrink-wrapped software he bought with the machine, I experienced a whole world of pain that I hadn't before: telephone software activation. You ever experience this? It's painful. Microsoft, at least, has it down to a science: you call them up, read of punch in the 6 groups of 5 digits, they read it back to you, then they read you the 6 groups of 5 numbers that you type in. At the end of the process (about 20 minutes... I kept track), "blammo" it's registered. Now, that's for Office. You need to go through it again for Windows, again for the OEM software that comes with the laptop, again for the other software that he bought... again and again and again. Of course, most of the places aren't open 24 hours - some of them don't expect you not to have Internet connectivity so they're not prepared to activate the software. One guy had to figure out how to do it and call me back. All at their expense, mind you.

So, here's my question. Why do this activation at all? The reason that we're always given is that it's a piracy-prevention measure. Now I contend that it doesn't for a number of reasons - for example, there are tons of groups out there that love to crack software for the intellectual challenge of the reverse engineering experience. But even if it does protect against piracy, is the cost associated with it worth the benefit? For example, one of the places that I called made a piece of design software that was used in combination with a mechanized wood carving tool. In order to support the activation process, my call cost them the following:

- toll-free connection charges for me to call in and activate
- long-distance charges for them to call me back with the activation code
- approx. 30 minutes of customer-rep time to deal with me
- approx. 5 minutes of the rep's manager's time to figure out how to register

So, is that worth it? If he wants to install the software on another machine (which he will), he'll have to call back and go through the process again. If his laptop crashes (which it will), he'll have to do it again. Each and every time, at significant expense to this company. Usually you don't hear this from security professionals, but I'll go on record - what's a little trust worth? In this case, it's worth hard dollars - and it's easier on customers. I'm wondering what the incentive is...