LocalCommentary.com
David Rodeback's Blog

Friday, February 10, 2006

IHC's Leak and the Larger Security Question

IHC's recent leak of confidential (and presumably secure) medical records is only the tip of the informational security iceberg.

When news of LDS Church President Gordon B. Hinckley's cancer surgery broke recently, I prayed for his welfare and allowed myself a smile at the wonder of any kind of surgery on a 95 year old being called "routine." I didn't realize then some of the circumstances behind the news. KUTV in Salt Lake City ran a story about the firing of two IHC employees who were involved (one indirectly) in the leaking of President Hinckley's medical records to media. Apparently, one IHC employee gave her IHC network password to another several months ago, for some relatively harmless purpose. This somehow led to the rather embarrassing leak of the most prominent Utahan's medical records by the state's largest health-care provider. Someone I know who watches these things more closely than I predicts heads will soon roll from much higher up the IHC corporate ladder.

This high-profile embarrassment highlights a widespread problem. For the most part, in American government and business, we have not yet figured out how to balance the need for informational security with the need for people actually to get work done. Hence the minor Dilbert character, Mordac, "the preventer of information services," is aptly titled. I met him last year at . . . never mind, but you'd recognize the company.

Here are two examples from my own less-than-thrilling biography:

Over the past year and a half, I spent more than 1000 hours doing contract work as a programmer for a very large, high-profile financial services corporation. Most of those hours I spent sitting in a cubicle at a workstation, attached to the building's extensive LAN (local area network) and the company's WAN (wide area network). It was supposed to be a one-  or two-month project, but, as often happens, it turned out to be bigger than anyone suspected.

A number of security measures were in place, and most were responsibly heeded. But there were holes. For the first couple of weeks I had to borrow a colleague's login and password, because that's how long it took to get a network ID so I could log on as myself. That's a gaping security hole and a bad practice -- but otherwise I could not have done my work. For the first four or five months, I used a colleague's separate login for access to the Internet while there, because I needed it, and because the prevailing wisdom was that I'd be long gone before my own access was processed. Another big hole. I won't even tell you about the biggest hole of all.

But here's the point: Even in a security-conscious corporation like that, they haven't figured out how to get people the access they need, when they need it, so people can do their work without breaching fundamental security principles.

Before that, for a while, I and others did contract work for another very large corporation, of which fewer people have heard, but which is somehow connected to a large fraction of the US population. Every week or two our e-mail would include a very serious set of recommendations about network and data security from the IT folks. For entertainment, we would read these aloud to each other. Virtually every week there was something which would have brought all our work to an immediate halt, had we obeyed it.

Now I'm in a position professionally where I am partially responsible for keeping others' sensitive data secure. Obviously, if security is too lax, bad things are likely to happen. But here's what somehow gets lost in the discussion: If security is too tight or inefficient, the same bad things will happen. Workers have to circumvent security to get their work done, and, perhaps worse, this encourages a cynical attitude about security measures in general.

Finding the secure middle ground in these matters is not easy. Nor is it common, in my experience. It seems most likely to happen when the IT folks and the management actually understand each other and each other's systems and processes, and communicate conscientiously and competently about them. You don't see that every day.

I'm not saying this sort of problem occurs at IHC. I am saying that an employee giving a colleague her login and password is just the tip of the security iceberg in industry and government generally.

Copyright 2006 by David Rodeback.
All rights reserved.
Permission is given to publish this article elsewhere on the Web or via e-mail only under these conditions: The article is published intact and unchanged, and is properly credited to the author; and a visible link is included to the article's page at LocalCommentary.com.