Resolve #2630, #2629

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

@@ -40,15 +40,16 @@ Logging events which are security relevant is an important mechanism for being a
 
 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.
 
+Note also that alerting is likely to be a separate process and system. As such, whilst logging the correct events if in considered in scope for ASVS, correlating and alerting on these events is not.
+
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |
 | **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. | 2 | 778 |
 | **7.2.2** | [MODIFIED] Verify that failed access control attempts are logged. For L3 this must include logging all access control decisions. | 2 | 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. | 2 | 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. | 2 | 754 |
-| **7.2.5** | [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected. | 2 | 390 |
+| **7.2.4** | [MODIFIED, MOVED FROM 11.1.7, MERGED FROM 8.1.4] Verify that the application can detect and log unusual activity, including business logic anomalies and abnormal or excessive request patterns, such as by IP, user, total per hour or day, based on documented limits. | 2 | 754 |
+| **7.2.5** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | 2 | |
 | **7.2.6** | [MODIFIED, MOVED FROM 9.2.5] Verify that the application logs security control failures such as backend TLS failures. | 3 | 778 |
-| **7.2.7** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | 2 | |
 
 ## V7.3 Log Protection
 

5.0/en/0x16-V8-Data-Protection.md

@@ -22,7 +22,7 @@ This chapter includes requirements related to defining what data needs to be pro
 | **8.1.1** | [MODIFIED, MERGED FROM 8.1.2] Verify that the application prevents sensitive data from being cached in server components such as load balancers and application caches or ensures that the data is securely purged after use. | 2 | 524 |
 | **8.1.2** | [DELETED, MERGED TO 8.1.1] | | |
 | **8.1.3** | [DELETED, INSUFFICIENT IMPACT] | | |
-| **8.1.4** | [GRAMMAR] Verify that the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application. | 2 | 770 |
+| **8.1.4** | [DELETED, MERGED TO 7.2.4] | | |
 | **8.1.5** | [DELETED, NOT IN SCOPE] | | |
 | **8.1.6** | [DELETED, NOT IN SCOPE] | | |
 | **8.1.7** | [ADDED] Verify that caching mechanisms are configured to only cache responses which have the correct content type and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when an non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | 2 | 444 |
@@ -52,7 +52,7 @@ Note: Privacy regulations and laws, such as the Australian Privacy Principles AP
 | **8.3.2** | [DELETED, NOT IN SCOPE] | | |
 | **8.3.3** | [DELETED, NOT IN SCOPE] | | |
 | **8.3.4** | [DELETED, MERGED TO 1.8.1] | | |
-| **8.3.5** | [MOVED TO 7.2.7] | | |
+| **8.3.5** | [MOVED TO 7.2.5] | | |
 | **8.3.6** | [DELETED, NOT PRACTICAL] | | |
 | **8.3.7** | [DELETED, COVERED BY 1.8.2] | | |
 | **8.3.8** | [LEVEL L2 > L3] Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | 3 | |

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

@@ -32,7 +32,7 @@ Business logic security is so individual to every application that no one checkl
 | **11.1.5** | [DELETED, MERGED TO 11.1.3] | | |
 | **11.1.6** | [MOVED TO 10.7.3] | | |
 | **11.1.7** | [MOVED TO 7.2.4] | | |
-| **11.1.8** | [MOVED TO 7.2.5] | | |
+| **11.1.8** | [DELETED, NOT IN SCOPE] | | |
 | **11.1.9** | [ADDED] Verify that 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. | 2 | |
 | **11.1.10** | [ADDED] Verify that very high-value business logic flows are restricted with multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to critical nuclear facility operations, healthcare record modifications, access to classified information, or safety overrides in manufacturing. | 3 | |