Find your people. Pick a challenge. Ship something real. The CreatorCon Hackathon is coming to the Community Pavilion for one epic night. Every skill level, every role welcome. Join us on May 5th and learn more here.

Uncle Rob
Kilo Patron

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.

find_real_file.pngWHY 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....

find_real_file.png

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.

1 Comment