Skip to main content

Data privacy

Data privacy

Passive capture privacy

After data is passed to the Tealeaf system, the first place in which data can be cleansed is on the Tealeaf Passive Capture Application (PCA) server.

Cleansing data at the PCA server is known as passive capture privacy.

The PCA server is the optimal place for blocking internal employee access to customer-sensitive information.

Types of personal information that you might want to block at the PCA server include:
  • Visitor account number
  • Social Security numbers
  • Credit card information

In addition to preventing access to customer-sensitive information, you can use PCA privacy management tools enable to encrypt customer-sensitive data, which can then be decrypted at a later time in the process. Blocking or encrypting data on the PCA using privacy rules ensures that the rest of the Acou (Tealeaf) system does not ever have plain-text access to customer-sensitive data that belongs to visitors of your web site.

How to decide if implementing privacy on the PCA server is the right thing to do

Implement PCA privacy if you want to:

  • Block private data
  • Encrypt private data that must recalled later
  • Drop traffic that does not need to be captured
  • Drop the response or "body" of unnecessary hits
Note: By default, the PCA is configured to sanitize all user input data from form fields for security purposes. If needed, you can disable this setting with the PCA Web Console and manage data privacy for fields on an individual field basis. This sanitization is managed through the TextBlockURLFields action configured by default in Rule 1.

Performance implications of PCA privacy

Because the PCA processes each hit in real-time, consider limiting privacy processing as much as possible. If the PCA is burdened with many privacy rules, then it may not be able to handle the traffic in real-time, which might result in dropped or missing hits. As you configure your privacy management rules for the PCA, you should move privacy processing that is not required to the downstream Tealeaf Privacy session agent in the Windows pipeline.
Note: At this time, the PCA does not support multithreaded privacy. Privacy actions can only utilize a single core. Running the PCA Privacy on a multi-CPU system does not alleviate processing load problems presented by excessive privacy actions.

Through the PCA Web Console, you can configure privacy rules to find beginning and ending text patterns, between which the text can be blocked. Privacy also enables regular expression pattern matching, so complicated text patterns can be applied. Using regular expressions is expensive to process.

Prebuilt privacy rules

Tealeaf provides prebuilt rules that enable the blocking or encryption of data fields that have been marked in the response with the appropriate comments.

When you build your web application, you can mark content in the response with HTML comments. These comments are not visible to the user. However, Tealeaf can scan the response for them and then blocks or encrypts accordingly.

For example, suppose the HTML response from your page includes the following user-readable text: 
Your Social Security No. is 123-12-1234

This information may be necessary for the visitor to your site, yet for security reasons, it should be blocked from the data captured by Tealeaf or encrypted so that only those Tealeaf users that have been authorized can see it.

Note: To manage these operations in Tealeaf, it is a recommended practice that you bracket data to block or encrypt with a specific set of HTML comments.

Example of blocking data

To block the Social Security number data (123-12-1234) from Tealeaf, you should bracket the data in the response using the following HTML comments: 
Your Social Security No. is <!-- TLTIHB--> 123-12-1234<!-- TLTIHE-->

Tealeaf Privacy can be configured to recognize these specific tags and then to block the data between them.

It is possible to configure Tealeaf to recognize any set of bracketing comments. However, when the provided privacy rule is enabled, the above bracketing comments are automatically recognized by Tealeaf, and the data is blocked. The resulting output sent to Tealeaf is the following: 
Your Social Security No. is <!-- TLTIHB-->XXXXXXXXXXX<!-- TLTIHE-->

To enable this privacy rule, additional configuration is required.

Example of encrypting data

You can configure the HTML output to enable Tealeaf to encrypt the data. In our example above, the generated HTML might look like the following: 
Your Social Security No. is <!-TLTENB-->123-12-1234<!--TLTENE-->
For Tealeaf users who do not have the appropriate permissions to view this data, the output looks like the following: 
Your Social Security No. is <!--TLTENB-->@@@@@@@@@@@<!--TLTENE-->

To enable this privacy rule, additional configuration is required.

Enable prebuilt rules

In the privacy configuration, Tealeaf provides a number of preconfigured privacy rules, which can be modified and enabled to meet the requirements of your application

Manage multiple levels of data security

If multiple levels of encryption are required, you can add more bracketing comments, with each set representing a different security level.

For example: 
Your Social Security No. is
<!--TLTTrustStandardB--><!--TLTTrustSilverB-->
   <!--TLTTrustGoldB-->123-12-1234<!--TLTTrustGoldE--><!--TLTTrustSilverE-->
   <--TLTTrustStandardE-->
If the examples of blocking and encrypting data in the previous examples are required, then you can enable both blocking and encrypting in the response. The response data sent from your web application should be the following: 
Your Social Security No. is
<!--TLTTrustStandardB--><!--TLTTrustSilverB--123-12-1234<!--TLTTrustSilverE-->
  <!--TLTTrustStandardE-->
