TLDR watch the video

ServiceNow update set is a collection of customizations that migrate or transfer from a source ServiceNow Instance to a target ServiceNow instance. The privileges required for this migration can be a source of privilege sprawl within your ServiceNow ecosystem. In this article, we will walk through the causes, challenges, and remediations to privilege Sprawl within the context of ServiceNow deployments.

ServiceNow Update Sets

An Update Set in ServiceNow is a collection or grouping of one or more customizations. Before coding customizations, ServiceNow developers will create an Update Set in ServiceNow and then make the new Update Set the Active Update Set for the ServiceNow Instance they are working in. All customizations that are coded and built by a developer will be captured within the Active Update Set.

When development is complete, a ServiceNow developer can now move or transfer all their work from the Instance they’ve been working in (the source) to another ServiceNow Instance (the target). Using this native ServiceNow mechanism, customizations are transported from developers to a test/QA Instance to be tested and then from QA to your production Instance for your customers or employees to use.

Privilege Sprawl

What is privilege sprawl? Privilege sprawl is when privileges, or access rights to a system (such as ServiceNow), have been granted to too many people. Elevated privileges are especially concerning in this regard. Privilege sprawl grows an organization’s attack surface and expands the exploitation points for cyber attacks.

According to the 2022 Data Breach Investigations Report, 61% of all breaches involve credentials, whether they be stolen via social engineering or hacked using brute force. Privilege sprawl is something companies are more aware of and vigilant about with the growing number of remote workers and a growing dependence on external contractors. Within the context of IT security, there is an industry best practice known as the principle of least privilege (PoLP).

The PoLP functions by granting the least level of privileges to a user required to perform a job or task on a secured system. The PoLP reduces risk by containing compromises both vertically and horizontally. For example, imagine a data entry employee whose access follows the PoLP. If malware infects the employee’s computer, a successful cyber attack is limited to adding database entries. On the other hand, if this employee had elevated privileges or root access, a cyber attack can spread system-wide and do considerably more destructive actions.

Deploying ServiceNow Update Sets

How are we unintentionally contributing to privilege sprawl in our ServiceNow ecosystem? ServiceNow developers need Administrator access to create Update Sets in the Instance where they code and build ServiceNow customizations. This requirement isn’t a big deal, as ServiceNow developers code within either a PDI or a shared development Instance.

The challenge arises when ServiceNow developers need to migrate their Update Sets to another ServiceNow Instance. Developers need Administrator access in the target Instance to deploy their Update Sets. They also need this privilege level to resolve conflicts between their Update Set and other Update Sets previously deployed to the target Instance.

It may seem reasonable to grant and revoke Administrator access only when Update Sets are being deployed. However, Update Sets are continuously being developed and thus continually being deployed in sub-prod Instances. Most companies attempt to have their ServiceNow production Instance locked down, and they publish customizations to this Instance far less frequently; however, the same privilege level is required. With a constant flow of customizations being produced, pragmatic necessity will often leave Administrator access granted.

The Status Quo

What we have covered thus far may be new to you, or perhaps it isn’t. But either way, what we have discussed is a known practice within the ServiceNow community. Notice I didn’t say it is an accepted practice. When I have spoken to ServiceNow professionals, they all recognize the potential risk, but they assume there isn’t another way and “accept” the established ServiceNow process and mechanics as the status quo.

Challenging the status quo at any company can be challenging. But doing so can help your company meet its goals and improve its processes. Challenging the status quo can also enhance your value as an employee. How do you change the status quo concerning ServiceNow deployments? Is there an alternative?

xtype Changes Everything

Rather than using Administrator access to deploy your ServiceNow customization throughout your ServiceNow ecosystem continually, let xtype manage this migration. xtype eliminates the need for granting elevated privileges to all the target Instances in your ServiceNow ecosystem. How does xtype do this?

By installing xtype in your ecosystem, ServiceNow developers only need Administrator access to their development Instance. ServiceNow administrators can lock down the rest of the ecosystem and grant specific access levels to xtype.

What is xtype? xtype is a platform engineering solution native to ServiceNow. As such, xtype utilizes native ServiceNow migration mechanics to move Update Sets from their source Instances to their intended target Instances. Being native to ServiceNow, xtype continually tracks all the Update Sets being built across your ecosystem, provides your ServiceNow professional with a real-time view of all of these Update Sets, and allows you to deploy them with a single click or automatically.

Rather than using Administrator access to deploy your ServiceNow customization throughout your ServiceNow ecosystem continually, let xtype manage this migration. xtype eliminates the need for granting elevated privileges to all the target Instances in your ServiceNow ecosystem. How does xtype do this?

By installing xtype in your ecosystem, ServiceNow developers only need Administrator access to their development Instance. ServiceNow administrators can lock down the rest of the ecosystem and grant specific access levels to xtype.

Applying the PoLP is just one benefit of installing and using xtype within your ServiceNow ecosystem. xtype can do way more for you and your organization. To learn more, please click and read through our site.
You can also find more information:
LINKEDIN | |