Friday, March 19, 2010

Bookmark and Share

Archive for the ‘QDSP Blues’ Category

PCI soothes nerves and promotes youthful vigor… good fer what ailes ye.

So, Pete Lindstrom posed an interesting question the other day:  does PCI work?

Now, the answer to this question is both simple and complicated: which is, it works for what it was built for – which may or may not have anything to do with making organizations more secure. Sound crazy? Paradoxical? Out of left field? Maybe so.

But let me ask you to reflect for a second on why PCI came out when it did. Why didn’t it, for example, come out in the eighties? It’s not because there wasn’t fraud then – remember carbon-stealing, BBS carders, and card forgers? They were are around back in the day. But PCI – or CISP when it was just VISA out in front – didn’t start until 2001. Why then and not some other time? The answer, it seems to me, speaks directly to Pete’s point about whether or not it works and also speaks to why people perceive thefts/attacks as problems with the standard.

So, for those folks who don’t remember back that far, 1996-2001 was the era of ecommerce. Everybody and their brother started offering goods for sale over the Internet. Since credit cards were the primary vehicle for online sales, this meant a tremendous number of credit card transactions.  There seemed to be no ceiliing,  and for folks whose business model gave them 2 percent of all goods sold that way?  Well that meant big, big, big bucks.

But there was a problem.  Consumers were afraid.  They didn’t want to use their credit cards on the Internet.  Studies like this one demonstrate that respondents were scared to make purchases because of perceived security risks. Articles like this one from Wired (called “Ecommerce Fears? Good Reason”) were jacking up consumers about the dangers and discouraging folks from using plastic online.

In short, the plastic folks had a marketing problem. Not a security problem, mind you. Why not? Because fraud was already built into the system. Fraud had been happening for decades – the customer wasn’t liable, the banks weren’t liable, the merchants were liable (but it was worth it to them because of the increased business they were doing.) The security of the system was fully understood. But the image problem? Well, that had people losing money… which was patently unacceptable.

What to do? Well, the technical initiatives weren’t faring so well, so what next? How about a vendor compliance program? Why not something called the “cardholder information security program”. Primary purpose: make consumers feel good about using their cards again, tap into the revenue stream held hostage by skittish online shoppers, and cut off the knees of any competitive payment vehicles that might be seeking to capitalize on the fear (Flooze, anyone?)

The real beauty of the compliance program is the subtext – which is that cards are fine from a security perspective, and instead it’s the merchant that has the security problem along along… if the dang belligerent merchants would get in line, it’d be safe again to use plastic and things would be all right with the world.

So now here we are 8 years later. SET failed. CISP is now PCI. So, ask yourself… Did it work? Damn skippy. You know how much commerce there is now? Lots. Are people scared to use their cards online? Nope. So, mission accomplished.

Now, the other question… about whether we’re more secure or not. That’s a bigger issue.

Bookmark and Share

Putting Heartland to rest for good this time

So, I know I said this the other day, but I’m done talking about Heartland until/unless something really interesting happens. And by really interesting, I don’t mean that their CEO was up to no good or that they get sued or that they failed to notify impacted individuals. If you’re surprised by any of those things, you’re way too trusting a person.

No, my prediction is a simple one, and I’m not going to talk about this company again until/unless it comes true. Namely, I think Heartland is going out of business.

Why? Because payment processing is a thin-margin business and it’s highly competitive. Relative to its competitors, Heartland will have increased overhead associated with all the incoming law suits and fines – not to mention all the remediation activity that they’ll have to go through if they do intend to stay in business. Plus, they’ll have less revenue coming in…

Think about it this way… what is it that a payment processor is in the business of selling? If you answered “trust”, you’re right on the money.

So is a merchant going to trust (and therefore sign with): a) the company that oversaw the biggest lost of data of all time or b) the guy down the street selling the same service at the same price with no record of incident? Who’d you pick? And last nail in the coffin in my opinion is that they’re going to need to dump their “bullseye-on-his-forehead” CEO. Seriously. Whether he was insider trading or not (looks like he probably was but let’s give him the benefit of the doubt), he’s an albatross. Dump him.

So what’s that spell? Unprofitableness for Heartland. There’s only so long that unprofitableness can continue, and I’m thinking they’ve got 2 years to go. Others might disagree, but remember what happened to Cardsystems? Sold for a song after losing most of it’s value… So, bye bye Heartland. Was nice knowing you! And thanks for that fraud on my Chase card…

