ITIL V3 advises to classify/log incidents sperately from service requests. There is a debate in my organization as to what a "password reset" is. Yes, our Service Desk still has to do some of these manually. My view is that is is neither. It is a "solution" to an incident.
Anyone have any other thoughts?
Incident or Service Request
When people anguish over this kind of question, I rather think they have put themselves in an ITIL straitjacket. Password reset is a process with important connotations.
It could be requested because;
- forgotten
- expired
- changed (not always distinguishable from forgotten)
and if changed then this could be by legitimate process or by a breach of the system. In any event the user only requests a password reset because they know (or at least believe) that is the solution to their problem logging in.
The organization has to have a view on how to deal with it both in the sense of authentication and of monitoring and review. Why call it an incident or a service request? Why not manage it under something called Password Management (or Security Management!) and build into the process the capability of raising an incident if the situation warrants it?
One of the problems with calling it a service request is that other service requests are likely to be about "real" services and the approach to monitoring them does not lend itself to dealing with the potential security implications or even to the kind of incident analysis that looks into, for example, its too frequent occurrence leading to problem analysis if necessary.
One of the problems with branding it an incident is how you isolate it from "real" incidents, and if you do not isolate it, you need to be mature about how you measure its impact.
Just in passing, there is always a direct interruption to service if someone is unable to login until their password is reset. So, if you want to go by definitions, it has to be an incident. But that is being truly pedantic, beyond even my comfort zone.
Design the procedure to do what needs done and put it under some generic umbrella if your generic process is comfortable with it.
I'm sure some organizations will consider every such request as a security incident, but whether they manage it under the mantle of incident management or security management probably varies.
In the end Incident Management and Service Request are conceptual categories.
It could be requested because;
- forgotten
- expired
- changed (not always distinguishable from forgotten)
and if changed then this could be by legitimate process or by a breach of the system. In any event the user only requests a password reset because they know (or at least believe) that is the solution to their problem logging in.
The organization has to have a view on how to deal with it both in the sense of authentication and of monitoring and review. Why call it an incident or a service request? Why not manage it under something called Password Management (or Security Management!) and build into the process the capability of raising an incident if the situation warrants it?
One of the problems with calling it a service request is that other service requests are likely to be about "real" services and the approach to monitoring them does not lend itself to dealing with the potential security implications or even to the kind of incident analysis that looks into, for example, its too frequent occurrence leading to problem analysis if necessary.
One of the problems with branding it an incident is how you isolate it from "real" incidents, and if you do not isolate it, you need to be mature about how you measure its impact.
Just in passing, there is always a direct interruption to service if someone is unable to login until their password is reset. So, if you want to go by definitions, it has to be an incident. But that is being truly pedantic, beyond even my comfort zone.
Design the procedure to do what needs done and put it under some generic umbrella if your generic process is comfortable with it.
I'm sure some organizations will consider every such request as a security incident, but whether they manage it under the mantle of incident management or security management probably varies.
In the end Incident Management and Service Request are conceptual categories.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
In the real world a password reset has security implications that need to be addressed, whether it is dealt with by the service desk, or account managers or through some clever software, as many are.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
In real world yes - Password resets are done by Service Desk and is done under an incident . ITIL V3 though will tell you that any pwd resets are SR's. I have seen some companies do this ... Log an incident for the pwd reset but categorize the incident area as SR- pwd reset ....
This depends on how the client wants to accept is as. But ITIL wise pwd resets should be SR's.
This depends on how the client wants to accept is as. But ITIL wise pwd resets should be SR's.
-
MadhavaVermaDantuluri
- Itiler
- Posts: 14
- Joined: Tue Jan 28, 2014 7:00 pm
- Location: Delhi, India
- Contact:
In our organization, we treat password reset as an incident by tagging it as "General function". So this way we won't need to confuse these type of incidents under the major real cases. Moreover on a average in a day, we receive around 20 such cases.