How to capture unauthorized changes with ServiceNow discovery?

[Josh P1]

Hey all,

In a some articles and demos I have seen, it appears that there is a way to have Discovery capture and report/display unauthorized changes: a change to a CI (such as an attribute value change or the addition of a new CI) has occurred but there is no related / corresponding change ticket.

Example: server A had previously been discovered with 8gb of memory, and this value is the accepted/authorized amount.  The most recent discovery finds server A with 16gb memory; however there is no change ticket in the system that is related to server A that authorizes this addition of memory.

Unfortunately, I am having trouble figuring out the methodology that was used to do this.  Is this type of functionality/behavior achievable out of the box with the discovery plug-in?  Does this come with another plugin/module?  Or is it a custom functionality I need to implement?  (Un/Authorized changes seems like a "basic tenant" of ITIL, part of me wonder if I am not looking for right the terms in the docs?)

Thanks,

Josh

[Chris M3]

Hmm, I remember seeing this also, but can't find that part of it specifically.  I do know that the Bulk CI Update plugin is part of the process as a whole.  I poked around a bit, but didn't find the specific feature you're looking for.

https://docs.servicenow.com/bundle/madrid-it-service-management/page/product/change-management/concept/bulk-ci-change.html

[ramini_one]

This is where the Change Management DataBase (CMDB) Compliance comes in. It may/should comprise few other tools integrated to the process to pick the changes in real time or in scheduled environments.

The report can be generated from the changes happening on any asset or CI history. When enforced to look for the changes related with any class on any specific CI and is tied with a Change or not.

Out of box plug-ins can do this, but eventually would use the same data. So if we focus on what exactly is need can be done through scheduled reporting.

[DaveHertel]

Hi - this isn't covered/captured by "out of the box" Discovery, but could be implemented via Change Mgmt, rules running on history of CI's (on platform), etc as others have replied and mentioned.  But the functionality you described isn't a core part of Discovery (nor should it be).   Disco is about collecting & inventorying whats out there on the net.  Change processes (authorized or not) should be part of the change mgmt processes on the platform.

Hope that helps..?

[Josh P1]

Thank you all for your responses - Using your guidance and suggestions it appears [to me] there are two general options:

1. Create a report/audit that is scheduled after discovery to look for CI changes in the sys_audit table that match [our] criteria, such as specific cmdb tables, fields, [MID Server] user, etc. and check to see if the updated CI is specified in a change task of appropriate criteria (status, time/date stamp, etc.).  The report would show the CIs that do not have a corresponding/correlating change task.

or

2. Create a business rule for New/Update CI records that have similar comparison criteria as option 1, and create an appropriate application task for the remediation.

I have a couple of questions:

Am I missing other options?

Overall is one considered best practice to the other?  Are there any significant downfalls that for either option (I would think that the business rule could potentially be highly taxing on the system...)?

Specifically concerning option 1 - I am a little fuzzy on if the sys_audit table will capture new CIs records if it only captures updated values for existing records?

Thanks again,

Josh