URI Data Masking process?

[AMJB]

Hi

We're being asked to prove that PII, specifically URI data, is not accessible. Documentations states that masked is disabled by default and...

Dynatrace captures full URIs of requests that are sent from desktop and mobile browsers, as well as URIs of requests that are sent and received within monitored server-side processes. URIs may contain personal data, such as a user name, password, or ID.

When Mask personal data in URIs is turned on, Dynatrace detects personal data—emails, IBANs, bank card numbers, IP addresses, UUIDs, and other IDs—in URIs, query strings, headers, and exception messages and replaces this data with the <masked> string (for example, /url?country=Austria&city=Linz changes to /url?country=<masked>&city=<masked> and /account/iban('123456678890') changes to /account/iban('<masked>')). As a result, the personal data is then masked in the PurePath® analysis, error analysis, user action names for RUM, and elsewhere in Dynatrace.

Can anyone advise please where and how the masking of data takes place? Is it done on the management platform or is it done at the user end or ActiveGate? Also, is RUM data encrypted?

Many thanks.

[marina_pollehn]

Personal data captured by Dynatrace | Dynatrace Docs

This part of the documentation will probably help you the most. For each data type Dynatrace specifies here when the masking is happening. 

There is also a section on RUM.

The definitions of masked at capture, masked at storage and masked at display can be found here: Levels of data protection | Dynatrace Docs

If you need to provide proof for a specific use case, you can also email  privacy@dynatrace.com or security@dynatrace.comto see if you can find a solution together with Dynatrace to alter the settings.

[AMJB]

Hi Marina

Another question please. Dynatrace is very specific in stating what information can be masked ....

Protect personal data by not capturing it (masking at capture)
Dynatrace automatically masks certain data points at the point of capture. This happens within the application, monitored process, or browser so that the data is already replaced by a placeholder before it is sent (data in transit) to the Dynatrace cluster. Asterisks are used for such placeholders. For example, the johnsmith username is sent and stored as *********.

Literals that are part of the WHERE clause of an SQL statement
URL query parameters in exception messages
IBAN and credit card numbers

What reason for this? Can the masking be customised for other types of potential PII? Ultimately what would be ideal is that all potential PII can be masked at source and that masking can be customised.

Thanks again

Andy

[AMJB]

Hi Marina

Apologies for the slow reply. Many thanks for this information. Can you advise if masking can be configured to take place at source instead of at storage? 

All the best.

Andy

[marina_pollehn]

With at source you mean at capture, right? Masking at capture does not really have a lot of opt-in options (except for the user action setting shown in my second screenshot) for RUM. For URI's and IP's and locations there is apparently no way of doing that at capture, see app settings below:  

The reason for that I don't really know, maybe the Dynatrace employees can give an answer on that. You can also submit it as an idea in the community and see what the reactions are. 🙂

Second screenshot to mask user action data at capture (probably not sufficient for your use case):