add checklists for logging, monitoring, error and exceptions

.wordlist.txt

@@ -278,4 +278,12 @@ JWKS
 deserialize
 deserialization
 unicode
+DSS
+GDPR
+PCI
 deserializes
+schemas
+unmanaged
+checksums
+FIPS
+UUID

draft/20-proactive-control-checklist/02-define-security-requirements.md

@@ -102,5 +102,4 @@ and submit your content for review.
 
 - [ ]   Scan user uploaded files for viruses and malware
 
-
 \newpage

draft/20-proactive-control-checklist/03-frameworks-libraries.md

@@ -29,7 +29,7 @@ and submit your content for review.
 
 - [ ]   Check that the buffer is as large as specified
 
-- [ ]   When using functions that accept a number of bytes ensure that NULL terminatation is handled correctly
+- [ ]   When using functions that accept a number of bytes ensure that NULL termination is handled correctly
 
 - [ ]   Check buffer boundaries if calling the function in a loop and protect against overflow
 

draft/20-proactive-control-checklist/05-encode-escape-data.md

@@ -51,7 +51,7 @@ The specific methods vary depending on the way the output data is used, such as
 The OWASP Developer Guide is a community effort; if there is something that needs changing
 then [submit an issue][issue2005] or a [pull request][pr].
 
