asvs/v16-logging-error-handling

18 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V16.1.1 Logging inventory requirement

Requirement 16.1.1 (Level 2): Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept.

V16.2.1 Log entry metadata requirement

Requirement 16.2.1 (Level 2): Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens.

V16.2.2 Time synchronization and timestamp requirement

Requirement 16.2.2 (Level 2): Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions.

V16.2.3 Log storage inventory compliance requirement

Requirement 16.2.3 (Level 2): Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory.

V16.2.4 Log readability and format requirement

Requirement 16.2.4 (Level 2): Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format.

V16.2.5 Sensitive data logging protection requirement

Requirement 16.2.5 (Level 2): Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially.

V16.3.1 Authentication operations logging requirement

Requirement 16.3.1 (Level 2): Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected.

V16.3.2 Authorization attempts logging requirement

Requirement 16.3.2 (Level 2): Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself).

V16.3.3 Security events and bypass attempts logging requirement

Requirement 16.3.3 (Level 2): Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation.

V16.3.4 Unexpected errors and security control failures logging requirement

Requirement 16.3.4 (Level 2): Verify that the application logs unexpected errors and security control failures such as backend TLS failures.

V16.4.1 Log injection prevention requirement

Requirement 16.4.1 (Level 2): Verify that all logging components appropriately encode data to prevent log injection.

V16.4.2 Log protection from modification requirement

Requirement 16.4.2 (Level 2): Verify that logs are protected from unauthorized access and cannot be modified.

V16.4.3 Secure log transmission to separate system requirement

Requirement 16.4.3 (Level 2): Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised.

V16.5.1 Generic error messages requirement

Requirement 16.5.1 (Level 2): Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens.

V16.5.2 Secure degradation on external resource failure requirement

Requirement 16.5.2 (Level 2): Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation.

V16.5.3 Secure failure and fail-close requirement

Requirement 16.5.3 (Level 2): Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic.

V16.5.4 Last resort error handler requirement

Requirement 16.5.4 (Level 3): Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability.

V16 chapter notes on language exceptions

Certain languages, including Swift, Go, and through common design practice, many functional languages, do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events.

Give your agent this brain