Is an application backend expected to potentially log sensitive customer data when in debug mode?

Question

As I am working on a website that asks customers to enter data such as their name, address, phone number, obviously customer data that needs to be protected.

I do my best to not log such data (although I have two levels of logs: normal and secure, and would use the secure log area for such), I am wondering whether an application is expected to still not log customer data when in debug or trace mode. All those logs happen on the server side. The client has no control over it.

In my current implementation, the normal release mode would not do so in INFO, WARNING, or ERROR log levels, but the DEBUG/TRACE levels might leak some of that information to the logs. Is that expected behavior in most website servers? Or should we attempt to limit such leaks even when in DEBUG, TRACE mode? (note that our C++ application is compiled in release mode, the "DEBUG" in this case references the log level and not whether some debug code is still in the software.)

Note that the application can be logging the data on another computer or even a third party system so security wise access to the logs is independent of access to the website server application or the database where, obviously, the data lays for sure. However, I can imagine some people having lower security requirements on their log computers than the computers with the database...

Answer 1

This is a great question! I'm also a developer on a c++ product that handles high sensitivity data, and we face this dilemma almost every day.

When a production system starts throwing alarms (especially performance or configuration-related ones, thought misbehaving software / bug ones also apply) we often need stack-trace level debugging turned on temporarily in order to diagnose the problem. These logs inevitably contain sensitive information: IP addresses or users involved in the transaction, sometimes pieces of the data, you name it. Often our customers don't feel comfortable giving us these logs for obvious reasons. It's tough.

The administrators actually running your server will know what level of sensitivity their data is, and what government or industry security policies they have to follow when handling it (for example: government, financial, and health data all have special rules). It's fair that your software has the ability to produce sensitive logs, but the admins need to be fully in control of how, when, and where they get produced and stored.

Some things you can do:

• Make sure you are very careful to correctly categorize all error messages containing (even potentially) sensitive information into the correct log level - INFO, WARNING, ERROR, DEBUG, TRACE, etc.
• Be explicit in your documentation about kinds of sensitive information is included in each log level. The more detail the better so the security-minded admins can do their jobs properly.
• Make sure DEBUG/TRACE log level is off in the software's default configuration, and that the admin has to run a gambit of warnings to turn it on (ie it's not possible to do by accident).
• You could send DEBUG/TRACE level logs to a separate log stream (you mentioned a separate "secure" log) that defaults to local storage, making it harder to "accidentally" ship it outside the secure zone, or get it mixed in with the standard logs.
• Ship your product with a redaction tool that knows how to mask all raw data, usernames, IP addresses, etc from your DEBUG/TRACE logs with unique placeholders (each unique username / IP gets masked by a unique A, B, .., AA, etc). Often the actual username / IP / data is irrelevant, but the key to diagnosing the problem is that the error only happens with data of type X, or that IP address A (and only A) always always sends its requests three times, or whatever. This way an admin can be confident that nothing sensitive is leaking if they ever ever need to move these logs out of the secure zone (for example sending them back to you for debugging).

Bottom line: I think it's fair that your software has the ability to log sensitive information for debugging purposes - and you'll thank yourself later when you have to debug a malfunctioning prod system! But make it as difficult as possible to turn on "by accident". Trust the admins to know their security requirements, and make their jobs easy.

Answer 2

I've been working as a penetration tester since the late 90's and have seen a lot of applications. It is not uncommon that once in a while an application logs user-identifying data. Most developers declare people having access to the logs as trusted and therefore don't limit the logging.

If this might be an issue depends on the business case and the desired security level. In my professional opinion logging passwords is never allowed. You might log the first character and the length if necessary. But nothing more. Otherwise you compromise the desire of encrypting passwords in motion and during resting.

In high-security environments this might even apply to other data like usernames, names, addresses, bank account numbers, etc.