-[control4]: https://owasp.org/www-project-proactive-controls/v3/en/c4-encode-escape-data
+[control4]: https://owasp.org/www-project-proactive-controls/v3/en/c4-encode-escape-data.html
 [encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
 [ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
 [issue2005]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/05-encode-escape-data

draft/20-proactive-control-checklist/08-access-controls.md

@@ -27,7 +27,7 @@ for more context from the 'OWASP Top 10 Proactive Controls' project.
 * Apply least privilege, providing the least access as is necessary
 * Log all authorization events
 
-## Access control
+#### Access control
 
 * Enforce authorization controls on every request
 * Use only trusted system objects for making access authorization decisions

draft/20-proactive-control-checklist/09-protect-data.md

@@ -14,7 +14,7 @@ order: 2009
 ### 20.9 Checklist: Protect Data Everywhere
 
 Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets
-require extra protection, particularly if that data falls under privacy laws (EU’s General Data Protection Regulation GDPR),
+require extra protection, particularly if that data falls under privacy laws (EU General Data Protection Regulation GDPR),
 financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
 
 Refer to proactive control '[C8: Protect Data Everywhere][control8]'
@@ -40,7 +40,7 @@ for more context from the 'OWASP Top 10 Proactive Controls' project.
 * Use peer reviewed and open solution cryptographic modules
 * All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system
 * Cryptographic modules must fail securely
-* Ensure all random numbers, random file names, random GUIDs, and random strings are generated
+* Ensure all random elements such as numbers, file names, UUID and strings are generated
     using the cryptographic module approved random number generator
 * Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard
 * Establish and utilize a policy and process for how cryptographic keys will be managed

draft/20-proactive-control-checklist/10-logging-monitoring.md

@@ -13,67 +13,51 @@ order: 2010
 
 ### 20.10 Checklist: Implement Security Logging and Monitoring
 
-![Developer Guide](../assets/images/dg_wip.png "OWASP Developer Guide"){: height="220px" }
-
-The OWASP Development Guide is being rewritten by the OWASP community,
-and the content has yet to be filled in for section 'C9: Implement Security Logging and Monitoring.
-
-If you would like to contribute then follow the [contributing guidelines][contribute]
-and submit your content for review.
-
-[contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
-
-
-- [ ]   Do not disclose sensitive information in error responses, including
-    system details, session identifiers or account information
-
-- [ ]   Use error handlers that do not display debugging or stack trace information
-
-- [ ]   Implement generic error messages and use custom error pages
-
-- [ ]   The application should handle application errors and not rely on the server configuration
-
-- [ ]   Properly free allocated memory when error conditions occur
-
-- [ ]   Error handling logic associated with security controls should deny access by default
-
-- [ ]   All logging controls should be implemented on a trusted system
-
-- [ ]   Logging controls should support both success and failure of specified security events
-
-- [ ]   Ensure logs contain important log event data
-
-- [ ]   Ensure log entries that include un-trusted data will not execute as
-    code in the intended log viewing interface or software
-
-- [ ]   Restrict access to logs to only authorized individuals
-
-- [ ]   Utilize a central routine for all logging operations
-
-- [ ]   Do not store sensitive information in logs, including unnecessary
-    system details, session identifiers or passwords
-
-- [ ]   Ensure that a mechanism exists to conduct log analysis
-
-- [ ]   Log all input validation failures
-
-- [ ]   Log all authentication attempts, especially failures
-
-- [ ]   Log all access control failures
-
-- [ ]   Log all apparent tampering events, including unexpected changes to state data
-
-- [ ]   Log attempts to connect with invalid or expired session tokens
-
-- [ ]   Log all system exceptions
-
-- [ ]   Log all administrative functions, including changes to the security configuration settings
-
-- [ ]   Log all backend TLS connection failures
-
-- [ ]   Log cryptographic module failures
-
-- [ ]   Use a cryptographic hash function to validate log entry integrity
-
+Logging is recording security information during the runtime operation of an application.
+Monitoring is the live review of application and security logs using various forms of automation.
+
+Refer to proactive control '[C9: HImplement Security Logging and Monitoring][control9]'
+for more context from the 'OWASP Top 10 Proactive Controls' project.
+
+#### Security logging
+
+* Log submitted data that is outside of an expected numeric range.
+* Log submitted data that involves changes to data that should not be modifiable
+* Log requests that violate server-side access control rules
+* Encode and validate any dangerous characters before logging to prevent log injection attacks
+* Do not log sensitive information
+* Logging controls should support both success and failure of specified security events
+* Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords
+* Use a cryptographic hash function to validate log entry integrity
+
+#### Security logging design
+
+* Protect log integrity
+* Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software
+* Restrict access to logs to only authorized individuals
+* Utilize a central routine for all logging operations
+* Forward logs from distributed systems to a central, secure logging service
+* Follow a common logging format and approach within the system and across systems of an organization
+* Synchronize across nodes to ensure that timestamps are consistent
+* All logging controls should be implemented on a trusted system
+* Ensure that a mechanism exists to conduct log analysis
+
+#### References
+
+* OWASP [Cheat Sheet: Logging][cslogging]
+* OWASP [Cheat Sheet: Application Logging Vocabulary][csvocabulary]
+* OWASP [Top 10 Proactive Controls][proactive10]
+
+----
+
+The OWASP Developer Guide is a community effort; if there is something that needs changing
+then [submit an issue][issue2010] or a [pull request][pr].
+
+[control9]: https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging.html
+[cslogging]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
+[csvocabulary]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
+[issue2010]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/10-logging-monitoring
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/
 
 \newpage

draft/20-proactive-control-checklist/11-handle-errors-exceptions.md

@@ -13,14 +13,46 @@ order: 2011
 
 ### 20.11 Checklist: Handle all Errors and Exceptions
 
-![Developer Guide](../assets/images/dg_wip.png "OWASP Developer Guide"){: height="220px" }
-
-The OWASP Development Guide is being rewritten by the OWASP community,
-and the content has yet to be filled in for section 'C10: Handle all Errors and Exceptions'.
-
-If you would like to contribute then follow the [contributing guidelines][contribute]
-and submit your content for review.
-
-[contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
+Handling exceptions and errors correctly is critical to making your code reliable and secure.
+Error and exception handling occurs in all areas of an application including critical business logic
+as well as security features and framework code.
+
+Refer to proactive control '[C10: Handle all Errors and Exceptions][control10]'
+for more context from the 'OWASP Top 10 Proactive Controls' project.
+
+#### Errors and Exceptions
+
+* Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code
+* Ensure that all unexpected behavior is correctly handled inside the application
+* Ensure that error messages displayed to users do not leak critical data,
+    but are still verbose enough to enable the proper user response.
+* Ensure that exceptions are logged in a way that gives enough information
+    for support, QA, forensics or incident response teams to understand the problem.
+* Carefully test and verify error handling code.
+* Do not disclose sensitive information in error responses, for example
+    system details, session identifiers or account information
+* Use error handlers that do not display debugging or stack trace information
+* Implement generic error messages and use custom error pages
+* The application should handle application errors and not rely on the server configuration
+* Properly free allocated memory when error conditions occur
+* Error handling logic associated with security controls should deny access by default
+
+#### References
+
+* OWASP [Code Review Guide: Error Handling][review]
+* OWASP [Improper Error Handling][handle]
+* OWASP [Top 10 Proactive Controls][proactive10]
+
+----
+
+The OWASP Developer Guide is a community effort; if there is something that needs changing
+then [submit an issue][issue2011] or a [pull request][pr].
+
+[control10]: https://owasp.org/www-project-proactive-controls/v3/en/c10-errors-exceptions.html
+[handle]: https://owasp.org/www-community/Improper_Error_Handling
+[issue2011]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/11-handle-errors-exceptions
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/
+[review]: https://owasp.org/www-project-code-review-guide/
 
 \newpage