PCI

Appearance on the Ranting Roundtable, PCI Edition

Submitted by Mike Rothman on Fri, 2009-08-21 09:37.

I was flattered to be invited by Rich Mogull of Securosis for the maiden voyage of the Ranting Roundtable. Basically this is a bunch of loudmouths, who need to yell and now we finally have an outlet. We didn't yell at each other (too much), use profanity (too much), abuse goats (too much) or delve into various circle jerks about the futility of our chosen profession (too much). OK, we did do the latter quite a bit, but that goes with the territory.

Amazingly enough, we kept the pace moving for 50 minutes or so and actually were more constructive than I hoped, since I figured with the topic of PCI, we'd just decend into useless chatter, Heartland hating, and get mired in a cesspool of futility.

But we didn't, so enjoy. Here is Rich's write-up and the link.

The Ranting Roundtable, PCI Edition

Sometimes you just need to let it all out.

With all the recent events around breaches and PCI, I thought it might be cathartic to pull together a few of our favorite loudmouths and spend a little time in a no-rules roundtable. There's a little bad language, a bit of ranting, and a little more productive discussion than I intended.

Joining me were Mike Rothman, Alex Hutton, Nick Selby, and Josh Corman. It runs about 50 minutes, and we mostly focus on PCI.

The Ranting Roundtable, PCI.

Odds are we'll do more of these in the future. Even if you don't like them, they're fun for us.

No goats were harmed in the making of this podcast.

—Rich

Photo credit: "Big Mouth" originally uploaded by upchuck_Norris.
Any likeliness of the picture to anyone on the panel is purely coincidental. OK, not really.

 

What the F is with Visa?

Submitted by Mike Rothman on Wed, 2009-03-04 08:51.
Today's Daily Incite

March 4, 2009 - Volume 4, #22

What the F is with Visa?

Good Morning:
Sometimes I just sit in my office and scratch my head. It's rare that I'm speechless (very rare, just ask the Boss), but when I came across this article in NetworkWorld on Visa's latest perspective on the "new" data breach, I was pretty much paralyzed. Yesterday, SC Magazine covered it as well.

Must be Visa, MasterCard and AMEX's PR folks...In a nutshell, Visa is either being run by lawyers or the Three Stooges. It's not clear to me which one, though I'd have to side with the lawyers at first glance.

In a classic Clintonian "it depends on what the definition of is is" moment, it turns out Visa's statement on the "new" breach didn't indicate it was actually new. And now they are saying it wasn't new. Maybe customers were compromised. Or maybe they weren't. Holy crap I'm confused.

Which is the real problem. First of all, it's clear that consumers credit card data has been compromised. Maybe it was a new breach, maybe it wasn't. But clearly there was a successful (very successful, dare I say) attack vector and we still don't know anything about it. Instead we have word games and obfuscation from the lawyers that have to approve any messages that go to either customers or the media.

With all due respect to my Dad and all the other lawyers I call friends (most of the time), I hate lawyers. You see, this gets back to the disclosure issue. These attacks are happening, RIGHT NOW. These attacks are being successful. Financial institutions and retailers are sitting under a two ton anvil called the recession (some would even say depression).

These folks need to optimize their resources and make sure their defenses are in place against new and innovative attack vectors. Instead, you have their lawyers trying to decipher what Visa and Mastercard's lawyers are saying or not saying. All the while the attackers continue to have their way with pretty much anyone and everyone (PCI compliant or not).

