Logging Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:17:02Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T13:03:03Z

Migration to GitHub

Show changes

Peter Mosmans: Remove Common Event Expression (CEE) as MITRE has stopped all work on CEE in 2014

2018-05-22T21:48:31Z

Remove Common Event Expression (CEE) as MITRE has stopped all work on CEE in 2014

Tony Hsu HsiangChih: /* Related articles */

2017-10-20T07:27:21Z

‎Related articles

Jmanico: /* Other Cheatsheets */

2017-09-11T06:08:54Z

‎Other Cheatsheets

Clerkendweller: /* Purpose */ Added anti-automation as example

2016-01-20T14:57:43Z

‎Purpose: Added anti-automation as example

Clerkendweller: /* Data to exclude */ Added examples

2016-01-20T14:56:22Z

‎Data to exclude: Added examples

Clerkendweller: /* Purpose */ Added mention of non-repudiation

2016-01-20T14:54:26Z

‎Purpose: Added mention of non-repudiation

Jmanico: moving nav to bottom for mobile friendliness

2015-07-18T23:12:27Z

moving nav to bottom for mobile friendliness

Clerkendweller: Small updates

2015-05-19T12:48:53Z

Small updates

← Older revision		Revision as of 14:17, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Logging_Cheat_Sheet.md Logging Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html Logging Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 67: / Line 67: @@
 ** In web applications, the logs should not be exposed in web-accessible locations, and if done so, should have restricted access and be configured with a plain text MIME type (not HTML)
 * When using a database, it is preferable to utilize a separate database account that is only used for writing log data and which has very restrictive database , table, function and command permissions
-* Use standard formats over secure protocols to record and send event data, or log files, to other systems e.g. Common Log File System (CLFS), Common Event Format (CEF) over syslog, possibly Common Event Expression (CEE) in future; standard formats facilitate integration with centralised logging services
+* Use standard formats over secure protocols to record and send event data, or log files, to other systems e.g. Common Log File System (CLFS) or Common Event Format (CEF) over syslog; standard formats facilitate integration with centralised logging services
 Consider separate files/tables for extended event information such as error stack traces or a record of HTTP request and response headers and bodies.
@@ Line 268: / Line 268: @@
 IETF [http://tools.ietf.org/html/rfc5424 syslog protocol]
-Mitre [http://cee.mitre.org/ Common Event Expression (CEE)]
+Mitre [http://cee.mitre.org/ Common Event Expression (CEE)] (as of 2014 no longer actively developed)
 NIST [http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf SP 800-92 Guide to Computer Security Log Management]

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 = Introduction  =
@@ Line 281: / Line 281: @@
 Other [http://www.arcsight.com/solutions/solutions-cef/ Common Event Format (CEF), Arcsight]
 Other [http://www.clerkendweller.com/2010/8/17/Application-Security-Logging Application Security Logging, Colin Watson, Web Security Usability and Design Blog]
@@ Line 293: / Line 295: @@
 Most of the information included is based on content in the articles referenced in the text and listed above, but the following people have provided their ideas, knowledge and practical experience:
-Colin Watson - colin.watson[at]owasp.org<br/>
+Colin Watson - colin.watson[at]owasp.org<br />
-Eoin Keary - eoin.keary[at]owasp.org<br/>
+Eoin Keary - eoin.keary[at]owasp.org<br />
 Alexis Fitzgerald - alexis.fitzgerald[at]owasp.org

@@ Line 297: / Line 297: @@
 Alexis Fitzgerald - alexis.fitzgerald[at]owasp.org
-== Other Cheatsheets ==
+= Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}

@@ Line 28: / Line 28: @@
 * Security events
 * Business process monitoring e.g. sales process abandonment, transactions, connections
 * Audit trails e.g. data addition, modification and deletion, data exports
 * Performance monitoring e.g. data load time, page timeouts

@@ Line 154: / Line 154: @@
 * Authentication passwords
 * Database connection strings
-* Encryption keys
+* Encryption keys and other master secrets
 * Bank account or payment card holder data
 * Data of a higher security classification than the logging system is allowed to store
 * Commercially-sensitive information
-* Information it is illegal to collect in the relevant jurisdiction
+* Information it is illegal to collect in the relevant jurisdictions
 * Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired

@@ Line 19: / Line 19: @@
 * Monitoring policy violations
 * Establishing baselines
 * Providing information about problems and unusual conditions
 * Contributing additional application-specific data for incident investigation which is lacking in other log sources
@@ Line 35: / Line 36: @@
 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 PCIDSS 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. Use knowledge of the intended purposes to guide what, when and how much. The remainder of this cheat sheet primarily discusses security event logging.
 = Design, implementation and testing =

@@ Line 46: / Line 46: @@
 * Client software e.g. actions on desktop software and mobile devices in local logs or using messaging technologies,  JavaScript exception handler via Ajax, web browser such as using Content Security Policy (CSP) reporting mechanism
 * Network firewalls
 * Network and host intrusion detection systems (NIDS and HIDS)
@@ Line 59: / Line 60: @@
 == Where to record event data ==
-Applications commonly write event log data to the file system or a database (SQL or NoSQL). Applications installed on desktops and on mobile devices may use local storage and local databases. Your selected framework may limit the available choices. All types of applications may send event data to remote systems (instead of or as well as more local storage). This could be a centralized log collection and management system (e.g. SIEM or SEM) or another application elsewhere. Consider whether the application can simply send its event stream, unbuffered, to stdout, for management by the execution environment.
+Applications commonly write event log data to the file system or a database (SQL or NoSQL). Applications installed on desktops and on mobile devices may use local storage and local databases, as well as sending data to remote storage. Your selected framework may limit the available choices. All types of applications may send event data to remote systems (instead of or as well as more local storage). This could be a centralized log collection and management system (e.g. SIEM or SEM) or another application elsewhere. Consider whether the application can simply send its event stream, unbuffered, to stdout, for management by the execution environment.
 * When using the file system, it is preferable to use a separate partition than those used by the operating system, other application files and user generated content
@@ Line 150: / Line 151: @@
 * Session identification values (consider replacing with a hashed value if needed to track session specific events)
 * Access tokens
-* Sensitive personal data and some forms of personally identifiable information (PII)
+* Sensitive personal data and some forms of personally identifiable information (PII) e.g. health, government identifiers, vulnerable people
 * Authentication passwords
 * Database connection strings
@@ Line 166: / Line 167: @@
 * Internal network names and addresses
 * Non sensitive personal data (e.g. personal names, telephone numbers, email addresses)
 In some systems, sanitization can be undertaken post log collection, and prior to log display.