Preventing Collection of Private Data
Hi,
I am trying to figure out if we can prevent the collection of private user data with Dynatrace?
Normally, privacy concerns are easily dealt with using the confidential string options, but in this particular case our app team is requesting that confidential user data simply not be collected.
We are planning to monitor customer facing applications that deal with processes such as: user login.
Any ideas are greatly appreciated.
Hi Jason,
I guess the answer depends on what you consider to be confidential data. The easy answer for much of this is to just not collect it. For example, don't collect any method arguments that contain confidential data. Don't collect any servlet parameter data, or SQL bind variables, or exception stack information, or whatever. But there is other stuff such as host names, and IP addresses, that are not configurable. Do you consider that to be confidential? What sorts of things are we talking about?
Rob
Hi Rob,
I have been told that both host names and IP addresses are being considered confidential in this case. Which is part of the problem I am having filling this request.
I think you're talking "RFE" then. There is no provision for masking things like server/host names and things like that.
Jason, I support Rob's suggestion of an RFE to block host/IP data if that's really what's needed, however I propose to you that this really is the wrong approach from your companys perspective. Don't you love vendors telling you how to run your business.. :)
Seriously, If things such as host/IP is sensitive, then you're be better off protecting the collected data and simply treating it as sensitive, rather than trying to remove this level of information from your APM data. At some point the APM data becomes so stripped of 'sensitive data' that it's lost it's value to the organization. We deal with many financial and other sensitive data institutions and we find the initial response and requests are many times unnecessarily restrictive. Perhaps with a bit of a nudge your organization can actually accept things being collected that may appear sensitive and keep the APM data rich and useful to the organization, either by redefining sensitive or simply defining processes to protect the APM data appropriately to the requirement. Respectfully, Joe Hoffman
Hi Jason,
As usual, Joe offers some great advice. If you pull all of that data out, how do you make any sort of reasonable analysis of your situation?
The reason I asked specifically about host and IP is that I've worked in classified environments where that info is, in fact, classified, so I'm sure that your organization's needs go far beyond just those things. But we didn't stop collecting it - we did what Joe suggested and implemented secure access to the data. Stepping back from responding to your request, and thinking more about what is useful, I think that Joe has the best response, and it's worked for me in the past. If you sanitize your data that much, it becomes less and less useful.
Rob
You say the confidentiality is around clients correct? so you are trying to scrub your client's IPs? There's a setting for that. Edit System Profile -> Data Privacy -> Enable IP address masking
Hey Jason,
AppMon won't specifically know what is considered private if it's not an OOB confidential string. I'd say the best practice to avoid collection of that data is to keep configuration light.
We can capture sensitive data from grabbing request parameters, headers, or queries. We can capture sensitive data from method arguments in certain methods, like a login(string username, string password). BUT, OOB, servlets/web requests/jsps won't give you confidential information unless it's passed in the URI (I hope you don't face that). Also, methods are only going to capture that data if you're explicitly capturing the arguments. So, generally you're fine to assume there won't be sensitive info.
Otherwise, you may see sensitive data in a query string. That's not a best practice from a DB perspective but it could happen. Just watch out for that.
Hope this helps!
Thanks Brett. I initially pitched a similar idea, in that we should just not collect data on whatever methods are collecting the confidential information. However, I was told some of this confidential information would likely appear downstream in the URI.
