Creating Epic Fail Conditions: PCI and Best Practices

| 2 TrackBacks

I grow increasingly impatient over the entrenched status quo. Throughout all the blah-blah from vendors, analysts, consultants, etc., there is very little new - let alone hopeful - news to look forward to. Why? Because the old school mindset fails time and time again. Why? Because the objectives are all wrong. Forget about risk - there's almost no point in trying to manage it right now (for a number reasons, as if organizations are really managing info risk right now anyway). If you want to survive, then you must establish a (legally) defensible position and then focus on recoverability, since it's not if but when bad things will happen.

Fear not... despite the semi-angst-like nature of my opening paragraph, not all hope is lost. In fact, honestly, there's reason to be very hopeful, if only we can get mainstream thinking to shift away from the failed old ways. Old ways such as relying on "best practices" (aka "mediocrity") and checklists (*cough*PCI*cough*). You cannot simply look for a list of known bad things (*ahem*AVIDSIPSFWACLDLP*ahem*) and then hope that everything will be ok. Instead, you absolutely, positively MUST build a program that is flexible (see my Sept. '09 ISSA Journal article "Elasticity: Will your organization bend or break?"), that seeks to achieve a (legally) defensible position, and that optimizes recoverability for its environment (see "Defensibility and Recoverability").

This latest line of contention (perhaps sounding like a broken record from me) was triggered by a couple things I read today. First up, "Ending the PCI Blame Game" by Phil Mellinger (CEO, Turiss) posted on CSO Online. In it, Mellinger proposes changing the game, in part to get away from the "blame game" (aka "litigation"), though it's unclear what the new game is really supposed to be. He proposes five steps to the future, which are:

1) A moratorium on litigation to eliminate the "blame game" - This is just a bad idea, because the "blame game" (aka "litigation") should drive companies toward adopting a legally defensible position. A short-term moratorium might be ok, but only to give companies a chance to refocus on doing the right things (i.e. defensibility and recoverability). More importantly, achieving such a moratorium would really take an act of Congress, and that seems highly unlikely to happen.

2) Mellinger wants PCI to evolve to address so-called "third-wave attacks" - This is a moronic approach, promoting more of the same stupidity that got us here in the first place. We need to quit writing checklist responses to known threats. Instead, we need to require due diligence and define how you measure due diligence and then let the details sort themselves out (in court and on the books). If the position is not legally defensible, then companies will lose in court and the markets, plain and simple.

3) Improve fraud intelligence - This is very reasonable, though as part of an overall program, NOT simply adding more checklist items to PCI. Mellinger says "This is a complete change in our current PCI dogma..." but I'm not convinced what he's asking for really is a change. What he's advocating is more of the same reactivity and checklist response. Threat intelligence is great for feeding the evolution of security programs, but only when the programs focus on defensibility and recoverability (i.e. survivability).

4) Changes are needed in international laws that create sanctuaries for attackers - I absolutely agree, though this is only the responsibility of companies involved from a lobbying perspective. Addressing this issue will require political leverage and diplomacy. Good luck with that - I won't hold my breath. Competing nation-states have too much to gain strategically in maintaining these sanctuaries. The only way I could see this really happening is if the number of attacks originating from countries like the USA against countries like Russia and China were to increase dramatically (and be incredibly successful). Such a shift in the balance of attacks could drive all parties toward unilateral agreements equivalent to Cold War era agreements.

5) "...new security approaches must be developed to thwart attackers and their weapons..." - Yes, this is definitely a good idea, but again, this should be driven by the desire for achieving a (legally) defensible position and for optimizing recoverability; it should NOT be driven by some sort of old school reactionary mindset.

The other article that got me thinking about how things are so broken, but that there may be a light at the end of the tunnel, was Bejtlich's "Let a Hundred Flowers Blossom" post today. Overall, I think he's pretty solid on his premise, though - as usual - he makes me nervous as his progressiveness sounds marginally reactive. It's striking the balance that is important, of course, between reactive and proactive measures. Field-assessed security, done well, can be very effective in building a defensible position, but it does not in any way decrease the importance of recoverability.

One thing he does bring up that concerns me is the mono-culture argument... is this argument really valid any more? It seems to me that there are a couple flaws in it. Part of the mono-culture argument is that you don't want everything on the exact same system, because if you do that, then one compromise can affect everything. However, this isn't terribly close to reality, is it? Rarely will a single OS-level exploit (for example) successfully target Windows XP, Vista, 2003 Server, 2008 Server, and Windows 7 (dare I say it would never happen?). Application-level attacks would be a different story, of course, but the point is this: is there even such a thing as a mono-culture any more?

The other aspect of the mono-culture argument is based on a premise that one slice of the pie is significantly larger than all the other slices, such that moving platform to a smaller slice will benefit you by making you less of a target. Unfortunately, if enough platforms switch over time (as has happened), then the slices become more comparable in size. At some point, all (major) slices become equally appealing. While this may reduce the number of attacks against the originally dominate platform, one would expect to see a correlated increase in attacks against the other major slices. As such, has anything improved from a security standpoint? It seems that you still have to focus on defensibility and recoverability, and simply relying on a less popular platform is nowhere near adequate in either case.

Lastly, I would agree with him that some standards are needed, but I think they need to be outcome-oriented, requiring:
- analysis and capabilities that achieve recoverability objectives
- adequate measures be implemented to achieve a legally defensible posture
- a shift in mindset from "winnable" to "survivable" online conflicts/incidents/events

Comparably, attackers have nothing to lose while the targets have everything to lose. This sort of skewed loss ratio tells us that we cannot hope to be 100% successful, and thus must focus on reducing the size of the losses. We can only achieve this through a survivability approach that seeks to build a (legally) defensible position with optimized recoverability.

2 TrackBacks

In August 2009 I wrote about "Defensibility and Recoverability", in which I started developing the notion of using a legal basis for building a defensible position. I later expanded on this notion in the post "Creating Epic Fail Conditions: PCI... Read More

In August 2009 I wrote about "Defensibility and Recoverability", in which I started developing the notion of using a legal basis for building a defensible position. I later expanded on this notion in the post "Creating Epic Fail Conditions: PCI... Read More

About this Entry

This page contains a single entry by Ben Tomhave published on December 4, 2009 4:56 PM.

BeFUDdled by Risk was the previous entry in this blog.

Embrace Murphy's Law is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7