UIC Privacy
Adhering to data sensitivity, safeguarding and privacy is an important aspect of HCL Discover, as such the solution provides multiple privacy approaches for masking, blocking & encrypting data throughout the Discover architecture.
The UIC is a first point of contact for sensitive data, at this stage the data resides within the local client browser and has not been transmitted to Discover, it is outside of the solution and organisation. At this stage the UIC can be configured to address sensitive data as required, however it is useful to understand that approaches other than using the UIC exist within solution and can be used to address sensitive data (data in general). These include:
-
UIC
Fields can be blocked by ID, xPath, style or other attribute. ID or xPath approach can be inverted an allow list instead of a block list if desired. Changes here require pushing an update of the JavaScript library.
-
DNCA
Data can be blocked / encrypted when it is received by the DNCA. Data is blocked / encrypted prior to disk storage, even if there is a processing issue that causes data spooling. These changes can take affect immediately.
-
Processing Pipeline
Data can be blocked / encrypted when it is processed by the HBR or Canister. These changes can take affect immediately.
-
On-Demand or Replay
Also called Search-Server Privacy, this privacy is designed to block data at time of replay should it not be blocked at prior stages. This privacy method should be seen as a short term solution for existing data already captured.
Discover enables the blocking and masking of sensitive data within the local client browser prior to data encryption and forwardeding for capture. This process does not impact data to be forwarded to your web servers for normal processing. Discover can act upon data input by the visitor and also data displayed to the visitor; both may contain sensitive information.
Examples are:
- email address
- telephone number
- postcode
- memorable word
- account ID
- account balance
- username
Data input by the visitor is managed through the UIC configuration privacy: [ ] section. Data displayed in the HTML is managed via privacyPatterns:.
Useful Practices
In situations where Discover is introduced into the a web architecture at a stage prior to web application development or deployment into production, its is useful to introduce changes to assist with effective identification of sensitive information. Where possible it is preferable to work with the web team to create a class to allow Discover to block data in an automated fashion.
<div class="control">
<input class="w120" tabindex="6" onblur="formatSSN(this.value);" type="text" value="" maxlength="11"/>
</div>
<div class="control">
Field ID suffixes
Further to the class it is also useful to append a suffix to form field IDs that contain SPI/PII data. Field IDs and field names for input fields may contain a suffix of dcxBlock or dcxEncrypt to allow for efficient privacy processing.
<div class="control">
<input id="ssndcxBlock" name="ssndcxBlock" class="w120" tabindex="6" onblur="formatSSN(this.value);" type="text" value="" maxlength="11"/>
</div>
<div class="control">
<div class="control">
<input id="fNamedcxEncrypt" name="fNamedcxEncrypt" class="w120" tabindex="6" onblur="formatfName(this.value);" type="text" value="" maxlength="11"/>
</div>
Adding a class to input fields
A specific dcxPrivate classe can be used to allow or block input fields containing SPI/PII data from being captured and transmitted into the Discover solution.
<div class="control">
<input id="creditCardNo" name="creditCardNo" class="w120 dcxPrivate" tabindex="6" type="text" value="" maxlength="16"/>
</div>
Where its not possible to augment the existing web application prior to (or during) development, or deployment into production, the option to specify individual IDs necessary address privacy requirements.
Privacy Practices
Highlighted below are an example set of fields that may need to be considered for privacy during the web application development/update processes. The development team should generate a list that contains fields similar to those below for review by the security team who will define the final blocking / masking / encryption list.
Data to Destroy (Block/Mask)
The following field IDs and Names should have a suffix of DiscoBlock. The field displayed value should be surrounded by the custom comment tags
- Passwords (including password re-entry)
- Password Hints
- Secret Answers
- Application Passwords
- Challenge Question Answers
- Credit Card Numbers
- Secret/SiteKey Images
- Mother’s Maiden Name
- Drivers License Number
- External Bank Account Numbers
- External Bank Credentials (Usernames, passwords, challenge question answers)
- PINs (including re-entry)
- Social Security Number
- Social Security Numbers Last 4 Digits
- Social Insurance Number (Canada)
- Answers to Out of Wallet Questions
- Multi-factor Authentication Reset Confirmation Codes
- Debit Card Numbers
- Usernames
- Challenge Questions
- Account Numbers
- Vehicle Account Numbers
- Dates of Birth
- First Names
- Middle Initials
- Street Addresses
- Cities
- Zip Codes
- Phone Numbers
- Email Addresses
- External Account Routing/Transit Numbers
- Account Balances
- Transaction Amounts
- Secret Questions
Implementing Privacy
Input Privacy
Within the UIC configuration, a privacy rule is simply defined within the privacy object as:
{
targets: [
{
id: "kartNoTextBox", // Id label from the HTML
idType: -1 // Id type, HTML
}
],
maskType: 3 // Mask type, masked according to defined parameters
}
The configuration of the id can also be defined as a regex to specific identifiers. For example, the following target configuration matches all HTML identifiers that start with quantity_.
{
targets: [
{
id: { regex: "quantity_.*" }, // Id label quantity + any other text
idType: -1 // Id type, HTML
}
],
maskType: 2 // Mask type, masked according to defined parameters
}
The configuration of the targets object can also be CSS selector(s) value to match CSS elements. For example, the following example is applied to all input fields with placeholder="Enter IBAN".
message: {
privacy: [
{
targets: [
"input[placeholder="Enter IBAN"]",
],
"maskType": 3
}
]
}
Additional targets can be supplied on a new line separated by a comma.
The idType should be one of three (3) types (note: recorded as negative numbers) allowed in the UIC.
- -1 HTML ID
- -2 xpath identifier
- -3 HTML name or other element attribute identifier
| Value | Description | Example | Masked Example |
|---|---|---|---|
| 1 | Value is blocked and replaced by an empty string. | "InputPrivacy123" | " " |
| 2 | Value is masked with a fixed string of X's | "InputPrivacy123" | XXXXX |
| 3 | Value is masked according to the following parameters: - a lowercase letter is replaced by x - an uppercase letter is replaced by X - a numeral is replaced by 9- a non-alphanumeric value is replaced by @ |
"InputPrivacy123" | "XxxxxXxxx1971" |
| 4 | Custom function. Note: A masking function must be defined as maskFunction. |
"InputPrivacy123" | Depends on the defined function being called |
Privacy Patterns
The use of privacy patterns within the Discover UIC is to match and replace any specific patterns found within in the HTML. Privacy patterns can include regex, functions and act on specific pages / screenviews or be global.
Warning
Applying regex to the HTML DOM can impact the application. Adequate testing must be performed to ensure that pattern matching is working as expected & not causing any impact.
Configuration of patterns is located in the section privacyPatterns:. All pattens should be added between the [ ] parenthesis.
privacyPatterns: [
]
{
pattern: { regex: "\\d{3}-\\d{2}-\\d{4}", flags: "g" },
replacement: "XXX-XX-XXXX"
}
{
pattern: {
regex: '<span class="spanDataAccount">.*?<\/span>',
flags: 'g'
},
replacement: '<span class="spanDataAccount">XXX-PCI-DATA-XXX<\/span>',
screenview: '/services/area/personal-banking'
},
In some scenarios it can be useful to introduce a JavaScript function for the replacement: object as shown in the example below. This is not an ideal scenario but where complex HTML or coding practices inhibit ease of pattern matching and selection, it is an option available.
{
pattern: {
regex: '<int-dropdown[^>]*?[\\s\\S]*?<\\/int-dropdown>',
flags: 'g'
},
replacement: function(fullMatch) {
function getHTMLText(node) {
var nodeType, htmlText = null;
if (node) {
nodeType = node.nodeType || -1;
switch (nodeType) {
case 11:
// DOCUMENT_FRAGMENT
htmlText = node.innerHTML;
break;
case 9:
// DOCUMENT_NODE
htmlText = node.documentElement ? node.documentElement.outerHTML : "";
break;
case 1:
// ELEMENT_NODE
htmlText = node.outerHTML;
break;
default:
htmlText = null;
break;
}
}
return htmlText;
}
var retVal, newElem = document.createElement('div'), spanblock, liblock;
fullMatch = fullMatch.replaceAll(/\\x3C/g, '<').replaceAll(/\\x3E/g, '>').replaceAll(/\\x22/g, '"');
newElem.innerHTML = fullMatch;
// Add ınt-dropdown name attrıbute ınto the below lıne .match
if (newElem.querySelector('int-dropdown').getAttribute('name').match(/drpTanimliEvAdres|drpEMail|drpIl|drpIlce|drpTanimliEvTelefonu|drpTanimliIsAdres|drpIsyeriIl|drpIsyeriIlce/)) {
spanblock = newElem.querySelector('span[id="select2--container"]');
spanblock.innerText = 'XXX-PCI-DATA-XXX'
if (newElem.querySelector('li')) {
liblock = newElem.querySelectorAll('li');
liblock.forEach(function(liItem) {
liItem.innerText = 'XXX-PCI-DATA-XXX';
});
}
;
}
;retVal = getHTMLText(newElem.firstChild);
return retVal;
},
screenview: '/account/profile/cards'
}