Encryption is the process of converting data (plaintext) into an undecipherable form (ciphertext) to prevent the disclosure of information. Use encryption to protect sensitive information.

At its core, modern encryption algorithms use secret keys to perform encryption and decryption operations. The security provided by encryption is fundamentally based on these keys. Keep keys secure and secret to protect your data.

Encryption is a reversible operation. You can decrypt ciphertext if you have access to the encryption key.

Information in the Now Platform is not encrypted by default. Encrypting all information would greatly increase processing time by requiring decryption for authorized users and then re-encryption to prevent unauthorized viewing.

Some encryption is required by law. For example, medical institutions must follow HIPPA requirements to protect patient privacy. Banks and other financial institutions must follow state and federal laws to protect sensitive financial information. Ultimately, as data owners, your organization decides what information to encrypt.

ServiceNow® offers different options to keep customers' data safe.

For instance for customers with statutory obligations for data protection which may require at-rest protection for all data you can select between

• Database Encryption
• Full disk encryption

Database Encryption is an additional cost option that allows you to encrypt all of the data stored within your database, with no loss of functionality. Data is encrypted with AES encryption and decrypted in real-time as it is accessed. If enabled, this will also be applied to all sub-instances and backup data.

Full-disk Encryption is another additional cost option where the disks used to store your instance and data include self-encryption capabilities. This encrypts all your information when the system is offline and therefore provides protection in the unlikely case of physical disk loss or theft.

Otherwise, they can decide for a different approach after determining which information the organization has to or wants to encrypt selecting between

• Edge Encryption
• Encryption Support

Edge Encryption is client-side encryption, where the keys are stored on the customer side (on-premise). The application can never decrypt and therefore access plaintext data because it never has access to the keys.

Encryption Support is a native Now Platform encryption option providing simple, secure encryption, but may not meet all of your requirements around key storage and management. Encryption Support is server-side encryption with keys accessed by the application.

In this article, we introduce this last method providing some guidance on its use.

Encryption Support

Encryption Support, also known as column-level encryption, is a built-in feature that permits encryption of data stored within an instance using AES128, or AES256.

This allows encryption of specified database fields and stored files through the use of encryption contexts. These enable you to decide what is encrypted, select the algorithm used, and supply the encryption key, which is stored within the instance.

This key is itself encrypted by a unique AES128 key stored separately in the ServiceNow key management infrastructure.

Encryption contexts are tied to defined user roles and hence are used to control user access to data.

Implementation of column-level encryption begins with defining one or more encryption “contexts” in your instances of the Now Platform. This process includes selecting the desired encryption algorithm and providing an appropriate secret key. Access to data later encrypted using the feature is role-based, with contexts being associated with roles. Users without the correct role don't see the field at all, or if they are assigned a role with a different context, a blank field appears. Figure 1 illustrates how role-based encryption is enabled.

• User 1 is a member of Role 1, which provides access to Encryption Context 1.
• This allows User 1 to see the contents of Field A and Field B.
• User 2 and User 3 are members of Group 1
• Group 1 is a member of Role 1, which allows everyone in Group 1 access to Encryption Context 1 and allows User 2 and User 3 to see the contents of Field A and Field B.
• User 4 is not a member of any group or role and has no access to Encryption Context 1
• Not only does User 4 not have access to Field A or Field B, but User 4 will not even see that these fields exist.

Having access to an encrypted data field by being assigned an encryption context does not necessarily mean that a user can modify the field. Role-based access also must be implemented appropriately for that field to be accessible to users who are assigned the context via a role.

Customer encryption keys for use with column-level encryption, whether provided by a customer or randomly generated by the instance, are stored in the same unique instance database where the data encrypted by them is stored. As a further security measure, they are re-encrypted with a second master key unique for that instance, which mitigates direct access to the encryption key for any context, either by an instance administrator or ServiceNow. Column-level encryption optionally lets you store encryption keys in your own hardware security module (HSM) or other key storage appliances or services.

The system does not have access to the user contexts necessary to decrypt data, so some actions are not possible on encrypted data. Column-level encrypted data cannot be filtered or sorted.

Platform Activation and Set-up

Activation does not require any specific permission from ServiceNow.

Platform administrators can navigate under System Definition > Plugins and search for 'Encryption Support'.

IMPORTANT. Because 'Encryption Support ' determines access to encrypted data the security_admin users are the ONLY ones able to create encryption contexts and grant an encryption context to a user by granting the user the associated role.

In order to access the encryption modules, it will be necessary to activate the 'security_admin' role using the 'Elevate Roles' functionality.

The next step requires navigating under 'System Security' > 'Field Encryption' > 'Encryption Context' and set a brand new context using the 'New' button available on the list.

The creation of a new context is easy and needs just to select a name and the encryption type.

At this point, it is necessary to select the field affected by the new encryption context navigating under 'System Security' > 'Field Encryption' > 'Encryption Field Configuration'

ServiceNow asks to select a table, a field from the selected table, and a context.

IMPORTANT. In my example, I created a brand new text field on the incident table named 'Secret info' to be affected by the encryption. The next image shows the situation BEFORE the creation of the context.

On the other hand, as soon as the context is created the field automatically disappears.

In order to allow someone to see the field again, it is necessary to assign the encryption context to a group.

As visible in the previous image, not even the admin can see it.

We need to link the context with an existing role as visible in the next image.

IMPORTANT. The field Encryption Context must be included in the form. ServiceNow baseline setup does not show it. Other relevant detail, for my example I created a brand new role to be used.

After the role is completed we can finally include the role in a group. Anyone obtaining the role will be able to see the field clearly.

Here's the final result on the form where the encrypted field has been placed.

In order to test the functionality remember the following simple rules.

That's it!

Cheers

r0b0