Refresh v7

5.0/en/0x15-V7-Error-Logging.md

@@ -1,57 +1,46 @@
-# V7 Error Handling and Logging
+# V7 Security Logging and Error Handling
 
 ## Control Objective
 
-The primary objective of error handling and logging is to provide useful information for the user, administrators, and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise.
+Security logs are a specific type of logging which is not focused on error handling or performance but rather specifically on recording when security sensitive events occur.
 
-High-quality logs, which often contain sensitive data, must be safeguarded in accordance with local data privacy laws or directives. This should include:
+The primary objective of security logging is to provide useful information for the user, administrators, and incident response teams, which contains more signal than discarded noise. When logging security-related events, ensure that there is a purpose to the log and that it can be distinguished by SIEM or analysis software.
 
-* Not collecting or logging sensitive information unless specifically required.
-* Ensuring all logged information is handled securely and protected as per its data classification.
-* Ensuring that logs are not stored forever, but have an absolute lifetime that is as short as possible.
+Security logs, which often contain sensitive data, must be safeguarded in accordance with local data privacy laws or directives. This sensitive data also makes them very attractive to attackers as a target in their own right so they should be carefully protected.
 
-If logs contain private or sensitive data, the definition of which varies from country to country, the logs become some of the most sensitive information held by the application and thus very attractive to attackers in their own right.
-
-It is also important to ensure that the application fails securely and that errors do not disclose unnecessary information.
+Aside from this, it is also important to ensure that the application fails securely and that errors do not disclose unnecessary information or cause the application to stop operating.
 
 ## V7.1 General Logging
 
-<!--
-Logging sensitive information is dangerous - the logs become classified themselves, which means they need to be encrypted, become subject to retention policies, and must be disclosed in security audits. Ensure only necessary information is kept in logs, and certainly no payment, credentials (including session tokens), sensitive or personally identifiable information.
-
-V7.1 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetration testable, it's important for:
+Logging sensitive information is dangerous - the logs become classified themselves, which means they may need to be encrypted, become subject to retention policies, and must be disclosed in security audits. Ensure only necessary information is kept in logs, and certainly no payment, credentials (including session tokens), sensitive or personally identifiable information.
 
-* Developers to ensure full compliance with this section, as if all items were marked as L1.
-* Penetration testers to validate full compliance of all items in V7.1 via interview, screenshots, or assertion.
--->
+For the specific information which should be included in a log entry, refer to external detailed guidance such as the OWASP Logging Cheat Sheet.
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **7.1.1** | Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. | ✓ | ✓ | ✓ | 532 |
-| **7.1.2** | Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. | ✓ | ✓ | ✓ | 532 |
+| **7.1.1** | [MODIFIED, MERGED FROM 7.1.2] Verify that the application does not log credentials, payment details or any data defined as sensitive based on local privacy laws or relevant security policy. Session tokens should only be stored in logs in an irreversible, hashed form. | ✓ | ✓ | ✓ | 532 |
+| **7.1.2** | [DELETED, MERGED TO 7.1.1] | | | | |
 | **7.1.3** | [MOVED TO 7.2.3] | | | | |
 | **7.1.4** | [MODIFIED] Verify that each log entry includes necessary metadata that would allow for a detailed investigation of the timeline when an event happens. | | ✓ | ✓ | 778 |
 | **7.1.5** | [MOVED FROM 7.3.4] Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. | | ✓ | ✓ | |
 | **7.1.6** | [ADDED] Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | | ✓ | ✓ | |
-| **7.1.7** | [MODIFIED, MOVED FROM 1.7.1] Verify that logs are readable and correlatable for the used log reader, preferably by using a common logging format. | | ✓ | ✓ | |
+| **7.1.7** | [MODIFIED, MOVED FROM 1.7.1] Verify that logs can be read and correlated by the log processor which is in use, preferably by using a common logging format. | | ✓ | ✓ | |
 
 ## V7.2 Security Events
 
-<!--
-Timely logging is critical for audit events, triage, and escalation. Ensure that the application's logs are clear and can be easily monitored and analyzed either locally or log shipped to a remote monitoring system.
+Logging events which are security relevant is an important mechanism for being able to investigate suspicious activity within the application.
 
