Monday, March 24, 2008

Employee access to production data still an issue (recent State Department passport file flap)

The recent flap about “curious” contractors at the State Department who peeked at the passport files of the three major presidential candidates reminds us of some serious workplace issues. Huffington’s account of this on March 21 2008 is here. Keep in mind, these were supposedly "good" or "exemplary" employees or contractors who would never actually abuse information. They were just "curious."

Most customer service employees have read and update access to a large list of individuals. In information technology, technical employees usually had read access and update access when specifically requested through formal channels. Some programmers resent the time and trouble to request access and say that they should have it, and that all is necessary is for programmers to be bonded. On the other hand, it is much safer to restrict access. Sometimes database protocols (like the IDMS central version when it is given as a DD in JCL) make it difficult to install security in batch programs. I think there was an issue like this with Information Expert (the other “IE”) in mainframe MSA systems from Dun and Bradstreet in the 1990s.

But this even goes further. At the IRS, customer service employees have been fired for snooping on accounts that were not in their assigned “range” – before the IRS had the ability to restrict mainframe access further by employee. Furthermore, much large scale quality assurance testing in shops is done by making copies of data from production regions, making data available to employees. Associates (and contractors) often work from home, often on computers that they own, allowing the possibility of data intermingling, however unintentional, or may take laptops home, allowing the possibility of theft, which has happened several times in government agencies and major corporations (the most recent being NIH).

When I took a corporate transfer to Minneapolis in 1997, one motive was to have less contact with military personnel related data, since I had just finished an published a book that dealt with, in large part, the "don't ask don't tell" policy regarding gays in the military. I thought it was more appropriate to have as little contact with that group of customers "professionally" as possible, to avoid the "appearance" of "conflict of interest" or the "appearance" of "temptation" for abuse.

There is a lot of “best practices” security management to do in these areas.

No comments: