Unauthorized Change Detection Strategies

MZC · ‎01-04-2022

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.

Daniel Borkowi1 · ‎01-06-2022

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:

It only works with Service Mapping.
New discovered (inserted) CIs are not detected as unauthorized Change, because naturally they are not attached to Application Services.
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.
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

View solution in original post

Community Alums · ‎07-09-2024

Hi Daniel,
Could you please provide more details about the customization that we need to further granulate filter for the CI Classes for unauthorized changes.

Daniel Borkowi1 · ‎12-18-2024

Hi @Community Alums this really depends on how you want to have the maintenance user friendly.

I did several approaches:

Simple System Property listing all the relevant CI Classes - BR checks if change is done on a class contained in property
System Property with JSON object containing classes and fields per class - BR checks if change is done on a class contained in property and change was done on a field assigned to this class
The user-friendliest alternativ: flag u_change_relevancy in sys_dictionary - BR checks if change is done field which is flagged as change relevant in dictionary
For Relationship changes you can use as criteria if one of the related CI class is change relevant, then relationship is also relevant. (more fine-granular create a flag on relationship type to distinct between relationship types which are relevant or not )

Then you can fire the event ci.change.unplanned like the OOTB unauthorize change capability uses https://www.servicenow.com/docs/csh?topicname=unauthorized-change-request.html&version=latest. In my opinion no additional customization is needed to handle such changes.

But this ideas are not a best practice recommendation, see it more as initial idea on which you can build your requirements.

Greets

Daniel

Please mark reply as Helpful/Correct, if applicable. Thanks!

MZC · ‎01-10-2022

Thank you so much for the two replies. The input provided by SMEs is very helpful. I will definitely share our strategy and experience with implementing once we have some tangible proof-of-concept functions in place to test out.

Ryan Lee2 · ‎04-17-2022

Were you able to make progress on this? One of my customers is looking to implement this as well and there's a lack of strong guidance on implementation.

MZC · ‎04-18-2022

Not Yet implemented it, still in progress. Awaiting a Proof of Concept solution to be devised. More of an MVP. We selected 1 mapped application service, to see if we could monitor changes to CIs related to that 1 Service. I agree, that this OOTB solution provided by ServiceNow still has a way to go. Its limitation on just reporting on CIs which are part of Mapped Application Services is one issue, which then tells me "What about Technical Services"? Those services which cannot be mapped with the traditional ServiceNow Service Mapping Tool? With that said, i started thinking about the use of "monitoring" tools, integrated via the Event Management Product of the platform. Along with Discovery, which is supposed to work with Mapped Application Services for Unauthorized Change Detection, is there an unauthorized change detection solution leveraging CI "monitoring" sources, those integrated via Event Mgmt?....havent' given up yet on the "unauthorized change detection" solution. I am happy to share more as we achieve milestones.