In my last post, I highlighted how important it is to protect customer data privacy in an IBM Tealeaf On Cloud implementation, and demonstrated techniques for how to implement privacy masking abilities on the “client-side” – that is, to make sure sensitive customer data never even leaves the browser.
But there are plenty of valid reasons why a strategy to protect customer data is incomplete if only client side blocking and masking is implemented. IBM Tealeaf On Cloud is able to protect customer data privacy on the server side as well. Let’s understand how the implementer should leverage this ability.
Implementing Server-Side Blocking and Masking
Initially one would think, “Wait, why would I need to worry about blocking and masking sensitive data on the the IBM server end if it’s never supposed to be leaving the customer browser in the first place?”
The answer would be: that is the correct instinct; ideally that data should never leave the browser. But, nonetheless, there are two valid responses here:
- the client might insist that it is necessary that some sensitive data be accessible outside of the browser session and
- the implementer (and client) can never be too careful with sensitive customer data.
Additionally, even if that data somehow leaves the browser, we don’t want it ending up on the Tealeaf servers. Failing all other explanations, redundancy is worth it when it comes to the safety and security of SSNs, credit cards, bank accounts, or other sensitive data.
Privacy blocking happens via Hit Attributes that are applied to conditions to an Event. In order for privacy to be applied, the event for which it’s Hit Attribute is a condition must fire.
The hit attribute can be defined by:
- starting and/or ending patterns of strings
- a regular expression applied to found text
- a certain string constant, like “SSN”
The scope of a privacy Hit Attribute must be set to be the server response (not the browser request).
Any sensitive data that makes it to the server usually makes it in the form of captured DOM snapshots. These snapshots will contain HTML elements that could contain form data that is comprised of one or more sensitive elements that require masking.
Sometimes, though, sensitive data may show up in elements other than forms, such as a confirmation message, an error message, or other “random” locations on the page. Below, we’ll address a few different scenarios of sensitive data needing masking on the server side.
Suppose the following error message on a form submit struggle is captured:
To mask the SSN:
- Log into IBM Tealeaf Cloud UI
- Click Event Manager
- In the Event Manager, click “New” at the top right part of the UI
- Select “Hit Attribute” from the menu that drops down
- Enter in the fields like so:
- Note that the start and end expressions encompass the text we know surrounds the SSN come from the captured HTML in a DOM snapshot
- Hit “Save” to save this Hit Attribute, called “Block SSN”
Oftentimes the web form will have different attributes in various permutations, such as these three cases:
- SSN: <input type=”text” name=”ssn” value=”123-45-6789″ required>
- SSN: <input type “text” name=”ssn” required value=”123-45-6789″>
- SSN: <input type “text” name=”ssn” disabled value=”123-45-6789″>
In this case, the start/end expression pattern would remain the same, but you’d use a regular expression value to mask only the content of the value attribute:
- .* value=”(.*?)”.*
- Everything within the parenthesis will be masked with the value of the “Block replacement” field
(Here is a good place to point to a regular expressions resource, https://regex101.com/. Additionally, there is, as always, a wealth of other resources on the internet about regular expressions, or “regex”.)
If you’re finding that sensitive information is appearing in the page HTML that has no recognizable identifier, such as:
- <div class=”panel_text”>123-45-6789</div>
… this is a case where the client developers need to make sure sensitive data is being properly kept under wraps, or at least identified properly so it can be masked (if for some reason the page really does need to display a Social Security Number.)
It’s important to keep in mind the principle that the IBM Tealeaf On Cloud implementer cannot and should not be in charge of a client’s security procedures. This is a client responsibility.
Once a privacy hit attribute is saved, it must be added as a condition for an event in order to actually be applied:
- Click “New” again, and select “Event”
- Enter an event name
- Select “Hits” as the object type on which the event should trigger
- Select Frequency of “Every Hit”
- Click “+ Condition”
- In the modal that appears, click Hit Attribute on the left-hand pane and search for the privacy hit attribute we just created (“cg mask SSN”)
- Click “Select” in the modal
- Then select “Hit attribute found” and “Is true” in the drop down menus that appear next to the newly added condition to signify that our desired condition for the event firing is merely if the privacy hit attribute is found on the page.
- It’s not necessary to configure any more of this privacy hit event in order for it to work, and, in fact, more privacy hit attributes should be added that fire this masking event to anticipate multiple kinds of scenarios where HTML elements containing sensitive customer information need to be masked.
- This is done by creating more hit attributes (using the same process we’ve already followed to create privacy hit attributes) and then adding them to this privacy event by stepping through the above step beginning with clicking “+ Condition”
- Click the blue “Save” button on the Event model to save the event and have it start firing on incoming data that may contain sensitive information
- Once this event is saved, it’ll appear in the column containing the list of possible events to use in the Event Manager pane.
If the privacy Hit Attribute and Event are configured correctly, sensitive elements in DOM snapshots captured by the IBM Tealeaf On Cloud configuration are sent to the Tealeaf Cloud UI should start showing up as masked in the fashion specified when the DOM captures are viewed in the replay pane of the Tealeaf Cloud UI.
When it comes to IBM Tealeaf On Cloud – Always Plan Ahead
After having implemented the above privacy regime, maintenance of the privacy configuration should become part of the client developer’s application test and release cycle. Changes or updates should require a review of the privacy filters to be sure they’re still effective, with a special focus on web forms. Even small changes in formatting code that may not be visible to a human viewer of a web page may render regular-expression based searches for sensitive information ineffective.
It is a good idea to develop a plan where, going forward from the IBM Tealeaf On Cloud implementation phase, the person responsible for the client’s IBM Tealeaf On Cloud implementation (whether a consultant or a client employee) is a stakeholder in any process that affects the privacy configuration.
I don’t think I emphasized enough in this post that Tealeaf will capture the response of the client’s e-commerce platform server to any sort of activity on the client end and that this response can contain elements that must be blocked and masked. It may be contained in server-generated HTML, or it may be in JSON messages sent from the response.
About this blogger
Digital Experience Solutions Consultant at CLEARGOALS – Eric is a consultant on the CLEARGOALS IBM Tealeaf (Digital Experience Management) team and helps customers dig deep into their CX data to find ways to improve and optimize overall customer experience. Connect with Eric on LinkedIn