How do I protect sensitive data?

Environment:

All pods (plus a few extra features specific for PCI pods)

Resolution:

There are several features available to address who can or should not see sensitive data as well as removing this data from your environment. There are also capabilities that prevent capturing this type of data. In this article we’ll identify these features with general reasons for implementing and pointers to documentation.

Data protection from a prevention perspective would be setup for Chat or any web form used to allow interactions that are built with Oracle B2C Service Customer Portal or APIs. There are features that keep data entered by your customers from appearing on Agent screens as well as those that allow a one-time viewing by an Agent but not saved into your database. These are:

• Chat Off-the-Record when used with Customer Portal will permanently truncate data entered into a Chat Message if the end-user chooses the “Off-the-Record” button/icon before sending the message. This enables the Agent to see the data during the chat conversation but not have the data saved into the database. Instead, “Message removed” replaces all data entered from that message line in both the Chat transcript and associated Incident if the conversation is saved there too. More details can be found in Answer ID 4019: Off the Record button in Chat.
• Web Chat for Service used with your websites, can be setup to function like the Off-the-Record feature as described above or you can prevent credit card and/or US Social Security numbers from ever reaching your Agent. Setting up pattern matching with Web Chat for Service (fka Inlays) will automatically and permanently truncate these numbers prior to being sent from the end-user’s Chat window. Details can be found at https://cx.rightnow.com/s/oit/latest/ under Documentation -> Inlays -> Embedded Chat -> Off The Record Features.
• Customer Portal Pages provide you with a vast array of capabilities to present and capture data from your customers. There are many approaches to customizing Widgets used in the Portal (or standalone) using PHP, CSS, JavaScript, and the standard Input Widgets. You can control if there is a specific format of data expected, whether to validate any field, and/or create custom code using Oracle B2C Service APIs. Web Developers can learn more about how to utilize Customer Portal and related API features in the Using B2C Service Customer Portal documentation.

If you don’t use the above features or collect data from your customers via other means, you can still prevent data from getting into your database. Two typical scenarios relate to sensitive data being stored in the chat transcript tables or within the incident messages/threads. 

If a chat conversation is added to an incident at the conclusion, to prevent specific sensitive data from being stored in the database you can implement Incident Thread Masking. This feature offers eight expressions that will transform the identified pattern text into Xs before saving. Three of the these ‘masks’ are preconfigured for credit cards, US Social Security numbers, and phone numbers. Documentation can be found in Using B2C Service under Incident Thread Masking and in Answer ID 6316: Enable Incident Thread masking feature.

Similarly, if saving the chat conversation into a transcript for review later, Chat Masking using Enhanced Business Rules provides functionality like Incident Thread Masking for credit card numbers, US Social Security numbers, phone numbers and up to 20 additional custom mask expressions. More details are available in Answer ID 12499: Masking end-user PII and other sensitive information shared via Chat.

Regardless of implementing these features, you can always find and remove sensitive data you did not intend to store. Some methods for finding data can be accomplished via Analytics and almost all fields in Oracle B2C Service are editable to remove offending data.  If you choose not to implement Incident Thread or Chat Masking, or decide later to turn these features on, but find you need to remove sensitive data from these fields, you have two additional features.

• Privileged users (as defined by Profile) can be given the ability to correct a response thread entry to remove unwanted content.  Documentation can be found in Using B2C Service under Edit or Convert a Response Thread and in Answer 1332: Editing the discussion thread of an incident.
• Privileged users can be given the ability to update or delete data from the chat table through a custom created report. This report also includes inline editing, as well as single and multi-deletion of rows. Details are available in Using B2C Service under Chat Reporting.

To protect sensitive data that is necessary to store in your environment, encrypted custom attributes can be defined. If you need to adhere to Payment Card Industry (PCI) standard or want to safeguard data from everyone except those that are privileged, a custom field should be defined using the Object Designer and added to one of your custom objects or to the incident or contact object. More details on setting this can be found in Answer 12667: Encrypting Data in the Database.

It should be noted too that if you have purchased the additional protection for PCI, which includes a 3rd party Auditor assessment of B2C Service’s ability in meeting  the PCI Data Security Standard V4.0, and more importantly the protection that no one in your company can see credit card numbers, several of the above features will work differently. This pod-level obfuscation operates on any 12-19 digit number that meets the credit card validation. When there is a match, instead of the numbers only asterisks will display on screen. However, the data will still get into your database unless you find and remove or implement the Incident Thread and/or Chat Masking features. More details on this type of masking can be found in Answer ID 5622: Credit Card and Social Security Number Masking in the PI (PCI) or FG Pod.