When you have a service running somewhere you need to find out whether it is functioning correctly. Besides the possible tests, liveness checks, metrics, you can use application logging. But what makes an application log “Good”? In this blog we discuss 6 pointers on application logging to help you on your way!
1. Purpose is everything!
Purpose case: logging for application maintenance
- Do you want to inform people about certain steps which are executed by the application?
- Which exceptions or errors in your application are actually worth logging in terms of faulty code paths? Does informing about them lead to better maintenance and/or business value?
- When is a certain state of the application worth waking up the standby for? There are various ways how you can resolve this. One of them is: use the difference between error level logging and warning level logging. error level would mean: get into action now, warning level could mean: when you are ready, pick it up. Many exceptions and errors that your code throws might not be worth picking up, and should not be logged as error or warning.
Purpose case: Audit Logs
Purpose case: Security Event Logs
2. Secrets in Logging
3. Sensitive Data in Logging
- Financial, Health & Business information which should not be shared publicly
- Personal Identifiable Information as defined by the GDPR or other applicable laws and regulations.
- Application source code
- Any other type of information which is deemed too sensitive based on the underlying threatmodel.
4. Logging and Security
- Never trust external input. Never just insert raw data into your logs. Instead make sure that you only record data from trusted zones. Next: make sure you do proper encoding & data sanitization. WebGoat contains a nice challenge which shows what happens if you do not clean your data properly.
- Harden your setup. The recent events with Log4J show that we should ensure that our logging infrastructure is patched, hardened, and monitored.
- Protect integrity of your logs: Integrity of data becomes all the more relevant when the logs need to show what has happened. Audit-logs, transaction-logs, and such often need to be protected by either having signed/HMACed messages or using a WORM(Write Once, Read Many) storage solution.
- Protect the data. Logs should be protected at least as the same level as the data the process is dealing with. This means that you need to setup access management for logs, encrypt them at rest, et cetera.
5. Stacktraces and Logging
Stacktraces require special attention. When stacktraces encompass business objects in their descriptions, they can leak information which we just listed not to log. Therefore, always be careful with what you put in the context of an exception. Make sure that either your business objects, or your logging & exception handling configuration ensures that confidential information is cleared out during a stacktrace.
6. Actionable Logs(with context)
Where to Go Next?
- What information is needed for higher level business goals?
- Which sources should you include to provide context to your logs? Think about the logs coming from your host-machines, cloud infrastructure, etc..
- Where do you store the logs over time?
- WebGoat 8: https://github.com/WebGoat/WebGoat
- OWASP cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Log4J: https://xebia.com/log4j-a-10-step-mitigation-plan/
- Wrongsecrets: https://github.com/commjoen/wrongsecrets