I’ve been asked a couple of times about confidentiality and the content of traces, including ETW traces through the .NET 4.5 EventSource (including a comment in this post on using Event attribute parameters).
The problem is that trace information is unlikely to get the same level of security protection as the database or other information sources. If you’re rolling your own tracing, consider whether it’s worth effort to ensure the trace remains forever confidential. It’s much easier to just keep the confidential information out.
If you’re using ETW, there are some considerations within the Windows design for some security limitations. This is documented to include the capacity to block registration of certain provider Guids to authorized users, and to limit the providers writing to certain provider Guids.
I would love someone to jump up and tell me that I’m wrong and post a link to a clear discussion of providing a secure ETW trace. But as far as I can tell, the designers of ETW considered it, and it’s not currently raised to any level of usability.
Registering an ETW manifest on a machine requires admin privileges. Turning on an ETW trace requires admin privileges. So, it’s not like any yahoo can create traces. Just admin privileged yahoos.
So, if you live in a land where all confidential information is available to your IT staff with admin privileges on your servers, then perhaps you can put confidential information into traces.
But this also means you have to keep track of and destroy all the trace files that might ever be created.
I think that’s too high a bar and you need to keep confidential information out of your traces – regardless of the tools you use to create them.