I know I'm asking a lot, but to hear the truth would be nice. It's all fine and dandy that Visa is now "risk scoring" each transaction to look for fraud (didn't they do that anyway? If not what the hell do I pay my 2% per transaction for?). But they are still reacting to the attacks, not helping to address them.

Makes me want to do my best Moe imitation and give an eye poke to Larry (Visa) and a head slap to Curly (MasterCard).

Have a great day.

Photo credits: “Three Stooges” originally uploaded by NYCArthur 

Technorati: , , ,

The Pragmatic CSO

The Pragmatic CSO:
Available Now!

Read the Intro and Get
"5 Tips to be a Better CSO"

www.pragmaticcso.com



The Increasing Irrelevance of PCI

Submitted by Mike Rothman on Mon, 2009-01-26 09:20.
Today's Daily Incite

January 26, 2009 - Volume 4, #9

Good Morning:
Quick intro today, since I spent most of my allocated TDI time ranting about PCI. It's got a major problem of relevance, given the second (that we know of) massive data breach on a PCI "compliant" organization. So what will they do? Let's just say I have some ideas about what they should do... 

PS: Last call for the Pragmatic CSO Forum I'm launching with the Business of Security folks. We start the Forum sessions tomorrow, so this is the last opportunity you'll have to learn the methodology. We're running a promotion now for anyone that signs up for the Forum will get a PDF of the book included.


Have a great day.

Technorati: , , ,

The Pragmatic CSO

The Pragmatic CSO:
Available Now!

Read the Intro and Get
"5 Tips to be a Better CSO"

www.pragmaticcso.com

The Increasing Irrelevance of PCI

This is a hard post for me to write. I've been a big fan of PCI, pretty much since it's inception. It was a lot more specific than previous regulations. I may not agree with all of the requirements (like the AV mandate), but at least there were a list of things that merchants could do to start on the road to security.

I'm a pretty Pragmatic guy, so I knew that most folks would look at the 12 requirements and figure that's all they needed to do. That once the PCI Assessor delivered the report, that they'd be secure and their credit card data would be safe. Of course, they would be wrong - but I figured we needed to start somewhere and PCI was a good start.

PCI = FailAnd it was for a little while, but it's like sending your playbook to the opponent before the big game. Your adversaries know exactly how you plan to defend against them. It's not too hard to devise a new attack to circumvent those lowest common denominators. Which is exactly what the attackers that successfully compromised both Hannaford and most recently, Heartland did. 

I wrote on the eIQ blog about how I think we can add incremental defenses to protect against these new attacks, but that still doesn't answer the crisis of confidence facing PCI right now. Sure the 12 requirements are a good start, but clearly they are not enough and the general consensus-based process of updating the requirements means PCI is always solving the attacks of 2 years ago. For instance, the mandate to eliminate WEP from wireless networks is only going into effect this year. WEP has been severely broken for over 2 years.

So I believe the PCI Security Standards Council has some serious soul searching to do. The Council needs to act quickly and decisively to stem the rising tide of irrelevance. Or else they'll need to acknowledge that PCI is the next HIPAA and organizations will continue to due the bare minimum to comply, while secretly snickering at the ridiculous hoops they have to jump through to little benefit.

The first step is to announce they are going to do a 45 day review of the current set of requirements to determine if they are still relevant and to pinpoint gaps, maybe even publish some new guidance and clarification on the weakest requirements (or the one's that just aren't working). The first step is always the hardest, and thus far the public stance from the Council has been one of "not my problem." They only set the rules, they don't enforce them. That's the wrong answer, but it's the predictable one.

In terms of the massive change needed, as you would expect, I have some ideas about how the requirements should evolve. The reality is that security is not binary. No one set of guidelines is reasonable for every organization out there. Larger organizations (with more to lose) should spend more than a mom and pop shop. The current process of requiring a real assessment for Tier 1 merchants (as opposed to a self-assessment) tries to factor this in, but everyone is working off the same set of requirements and that's wrong. 

I would define a set (probably 3) of different security levels. The lowest level would be today's bar. We know it's not sufficient, but again it's a start. Then they add at least two more levels beyond that, including maybe a full monitoring level and perhaps an end to end encryption level, depending on the merchant's threshold for risk, their size and their willingness to invest in security.

The sad truth is that it's probably not cost effective for every retailer to get to the highest level. Even if they do suffer a breach, the cost of doing whatever the highest level may be (especially if it involves widespread use of encryption) may outweigh the cost of cleaning up the mess. Not for everyone, but for enough that requiring the highest level of security doesn't make sense for them.

Saving Private PCIBut how is this different? So what if there are three levels of security (that merchants can market to), where is the catalyst to get anyone to the highest level of security? Drum roll please.... the answer is TRANSACTION FEES. Merchants live and die on transaction fees. It's a huge part of their cost model and if they can reduce those fees, then investments can easily be justified.

I believe the only way to get retailers to adopt higher levels of security is to make it a good business decision. They need to be able to make a reasonable return on their investment, and then it will happen. That's the way free market economies work. Thus, we set different levels of transaction fees, depending on what level of security the organization achieves.

By the way, this makes sense for the upstream side of the equation as well. Given the potential risk of having a low level of security and the associated fraud costs that accrue to the system, issuing banks and credit card brands can also make money by reducing the transaction fees - for an increased level of security.

I've spent two decades paying attention to the drivers of what makes businesses do things. I've spent a lot of other people's money proving that you cannot make a market. Latent demand needs to be there based on a good business decision for the customer. They need to be able to either save money or make money by deploying technology. It's a simple as that. So it's just simple economics that drives me to believe the only thing that will get organizations to invest in security is to help them reduce their costs. If they can't see a clear cost savings, they'll do the least amount possible. Not many organizations do security because it's the right thing to do.

It's Monday and I guess I'm being a bit idealistic, eh? The likelihood this will happen is very small. There are a lot of folks within the council that can't afford to rock the boat too much, and the occasional black eye isn't enough to truly agitate for longer term change. So with each data breach PCI becomes weaker and weaker until it ends up similar to HIPAA. Unless something changes organizations will continue to pay lip service to it, customers won't trust it (to the degree they even know about it), and it becomes just another report that is generated out of the security reporting system, which is my definition of irrelevance.

Photo credit: “Fail (19/08/07 137)” originally uploaded by The Happy Robot


Incite Redux: Day 7 - The SDLC is your friend

Good Morning:
When was the last time you used a pay phone? For me it was a LONG time ago. I'm not sure why I thought about that, but sometimes entire industries just go away and we hardly notice. Pay phones were a very big business for the phone companies many years ago. I remember having my trusty phone card always by my side and finding those germ-ridden phone boxes wherever I could to check in.

Yes, this was before cell phones became ubiquitous and Blackberry's made 24 hour connectivity not only possible, but connected. This is why I always tell everyone to question everything. I'm sure the phone executives didn't figure their cash cow pay phone business would just go away. Even early in the cell phone revolution. I still used my calling card in hotels because the cell phone was too expensive to use all the time. Now, not so much.

So what can kill your business? What will you do if your main cash cow just goes away? If you work for a big business, these questions may not be that relevant (since I doubt a company like GE is going away, even if a portion of their businesses), but if you work for a small business - it certainly is relevant. I see this every day. Companies that were great businesses are rendered obsolete. And the businesspeople either adapt or they die.

Darwin would be proud. He was right. Have a great day.

Incite #7: The SDLC is your friend

As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Read the original Days of Incite post on this topic.

6-month grade: C

I curse the PCI 6.6 clarification. Ugh. It was that one little clause of either WAF or code reviews/SDLC to be compliant with 6.6 that torpedoed this Incite. Fact is, I've written a lot about the fact that most organizations will opt for the path of least resistance, and that usually means a box - as opposed to a process change. And a WAF is a box, and an SDLC is a process change. Guess which one wins, when deemed reasonably equal in the eyes of the assessor?

Path of Least ResistanceNow has their been a lot of innovation in the WAF space? Not really. But who cares. It's the path of least resistance for many trying to outrun the specter of PCI - so it's not only have WAFs found their sea legs, but you are seeing integration with web app scanning and other parts of the eco-system. By the way, if being wrong about an Incite means things are moving forward - then I'm cool with it.

But what about secure development practices? What about SDLC and code reviews and the like? Yep, they are still important and I think that implementing these concepts now will pay dividends for years down the road. And I also know it's hard and that many dev teams will be resistant to changing the way they do things. All I can say is to keep fighting the good fight and focus. 

One approach is to build up a grass roots effort by focusing on those apps that directly handle critical data. You aren't going to totally and fundamentally change things overnight. Nor should you. Some apps don't need to be overhauled, since they are either not exposed or they don't handle sensitive data. But for those that do, keep banging away. Yes you get a headache, and probably a callas on your forehead. 

If it was easy, everyone would be doing it.

Photo credit: "Path of Least Resistance" by kisses are a better fate than wisdom

PCI 6.6 and Fear Mongering

Submitted by Mike Rothman on Mon, 2008-06-16 09:24.

Amazingly enough, every time it starts to look dour for the security business, a new regulation comes down from the heavens to give security marketers another wave of fear, uncertainty, and doubt to throw at unsuspecting customers.

Yes, the recent "clarification" of PCI requirement 6.6 (pdf) is the latest in the ongoing wave of regulations that are meant to keep security professionals on the edge of their seats in Depend undergarments. Given the number of ways you can get killed today (just ask the security marketers for a few examples), there is no shame in a blowout or two every so often.

FUD TruckThough this rant is not about PCI 6.6, which I think is the kind of clarification we need to provide good direction to security professionals about what good practice is. My problem is in how some security companies are using the regulation to try to get some level of urgency, so they can sell their stuff.

I'm a businessman, and I've been in the game long enough to understand how it's played. I know fear-based marketing is part of the process. Security is like insurance and unless you think you are going to die or wreck your car or have a tree fall on your house, you wouldn't buy much insurance. So the job of the insurance salesperson is to convince you that not only will those scenarios happen, but they are even likely.

From a disclosure standpoint, I carry insurance on my life, my cars, and my house -even though I understand statistics and know that it's probably a bad deal. I still buy it anyway because you never know... But security is a bit different. Most folks understand what happens when a tree falls on your house (it isn't good). Most executives can't really envision what it means when a hacker sells your customer database to the Russian Business Network.

