PAST ARTICLES

Part 1 - The encryption feature checklist

Part 2 - Maximizing engagement time

Part 3 - No longer needed.

 

Understanding how variables work is going to save you a TON of pain on encryption initiatives for the Now Platform.  This is true whether you're using the old OOB "encrypted fields" feature, use ServiceNow's premium Edge Encryption product, or a 3rd party tool like Ciphercloud.

 

WHY SHOULD I CARE?

So glad you asked!  Listen, you care enough to *pay* for encryption either way.  Whether its an on-site admin who uses the OOB field encrypter, or the 5-6 figure contracts for Edge Encryption or a 3rd party.  So what if I told you that you paid that money and I can pull un-encrypted plain text data out of your instance?

 

THE TWO WAYS RECORDS ARE CREATED IN SERVICENOW

Via Catalog / Service Portal:  Consumer fills out "a form" and that creates records in the correct table.

Via "the form":  A worker fills out the appropriate table's base form on behalf of another user.

 

In the first case, the data is being stored in two places:

1)  The destination table.

2)  The repository of variables and their answers.

 

THE WHAT-NOW?

Your catalog will have anywhere from dozens to thousands of items ready for consumption.  The same reason you don't want to add a bajillion columns to each task table is the same reason variables (questions) and their answers are stored in a seperate table.

- Record Producers store answers to their questions in the question_answer table.

- Catalog Items store answers in the sc_item_option

 

Now... even though your record producers and catalog items are instructed to dump data into fields that are encrypted....

In the few encryption implementations I've audited, the front-end Catalog/Portal aspect of data intake has been overlooked.  Its essential that you consider if your intake is via catalog, to ensure your data is *TRULY* protected.

 

MITIGATING RISK

In the case of Record Producers, make sure any data pumping to an encrypted field *also* blanks itself out.  Something like this...

current.secret_field = producer.secret_field;
producer.secret_field = '';

 

Catalog Items will require something a little stronger... a business rule on the sc_item_option table that scans for precise questions and redacts their answers.