P.S. Tombstone from JJ Chandler’s tombstone generator

Bookmark and Share

Less QQ about Heartland, more pew pew on Blizzard

I really don’t want to talk about Heartland again. The discussion is tired in my opinion, but I want to once again go on record saying that PCI is fine, no matter says otherwise. The fact that Heartland was busted doesn’t mean that there’s something wrong with PCI – the same way that a hospital being busted doesn’t mean there’s something wrong with HIPAA. Again, if I go out and streak the superbowl, that doesn’t imply that there’s anything wrong with the indecent exposure and public nudity laws.

What I think is much more interesting (although nobody else seems to care) is the summary judgment issued today in Arizona court on the MDY vs. Blizzard case. Here’s the text if you think you might care.

What’s interesting about it, you ask? Well, here’s the 50000 foot: MDY makes a product that automatically plays Warcraft for you. Blizzard provides Warcraft to users at outrageous fees. MDY says they’re not doing anything wrong – just automating the gameplay experience so you can get phatter lutez and mad XP in-game. Blizzard says that MDY is generally evil for a number of reasons such as violating the DMCA, spitting on their EULA, ruining the in-game economy, blah blah blah. MDY says that’s bogus. Blizzard sues. MDY refuses to comply. Rinse and repeat.

Turns out the court thinks Blizzard’s right.

Now, don’t get me wrong here. I think MDY is in the wrong – after all, why do we need MDY’s mindless WoW-playing automaton when Blizzard already has the WoW-automaton market cornered?

But what I find scary about this is that it’s precedent for other things – actually a comment on the Freedom to Tinker blog beat me to this punch, but I’ll underscore it here too… If it wasn’t add-on software for WoW that we were talking about, but instead something else? Does Microsoft get to sue me if I use an undocumented API? What if I write software like Wine? Do software manufacturers now get to decide who can integrate with their products and who can’t? I’m not sure I like where that road leads…

Bookmark and Share

Heartland, Heartland, blah blah blah…

Everybody keeps talking about Heartland. Now, personally, I think the story’s been played out just a touch too much… but since everyone keeps talking about it, who am I to criticize? I’ll just go with the flow.

So, interestingly, the CEO of Heartland has gone on record saying that he’s concerned about the frequency of cyber attacks and that he wishes PCI has a requirement for encryption built into the process. Specifically, he said:

“I believe that had we known the details about previous intrusions, we might have found and prevented the problem we learned of last week,” Carr said…The Heartland boss is also advocating the adoption of data encryption throughout the payments industry, as well as improved and safer standards of payments.

Umm… Is it me or does anybody else see something wrong with that statement? Like, the article isn’t real specific about where he wants there to be more cryptography, but it seems to me that there’s a number of cryptography requirements built into PCI already. For example: 2.1.1, 2.3, 3.4, the entirety of requirement 4, and so on… and so on.

If “render PAN, at minimum, unreadable anywhere it is stored…” isn’t clear enough, it goes on to describe using cryptography to do that. Based on what I’ve heard, I’m not sure how encryption would have helped here anyway. But I guess I’ll wait until there’s more data out there before calling them to task on that.

No, I think this is just an attention-diverting technique on the part of Heartland to say “it’s not our fault, there should have been more regulation”. The bankers said that too about the financial meltdown, and I’m getting tired of it as an excuse. I can’t use it in day-to-day life, for example. I can’t go on a kleptomaniacal rampage in the mall and then say, “well, I realized that there were laws about shoplifting, but really they weren’t specific enough. Rather than holding me accountable, why don’t we all join together in advocating more specific guidance. Like about not stealing pickled ribs… from Hickory Farms… during the post-holiday sale”?

It’s just dumb.

Bookmark and Share

PCI irrelevant? Or is it just us assessors?

It seems that the world’s abuzz with thoughts about the utility of PCI. Not surprising in light of the worst credit card breach of all time happening just the other day.

So, first I saw Alex’s take over at RiskAnalysis and he’s got some interesting juice for making you think and then I saw Mike Rothman’s thoughts on the increasing irrelevance of PCI. Both are worth reading, and I highly recommend that you do so. Props to Mike and Alex for (as usual) getting something worth reading into the security blogosphere.

So, there’s been some speculation on the utility of PCI and whether or not it continues to have any in light of the recent breaches. People are naturally wondering:

