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?
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 email@example.com or firstname.lastname@example.org see if you can find a solution together with Dynatrace to alter the settings.
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.
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):