This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 LoggingCode

From OWASP
Revision as of 16:57, 28 September 2014 by Gary David Robinson (talk | contribs) (Created page with "Description: Application logging should be consistent within the application, consistent across an organization's application portfolio and use industry standards where relev...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Description:

Application logging should be consistent within the application, consistent across an organization's application portfolio and use industry standards where relevant, so the logged event data can be consumed, correlated, analyzed and managed by a wide variety of systems.

The application has the most information about the user (e.g. identity, roles, permissions) and the context of the event (target, action, outcomes), and often this data is not available to either infrastructure devices, or even closely-related applications.

Consider how the source (log) can be verified, and how integrity and non-repudiation can be enforced.

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. All types of applications may send event data to remote systems - this could be a centralized log collection and management system (e.g. SIEM or SEM) or another application elsewhere.

The level and content of security monitoring, alerting and reporting needs to be set during the requirements and design stage of projects, and should be proportionate to the information security risks

Log data, temporary debug logs, and backups/copies/extractions, must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time. Legal, regulatory and contractual obligations may impact on these periods.


Review Points:

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 For file-based logs, apply strict permissions concerning which users can access the directories, and the permissions of files within the directories 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 Input validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and values Output validation failures e.g. database record set mismatch, invalid data encoding Authentication successes and failures Authorization (access control) failures Session management failures e.g. cookie session identification value modification Connection timings External classifications e.g. NIST Security Content Automation Protocol (SCAP), Mitre Common Attack Pattern Enumeration and Classification (CAPEC) Perform sanitization on all event data to prevent log injection attacks e.g. carriage return (CR), line feed (LF) and delimiter characters (and optionally to remove sensitive data) If writing to databases, read, understand and apply the SQL injection cheat sheet Ensure logging is implemented and enabled during application security, fuzz, penetration and performance testing Ensure logging cannot be used to deplete system resources, for example by filling up disk space or exceeding database transaction log space, leading to denial of service The logging mechanisms and collected event data must be protected from mis-use such as tampering in transit, and unauthorized access, modification and deletion once stored Store or copy log data to read-only media as soon as possible

Don't log • Session identification values (consider replacing with a hashed value if needed to track session specific events) • Sensitive personal data and some forms of personally identifiable information (PII) • Authentication passwords (successful or unsuccessful) • Database connection strings • Keys • Data of a higher security classification than the logging system is allowed to store


Reference: See NIST SP 800-92 Guide to Computer Security Log Management for more guidance. Mitre Common Event Expression (CEE) PCISSC PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4

Other Common Log File System (CLFS), Microsoft