Harvard Business Review: Excellent Data Breach Case Study…
I read the Harvard Business Review frequently and find that the quality of writing and insight it provides is excellent. This month’s (September 2007) edition is no exception as it features a timely data breach case study written by Eric McNulty titled "Boss, I think Someone Stole Out Customer Data."
The format of the HBR case studies are well framed because they ultimately ask you, the reader, to conclude what you would do in the situation and provide many — often diametrically opposed — opinions from industry experts.
This month’s commentators were Bill Boni (CISO, Motorola,) James E. Lee (SVP ChoicePoint,) John Coghlan (former President & CEO of Visa,) and Jay Foley (Executive Director of the Identity Theft Resource Center)
The fictitious company profiled is Flayton Electronics, a regional electronics chain with 32 stores across six states. The premise of the fictitious data breach focuses on the manner in which Flayton Electronics decides what to do, how to interact with LEO, and how/if to communicate the alleged data breach consisting of potentially thousands of their customer’s credit cards.
What I liked about the article are the classic quote gems that highlight the absolute temporal absurdity of PCI compliance and the false sense of security it provides to the management of companies — especially in response to a breach.
You know, "We’re compliant, thus we’re secure, ergo we’re at less risk."
Now, I’m not suggesting that compliance initiatives don’t make things "better," in some sense, but they don’t necessarily make a company more "secure." I think the case study demonstrates that well enough and the readership of this blog certainly doesn’t need to be convinced.
So, why write about it then? The quote snippets below illustrate reality — sometimes hysterically. You’ll have to read the entire story to gain true context and to appreciate the angst this sort of thing brings, but I chuckled a couple of times when reading these quotes:
“What’s our potential exposure?” Brett inquired matter-of-factly.
Quietly he wondered whether the firm’s PCI compliance would provide
sufficient protection.“Why do we have to notify customers at all?” Brett asked, genuinely
puzzled. “Haven’t the banks already informed them that their accounts
have been compromised?”“What about some kind of coincidence?” Brett was grasping at straws.
“Perhaps 1,500 of our customers just had the same bad luck?”“We’re still trying to determine what happened,” the CIO offered meekly.
“But we are sure that our PCI systems were working, right?” Brett pushed.
“Becoming PCI compliant is
complicated,” Sergei hedged, “especially when you’re constantly
improving your own technology.” He ran through a laundry list of the
complexities of recent improvements. At any given moment, Sergei had
three or four high-priority tech projects in various stages of
implementation. It was a constant juggling act.Brett, in a rare display of anger, pounded his fist on Sergei’s
desk. “Are you saying, Sergei, that we’re not actually PCI compliant?”Sergei stiffened. “We meet about 75% or so of the PCI requirements.
That’s better than average for retailers of our size.” The response was
defensive but honest.“How have we been able to get away with that?” Brett growled. He
knew that PCI compliance, which was mandated by all the major credit
card companies, required regular scans by an outside auditor to ensure
that a company’s systems were working—with stiff penalties for failure.“They don’t scan us every day,” Sergei demurred. “Compliance really is up to us, to me, in the end.”
Sergei reported finding a hole—a disabled firewall that was supposed to
be part of the wireless inventory-control system, which used real-time
data from each transaction to trigger replenishment from the
distribution center and automate reorders from suppliers.“How did the firewall get down in the first place?” Laurie snapped.
“Impossible to say,” said Sergei resolutely. “It could have been
deliberate or accidental. The system is relatively new, so we’ve had
things turned off and on at various times as we’ve worked out the bugs.
It was crashing a lot for a while. Firewalls can often be problematic.”
Sounds like a typical Monday morning staff meeting to me…I think you could be a fly in the wall in many mid-size (or large, for that matter) companies and hear this same set of quotes — regardless of how many millions of dollars the company may have spent on compliance initiatives. It is indeed sad to see how many of these folks don’t realize that "compliance" is merely the floor, not the ceiling. <sigh>
If you pay close attention to the dynamics of the management team within the story, you’ll bear witness to all seven distinct stages of the data breach grieving process:
Shock or Disbelief
Denial
Bargaining
Guilt
Anger
Depression
Acceptance and Hope
I’m not really aiming for a punchline here, but I will suggest that you read the entire story to appreciate the tale in the grandest of its context. The commentary from the industry experts is also very interesting…
/Hoff
P.S. I think it’s very cool the HBR allows you to access these stories without paying or registering and allows one to use up to 500 words on blogs and the like for the non-commercial purpose of summarizing the story. Nice policy.
I used to read the HBR too, and really enjoyed those case studies. Then I stopped, mainly because I was living it more and having fewer cycles available to read about it. These reactions above are spot-on. And I've been there to see a firewall's rules disabled for "troubleshooting" and not replaced — which is how your mainframe can suddenly start relaying spam …
Thank you for this link; I enjoyed reading the article very much and I made a post about it on my own blog as well.
Thanks, that reminded me to finish off my thread on CSOs with MBAs. (Darn it, another blog that doesn't understand https….)
One thing that struck me about that case study was the lack of technical input (which might explain why their answers were vague or empty). It’s one thing for a C-level to “feel good” about their security, but it’s another thing for people in lower levels to feel that way. A breach can’t be solely dealt with in the boardroom, it must include lower levels. For instance the answer to why the firewall was down was pretty weak. And I wouldn’t want my Brett to be making a decision like this based on watered down vagueness.
I really liked that case study. I felt like the reactions were very realistic and common.
What do you mean by…
"P.S. I think it's very cool the HBR allows you to access these stories without paying or registering and allows one to use up to 500 words on blogs and the like for the non-commercial purpose of summarizing the story. Nice policy."
The only way to access this story is by paying.
Well, when I wrote this post, I could read the entire article without being a subscriber…why that's changed I can't tell you.
Perhaps they revised their policy?
Things change. Their articles are worth subscribing to.
Sorry it no longer works.
/Hoff