Configuring a confidentiality policy on a Collector
To manage what private data the system obscures, deletes, or leaves unchanged, the Security role configures one or more confidentiality policies for cookies, POST parameters, URI path parameters, or URI query parameters.
Traffic elements and keys used by confidentiality policies
The system can obscure or delete private data according to policies that you configure for each of the following elements of traffic data:
Cookies
Web applications use cookies to save information about the client for later use by the server. Cookies are a convenient way to store user preferences and session-state information (for example, session ID). However, they can store such sensitive data as account numbers and logon credentials.
Note
Cookie key names are case insensitive. Cookie values, however, are case sensitive.
POST command parameters
Forms are a common feature of websites, used as means of getting information from end users to authentication engines, reservation systems, help desk and e-commerce applications. Logon credentials, credit card numbers, and so forth, are transmitted to the server by the parameters of the POST
command.
URI path and query parameters
Web applications use Unified Resource Identifiers (URIs) to identify Internet resources. Both the path and query segments of a URI can contain private or otherwise sensitive data. The following table lists example URIs with the path and query parameters:
URI examples showing path and query segments
URI type | Example |
---|---|
With path parameters | http://example.com/home;param1=value1/search;param2=value2/page.htm |
With query parameters | http://example.com/index.htm?param1=value1¶m2=value2\ |
Keys for applying policies to traffic elements
For each element, you must identify keys and specify how the system will handle the element. For example, the system can apply MD5 hashing to obscure the value associated with a given key, it can delete the value only, or it can delete the entire name-value pair. You can also instruct the system to leave the data unchanged. Refer to the following table to see how the system handles data:
Options for handling private data
Option | Result |
---|---|
Do nothing |
|
Hash |
|
Delete | |
Delete value |
|
You can use the asterisk character (*) as a wildcard for matching in any key name. For example, typing ASPsessionid*
to create a rule for cookies will match ASPsessionid2293C100
, as well as ASPsessionidAF095BFF
.
Note
POST
parameter keys are case sensitive.
For keys that are not explicitly identified, the system provides "catch-all" rules.
To configure a confidentiality policy for POST
command parameters
To configure separate rules for individual keys, use the asterisk character (*) as a wildcard in key names and change the processing order. For keys that are not explicitly identified, you can set the "catch-all" rule.
The procedure for configuring confidentiality policies is the same for all traffic elements. The following example shows how to configure a confidentiality policy for POST
command parameters.
In the Real User Collector component, point to the Administration > Security settings, and then click Confidentiality policy.
- On the Action menu for the Confidentiality for Post - Param section, click Add.
In the Key column, type creditcard, and then click Hash.
Note
If you do not know what key name corresponds with a given
POST
command parameter, click the lookup to get a list of observed values. In this example, if you open the list of observed values, it shows information about credit card and password (and possibly other key names).- In the same way, add a confidentiality policy for passports, by typing passport in the Key box.
- Click Save.
Result
The system now obscures passwords and credit card numbers.
Comments
Log in or register to comment.