Database Encryption with Customer-Controlled Switch (DBE with CCS) is an encryption solution that encrypts all data at rest when not in use in the database. Database Encryption with Customer-Controlled Switch uses industry-standard AES encryption, with no impact on functionality. The database encrypts data as it is written to the disk and decrypted by the database as it is read from the disk. Applications always have the data in an unencrypted state to perform the necessary logic and functions.

As illustrated, ServiceNow stores and manages keys using a three-level key hierarchy:

1. A customer-specific AES-256 key is created by the database engine and is used to encrypt the data.
2. A second customer-specific AES-256 key is created by the database engine and is used to protect the first-level key.
3. A third AES-256 key is created by and stored within FIPS 140 validated key management appliances in the ServiceNow datacenters. This key protects the second-level key and is unique per customer instance.

Key scope

• * The first two keys are customer specific and are created by the database engine
  
  • The third key is instance specific
    
  • Key management practices, including key rotation, are per ServiceNow's SOP. Please refer to CORE on HI for the SOP.
    
  • ServiceNow performs key management. Customer-managed keys are not currently an option.

The Now Platform supports database encryption with a customer-supplied switch, DBE with CCS. This is an encryption solution that encrypts all data at rest when not in use in the database. It uses industry standard AES encryption with no impact to functionality. The database encrypts data as it is written to the disk, and decrypts data as it is read from the disk. That means that applications always have the data in an unencrypted state to perform the necessary logic and functions without impact.

Database Encryption Vs Full Disk Encryption

The offering is similar to Full Disk encryption with a few exceptions:

• Full Disk Encryption provides hardware-based encryption, Database Encryption happens at the software level.
• Database Encryption offers protection against the theft of database files, not just theft of the disks like Full Disk Encryption.
• Full Disk Encryption requires dedicated hardware; Database Encryption does not.
• Database Encryption is generally less expensive than Full Disk Encryption.
• Database Encryption and Full Disk Encryption can be used in parallel if desired. Performance impacts will be cumulative as both Full Disk Encryption and Database Encryption decrease performance.

Database Encryption Vs Application-tier encryption (Edge Encryption or column-level encryption)

• Database Encryption is complementary to application tier encryption but does not replace it in some cases. Common use cases addressed by application level encryption but not Database Encryption include:
  
  • Data must be protected at the application layer
    
  • Data must accessible in the clear to only certain groups of users
    
  • Customer must own encryption keys (Edge Encryption only)
    
  • ServiceNow cannot have access to data in the clear (Edge Encryption only)
    
  • Encrypted data should not be in the clear outside of the customer's environment (Edge Encryption only)
• Database Encryption also covers certain use cases that application-level encryption does not:
  
  • Protection of data types that cannot be encrypted via Edge Encryption or column-level encryption
    
  • Encryption with no impact to functionality
    
  • Encryption of all data-at-rest
    
  • Database Encryption can be used in conjunction with Edge Encryption and/or column-level encryption to apply a layered security approach. Database encryption protects all data at rest and Edge Encryption or column-level encryption provides higher security protections to sensitive fields such as PII and PHI.

Why DBE to consider and How it add value

Database encryption addresses two different threat vectors. In each case the data will be encrypted and is thus of no use to the adversary

• The threat of an adversary getting into our network, stealing the database files and exfiltrating them
• The threat of an adversary getting into our datacenter and stealing the drives.

Database encryption does not provide protection at the application level. If application-level encryption is needed, Edge Encryption or column-level encryption should be used. Database Encryption can be used in conjunction with Edge Encryption and/or column-level encryption where higher levels of protection are needed, such as may be the case with PII and PHI.

Database Encryption also does not protect against authorized users, either internal or external.

Steps to enable CCS/CSK DBE end-to-end

1. Setup a mechanism to host and manage the secret key
2. Design the endpoint as per Implementation guide to supply the secret in encrypted way to ServiceNow
3. Enable TSE for instance
4. Test and validate the endpoint internally
5. Test and validate the endpoint by ServiceNow with secret key supplied
6. ServiceNow Dev team will implement the DB encryption after a successful validation of endpoint.
7. Evidence report will be shared with us upon successful enable to DBE

Limitations

Database Encryption has an approximate 5% impact to performance. This number is consistent between our testing and the quoted impact by MariaDB.

• Database Encryption is not available on Oracle databases.
• Sparse backups are not supported.
• MetricBase cannot be encrypted with this offering.
• Read replicas are supported.

Cloning impacts to keep in mind. Encryption follows cloning

• If a clone is done from an encrypted source to an unencrypted target, the target will be encrypted after the clone is done.
• If a clone is done from an unencrypted source to an encrypted target, the target will no longer be encrypted after the clone.
• It is critical that all instances are encrypted to avoid unintentionally exposing decrypted data