5

Securing Your ServiceNow Instances

As you implement ServiceNow for your organization, you’ll focus on delivering exceptional value, but all that value can be erased in the blink of an eye if appropriate steps are not taken to secure your instance. A single cybersecurity incident can erode confidence, expose your company to massive liability, and have a profoundly negative impact on all those involved. Fortunately, ServiceNow provides effective tools for its customers to improve its own security position, and this chapter will help you understand which tools are available to you and how to make use of them as well as instill a culture of secure practices in your project team.

In this chapter, we’re going to walk through the following topics in order to give you a better understanding of what should be done to protect your investment in ServiceNow from malicious outside actors:

• The case for investment in security
• Planning for instance hardening
• Improving instance security posture
• Encryption
• Integration security

The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it. (Gene Spafford)

The case for investment in security

The ServiceNow platform spans many critical use cases in the typical enterprise, from human resources (HR) to information technology (IT), from legal to customer service. The value that stems from having ServiceNow support for these processes is often rooted in the availability of relevant data and orchestration abilities, which means that any breach of the data in ServiceNow can result in the loss of information and the potential for a malicious actor to exercise control over systems or infrastructure in your network.

Unfortunately, the investment in the security of your ServiceNow instance should go almost unnoticed if all goes well. A strong security posture deters attackers who prefer to aim at easier targets, and years of uneventful operation can make it appear as if the need to focus efforts on security is limited. Nonetheless, the potential impact of even a single mistake is so large that you should be continuously monitoring and improving your ServiceNow security, particularly where your ServiceNow instance contains tempting targets for attackers. As a project leader or sponsor, you have the chance—and even obligation—to make a clear and effective case for securing your instances. This section will guide you through the arguments in favor of investment in security.

What is at risk?

The specific modules used in your ServiceNow instance will determine what information or access is at risk. In considering and justifying investment in ServiceNow, it is important to be clear on what it is that you’re protecting. The following list will indicate specific examples from each of ServiceNow’s major workflow areas.

IT workflows

ServiceNow has supported IT workflows since its inception and has come to rely on the ability to both store critical data about the detailed configuration of your technology systems and remotely execute scripts within your network. A fully developed IT workflow capability includes the following:

• Discovery processes with access to a large majority of your networked technology assets
• Lists of specific Internet Protocol (IP) addresses with details of the specific software (including versions) of those endpoints
• Incident and problem records, potentially including log data or sensitive data related to users
• Orchestration processes that can patch, reset passwords, or modify the configuration of your technology assets

Naturally, the number and nature of sensitive data elements vary between instances; however, these provide a useful starting point for considering the importance of securing your environments.

Customer workflows

With the expansion of ServiceNow’s customer support capabilities, entirely new classes of data are being integrated into ServiceNow. Customer lists, contact information, and even pricing and sales-related data can all be part of a customer workflow deployment, and the increased visibility of the solution only magnifies the importance of protecting this information for the sake of your company and the customers who trust you. Customer workflow deployments include the following:

• Personally identifiable information (PII) about the end consumers of your products and services
• Competitively sensitive information about customer satisfaction levels subscriptions and entitlements
• Details of products and services sold to customers
• Details of appointments booked by your field service staff to resolve customer issues

A breach of customer data can hang over your company’s reputation for years, making the case to secure your instances even more compelling.

Employee workflows

HR data is among the most sensitive information within an organization and is a frequent target of data breaches. While employee details in an IT-only implementation can be minimal, HR profiles are often populated not only with work contact information but also with home addresses and personal contact details. In an implementation involving employee workflows, the following data is particularly sensitive:

• HR-profile sensitive fields, including place of birth, marital status, and date of birth
• Details of HR cases, and—in particular—employee relations cases
• Integration credentials with access to HR systems such as Workday or SuccessFactors.

Creator workflows

The ServiceNow platform also offers nearly unlimited potential for customization to address new business needs. As such, the scope of potential data that can be included within creator workflows is nearly unlimited. Assessing the risk for creator workflows is best done on a case-by-case basis.

Securing leadership support for security

We hope the preceding section has impressed on you the potentially catastrophic ramifications of any breach of your ServiceNow instances’ security. Given the impact such a breach could have, it is surprising that many implementation plans observed in industry do not have dedicated effort allocated to ensuring the security of the instances. As a leader or sponsor of a ServiceNow project, you have the right and obligation to ensure that appropriate actions are being taken to keep your company’s data and systems safe.

