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.