SCP [53, 121, 124, 125, 126, 127, 128, 129] Cornucopia - Logging and Monitoring

[sydseter]

These are SCP coding practices used during Cornucopia threat modeling sessions that we could add here.

ref: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/assets/docs/OWASP_SCP_Quick_Reference_Guide_v21.pdf

First of all, I see that

5. Do not log sensitive information

and

7. Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords

is saying the same thing. The additional details are all good, but the first should perhaps be replaced with the latter?

Suggestions from SCP and Cornucopia

SCP [53] Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed (9.2.9, 6.1.4?)

Suggestion:

Effective monitoring and alerting should be established to detect and respond to suspicious activities quickly

Account for attack patterns that bypass standard lockouts, like using the same passwords against multiple user accounts while rotating IP addresses

SCP [AT7] is referred to in AT7.

---

SCP [121] Log all input validation failures

SCP [124] Log all apparent tampering events, including unexpected changes to state data (is this 5.3.4)

SCP [125] Log attempts to connect with invalid or expired session tokens

SCP [126] Log all system exceptions

SCP [127] Log all administrative functions, including changes to the security configuration settings

SCP [128] Log all backend TLS connection failures

SCP [129] Log cryptographic module failures

SCP [121, 124, 125, 126, 127, 128, 129] is referred to in C7.

References:

https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/
https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#logging-and-monitoring
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet#event-attributes
https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

Suggestion:

1. Security logging

1. Log submitted data that is outside of an expected numeric range
2. Log all apparent tampering events, that involves changes to data and state that should not be modifiable
3. Log requests that violate server-side access control rules
4. Encode and validate any dangerous characters before logging to prevent log injection attacks
5. Do not log sensitive information, including unnecessary system details, session identifiers or passwords
6. Logging controls should support both success and failure of specified security events
7. Use a cryptographic hash function to validate log entry integrity
8. Log attempts to authenticate with invalid or expired credentials
9. Log all input validation failures
10. Log all system exceptions
11. Log all administrative functions, including changes to the security configuration settings
12. Log all backend TLS connection failures
13. Log cryptographic module failures

I like to log all input validation failures because it usually indicates someone is trying to hit the web API directly instead of going through the UI. In the good old days when the backend and frontend were one big lump, this usually meant logging false positives. Not anymore.