Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Incident team declares "service restores" but i di
Posted: Fri Mar 18, 2011 1:34 am Post subject: Incident team declares "service restores" but i di
So happy i found this forum, it will make a tangible difference in my expertise
Incident team declares "service restores" but i disagree... What do you think ?
Background: An application running on server X has stopped responding, the cause points towards the antivirus scan hogging resources, and yes in fact, when the "realtime" scan is disabled, incident team does not ever see the app become unresponsive again. Incident team closes ticket but leave the antivirus disabled....
Is it normal that incident team considers service is restored even though they leave the machine w/o antivirus protection (or some other important service) and turn it over to pb management ? Now i have security breathing down my neck and i cant reactivate the A/V because it will cause an outage again...
In my opinion, this should be managed by incident until they get back to a situation where, yes, the app runs but the server is also not missing an essential service le A/V protection.
I thought that i would not be stuck in those situations in pb management, i tought that i would have the time to do a good, thourough job.....
Joined: Mar 17, 2011 Posts: 3 Location: Toronto, Canada
Posted: Fri Mar 18, 2011 5:34 am Post subject:
technically they are correct - they have found a workaround and so the incident is resolved.
You can now engage as problem management to find a permanent solution to the issue i.e drag them back in as subject matter experts to help define & implement a solution for your issue (also include security in your meetings)
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Mar 18, 2011 7:58 pm Post subject:
No! No! No!
Where is the change management??????
How can anyone stop a security process without business led approval after considering the cost and risk consequences?
This is not a workaround unless approved and it sounds like security are not going to approve this easily. _________________ "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
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Fri Mar 18, 2011 9:42 pm Post subject:
Diarmid is correct
As the restoration of the service with the server required a change to the system - ie stopping the AV service, then there should have been an emergency change request processed before the work was done
There should have been at least an notification about this _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
How can anyone stop a security process without business led approval after considering the cost and risk consequences?
This is not a workaround unless approved and it sounds like security are not going to approve this easily.
Security were not involved in the resolution of this particular incident.... Perhaps the outcome would have been different as far as the temp workaround goes.
Thanks for all the reply, our Prob management process implementation is barely a year old and we will need to be mo authoritarian i think and more rigorous incident management is needed also.
Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
Posted: Fri Mar 18, 2011 10:44 pm Post subject:
UKVIKING wrote:
Diarmid is correct
As the restoration of the service with the server required a change to the system - ie stopping the AV service, then there should have been an emergency change request processed before the work was done
There should have been at least an notification about this
Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
Posted: Fri Mar 18, 2011 10:46 pm Post subject:
Diarmid wrote:
No! No! No!
Where is the change management??????
How can anyone stop a security process without business led approval after considering the cost and risk consequences?
This is not a workaround unless approved and it sounds like security are not going to approve this easily.
The first tenet of Security Management is availability - who says this wasn't behind a firewall, endpoint protection, etc..........and security don't approve changes.
As the restoration of the service with the server required a change to the system - ie stopping the AV service, then there should have been an emergency change request processed before the work was done
There should have been at least an notification about this
Who says there wasn't?
There was a change, and security was approver and approved as per our process BUT they approved it because by the time they were asked for approval the business line was weighing heavily to have their service back. Business lines are very big gorrillas in my neck of the woods.
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Sat Mar 19, 2011 3:10 am Post subject:
The following should be done
1 - raise a PM record concerning the fact that the systems are being slowed due to the AV software running constantly. This PM record is part reacrtive to te the incident and proactive as the AV is not running
The PM record / ticket should be given to the security and system architecture team to determine what is needed to have the system perform as it should (service impact) and the fact that there needs to be checks concerning AV - security. This would be able to then be looked at
2 - An new incident should be raised by security team about the fatc that the AV s/w was stopped. This and the above PM record should eb linkled to gether as wella s the original incident
This should highlight tho mgmt the seriousneess of the issue and its effect ont he business and the security model _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Many thanks for all the answers. This is all very usefull, i'll do much more reading on this forum before posting again, we (my corp) have a long way to go to a usable efficient PM process.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sat Mar 19, 2011 5:53 am Post subject:
Boris,
I applied the following logic:
1. a change had been made
2. security were unhappy
therefore 3. security had not been part of the change process or there is no requirement in the change process to take proper consideration of security issues
therefore 4. change management had either not been invoked or was inadequate
I would also suggest that every interested party is part of change approval including security for any change that impinges on security. In fact if security do not have input to change decisions then they are not able to function as security.
Your speculative reference to the firewall is a red herring unless you are saying that such situations do not require security, in which case someone is wasting money putting it there in the first place.
It is not my way to err on the side of assuming over-zealousness on the part of security or any other section in answering questions with less than the full story, as we (naturally) have here.
It is not in dispute that switching off the security could be the correct interim measure, but there are serious doubts whether the decision was arrived at in a sound manner. _________________ "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
Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
Posted: Mon Mar 21, 2011 8:33 pm Post subject:
Diarmid wrote:
Boris,
I applied the following logic:
1. a change had been made
2. security were unhappy
therefore 3. security had not been part of the change process or there is no requirement in the change process to take proper consideration of security issues
therefore 4. change management had either not been invoked or was inadequate
I would also suggest that every interested party is part of change approval including security for any change that impinges on security. In fact if security do not have input to change decisions then they are not able to function as security.
Your speculative reference to the firewall is a red herring unless you are saying that such situations do not require security, in which case someone is wasting money putting it there in the first place.
It is not my way to err on the side of assuming over-zealousness on the part of security or any other section in answering questions with less than the full story, as we (naturally) have here.
It is not in dispute that switching off the security could be the correct interim measure, but there are serious doubts whether the decision was arrived at in a sound manner.
You were the one that started the speculation in the first place
Strip it back to the originial question - was service restored..........the service was running slowly and then with the action taken it was running at normal speed again, so normal service was restored.
How it was done, why it was done and who approved it are all important but service was indeed restored
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Tue Mar 22, 2011 1:00 am Post subject:
Unfortunately, Boris, I also subscribe to John's comments. Thus raising an incident that security is compromised should lead to immediate restoration of security features - equally inappropriately - and, hey!, you have a lovely circle.
I did not speculate. If the security team were unhappy then, both, the change was not properly managed, and also there was a security concern to have been addressed. Had the change been properly managed then one of the outcomes would have been the initiation of problem management for the situation and thus no need to"have security breathing down my neck".
Had there been no "real" security issue, that would have been established in the risk assessment for the change and the security team would have been either "on-board" or put in their place at that stage.
It's all there in the question. Even down to the clue that it is the "incident team" that "considers service is restored".
The entire issue concerns change management and the problem manager is feeling the brunt of that failure. _________________ "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
Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
Posted: Tue Mar 22, 2011 1:18 am Post subject:
Diarmid wrote:
Unfortunately, Boris, I also subscribe to John's comments. Thus raising an incident that security is compromised should lead to immediate restoration of security features - equally inappropriately - and, hey!, you have a lovely circle.
I did not speculate. If the security team were unhappy then, both, the change was not properly managed, and also there was a security concern to have been addressed. Had the change been properly managed then one of the outcomes would have been the initiation of problem management for the situation and thus no need to"have security breathing down my neck".
Had there been no "real" security issue, that would have been established in the risk assessment for the change and the security team would have been either "on-board" or put in their place at that stage.
It's all there in the question. Even down to the clue that it is the "incident team" that "considers service is restored".
The entire issue concerns change management and the problem manager is feeling the brunt of that failure.
I subscribe to the real world where online service is King.
The incident that was raised was latency in the online service, that latency has been resolved with appropriate parties subscribing to the resolution (you can't please everyone) so it's resolved. A new incident to restore AV coverage will be required - appropriate resolutions would not include anything that adversely impacts online service.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
and more rigorous incident management is needed also.