For each of the security levels shown above, you should create a separate user group. Taking the example above, you might create the following groups, whose privacy rules will reference the listed bracketing tags:
Table 1. Groups to create and tags to reference
Group to create Bracketing tags to reference
TealeafTrustStandard <!--TLTTrustStandardB-->...<!--TLTTrustStandardE-->
TealeafTrustSilver <!--TLTTrustSilverB-->...<!--TLTTrustSilverE-->
TealeafTrustGold <!--TLTTrustStandardB-->...<!--TLTTrustStandardE-->
In implementation, you can determine what each of these groups is permitted to see.

TealeafTrustGold example

If only the Gold group is permitted to view the social security number, the example bracketing would be the following: 
Your Social Security No. is
<!--TLTTrustGoldB-->123-12-1234<!--TLTTrustGoldE-->
In the TealeafTrustGold example, when the response was viewed by a TealeafTrustGold user, the user would see the actual social security number. For all non-TealeafTrustGold users, the number appears as several @ signs. Output: 
Your Social Security No. is
<!--TLTTrustGoldB-->@@@@@@@@@@@<!--TLTTrustGoldE-->

TealeafTrustSilver example

If only the Gold and Silver groups are permitted to see the email address, then following the example, Gold users must also be included in the Silver security group.

Example HTML: 
Your Email Address is
<!--TLTTrustSilverB-->test@example.com<!--TLTTrustSilverE-->
When the response is viewed by a Gold or Silver user, the user sees the actual email. All non-Gold or Silver users see the email address as several @ signs. Output: 
Your Email Address is
<!--TLTTrustSilverB-->@@@@@@@@@@@@@@@@<!--TLTTrustSilverE-->

Steps for enabling multiple levels of security

The following is a general approach to enabling multiple levels of data security in Tealeaf, after applying the above standards in your web application. You are likely to need to modify these steps to meet your enterprise requirements.

  1. Create Tealeaf user groups for each type of security to employ. In the above example, you might create the following groups.
    • TealeafTrustStandard
    • TealeafTrustSilver
    • TealeafTrustGold
    Note: If you are using tiered levels of security clearance, then users with the highest level of clearance must be included in all of the lower levels.
  2. Bracket all sensitive data with the appropriate HTML comments, as shown in the examples.
  3. Add Tealeaf users to the appropriate groups.
  4. Create and enable the privacy rules.
  5. Deploy Privacy rules accordingly.
    • For Tealeaf Passive Capture Application:

      You can deploy privacy rules to be applied at the point of capture, which ensures that the sensitive data is never in an unprotected state in Tealeaf. However, PCA privacy rules can impede performance of real-time processing.

    • For Windows Pipeline:

      You can deploy privacy rules in the Windows pipeline on the Processing Server(s). However, using the Privacy session agent to block or encrypt data means that the data has not been secured until it passes through the PCA and the Transport Service to the Processing Server. Tealeaf does employ application and database security methods to protect general access.

  6. Test the availability of sensitive data for one user from each privacy group.

Design privacy rules

Several types of privacy rules inherently require high CPU/time requirements and can affect PCA performance.

These types of rules include the following:

  • Rules that search the entire response of the hit
  • Rules that use regular expressions, instead of plain text to match patterns
  • Rules that use both start and end pattern regular expressions
  • Rules that encrypt data
Actions based on regular expressions are the most time/CPU intensive types of privacy actions. These rules should be avoided unless absolutely necessary.
Note: A single regular expression rule can be created, which causes the PCA to begin dropping traffic. Use them cautiously.
Some regular expressions must examine each character in the data, as well as a predefined preceding number of characters to match the pattern. The net result is the following computation for number of searches: 
# of characters in data * # of preceding characters to match

Including several rules with these types of regular expressions can raise the processing requirement for each hit to dangerously high levels. Whenever possible, use plain text to identify the start and end pattern of what you wish to block or encrypt.

In your rule configuration, you may also use the Stop Processing flag, which stops evaluating the data if you need to block only the first occurrence of the data. This flag allows privacy to stop searching after the rule has been triggered. For example, if you know that a customer's login ID is displayed only once on any page, then this flag is useful for limiting the processing required to block it. For text sequences occurring at the beginning of the response, the Stop Processing flag can make a considerable difference in processing requirements.

Test privacy

PCA privacy management also enables testing to identify and eliminate potential processing issues.

For example, if you have a single page that requires encryption of a specific text sequence, you can create a test to trigger that rule only when the page's URL appears in the URL section of the request buffer. Privacy passes on evaluating any page that does not contain the URL, resulting in a dramatic decrease in processing overhead.

The test for the request value is far less intensive than the processing of the entire response of the hit for a text sequence.

Related articles

community icon

Join the community

Ask questions, share best practices, and connect with fellow marketers.

Ask a question

Academy

Read how-to articles, guides, and more to help you on the path to success.

Learn more