Is anyone maintaining Patches related information in CMDB?

[Suggy]

Around 6 years back one of the customer asked us to retrieve the patches related information using Discovery product.

That time had came across this article - https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0695180

Even today its the same situation. Its surprising that ServiceNow still has not considered this in OOTB Discovery and asking us to build customization if required. And this is a very much important information for any Infra team and unfortunatley this is not covered in ANY of the discovery products I have come across till now.

Question - Is anyone maintaining patches related information in CMDB? If yes, pelase do share some light on this.

I also see a table 'cmdb_ci_patches'. Just wanted to hear from those who have been successfully maintaing patching information.

Even CSDM talks about that but there is no OOB solution/guidance on this.

[Fabian Kunzke]

Hello,

We have one customer who tracks the patch deployment of windows machines through ServiceNow based on security guidelines. They check for certain patches to be installed on each machine and use the ServiceNow discovery to inventorize them (note: oob the patch are blacklisted for the inventorization).
Patches are usually stored in the software package table (a related list for all computers) meaning they are handled in the same way as any other software being distributed. This is also what i would recommend for this maintainance.

The picture you posted is not actually related to patch management at all. This is "just" an example for dynamic CI groups. By grouping all windows servers into groups, it makes a staggered approach to rolling out patches easier (e.g. in patch group A you would group all windows servers from the APAC region).

That said, most companies don't have a need to track patches outside of SecOps. There, the remediation task for a security issue could be the deployment of a patch. Tracking if that patch was installed can then be done with the installed software packages. BUT when it comes to OS level patching - at least for windows, i am not a UNIX expert - some patches are overruled by OS version. This means that even if all the patches are inventorized, a system may not have a patch, but also may not require it due to a higher OS version.

In short: To track patch installments, use the installed software package tabel (ootb). But be aware, that outside of SecOps there may not be a real use case and even then, OS version must be included when checking for patching. Rolling out a patch should be done via change management.

What not to do: You should not handle the patches as standalone applications.

Note: The "customization" for the discovery is very minor. In the discovery console you can just remove the blacklisting of security patches for the software inventorization. That should cover it from my experience.

Hope this helps,

Regards

Fabian

[Jill Jackson-Jo]

Hello, is one change request created in Service now for ALL CIs being patched?  How are you handing the change ?

[Fabian Kunzke]

Hey Jill,

This really depends on your organisation, but let me give you an example that may clear things up:

The horizontal grouping of CIs is done with CMDB groups & dynamic CI groups. In a simple structure all Windows Servers can be grouped under one CMDB group. You'd then add that CMDB group to your rollout-change. This in return will add all members of the group to the change as well.

This is very useful for the exact case you've hinted at.

Now, most companies will differentiate between production and non-production systems. Same principle, but this time 2 different cmdb groups and with that 2 different changes.

The more your company separates into different groupings of CIs, the more changes may be opened.

It is also plausible to add multiple CMDB groups to a change at once. I like to think of patch rollouts in a similar way as application rollouts. One could also have standard changes for patching processes.

BUT: when we talk about security patches, this may be entirely different. Security patches usually have urgency and priority and may not be rolled out as a batch but to singular systems. In that case - instead of linking a cmdb group - you may only link a singular CI which needs patching.

I hope this helps 🙂 Really, patch management is one of the processes within change management. I personally like to think of patches in similar fashion as with applications. And then it really depends on how your company handles these. Is everything rolled out at once? Do you have individual patch windows? Is there automation in place which could integrate into the change management?

Regards
Fabian

[karenkolek-fraz]

(1) Is using dynamic ci groups similar to using the bulk load feature as the CIs will be added to the change?  (2) When using dynamic ci groups on an RFC does it have any system performance issues / concerns?