Unauthorized Change Detection Strategies

[MZC]

Implementing Unauthorized Change Detection activity with ServiceNow.  Does ServiceNow track, document and/or publish any customer experience or strategy white papers, from customer real-world implementation of this activity?  What are key elements in being able to implement this activity from a technical perspective using Rome version of ServiceNow and with ServiceNow Discovery, Service Mapping functionality in place, along with an active Change Module?  What are the key elements which need to be aligned for an initial implementation of the function.

[Ed Laar1]

Hi,

ServiceNow has the OOB capability to detect changes on IT-infra components that are not 'covered' with an authorized change request. This one is available when Service Mapping is also used. As soon as a change is detected in the CMDB and an authorized change can not be found an Unauthorized Change is created and assigned to a specific group.

See this doc pages for further info:

https://docs.servicenow.com/bundle/rome-it-service-management/page/product/change-management/concept/unauthorized-change-request.html

My experience is that this functionality works fine but unfortunately the CI's involved in this procedure are only selectable on class level so a check like 'Are changes on Windows servers running Wxyz' is not possible. I already created an idea for this.

Hope this helps,

Ed

[Daniel Borkowi1 · Accepted solution]

Hi,

the OOTB implementation is a good start, but have lot of gaps. It checks only CI which are assigned to a Application Service.

Gaps:

1. It only works with Service Mapping.
2. New discovered (inserted) CIs are not detected as unauthorized Change, because naturally they are not attached to Application Services.
3. As Ed mentioned, it's only on class level. You can not decide which fields should be observed or not, e.g. change of free space of disks is not relevant. It seems there is a learning algorithm in the backend to remove such noises, but I guess this will take long time, to have this stable and only real unauthorized changes will be detected.
4. Also removed change relevant relationships will not be detected as unauthorized Change.  

What we did in the past is, that we built such logic on our own. So we created some Configuration class where you configure which classes and fields and which relationships are change relevant. In a Business Rule which runs on every update of CI by discovery, we checked if a matching class and field is changed the Change Requests will be checked. If there is no authorized Change, we flagged these CIs or created a unauthorized change (dependend on Customer requirements). Also we ensured, that if everything is done on the right way, a CI of a change relevant class will never be created by discovery, because the CI sleeve was created by Change Request Workflow before discovery can detect it. So every new CIs in a change relevant Class without such a Change Request will be detected as unauthorized Change.

I hope these gaps will be closed in future, so that OOTB Unauthorized Change Detection needs no additional custom implementation.

Greets,

Daniel

[astha10]

Hi Daniel,

Could you please provide more information on how you built the logic to detect changes to the CIs?

[Daniel Borkowi1]

Hi @astha10,

we build the logic like this:

1. Table with fields: Table name, field list to describe which fields are change relevant. Similar you can use this table with field child class, parent class, relationship type to define which relationships are change relevant.

2. Business Rule on insert or update CMDB_CI with condition checking if a table or a field is changed which are defined in 1. If yes check if there is a Change Request in state Implement --> if not raise ci.change.unplanned event. 

3. Similar on cmdb_rel_ci for change relevant Relationships.

Hope that helps.

Greets Daniel