March 24, 2008, 1:03 PM — Suppose for a moment that your first name isn't Bob or Dave. Maybe it's something less common, like, say, Barack. Or instead of Jane or Sue, it's, oh, maybe, Hillary. And to be fair to the common man, let's include a more oft-used name, perhaps John.
Now suppose that Barack, Hillary, and John travel a lot. They'd need passports to do that. And though it's not printed in any passport, the way people are uniquely identified is through their Social Security number and street address, stored in the passport database. That's pretty sensitive information, the sort of stuff we'd want to stay private.
As we all know from our programming or systems analysis days, in a good transactional system, a log record is written to a journal file every time a data record is accessed, changed, deleted, or added. In mainframe-speak, we called it CICS journaling; Novell used to call it TTS, or transaction tracking system. Whatever it's called, I'm sure you agree that journaling is important, not just for reconstructing the data file should it become corrupted, but also to track exactly who's doing what.
The hundreds of records that an individual worker might access in a typical business application on any given day are likely pretty ordinary stuff (payroll applications notwithstanding). But imagine in a typical data file with general accessibility that there's a field, we'll call it VIP. Anytime a record with the VIP flag turned on is touched, a manager -- somewhere -- gets a report. Who gets the VIP flag? Probably movie stars and professional athletes. Politicians, too. Access one of these records and your boss will know.
There might be a legitimate reason for access, perhaps an address change to, say, 1600 Pennsylvania Ave. in Washington, D.C. So far, so good. But let's say that over a short period of time, the manager sees the records for our three intrepid travelers, Barack, Hillary, and John were each accessed multiple times. If I was that manager, I'd sure want to know why. There's a distinct possibility that no legitimate reason for accessing these records exists. Unfortunately, the report doesn't list a reason.
You can bet the manager would say, "If I catch you doing this again, you're outta here, and I'm reporting it to my boss to cover my own backside." That's what I'd do. And then it happens again. And again.
There's a problem here. But that problem is not what the average citizen thinks. Bob, Dave, Jane, and Sue might be quick to blame a "computer glitch," the term that makes IT professionals everywhere cringe when they hear it on the news. But the system worked perfectly. Access to certain records triggered a reporting mechanism. The proper notification was generated. The problem is actually one of user error, not leveraging the information provided to its fullest capabilities.