What controls exist to prevent ServiceNow decrypting passwords stored in the credentials table?

[Adz1]

It's a question that comes up with every Discovery implementation I've ever done, but I've never found a satisfactory answer. 

Passwords stored in the credentials table are encrypted, yes.
A support agent once informed me that every instance has its own unique encryption key, ergo credentials must be entered manually in each instance rather than being XML'd across between dev, test, and prod.
They're decrypted and re-encrypted with the MID server's key whenever the MID needs it. 

But when the data is at rest in the database, the instance's encryption key and the data are both under ServiceNow's control and not in the hands of the customer. 

Therefore, there is a theoretical risk that a rogue SN employee could decrypt the passwords stored in the credentials table.

Obviously, that is highly unlikely to ever happen and external credential vaults exist for those who prefer to keep the keys to the kingdom within the walls of their castles, but Information Security teams still want reassurance that there are some controls around it to reduce the threat surface area. 

So, the next time a customer asks, "could ServiceNow in theory decrypt our passwords stored in the credentials table?", what can I tell them to offer reassurance that there are mitigations to ensure that doesn't happen? 

[Hitoshi Ozawa]

Credential encryption is explained in the following Now Support page.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0679355

I think the key point is the following. There's 2 sets of encryptions. In most SaaS, these are maintained by different people in the organization so even if a rogue employee tries to crack the password, the employee will need assistance from another rogue employee with access to the other set of encryption. Also note that activities are monitored and logged usually be different team in the organization. So, to it would need a team effort.

Can't say there isn't any chance of such activities as happening but it seems like that happening is lower than  a chance of outsiders cracking into the service. That, I think is pretty low too.

• first, we are using our regular GlideEncrypter with 3DES cipher where the 3DES decryption key is stored in the instance DB
• second, we further encrypt the 3DES key using AES with a 256 bit key size, where the key is stored in the safenet devices (a separate key storage appliance and retrieved by the instance) 

[Rahul Priyadars]

what can I tell them to offer reassurance that there are mitigations to ensure that doesn't happen? -->

New way to portray same Down the line Agent based discovery will happen ACC so no such permanent storage in creds table

Or Password Vault is another way to have more secure

I recently got same question - what if employee got rogue and do something weired - Answer was on the lighter note this can happen with any system - what if your AD Administrator got rogue then imagine what will happen 🙂. This risk is everywhere and the last possible resort is the restore

Regards

RP

[Daniel Oderbolz]

Please refer to Cloud Encryption with Key Management.

You may provide your own keys (Level 3), but of course, you need to have your own system (either a HSM

or a tool like CyberArc) to store these keys.