Yet again I digress. I got a head's up about a release from Ounce Labs last week when I was about to board a plane. Thankfully they had barf bags on the plane, so I didn't make a mess. The release pretty much made me sick because it represented pretty much everything I hate about security marketing. OK, not everything - but a lot.

Let's start at the title: "Leading Security Expert Asserts that PCI Compliance is Not Achievable Without Source Code Analysis." I hope you haven't eaten yet today because you are about to be served a FUD sandwich. Yummy. The release goes on to talk about how PCI compliance is about more than a firewall and that an organization cannot be truly secure (or PCI compliant) without reviewing their source code.

Let's be very clear. An organization CANNOT be truly secure - even if they review their source code. There is no such thing as "truly secure." But it does provide a good sound bite and some good FUD for security professionals to chew on.

In this case, Ounce is both right and wrong. Since I'm trying my best to be a half-full type of guy - they are right in that source code analysis needs to be part of any security program. You won't get much disagreement about that.

What I object to is saying that you cannot be compliant without source code review. Huh? How do they know? I'm sure there are lots of QSA's out there that will provide the rubber stamp via other methods to secure applications. Like a web app firewall or other compensating controls (like database monitoring and leak prevention).

PCI Assessments (and every audit for that matter) are a totally SUBJECTIVE process. It's based on the judgement of the auditor/assessor that shows up. Sure they have guidelines and even some new quality standards, but at the end of the day, it's based upon whether the auditor buys into your security strategy and believes you can meet the spirit of the regulation.

