
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.