The best time to raise instance security is early in the planning process of your implementation; the second-best time is now. When you present your case for allocating some of your company’s scarce resources to an activity that does not have immediately visible outcomes, it’s important to be neither dismissive nor alarmist regarding the risks.

In our experience, a clear articulation of the value and risk inherent in your instance—based on the factors laid out so far in this chapter—and the unique conditions of your industry and use case can be used to establish the need to actively manage security. The remainder of this chapter will help you determine what to do and when.

We recommend using this approach to present the problem of security together with the solution of a straightforward plan that can be accomplished with a small fraction of the efforts of your implementation team. If you present only the concern without a view on how it can be addressed, you will either be immediately asked to go and prepare the solution (in which case, you lose an opportunity to anticipate needs and be proactive) or in the worst case, you risk the problem being ignored. Let’s get to work building your plan for instance security.

Planning for instance hardening

Knowing that you should be securing your instances but not knowing where to start is a tough place to be. Fortunately, with a few simple guidelines and tools provided by ServiceNow, you can make a big impact quickly. Let’s start with a clear picture of where security should be applied in your ServiceNow deployment.

Implementation security measures

With security often seen as a “checklist” activity that must be addressed prior to go-live, it can be tempting to try to focus the security standards for your environments on the production instance only, hardening it as your initial cutover approaches. Teams taking this approach often restrict the data that flows to sub-production instances and adopt less strenuous controls in those instances. Others allow security-related tasks to be undertaken in a final hardening cycle prior to production rather than continuously throughout the implementation. Rather than adopt these approaches, you should consider securing all instances early.

Secure your instances when they are provisioned

You should be taking steps to secure your ServiceNow instances as soon as they are provisioned because a compromise to security at this stage (such as sharing initial administrative credentials over insecure channels) could immediately compromise all future work in that instance. Compounding this upfront risk is the default capability in ServiceNow to postpone administrative multi-factor authentication (MFA) set up for the first few logins, meaning that a simple username/password combination is enough to gain access.

Secure all instances that promote code to production

It’s not enough to secure only your production instances because development, testing, and staging environments all impact the final code that makes its way to production. A compromised test instance,for example,will allow an attacker to insert a malicious payload into an update set or Application Repository package before it’s installed on production. While a careful audit of every line of every update set would pick up on the issue, relying on such manual and time-consuming reviews to secure your data is a recipe for failure.

Planning for secure platform operations

Knowing that your instance will be operational for many years, it is imperative that you consider not only the day-one security posture but also the continuous operations of the instance over time. This means documenting the security standards that are applied and the decisions that were made in setting up the instance. The following sections will provide a more detailed review of how to leverage the tools ServiceNow gives you to secure your environments.

Improving instance security posture

Security is best thought of with a layered approach. You can always improve the security of a system, but the goal is to provide security that is just a bit better than “good enough,” and a common and effective way to do this is with many redundant layers. One common example of this that many people are used to today is MFA. When you log in to your bank account, the bank likely sends you a security code to enter. This is an example of layered security because the probability of someone guessing both your password and the code is much lower than the chance of them guessing (or otherwise discovering) either one. The more overlapping layers of security you have in your environment, the harder it is for an attacker to penetrate and access your systems.

Fortunately, ServiceNow provides several tools that provide mutually reinforcing layers of security to address the needs of even the most security-conscious customers. The most common of these tools are discussed in this section.

Instance Security Center

After securing your instance admin accounts, the Instance Security Center should be your next stop. You can access Instance Security Center on the menu under System Security or at http://yourinstance.service-now.com/isc. This dashboard provides you with three important resources, as follows:

• Security metrics, including data export counts, login failures, external logins, and antivirus statistics
• Compliance scores that inspect your instances’ security controls and provide aggregate scores for security and Payment Card Industry (PCI) compliance
• Security resources and frequently asked questions (FAQs) to assist in your security setup

The following screenshot provides an illustration of where to find the Instance Security Center:

Figure 5.1 – The Instance Security Center is found under System Security on the menu

In general, the Instance Security Center is one of the most underutilized resources on the ServiceNow platform because of how easy it makes it to drastically improve your instances’ security. The following screenshot shows some of its features:

