We had a minor incident the other day where a user had phoned up to request a password reset. Nothing odd there but the helldesk operator just thought that the voice on the end of the phone was wrong.
She phoned back and sure enough the 'person' that had requested the reset was off sick. To cut a long story short X needed to get to a file in Z's my docs. Z was off. X phoned up Z and agreed that X would impersonate Z to get to the file and provided the answers to the required questions to change the password. X phoned from Z's phone so helpdesk would see the right ext.
This gave us a few questions.
1)Why did X need to reset the password? Why didn't Z just give X the password?
2)How can we better validate users requesting changes that affect the security of the system.
3)How can we protect aganst users impersonating other users when they are willingly giving up the details?
The only solution we can come up with at the moment is to have 2 factor ID. Where 1 of the factors is a physical token that must be carried by the user (i.e. clocking in card) to stop the token being left in a drawer for other to use.
This would work but isn't feasable in the short term.
Asking users to physically present themselves isn't possible due to the geographical distribution of workers.
Asking users to channel all such requests through line managers could cause unacceptable delays.
We're trying to figure a way of guaging how big an issue this is and if it's an isolated incident or normal working practice.
The users involved in the actual incident have been roasted royally (but not formally) by managers.
