Implement Logging and Intrusion Detection

Application logging should not be an afterthought or limited to debugging and troubleshooting. Logging is also used in other important activities:

  • Application monitoring
  • Business analytics and insight
  • Activity auditing and compliance monitoring
  • System intrusion detection
  • Forensics

To make correlation and analysis easier, follow a common logging approach within the system and across systems where possible, using an extensible logging framework like SLF4J with Logback or Apache Log4j2, to ensure that all log entries are consistent.

Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different. For example a PCI DSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions.

It is important not to log too much, or too little. Make sure to always log the time stamp and identifying information like the source IP and user-id, but be careful not to log private or confidential data or opt-out data or secrets. Use knowledge of the intended purposes to guide what, when and how much to log. To protect from Log Injection aka Log Forging, make sure to perform encoding on untrusted data before logging it.

The OWASP AppSensor Project explains how to implement intrusion detection and automated response into an existing application: where to add sensors or detection points and what response actions to take when a security exception is encountered in your application.

Reference: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Top_Ten_Proactive_Controls