V8.4 Verify that error handling logic in security controls denies access by default. Verify security logging controls provide the ability to log both success and V8.5 failure events that are identified as security-relevant. Verify that each log event includes: a timestamp from a reliable source, severity level of the event, an indication that this is a security relevant event (if mixed with other logs), the identity of the user that caused the event (if there V8.6 is a user associated with the event), the source IP address of the request associated with the event, whether the event succeeded or failed, and a description of the event. Verify that all events that include untrusted data will not execute as code in V8.7 the intended log viewing software. Verify that security logs are protected from unauthorized access and V8.8 modification. Verify that there is a single application-level logging implementation that is V8.9 used by the software. Verify that the application does not log application-specific sensitive data that assist an attacker, including user’s session identifiers and personal or V8.10 sensitive information. The length and existence of sensitive data can be logged. Verify that a log analysis tool is available which allows the analyst to search for log events based on combinations of search criteria across all fields in the log V8.11 record format supported by this system. Verify that all non-printable symbols and field separators are properly V8.13 encoded in log entries, to prevent log injection. Verify that log fields from trusted and untrusted sources are distinguishable in V8.14 log entries. Verify that logging is performed before executing the transaction. If logging was unsuccessful (e.g. disk full, insufficient permissions) the application V8.15 safe. This is for when integrity and non-repudiation are a must.
V8.4 Verify that error handling logic in security controls denies access by default. V8.5 Verify security logging controls provide the ability to log both success and failure events that are identified as security-relevant. V8.6 Verify that each log event includes: a timestamp from a reliable source, severity level of the event, an indication that this is a security relevant event (if mixed with other logs), the identity of the user that caused the event (if there is a user associated with the event), the source IP address of the request associated with the event, whether the event succeeded or failed, and a description of the event. V8.7 Verify that all events that include untrusted data will not execute as code in the intended log viewing software. V8.8 Verify that security logs are protected from unauthorized access and modification. V8.9 Verify that there is a single application-level logging implementation that is used by the software. V8.10 Verify that the application does not log application-specific sensitive data that assist an attacker, including user’s session identifiers and personal or sensitive information. The length and existence of sensitive data can be logged. V8.11 Verify that a log analysis tool is available which allows the analyst to search for log events based on combinations of search criteria across all fields in the log record format supported by this system. V8.13 Verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection. V8.14 Verify that log fields from trusted and untrusted sources are distinguishable in log entries. V8.15 Verify that logging is performed before executing the transaction. If logging was unsuccessful (e.g. disk full, insufficient permissions) the application safe. This is for when integrity and non-repudiation are a must.
OWASP_ASVS_Version_2.docx