- If it’s useful to give an attacker a list of what protections a retailer is going to have in place as PCI does?
- Is PCI useful when all these supposedly-compliant organizations are getting broken into?
- Should there be an overhaul of the process in light of all the foolishness that’s been going on?

But I think there are a few points that bear mentioning related to the discussion. The first is that compliance != security. You can be compliant until you’re blue in the face, and that has no bearing on whether or not you’ll get attacked (successfully or not). So, just because somebody who was (allegedly) compliant gets hacked, doesn’t necessarily mean the process is broken. If the value is high enough, somebody will find a way to attack it, no matter what they are or aren’t compliant with. Just ask the military.

But the second point is whether they should have been given compliant status in the first place. In the case of Heartland, they had malware on a system that was passing around track data (at least according to the reports I’ve seen so far – maybe that’s off base.) Is it a problem that that system was asserted to be compliant by a QSA? I’m not sure it is…

First of all, no assessor can audit every aspect of a retailer. If they did, each assessment would cost bagillions of dollars every year. So, there’s sampling involved – and plenty of opportunity to slip through the cracks. Second, there’s varying degrees of skill and technical astutitude in the QSA population. Do some QSA’s suck? Yes, they do. Will some of them rubber stamp your dog as being “compliant”? Yes, they will. But that doesn’t mean the standard itself is flawed…

All in all, I think it’s a good thing. In my opinion, telling a retailer that they have to run an AV program doesn’t give away too much secret sauce to make attacking them any easier. It just a) gives them guidance that they should be doing it and b) sets a minimum bar for someone to hold them too.

Anyway, just my two cents.

Bookmark and Share

Pure, unadulterated, hilarity

Today, Diana came across this on the wild, wild, world of web. I won’t spoil the fun by giving away too much of it here – suffice it to say that it is hilarious. Unadulterated hilarity.

I suppose it’s funniest because of the grain of truth nestled inside their sarcastic message. Now, we over here would never say that the whole PCI certification process is a joke (please don’t interpret what we’re saying as anything close to that), but suffice it to say that the fact that we’re totally on board with poking fun at those unscrupulous vendors who would attempt to leverage PCI to make a quick buck… as Mastercard would say, “priceless.”

Bookmark and Share

PCI Security Standards Council: Summary of Changes DSS 1.1 to 1.2

Yesterday the SSC released a 4 page summary document of changes to the PCI-DSS. The next version of the DSS is due out on October 1 this year.

So how’s it look? Overall, we’re pretty encouraged. The core changes relate to wording clarification and will help merchants and retailers to understand available options for compensating controls.

As with any update, though, it looks like this one might have introduced some big questions as it simultaneously answered many others. Let’s take a closer look:

Cause for Celebration Changes

Requirement 1

Bookmark and Share

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

Bookmark and Share

My mouth gets me in trouble (once again)

OK, so I posted a while back about the whole QDSP training process, and the folks over at the PCI and Data Security Compliance Blog (rightly) called me on it for being overly negative toward the wrong people. Actually, I was mostly trying to be funny, but this was unquestionably the wrong way to go about doing it. Anyway, I felt it might be good to take a moment and lay out what my frustration actually is (and why it’s not with them) and apologize to those folks for taking it personally (I actually respect their work quite highly)…

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.

Bookmark and Share

Musings about PCI in the press

First of all, my apologies for not blogging in a while… even after I said that I was back and that I’d be blogging more. It’s the holidays, and trust me, I really needed the downtime. Anyway, now I’m back and should be keeping abreast of things – at least until the new year. :-) Anyway, I came across an interesting thing the other day; it was an article from -Rob Pollard entitled PCI Data Security Standard Calls for Next-Generation Network Security. Check out the following excerpt:

“The confluence of network security and network performance creates a secure sphere of vigilance from the core of the network to its edge, enabling IT managers to watch for internal breaches of established security protocols at the same time they are monitoring for external infiltration.”

Now, I was interested because of the reference to PCI.  I try keep up on
this stuff because I’m a “QDSP” – which, though I would like to tell you stands for “Quasi-Delirious and Spasming with Pain,” really stands for
"(supposedly-)Qualified Data Security Professional”; what that means in
practice is that I’ve been to VISA’s "sit in a room and drink burnt
coffee" training.  It also means that I’m approved by VISA to assess
people on their PCI compliance.  Since the training didn’t really prepare
me for some of the things I’d encounter in the field, such as how to conduct a
PCI audit or how to interpret the standards (preferring instead to concentrate
on the format/structure of the magnetic stripe on a credit card, why it’s
important not to let criminals get credit card numbers, and why SET was a work
of misunderstood genius), I tend to read any articles I can find about PCI to
keep abreast. 