Anyone who tells you any different is:

  1. Full of crap
  2. Trying to sell you something
  3. Just fell off the turnip truck
  4. A combination of all 3

Relative to PCI 6.6, I personally believe that the best approach is to deploy a web application firewall (or some other application layer blocking technology) to eliminate the low hanging fruit of application attacks. At the same time, high profile applications should be reviewed for security problems, first with a scanner and then a pen test to isolate logic flaws.

Finally, to complete the secure application triad, the development process should evolve to include things like source code analysis and other secure coding techniques. But in the real world, it's unlikely you get to complete the triad, so you do your best to eliminate the most obvious issues and pray that the less obvious ones don't bite you in the ass.

Ultimately this gets back to money. Since the beginning of time, it's been easier for security folks to throw boxes at the problem, then to change behavior or evolve process. And the 6.6 clarification provides a clear excuse to look for a silver bullet wrapped in a 1U enclosure with flashing lights.

Ounce is just trying to say that a WAF is not a panacea. And that they have a quarter to make and investors to keep happy and customers really should look at source code analysis. Please, pretty please, with sugar on top. I get that, and I empathize with the folks that are trying to sell "solutions," when the market wants to apply a band-aid and make the problem go away.

But leveraging FUD, conjecture, and other marketing tactics like this still annoys the crap out of me. It's disappointing, but I'm a big boy and I know it will always be part of the process. That doesn't mean I won't continue to call it out for what it is.

OK, off soapbox now.

Photo credit: "FUD Truck makes a delivery.... (NEW! Savoring our FUD)" by crmudgeon23

 

Does PCI have teeth?

Submitted by Mike Rothman on Mon, 2006-09-25 13:53.

One of the things I've mentioned pretty frequently is the need for the PCI (payment card industry) standard to get some teeth (here, here, here). Now it seems (at least according to the Wall St. Journal) that enforcement is commencing on folks that can't get their PCI act together, which is GREAT.

Of course, I'll reserve my judgment until I see Visa and/or MasterCard take a bite out of some retailers leg in a public way, but the early indications are promising. The WSJ (here - requires subscription I think) reports that MasterCard has already started fining organizations and Visa will begin this week, ranging from $10,000 to $100,000 a month.

$100,000/month is still a rounding error for a mega-retailer, but it's not chump change either. That combined with the recent update (PCI 1.1) which eases some of the restrictions in favor of compensating controls, makes it achievable for the larger retailers to get there since much of this is stuff they should be doing anyway.

But as with most other things, I know of at least one group that will continue to profit mightily from the regulation, and that's the assessors that give the yay or nay on whether someone is "compliant."