We continue a series of articles about aspects of SOX audit by Richard Muniz. The first one tells about the challenges of an internal audit, network security and some common mistakes IT Pros make. The second one illustrates how a SOX audit results can show IT Pros what needs to be fixed. Here is the third article, explaining the problem of overlapping temporary accounts and risks, that could be provoked by this.
Boy, did we walk into that one. And the Bride of Dracula took us apart on it, and sadly we did it to ourselves. And boy did it offend the heck out of us when called on it. After all, we’d been doing things this way for years, and never, ever, even once, had a problem.
But I can’t blame her for taking the shot! We’d put ourselves into the position of a deer that takes the same trail to water every day. Given that, who could blame the wolf for waiting for an easy meal.
Here’s what we were doing. Before we ever became a public entity and SOX reared its ugly head, we’d hire all manner of temps. They’d be here for a week to 3 months and then be gone. In the interest of making things easier, we had a handful of temp accounts. We’d simply assign one to the new temp and call it good.
With hind sight being 20/20, I understand perfectly what she was saying. “It’s like this,” she explained patiently. “Temp1 logs in and does something. They leave, and a few days later, we hire another person, giving them the same user name. It confuses things.” Well, from just the administration point of view, she was absolutely right.
For example, HR brings some temps in, they send out a request to us to assign them user accounts etc. Well since there was such a big revolving door for temps, it became hell on earth to keep track of all the comings and goings. And indeed, there had been a couple of incidents. Sometimes the temp would leave, and we just never know. So here we have an active account with a password known to a third party who was no longer with us out in the wild. Or we’d find out someone has left, and we’d end up disabling a wrong account.
The best practice is simple. A username is a username, and it should be associated with only one person. If a temp is hired, even if it’s just for a week, assign them a username that is associated only with them. Example: if the user is John Smith, then his username would be something like jsmith or johns, but never temp1.
WE want to be able to go through logs and be able to see what that user did, and to do it with no questions or confusion.
In short, if it could be used by someone else, we don’t use it.