Anyway, the point is that I read this in the light of trying to better
understand PCI.  Now, before I get into this, let me say that I have no axe
to grind here – I think the article was on-track from a security perspective,
and I think it was executed very eloquently by the author – I am not
doing it down.  However, that being said, I think it illustrates a point
that I’ve been trying to make for a while now – which is that when it comes to
compliance, it pays to take what’s in the media with a grain of salt.  For
example, check this out:

[PCI] requires that network security managers know the established network conversation patterns of every employee, who has access to which servers, what data must be encrypted, and how to restrict access to the most sensitive data stores. 

That’s a pretty bold stake in the ground, no?  In order to do this, network
managers would have to have detailed information about every user, every
application in use, every machine on the network, and every little tidbit of
data enterprise-wide.  Wouldn’t they?   After all, how would they
know what the "established conversation patterns" are if they didn’t
know what applications were in use?  Or how would they know what data to
encrypt if they didn’t know what data there is to choose from?  Now, I
agree that this type of thing would be useful.  For sure.  But is it mandated
I don’t think it is.  Saying that this is "expensive and
time-consuming" is an understatement akin to saying "some people don’t
really enjoy liver all that much." 

PCI requires a new breed of security technology that can ensure the same level of security for internal operations as for the perimeter…
The ideal solution would be able to track routine network usage by every employee, identify when and how critical servers are being accessed, harden and segment networks to proactively prevent unauthorized access to confidential information, and prevent attacks from compromising legitimate access to critical information.

Really?  The same for internal as external?  Look – I’m not saying
these aren’t good security measures.  All I’m saying is that I don’t agree
that they’re required by PCI; in fact, I would argue that the PCI requirements
merely codify what most folks should be doing anyway.

Bookmark and Share
“Targeted security advice when it’s needed.”
Blog Cloud

The Law: Fear It Administrative Cruft (16)
Analysts (31)
Apple (25)
AppSec (12)
Assessments (2)
Auditors (2)
Biometrics (4)
Blogs (13)
Breaches (21)
Buzzwords (2)
By Grabthar's Hammer!! (1)
Certifications (1)
Change Management (1)
Cheezburger Network (1)
Chupacabra (1)
Cloud Computing Security (4)
Collaborative Strategy Guild (2)
Compliance (4)
Copyright (9)
Credit Cards (3)
Crypto (11)
CXO Summit 2010 (1)
Cyberterrorism (2)
Data Protection (2)
DHS (25)
eBay (1)
Emergence (1)
End-to-End Encryption (2)
England (1)
Financial Fraud (1)
FISAP (1)
Forensics (5)
FTC Red Flad Rules (1)
FUD (12)
gnisreveR (2)
Google (2)
Holidays! (3)
Humor (16)
Identity Theft (4)
James Bond Shiz (1)
Legal Shiz (13)
Linux (3)
Malware (35)
Marketing and PR (9)
Messaging Security (1)
Microsoft (26)
Monoculture (3)
Mouth-Frothing (2)
Musings (17)
Open Source (3)
Oracle (21)
Outsourcing (4)
Paris Hilton (1)
Passwords (1)
PCI (4)
Phish-Eye (8)
Phones (5)
Planes (1)
Privacy (1)
Programming (1)
QDSP Blues (15)
Research (30)
Resources (6)
Rhesus Monkeys (2)
Risk Management (18)
RSA 2009 (1)
RSA 2010 (1)
SAML (1)
SAN (1)
SC Mag Blues (1)
SCADA (1)
Security Curve (8)
SecurityCurve Speaking (2)
SIEM and Log Management (5)
Social Networking (1)
SOX (1)
Speaking (2)
Spinach (1)
Spy Stuff (1)
Stealing Stuff (8)
Storage (1)
Symantec (7)
Tarot (1)
Teleological suspension of the ethical (3)
The Great Borack (1)
The Law: Fear It (10)
The Old Man of the Mountain (1)
The Regs (5)
Tokenization (1)
Useless Shizz (13)
Vendors (37)
Virtual Worlds (2)
Voting (2)
Vulnerabilities (40)
Walt Disney (2)
Wi-Fi (16)

WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.

Archives