Figure 5.2 – ServiceNow’s Instance Security Center provides a suite of tools to improve your instances’ security

The best place to start is with the security compliance metric score. While the exact number varies with the version, you can expect a score near 80% for a completely out-of-the-box instance, but with a few simple configurations, you can improve this score to at least 90%. Higher scores are better, but some security settings have an impact on user experience (UX) or functionality. This also means that configuring these settings early avoids you having to take away features from users later to satisfy a security audit.

ServiceNow provides multiple groups of security settings, each with High, Medium, and Low requirement levels. It is good practice to review all security settings that are marked as non-compliant and for each one to make a decision as to whether you can accept the ServiceNow recommendation to move them to a compliant state.

Important note – IP access controls

One setting that is very powerful is the ability to restrict access to IP addresses and ranges. These settings can be found in the Low section of the Access Control section. Many customers leave this feature off after go-live in order to make mobile and remote use easier, but it can be particularly useful in the early stages of an instance’s configuration as it allows you to restrict access to only your company’s corporate network. This significantly reduces the potential for an outside party to gain access over the internet while you are setting up other controls.

The Instance Security Center also provides the ability to track trends in login and antivirus activity. For basic deployments, the use of the security center can be enough to keep an eye on these metrics, but most sophisticated customers choose to tie these into their security monitoring to detect anomalous patterns early.

With the clear interface of the Instance Security Center and the built-in best practice check, ServiceNow has made the first steps of securing your instance the most straightforward—don’t overlook it. While these security settings address the needs of many customers, ServiceNow offers further options to secure data, including options for various forms of encryption, which we will cover in the next section.

Encryption

A major topic in almost every large ServiceNow deployment is the selection of an encryption technology, and we’ll dedicate some time to discussing how encryption should be addressed and making these options clear. We will also illustrate cases where each type of encryption might be used. Note that the most recent encryption updates are always available in the ServiceNow Encryption Whitepaper, available on the ServiceNow website or from your ServiceNow account executive. One of the most important things to realize is that in the ServiceNow ecosystem, ServiceNow has committed to addressing the in-transit encryption of data but leaves the decision of encryption at rest entirely to the customer.

How to approach encryption

Before diving into the selection of a particular encryption technology, it can be useful to consider your motivations and objectives for applying encryption. In almost all cases, the company implementing ServiceNow will have an information security policy or standard that classifies various types of data or various system use cases and then prescribes minimum technical controls for each classification.

Once you know the security requirements for the relevant classifications, you’ll need to determine which of the encryption options provided by ServiceNow addresses the requirements while presenting tolerable trade-offs in cost and functionality. These classifications and the associated requirements should be discussed early, and a plan should be documented to avoid a scramble late in the project to adjust compliance and potentially introduce breaking changes from encryption.

Encryption types

ServiceNow offers a variety of encryption options that can be used in conjunction with other controls to secure the data in your instances. It’s important to note that encryption alone is never sufficient protection for data in ServiceNow and must be combined with the recommendations of the Instance Security Center and general security good practices to secure your instances. We will cover the practical aspects of each, and for details on the cryptographic properties of each, we recommend referring to the ServiceNow Encryption Whitepaper.

Column-level encryption

ServiceNow offers the ability to encrypt specific attachments as well as targeted string, date, time, and Uniform Resource Locator (URL) fields directly on the platform with a feature set known as Column Level Encryption Enterprise or CLEE. This encryption solution allows administrators to set up role-based or application-scoped-based access to the cryptographic modules required to access certain data fields. CLEE is most effective when a limited set of attributes must be secured and where the encrypted data should be accessible to only a subset of the instance’s users or applications. CLEE can be thought of as a complement to the access-control list (ACL) features that ordinarily provide role-based access control (RBAC) in ServiceNow.

Edge Encryption

The Edge Encryption capability in ServiceNow seems at first glance to offer a very similar capability to column encryption. Both methods allow specific fields to be encrypted while the rest of the data is unaffected; however, there are some important differences that determine when each method is appropriate. While column encryption functions fully within the ServiceNow cloud, Edge Encryption requires you to deploy an encryption gateway (or proxy) within your own network that allows you to encrypt and decrypt data for a specific set of fields inside your own firewalls, meaning that the unencrypted data never even leaves your network. This approach provides a very high degree of protection for specific fields but comes with some important trade-offs, as outlined here:

