The Art of Securing a ServiceNow Instance

A ServiceNow instance is a dedicated, isolated environment that includes its own applications, databases, and configurations. In turn, customers receive their own unique instances, fully customizable and designed to support a wide range of use cases, from production environments to development, testing, and demos. Instances come in several flavors, such as a production instance where actual work gets done and sub-production instances for dedicated purposes like development, testing, or demos.

What makes instances interesting is that ServiceNow customers get their own unique instances, which include access to the entire platform and are extremely customizable.

As Aaron Munoz, Technical Architect, CoreX, puts it, “An instance works to centralize where people do their work.”

He adds that an instance holds information critical for business processes and serves as the central dispatcher for both human and virtual agents performing processes and workflows.

Given that a ServiceNow instance holds confidential, sensitive, and personal information, it’s important to ensure only people who need that information are able to access it, explains Munoz. Without proper controls, there’s a data leak risk with implications from privacy and intellectual property concerns to potential regulatory or compliance liability.

When thinking about securing a ServiceNow instance, the two main concerns are: Who is able to access information? And how do you ensure those people are who they say they are?

How to Get Started

The first step in securing a ServiceNow instance is to ensure all users authenticate via single sign-on (SSO) using enterprise credentials managed through Active Directory. From there, apply role-based access control (RBAC) using access control lists (ACLs). ServiceNow also supports multifactor authentication (MFA), which adds an extra layer of protection. 

(In fact, as of the Yokohama release, MFA is enabled and required by default.)

Out of the box, ServiceNow comes with the most common rules around securing instances ready to go. An important role is assigning a security admin as a very privileged role, able to make changes and customize access controls. Within the ACL, there are roles with “allow” permissions and also “deny” roles, which take precedence over “allow” rules.

Rules can also be customized. For example, if a pre-existing table is extended, it’s possible to leverage all the rules inherited from the parent table. This way, if the rules for the parent table are very well controlled, there’s no need to reinvent everything for the extended table.

Dealing With Threats

While user authentication is the first layer of defense, threat detection and response are equally critical. The Security Center application provides administrators with real-time visibility into login patterns, suspicious activity, and potential breaches.

”We have indicators or metrics for who is logging in. And because these tend to be daily trends, we can see if we have abnormal amounts of logins or abnormal amounts of failed logins,” states Munoz. “We see that we are the target of some sort of an attempt to penetrate the instance with massive attempts to use leaked passwords. We have ways to see who can log in as an admin. And if anything seems suspicious, then we can take action.”

He adds, “We can also see massive exports of information. If it's something that wasn't expected or it's suspicious, then we can set targets and thresholds for anything that we want to be alerted to as admins of the instance.”

Security and Third-Party Systems

Since ServiceNow isn’t an isolated system and is built to connect across the tech stack, Munoz describes a common scenario where there is middleware that is aware of what is happening in connections between ServiceNow and other enterprise systems, providing clues into possible threat activity. 

And even though ServiceNow is in the cloud rather than on-premises, it is an enterprise asset and is monitored by connecting with event management enterprise systems. It’s tracked as a configuration item, and connections between the ServiceNow instance and other enterprise systems are monitored, explains Munoz.

When Security Gets Real

Securing instances in the real world involves taking stock of tradeoffs in balancing security with user experience. Munoz explains that hardening an instance too much can mean a cumbersome user experience on the platform. One example is automatically logging users out every 30 minutes and having them reauthenticate as a valid user. That will effectively ensure that if someone leaves their laptop unattended for a length of time, it reduces the possibility of someone gaining unauthorized access to the instance.

The real-world impact is in field service management implementations, where the 30-minute window requires reauthentication of posed issues. For one, it probably takes field service agents more than 30 minutes to just drive to a location. Meaning those people had to keep using SMS codes over and over again. The tradeoff is making the reauthorization window more lenient for the agent mobile application.

Another tradeoff is the detection of export activities. It’s important to be able to detect exports of large amounts of data. As Munoz explains, that’s a notification you don’t want to get retroactively. The tradeoff is not necessarily blocking large exports, but providing admins with alerts to ensure the export is justified.

Munoz sees monitoring activities like this as an area where AI will come into play by being aware of events, reporting, and possibly even stopping security threats as they happen.

Think Security First

One ServiceNow security tool that Munoz says isn’t being used to its full potential is adaptive authentication. This policy framework goes beyond a “yes or no” scenario in which someone can log in and have access to all their roles all the time.

“We can make it so that if they're logging in from outside of trusted IP addresses or from devices that are known, so maybe they pass the initial authentication to log into the instance,” says Munoz. “But they get a more limited subset of roles. That is something that we support. Or it could be based on the location. It could be based on the time of day. There are a lot of rules that ServiceNow is now supporting.”

He adds that adaptive authentication is a “game changer” for securing a ServiceNow instance.

Build Security In, Don’t Bolt It On

Beyond different security tactics and configurations, the key takeaway for securing a ServiceNow instance is to consider security from the very beginning of a ServiceNow implementation.

“It's much harder to retrofit the security after you have built a solution than to front-load the concerns,” states Munoz. “And even if you don't have a stakeholder that is pushing you to make sure that your customizations or your development is secure, it is up to you as a developer to ensure that anything that you're building is not going to expose users to accidental or intentional security issues.”

Instances are integral to the ServiceNow experience, and security is always a top-of-mind concern, balancing a series of tradeoffs between threat protection and user experience. With powerful built-in tools and extensive customization capabilities, ServiceNow empowers businesses to align security with the way they work.