Vulnerability Scanning Going through Change Management

[MegaDuck]

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?

[scar3face]

Good question, I'm interested in the replies.

[dboylan]

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.

Don

[UKVIKING]

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

[Ed]

For me this is about Availability, not about Change - All that really needs to happen, is that the scans are run 'out of hours'.

The incident should be enough, if routed properly, to get the Availability guys aware of the issue.

Regards

Ed

[Skinnera]

I would put this under Change, as it is a non-BAU activity that affects the status of the server and potentially impacts its performance.

Doing so also allows the CAB to test whether the proper checks & processes have been put in place to mitigate any potential risk, which is the purpose of any Change system.

It is not an Incident, as that's something we didn't expect to happen?

As for virus scans etc, they are BAU activities for me, so no need for Changes to be raised.

[Ines]

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.

[Mark-OLoughlin]

Hi,

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