Information Privacy
You can configure AppResponse 11 to prevent private data in observed web traffic—URLs, cookies, POST data—from being saved in the metric database or displayed in the user interface. Examples of private data include passwords, personal identification such as Social Security numbers, and other internal information.
This section discusses the following:
Information Privacy Definition Settings
Setting | Notes |
Key | The [key] string in the [key]=[value] pairs that contain the private information to exclude. For information about how to find the key string, see
Information Privacy Definition Settings. |
Description | |
Status | If the definition is not enabled, private information for the specified key will not be hidden. |
IP Addresses Ports URLs | To reduce unnecessary load on the appliance, it is good practice to apply the privacy definition only to server IP addresses and ports for the web application of interest. For information about how to find this information, see
Information Privacy Definition Settings. |
Important Notes and Warnings about Information Privacy and WTA
Note the following:
◼ WARNING—This functionality does not hide private data after it has been observed by the appliance. For this reason, you must specify the private data to mask out before you enable web page analysis or SSL decoding.
◼ WARNING—This Information Privacy functionality applies to Web Transaction Analysis data only. You cannot use this functionality to hide sensitive information in packet data captured over unencrypted connections.
If you want to use Web Transaction Analysis and capture packets but cannot do both over an encrypted connection, Riverbed recommends that you configure the appliance using one of the following methods:
Capture in "headers-only" mode, as described in XREF.
Set the Packet Size Limit to no higher than 128, as described in XREF.
◼ AppResponse 11 assumes that private data fields are embedded in the web traffic as key-value pairs separated by the ‘=’ character (for example, username=jsmith and sessionID=1131).
If a web application uses different conventions for transferring values, you must define the keys using regular expressions as described in Defining Keys Using Regular Expressions. Note that to use this method, you must have a working knowledge of regular expressions and the exact data formats used by the web application of interest.
Task: Define Private Information to Filter from WTA Data
The following items describe the general workflow:
1. For each web application of interest, create a list of HTTP parameter fields that contain private data you want to mask out. Examples of private data include
– Passwords
– Social Security numbers
– External usernames
Note—The best source for obtaining this information is from the web developers or other staff who develop, maintain, and/or troubleshoot the web application directly. If this is not an option for you, the following steps provide additional guidelines for obtaining this information on your own.
2. If you cannot obtain the data key, server, and URL information from someone in your organization, use tcpdump, Wireshark, or another program to capture one or more page views that contain at least one instance of each data field that you want to mask out.
Capture the web traffic as follows:
– Go to the login page for the web application.
– Start the capture.
– Log in as a user who can enter and submit the data fields you want to mask out (password, Social Security number, and so on).
– Wait until the "login-succeeded" page downloads completely.
– Navigate to a web page that prompts you for the data field(s) of interest.
Note—Pages such as “Update Profile” or “New Profile” are likely candidates for entering and submitting this type of information.
– When prompted, specify the requested information. If necessary, write down the values that you specify so you can search for these values in the trace.
– Submit the information to the web server (for example, by clicking OK or Submit).
– Stop the capture.
– Open the resulting trace file in Wireshark or in the Trace Explorer window of Transaction Analyzer.
3. Go to Administration > Web Transaction Analysis: Information Privacy.
4. Click Add to create a new Information Privacy definition.
5. Specify the Key, IP Address(es), Port(s), and URL(s) in which the private information will be found.
Note—The best source for obtaining this information is from the web developers or other staff who develop, maintain, and/or troubleshoot the web application directly. If this is not an option for you, the following sections describe how to find this information if the trace file you created in step 2.
Key
Using the Find Packets operation in Wireshark or Transaction Analyzer, search for packets that contain the [value] string that you submitted for the data field of interest (password, Social Security number, etc.). Make sure that you search the text/string/ASCII data rather than the binary/HEX data.
Finding Packets with a Social Security Number (Example) 
For each packet that contains the [value] string, parse the HTTP contents of that packet to locate the corresponding [key]string. This best places to look are in the POST data (most likely) or the URL parameter of a GET request (less likely, but possible).
Servers > Ports
Servers > IP Addresses
Examine the POST message for the web page that contains the [key]=[value] string of interest.
– The port number is in the TCP header > destination port.
– The IP address is in the IP header > destination IP.
Server Port and IP address in POST Message
Note—If the web application uses multiple servers, you might need to specify multiple server ports/IP addresses.
URLs
When you specify the host and path, your goal is to enter one or more regular expressions that match all page views that might include the specific [key]=[value] string. The following are some example hostnames/paths:
inet.acme.com and */*profile* (“Any page view whose URL includes the host string inet.acme.com and a path with the parameter string profile”)
myprofile.acme.com and * (“Any page view whose URL includes the host string myprofile.acme.com”)
www.webstore.com and /purchase/* (“Any page view whose URL includes the host string www.webstore.com and a parameter string that starts with /purchase/”)
6. Repeat
Step 4 and
Step 5 for each additional parameter you want to mask out.
7. Review all your entries in the Information Privacy definitions, then click Apply or OK.
Note—AppResponse does not mask out private data after it is stored on an appliance. For this reason, it is good practice to review all Information Privacy profiles for all private key strings before you enable Web Transaction Analysis or SSL decoding.
8. If the data fields you want to mask out are included in URLs, you can use the following steps to verify that the Information Privacy profile you specified works as intended:
– Go to the Administration > System > Pages web page and enable (turn on) the “Enable Page Analysis” option.
– Go to the login page of the web application and log in (if you are already logged in, log out and then log back in).
– Repeat the web session you performed in
Step 2 to generate the trace file.
– Go back to Administration > System > Pages and disable (turn off) the “Enable Page Analysis” option.
– Set the project time to focus on the web session you just performed.
– Open the Individual Page Views insight (Insights > Page Analysis > Individual Page Views).
– Select the Top Page Analysis Groups tab and select Web Application in the pull-down menu (top left).
– In the Group table (top left), select the web application you are verifying.
The Top Individual Page Views table (bottom) shows the top page views for the web application.
– In the Top Individual Page Views table, resize the Individual Page column so that you can see the entire URL. The sensitive parameter strings should appear masked.
9. If the parameter values of interest appear unmasked in the URLs, repeat step 2. through step 9. until you get the results you expect.
Defining Keys Using Regular Expressions
AppResponse can automatically find keys that are encoded in the application/x-www-form-urlencoded format: key=value pairs separated by ampersands—for example, key1=value1&key2=value2.
If a web application uses a different encoding format, you can enter regular expressions to find the username, session ID, and other keys. This requires the following:
◼ A working knowledge of regular expressions
◼ A knowledge of the exact key-encoding format used by the application you want to monitor. Information about non-urlencoded formats is outside the scope of AppResponse documentation.
You can specify regular expressions in the following fields only:
◼ Administration > Web Transaction Analysis: Information Privacy .> Key
◼ Administration > Web Transaction Analysis: User Session Tracking > Name of User Key field
◼ Administration > Web Transaction Analysis: User Session Tracking > Name of Session Key field
Required Format
To find a non-urlencoded key, you must enter a regular expression in the following format:
1. [regex] - This tag tells the appliance that you are defining a regular expression rather than a key string.
2. A regular expression that tells the appliance how to find the matching string
3. A parenthesized expression that tells the appliance how to find the key within the matching string
For example, suppose a web app defines usernames in the format
username:jsmith,password:XXXXXXX
In this case, you would do the following:
1. Go to Administration > Web Transaction Analysis: User Session Tracking > User Session Tracking.
2. In the Name of User Key field, enter [regex]username:([^,]*)
This says: find the string username:[all-chars-until-the-next-comma]
The appliance finds the matching string: username:jsmith
The appliance uses the parenthesized expression ([^,]*) to find the username: jsmith