1. The setup and maintenance of Edge Encryption will require appropriate skills to deploy and maintain.
2. Unencrypted data is never present on the ServiceNow servers, which means that server-side logic and validations of the data are not possible.
3. Sorting and filtering of data in the user interface (UI) are impacted so that only exact matches or numeric comparisons can be made. You will not be able to use contains or other query types on edge-encrypted data.
4. Edge Encryption is not a useful solution for encrypting data that must be used within ServiceNow, and it cannot be used to encrypt all data in an instance.

Edge Encryption does, however, offer the most flexible toolkit for addressing stringent requirements such as data residency requirements or policies that require data to remain only within the customer network. Although Edge Encryption is arguably the most powerful of the encryption options, it is most certainly not right for everyone. A notable drawback is the inability to encrypt all data in the instance, which can sometimes be a requirement. Fortunately, ServiceNow offers other encryption options that can be used alone or in conjunction with edge and column encryption and that provide complementary protection.

Database Encryption

When security policy requires the encryption of all data or where the cost to determine which data needs to be encrypted would be prohibitive, it can be useful to adopt an encryption approach that simply encrypts all data. To enable this, ServiceNow provides a database-level encryption service called simply Database Encryption that causes the entire contents of the database to be encrypted at rest but without impacting application functionality (other than a typically insignificant performance impact). Database Encryption is often an efficient way to meet encryption at rest requirements, provided that the data can be encrypted in the ServiceNow data center and decrypted by any ServiceNow features that would normally have access to it (subject of course to ACLs).

It is noteworthy that Database Encryption can be combined with other forms of encryption such as Column Encryption or Edge Encryption to apply a higher level of control to specific fields while providing an at-rest encryption baseline for all data.

Full-disk encryption

In some small fraction of deployments, there may be a specific requirement to use self-encrypting drives, which provide protection against an attacker physically stealing the drives from the ServiceNow data center. This option would not typically be recommended unless there’s a specific policy requirement dictating it as the capabilities and impact to the ServiceNow application are broadly similar to the database encryption features, which are generally less costly to implement and maintain.

While core instance security and data encryption are certainly good places to start, there is still one major area of the platform where security must be carefully considered: integrations.

Integration security

ServiceNow makes it incredibly easy to connect multiple production systems together, typically with web services that allow the real-time exchange of data between two applications on a network or on the internet. This ability for one system to remotely access and manipulate another introduces yet another place where security must be considered.

The security of an integration relies on the security of the source and target systems, the communication channel, and the authentication and authorization systems used. Each integration should be assessed for security on each of these elements, although special attention should be placed on authentication and authorization.

Source and target system security

When data is being transmitted in an integration, it is subject to the assumption that both sender and receiver endpoints of the integration can be trusted to handle that data securely. If either system is compromised, the data could be exposed. Data stored in two systems is inherently less secure from breaches than data stored only in a single system because all systems have some degree of security risk associated.

In a ServiceNow implementation, this requirement for endpoint security has two important implications, as follows:

1. You should ensure that the systems to which you send sensitive information comply with your organization’s minimum standards for the relevant classification of data.
2. You should ensure that any customizations you might make do not decrease the security posture of the ServiceNow instance.

Securing endpoints

Developing integrations on ServiceNow has traditionally been difficult work, often requiring an experienced developer to work for days. While recent advances in Integration Hub have decreased the need for developers to custom-code integrations, you should be vigilant when an interface does require scripting. Utilizing Integration Hub can help to avoid common mistakes with security that can be made when scripting fully custom integrations.

An example of this endpoint security would be the use of the GlideRecord application programming interface (API) rather than GlideRecordSecure. In everyday development, it is common for developers to access data with standard APIs such as the GlideRecord API, which will query all data regardless of ACL constraints. In the right circumstances, this could allow an integration to be used to access data that was not intended to be shared.

Features such as Edge Encryption or CLEE would mitigate this risk if configured, but rather than rely on these additional controls, a developer should simply use a GlideRecordSecure call, which will evaluate ACLs within the context of the current users. This increases the configuration effort as appropriate ACLs will need to be set up (or roles granted).

