Filter Sensitive Data

By default, the AppDynamics Java Agent sends transaction data to the Controller that your organization may classify as privileged information. Although such data is useful for diagnosis and troubleshooting, security considerations may require you to filter certain information from view in the Controller. You can use:

• Sensitive data filters to exclude environment variables, system property, and JMX data.
• Sensitive URL filters to exclude sensitive information from a URL in snapshot details. 
• Sensitive message filters to exclude sensitive data that the application may place in log messages or exception detail messages.

Default Sensitive Data Filters

When you enable a sensitive data filter, the Controller displays asterisks for the values of matching environment variables or system properties. By default, the Java Agent enables two sensitive data filters in the app-agent-config.xml:

• Environment variables or system properties that contain the case insensitive substring "password".
• Environment variables or system properties that contain the case insensitive substring "key".

<sensitive-data-filters>
        <sensitive-data-filter applies-to="environment-variables,system-properties"
                               match-type="CONTAINS"
                               match-pattern="password"/>
 
        <sensitive-data-filter applies-to="environment-variables,system-properties"
                               match-type="CONTAINS"
                               match-pattern="key"/>
</sensitive-data-filters>

Add a Sensitive Data Filter

1. Edit a versioned app-agent-config.xml file: <agent_home>/<version_number>/conf/app-agent-config.xml.
2. Add a sensitive data filter element as a child of the Sensitive Data Filters element using one of these attributes.

   • Specify a comma-separated list in the applies-to attribute to filter:

     environment-variables

     system-properties

     jmx-mbeans 

   • Set the match-type attribute as:

     EQUALS

     CONTAINS

     STARTSWITH

     ENDSWITH

   • Specify a string to match for the match-pattern attribute. String matches are case insensitive. The pattern matches against the environment variable and system property names, not values.

3. Restart the JVM.

In this example, the Java Agent checks for system properties and environment variables beginning with the string "DB_". The Controller displays the values of matching environment variables and system properties as asterisks. For instance, an environment variable "DB_USER" is replaced with an asterisk.

<sensitive-data-filter applies-to="environment-variables,system-properties"
                                    match-type="STARTSWITH"
                                    match-pattern="DB_"/>

Add a Sensitive URL Filter

You can use sensitive URL filters to configure the agent to obfuscate sensitive information from the URLs in transaction snapshot details.

1. Edit a versioned app-agent-config.xml file: <agent_home>/<version_number>/conf/app-agent-config.xml.

2. Add a sensitive URL filter element as a child of the sensitive URL filters element:

   <sensitive-url-filter delimiter=""
      segment="" match-filter=“EQUALS|INLIST|STARTSWITH|ENDSWITH|CONTAINS|REGEX|NOT_EMPTY"
      match-pattern="pattern"
      param-pattern=""/>

   CODE

   • delimiter: Specify the character that you want to use as URL segment endpoints. The agent splices the URL at each delimiter instance to create the segments. For HTTP, use the forward slash character "/". In the case of a forward slash, the agent does not split on the slashes immediately following the protocol. For example, "https://myapp.example.com/" constitutes a single segment. By default, the delimiter is "/".

   • segment: Specify a comma-separated list to indicate the segments that you want the agent to filter. Segment numbering starts from 1. 

   • match-pattern: Specify the string that you want to be filtered by the match-filter.

   • param-pattern: Specify the regular expression matching the query parameters to filter.

For example, the following configuration splits the URL on the "/" character and masks the second segment and the param-pattern in the third segment of the URL. In this case, the segmentation and obfuscation apply only to URLs containing "myapp".

<sensitive-url-filters>
<sensitive-url-filter delimiter="/"
 segment="2"
 match-filter="CONTAINS”
 match-pattern="myapp"
 param-pattern="[a-z]+_name"/>
</sensitive-url-filters>

The exit call to https://myapp.example.com/sensitive/data?first_name=abc&last_name=xyz breaks down to three segments: "https://myapp.example.com/", "sensitive", and "data?first_name=abc&last_name=xyz". The Controller shows the masked values of the URL and the param-pattern display https://myapp.example.com/*****/data?first_name=***&last_name=*** in the snapshot details.

Add a Sensitive Message Filter

You can use sensitive message filters to configure the agent to obfuscate sensitive information contained within text messages collected by the agent from log messages, or detail messages from exceptions. 

1. Edit a versioned app-agent-config.xml file: <agent_home>/<version_number>/conf/app-agent-config.xml.

2. Add a sensitive message filter element as a child of the sensitive message filters element:

<sensitive-message-filter message-type="throwable,logger-message,all"
                                  match-type="EQUALS|CONTAINS|STARTSWITH|ENDSWITH|REGEX"
                                  match-pattern="CASESENSITIVE_PATTERN"
                                  redaction-regex="SENSITIVE_INFO_REGEX_GROUP"/>

• message-type specify throwable, logger-message or all

• match-type specify the type of match that should be used to opt-in messages for redaction

• match-pattern specify the pattern that, when matched, opts the message in for redaction

• redaction-regex specify a regular expression identifying data that should be redacted from the opted-in messages

For example, if an application logs SQL queries including secret numeric values, the following configuration would remove all the numeric data from the logged messages:

<sensitive-message-filter message-type="logger-message"	
                                  match-type="CONTAINS"
                                  match-pattern="SELECT"
                                  redaction-regex="[0-9]+"/>

Resulting in – 

"SELECT name from customer WHERE customer.id = 773"

Being collected as – 

"SELECT name from customer WHERE customer.id = *****"