Friday, February 15, 2008
To Record or Not To Record Password Resets?
Why Bother Recording Password Resets - Isn’t it more work than it is worth?
If you have ever worked on a service desk and or managed one (I have done both) you have probably wrestled with the question about what to do with password resets. Unless you have invested heavily in self service options this is one of the bread and butter elements and daily tasks that make the IT service desk a critical business function. The age old question surrounding this high volume service desk task is whether it is worth the effort to record these actions in your service management tool.
This year the question even got more confusing with the release of ITIL V3 which dictated that the “Password Reset” is not an Incident which is what I thought it was for the last nine years and now calls it a Service Request. The premise being that an Incident is a service impacting event.
Incident: (Service Operation) An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example, failure of one disk from a mirror set.
Service Request: (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example, to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.
I suppose the thinking here was that the service is still available whether the user of the service has forgotten their password or not. The call to the service desk in this view is a plea from the user to be let back into the service that is happily humming along without them. Oh well I am not going to argue semantics on this one and in this case an old dog is willing to learn some new tricks and terms.
This re-classifying of the Password Reset now prompts another question above and beyond “should we bother recording it.” Now we need to consider whether the action should be recorded in the incident tracking system or the Request Fulfillment tool.
However, whatever you want to call this task we still need to answer the first question. “To record or not record the Password Reset.”
The arguments for and against this activity typically comes from two different schools of thought.
View Point #1: Best practice theory and principles says that every support or request action taken should be recorded in the service management tool. How else will we learn from our past and capture critical business data for reporting and management decision making. Also, it is important to capture the work effort expended in support actions so that we can accurately assess head-count requirements.
This is the classic view point of the ITIL champions and it makes sense from the point of view of logic. However, there is a counter argument to this view that is also based on logic.
View Point #2: Why should we take the time and effort to record password resets. It takes more time to record the bloody ticket then it does to reset the password. If we were to record a ticket for every time a password was reset we would be spending more time entering data into the service management tool then doing the support work we are being paid to perform. In fact if we record every password then customer service is going to suffer since the phone’s and email will not be answered as quickly. As long as there has been computer systems with a login people have needed password resets. This is a fact of life and it will not change until all security systems are based on biometrics.
As for myself I am an advocate of view point #1. To provide some context for this opinion I will share with you a story from my consulting past.
The year was 1999 and I was managing a service desk for a major insurance organization. I had recently taken on this role as an interim manager on contract and was covering for a maternity leave.
In order to get to know the support issues I asked my new team for the service desk reports so I could get a feel for what types of issues we were dealing with on a daily basis. While comparing the phone stats for incoming calls with the actual incident records opened I found a huge discrepancy between the numbers. Digging a bit further the agents on the service desk were quite open about the fact that the majority of the calls taken on a daily basis were password resets. In fact over 60% of the calls fell into this category and not one of these calls were being captured in the support tool.
To make an already long article a tad bit shorter I convinced the agents after many discussions to begin tracking these calls in the tool. What we observed is that of the all the password resets they were doing over 50% were from a single mainframe based application.
Now curious and wanting to improve the performance of the service desk team I was managing, we did some digging aka “Root Cause Analysis.” It turns out that the security team had developed a policy so strict for this application that it was almost impossible to come up with any password that could be hacked and for that matter remembered by the users. To ensure that each user had a strong password they had removed the ability to use common words like the days of the week, common names or the months of the year and so on. On top of this they had built in the requirement to change the password every 30 days and of course you could not use the last 9 passwords you had previously.
Having this data I took the information to the security group and explained the service issue and request a change the the security policy for this application. To say they were unmoved by my argument would be an understatement. I was the service desk manager and a contractor on top of that and they were the security group, keeper of the keys.
So with a polite but firm statement that they were not about to change anything, I left the meeting.
For the next 2 months we carefully tracked the volumes of password reset against this application. With this data we developed models which demonstrated the business cost of hundreds of password resets a week on one application. Armed with this data with a business value attached I requested another meeting and presented our case again within the context of financial and productivity impact. The outcome was modest but still was an improvement. They changed the policy from 30 days to 60 for password changes.
Not much of a victory perhaps but this story does shed light on why I believe it is important to capture and record password resets in your service management tool. Yes every one!
The irony of my story is that during this process I found out that the agents were giving the users passwords that they knew would work. These ready made passwords were kept on sticky notes and posted on the walls of their cubicles. So much for security.
So in conclusion, yes it is important to capture data about password resets regardless of the effort.
Troy’s thoughts, what are yours?
What is not defined cannot be controlled!
What is not controlled cannot be measured!
What is not measured cannot be improved!