Posted: Thu Jan 17, 2008 5:35 am Post subject: Vulnerability Scanning Going through Change Management
There has been some recent discussion in my organizations on how to handle vulnerability scanning against production devices. While agents have been installed on all the target devices, my security group would like to run quarterly vulnerability scans.
The issue at hand is how to handle this request. Most people I have spoken to have agreed that "scanning" a server is not a change. It has been argued that it is an operational task. However, we have identifed the risk that scans can impact production servers by impacting performance. Because of this risk of impact, some people would like to classify the scanning event as a change.
The risk that we have of classifying the vulnerability scanning event, is that it would set precedence for similar type of events. For example, we could start getting into the business of managing Virus Scans, Altiris Discovery, Hardware/Software Discovery, and other planned operation that may affect service levels as a change. It has been argued that this is not a platform for change.
If that is the case, what is the best way to handle it? Or, how do you handle similar type of events which have known impact, requires approval and notification, but does not fall into an ITIL definition of a change?
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Thu Jan 17, 2008 10:37 am Post subject: Re: Vulnerability Scanning Going through Change Management
Whether or not this is a Change is dependent on how you have structured the data in the CMDB. The implemented Change record should be the driver to update a state or attribute of a CI in the CMDB. If you are tracking "Last Scan Date" in the CMDB, then yes, the Scan would update that field. In which case, it should be handled as a Change request.
Personally, I wouldn't track that level of detail in a CMDB since it adds little value to my managing the inter-relationships of the IT infrastructure.
What it sounds like you should be doing is opening an Incident. Remember that an Incident isn't just an outage. It is any event outside the normal operation of a Service that causes, or may cause, an interruption or degradation in quality of that Service.
The scan sounds like an event that is outside the normal operation of a scanned device that might cause a degradation in the quality of the Service reliant on that device.
Joined: Sep 16, 2006 Posts: 3371 Location: London, UK
Posted: Thu Jan 17, 2008 7:40 pm Post subject:
To carry on from what Don said.
There should be at least an Incident ticket for this because this is happening.
If the scan is going to cause ANY noticeable impact on the service that is provided during the operational hours of a service, then a change request shoudl be raised merely to get the services imapct a chance to be aware
sort of like maintenance change requests _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Fri Jan 18, 2008 12:21 pm Post subject: "Informational change"
My org treats these as Informational Changes - There will have been a previous official RFC raised and approved to install the scanning software on the devices, with advise of its approximate running frequency.
Therefore, just a change record in the system, raised by the Change Manager, to warn of this event, given the potential for degradation of service, particularly during BH. A placemarker for visibility purposes, essentially.
At the very least you need an incident to trigger off awareness of what you are doing and when, The Service Desk need to be informed of this.
I prefer to see thiese as change requests due to the potential impact that could be caused and I have seen impact. E.g. a scan takes up all the available bandwidth and basically killed the network - that was major impact. to prevent this from happening again the scans were under change control as change control covers risk and impact assessments and incidents do not.
Also scan may have to happen duing the day which adds to the risk. Remember it is about control and making sure that you do not disrupt any services. The change process can ensure this better that incident process. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
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