Home > Information Security > Data breach disclosure: Business vs. Security?

Data breach disclosure: Business vs. Security?

June 18th, 2009

And what about ethics?

This is not quite a book review, not enough time for all that, but I did just finish reading an excellent book, really the first of its kind that I’ve encountered. The book “Adventures of an IT Leader” by Harvard Business Press is written as a story, not some horribly dry academic treatise on the subject of managing IT. The plot, in a nutshell, is about a business leader in a turnaround company (new CEO) who is asked to take over IT and shape it up. He knows nothing about IT management, is not technical, and is under a lot of pressure from day one. The book then goes through a series of events and circumstances in this guy’s first year on the job.

I loved it. In fact, for any technical person in IT or infosec who wants to get a good grasp of business decisions and the process you’ll go through in making them, this is a fantastic read. A little contrived, and if you’ve been around a while, you’ll recognize some things and already know others, but a fun book nonetheless.

Why am I talking about it, though, and what’s the relation to the title of this post? Well, about midway through the new CIO’s tenure, the company has a security issue. This is a major topic in the book, although they stereotyped us “security types” a bit (purple hair? Skull T-shirt? C’mon, that’s only for Defcon for most of us). I won’t give away too much plot, overall, but here are the relevant facts:

  • Company has sensitive financial data on people (they process loans)
  • A fair-sized risk exists due to coupling of an acquisition’s network, security and IT have known about this for a while. Nothing was done (budget priorities.
  • Company’s site experiences a DoS attack, coupled with some odd behavior that makes them THINK customer data may have been accessed. They can’t find definitive evidence (logs, etc) however.
  • Legal wants them to be proactive and notify customers to be alert for strange account activity.

This brings us to the executive meeting where everyone has to decide what to do. To make this short:

  • New CIO recommends a pretty drastic plan to wipe systems and start clean to make sure no more compromises exist. 2-3 days of downtime, planned for a weekend, still a big impact. We all know this isn’t that practical in real life, either, but it’s not wholly unrealistic.
  • CEO says “Hell NO” to notifying customers AND shutting down systems. In other words, no GNUs is good GNUs.
  • Head Legal Counsel and new VP of Loan Operations (new CIO’s replacement) challenge the CEO, saying they should notify customers to be proactive and wipe the systems.
  • CEO promptly fires them both. Meeting adjourned.

Wow. This was a very interesting case study, and one that did not seem TOO unrealistic to me, frankly. There are some later follow-ups in the book, where the CEO explains that business can be a gamble sometimes. Risks have to be taken, regardless of a “higher moral ground” kind of stance. Also, keep in mind that there was no DEFINITIVE proof of data leakage, just suspicions. Other hacking activity (like the DoS) was present, but a data breach was not certain.

What do you think? Aside from legal requirements to notify, if a company feels that it can protect its reputation and save jobs, stock price, etc…is there an occasion when the “silent fix” is the right approach? In other words, clean up the backyard but don’t say a word about it? What if they did the risk analysis and determined there was a 80-90% chance they could pull it off? Mind you, I’m not necessarily espousing this approach, only debating.

Categories: Information Security Tags:
  1. June 18th, 2009 at 06:48 | #1

    I remember someone telling me (guess it was a friend) morals do not matter in business but breaking the law is a different matter. It becomes more difficult when things like jobs are involved; razors edge 🙂

  2. Greg
    June 18th, 2009 at 15:06 | #2

    Sounds like my last job!

Comments are closed.