It is also advisable to secure REpresentational State Transfer (REST) endpoints with defined ACLs to ensure that no endpoint is accessed by an account that has not been authorized. Note the two distinct but complementary objectives, as outlined here:

1. Prevent the intended consumer of an endpoint from accessing more data than they should have access to
2. Prevent an unintended consumer from being able to access an API they were not intended to access

If your team is not able to dedicate the necessary efforts or skills to securing endpoints, you should consider engaging a consulting specialist in integrations or utilizing only the interfaces supported by ServiceNow’s Integration Hub.

Authentication and service accounts in ServiceNow

When an external system integrates with ServiceNow, that system will typically authenticate as a service account, also known as an integration account, which means that there is a record in the sys_user table that holds the identity of that integration connection. Managing these service accounts effectively is an important part of developing secure integrations and requires you to consider the level of access granted to each service account and the controls that will prevent unauthorized use of each account.

Recommendations for use of service accounts

Some general recommendations can be applied to the setup of service accounts in ServiceNow, as set out here. Following these will help you more effectively manage these important and sensitive credentials:

• Grant least sufficient privileges: A common principle in systems design is that of least sufficient privilege. The principle states that no account should have any greater level of access than the minimum that is sufficient for the account’s purposes. It is far too often the case in systems integrations in general—including ServiceNow—that service accounts are provisioned with broad access through the reuse of out-of-the-box roles. This typically occurs when integrations are quickly set up and administrative or other elevated roles are granted to work around access errors. You may additionally restrict service accounts to interact only via web services by checking the Webservice Access Only box on the user account.
• Utilize a common naming scheme: Service accounts should be treated differently from regular user accounts as they are not tied to any one individual. To facilitate this distinction, it is often useful to name service accounts with a common prefix such as svc-.
• Manage credentials securely: The credentials of service accounts should only be stored in a secure credential store such as CyberArk. These credential stores are the corporate equivalent of password managers and can help prevent the loss or misuse of account credentials. If a secure credential store is not available, then you should not store the passwords in an insecure form. Rather, configure the connections, knowing that if the password is needed at a future date, it can be reset to a new value at that time.
• Refresh credentials periodically: Passwords should be refreshed periodically according to your company’s security policy. If you have no policy on service account credentials, an annual rotation of the passwords should be considered.
• Periodic service account reviews: Throughout your implementation and during regular system operations, the roles of all service accounts should be routinely reviewed to ensure that the appropriate roles are assigned.

Important note – Integrations authenticating with end-user tokens

It is also possible in ServiceNow to set up an integration where end users generate their own tokens that allow an outside system to authenticate on their behalf. This is rare for production use cases in ServiceNow deployments and should be discussed with a qualified security professional if you believe it to be necessary.

Role of the ServiceNow MID Server

One of the most important tools in a ServiceNow integration specialist’s toolkit is the Management, Instrumentation, and Discovery (MID) Server. The MID Server is a service that runs on a server or container inside the customer’s network and brokers integration traffic by establishing a secure outbound channel from the customer network to the ServiceNow instance and using that channel to facilitate bi-directional integration.

MID Servers are typically set up in clusters, which can provide load balancing and redundancy for interfaces. When ServiceNow needs to integrate with resources on the customer network, the MID Servers allow it to do so without requiring firewall rules for inbound connections or complex proxy configurations.

When developing an integration between ServiceNow and an on-premises system, you should always consider MID Servers as these allow you to leverage ServiceNow’s investment in a secure channel from the MID Server to your instance.

At the same time, consider the power that these MID Servers have in accessing your ServiceNow environment and ensure that you have secured them appropriately, taking special care to manage their service account credentials securely. In particular, MID Servers should always be set up according to the current installation documentation, which will protect the credentials and support a secure connection.

Summary

In this chapter, we have discussed the need for security in a ServiceNow implementation and helped you understand how you can build a case to allocate the limited resources of your project to ensure the systems and data under your control are protected.

We’ve covered the tools at your disposal to secure your instances through the Instance Security Center as well as the various data encryption options available on ServiceNow. Finally, we addressed the considerations for secure integrations within ServiceNow.

As discussed in this chapter, the concepts of security must be applied to all ServiceNow instances under your control. The next chapter will cover the management of multiple ServiceNow instances and provide you with tools to assess how to use your ServiceNow instances.