-V7.2 covers OWASP Top 10 2017:A10. As 2017:A10 and this section are not penetration testable, it's important for:
-
-* Developers to ensure full compliance with this section, as if all items were marked as L1.
-* Penetration testers to validate full compliance of all items in V7.2 via interview, screenshots, or assertion.
--->
+This section will briefly discuss the types of events to log but deliberately does not go into too much detail. It will be necessary to refer to external detailed guidance such as the OWASP Logging Cheat Sheet and the OWASP Application Logging Vocabulary Cheat Sheet for specific implementation details.
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **7.2.1** | [MODIFIED] Verify that all authentication decisions are logged. | | ✓ | ✓ | 778 |
-| **7.2.2** | [MODIFIED] Verify that all access control decisions can be logged and all failed decisions are logged. | | ✓ | ✓ | 285 |
-| **7.2.3** | [MODIFIED, MOVED FROM 7.1.3] Verify that the application logs security relevant events including deserialization failures, input validation failures and incorrect HTTP requests (including requests with an unexpected HTTP verb). | | ✓ | ✓ | 778 |
-| **7.2.4** | [MOVED FROM 9.2.5] Verify that backend TLS connection failures are logged. | | | ✓ | 778 |
+| **7.2.1** | [MODIFIED] Verify that all authentication operations are logged including both successful and unsuccessful attempts. Additional metadata such as type of authentication or factors used should also be collected. | | ✓ | ✓ | 778 |
+| **7.2.2** | [MODIFIED] Verify that all access control decisions are logged including failed attempts. | | ✓ | ✓ | 285 |
+| **7.2.3** | [MODIFIED, MOVED FROM 7.1.3] Verify that the application logs attempts to bypass the security controls defined in the design documentation such as input validation. | | ✓ | ✓ | 778 |
+| **7.2.4** | [MODIFIED, MOVED FROM 11.1.7] Verify that the application monitors for unusual events or activity from a business logic perspective. | | ✓ | ✓ | 754 |
+| **7.2.5** | [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected. | | ✓ | ✓ | 390 |
+| **7.2.6** | [MOVED FROM 9.2.5] Verify that the application logs security control failures such as backend TLS failures. | | | ✓ | 778 |
+| **7.2.7** | [ADDED] Verify that Content Security Policy violation reports are logged. | | | ✓ | |
 
 ## V7.3 Log Protection
 
@@ -65,11 +54,9 @@ Logs that can be trivially modified or deleted are useless for investigations an
 | **7.3.4** | [MOVED TO 7.1.5] | | | | |
 | **7.3.5** | [MOVED FROM 1.7.2] Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. | | ✓ | ✓ | |
 
-Note: Log encoding (7.3.1) is difficult to test and review using automated dynamic tools and penetration tests, but architects, developers, and source code reviewers should consider it an L1 requirement.
-
 ## V7.4 Error Handling
 
-The purpose of error handling is to allow the application to provide security-relevant events for monitoring, triage and escalation. The purpose is not to create logs. When logging security-related events, ensure that there is a purpose to the log and that it can be distinguished by SIEM or analysis software.
+The purpose of error handling is to ensure the application fails gracefully and securely without disclosing sensitive information. The application should be written in a way that ensures this will always happen.
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
@@ -86,3 +73,5 @@ For more information, see also:
 
 * [OWASP Testing Guide 4.0 content: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README.html)
 * [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages)
+* [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html)

5.0/en/0x17-V9-Communications.md

@@ -38,7 +38,7 @@ Server communications involve more than just HTTP. Connections to and from other
 | **9.2.2** | [MODIFIED] Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | | ✓ | ✓ | 319 |
 | **9.2.3** | [DELETED, NOT IN SCOPE] | | | | |
 | **9.2.4** | [MOVED TO 9.4.3] | | | | |
-| **9.2.5** | [MOVED TO 7.2.4] | | | | |
+| **9.2.5** | [MOVED TO 7.2.6] | | | | |
 
 ## V9.3 HTTPS Communication between Internal Services
 

5.0/en/0x19-V11-BusLogic.md

@@ -20,8 +20,8 @@ Business logic security is so individual to every application that no one checkl
 | **11.1.4** | [MOVED TO 11.2.2] | | | | |
 | **11.1.5** | [MODIFIED] Verify that the application has globally defined business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies. | ✓ | ✓ | ✓ | |
 | **11.1.6** | [MODIFIED] Verify that the application uses synchronization and locking mechanisms for sensitive operations in order to keep internal data consistent, maintain user state, and prevent race conditions, such as 'time of check to time of use (TOCTOU)' vulnerabilities. | | ✓ | ✓ | 367 |
-| **11.1.7** | Verify that the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. | | ✓ | ✓ | 754 |
-| **11.1.8** | Verify that the application has configurable alerting when automated attacks or unusual activity is detected. | | ✓ | ✓ | 390 |
+| **11.1.7** | [DELETED, MOVED TO 7.2.4] | | | | |
+| **11.1.8** | [DELETED, MOVED TO 7.2.5] | | | | |
 | **11.1.9** | [ADDED] Verify that "atomic transactions" are being used at the business logic level such that either a business logic operation succeeds in its entirety, or it is rolled back to the previous correct state. | | ✓ | ✓ | |
 
 ## V11.2 Anti-automation