More CLE San Diego guidance after completing the upgrade

[Jonathan F]

As far as I can tell, this information is specific to companies who have installed Column Level Encryption (CLE) (previously Encryption Support), NOT the paid option Column Level Encryption Enterprise.

Our company came across three issues while upgrading to San Diego (the first two were caught and fixed before the upgrade):

1. Our CLE was either corrupted and/or installed incorrectly in our environment, AND differently so across environments. This led to different behaviors as we tested the San Diego upgrade.
2. We created some custom scripts that used publicly available (if you find them) JavaScript libraries, and those were not properly upgraded with San Diego.
3. 2 way Encrypted Passwords also suffered from this known bug described in KB1117261, which wasn't clear in the KB article.

This article describes what to look for and how we resolved the issues. We also provided a description for a wider, non-technical audience, which I've attached in case it's helpful. It was written before we uncovered the third problem.

Important disclaimer: even after spending many hours finding and resolving these issues, I am still very excited by the changes introduced in San Diego (once fixed) and am happy ServiceNow made these changes. I am already taking advantage of easier key rotation, for example.

If you can't navigate to the places described below, it is likely because you need the security_admin Role then you need to go to System Security > Key Management Administration to grant yourself access to these features.

Broken CLE Plugin

It's highly unlikely you are also experiencing this issue. ServiceNow has been at my company since 2013, and we installed the CLE plugin in 2017, of which both dates predate my time supporting ServiceNow by years.

The way we noticed this issue was by navigating to the sys_mass_encryption_job table. As part of the San Diego upgrade, a series of migration jobs occur in this order:

• all_keys_to_kmf
• all_data_to_kmf
• Multiple "Migrate Attachment Context to Module" jobs, one for each table that includes at least one encrypted attachment

Some will Have a State of Error, and some may execute indefinitely. If you notice this, submit a Now Support Case to re-install the plugin, then (if they don't automatically generate) re-run all of the migration jobs.

Custom encryption scripts

At least one of our business lines has specific requirements to use a specific encryption context (now crypto module where Parent crypt module = column_level_encryption. you can find these by navigating to System Security > Field Encryption Modules) rather than the one selected by the user. This required the developers in 2017 to modify records via scripts and business rules, etc.

The challenge here is that the SN scripting libraries previously used were not updated to the new way of storing and checking for access, so they needed to be entirely replaced with different libraries which are similarly not fully supported by SN. Some example issues include: the raw format of the values changed, so the old libraries could not properly parse the data, the location of records moved to different tables, so the code used the wrong sys_ids for the wrong tables to look up keys, etc.

I've attached two scripts, one a Script Include and one a Scripted Web Service (sys_web_service) in case the example code is useful. It all works post San Diego.

2 way encrypted passwords

The only important thing to note on this topic is that in the product documentation for 2 way encrypted passwords for San Diego, (I did not find a note in the release notes for San Diego), there is a section called "Legacy Password2 and the current Password2" which notes that these were similarly migrated with San Diego. You can also find a security job that migrates these passwords and in looking at the raw values of these passwords using "show XML" you can see that after the migration they noticeably change in format. KB1117261 did not call this out either, so we did not catch it until after our San Diego upgrade and ran into issues until after the fix in Patch 3.

If you use this feature, the fix is simple: make certain you use at least Patch 3 when upgrading to San Diego.