ASVS
ASVS copied to clipboard
OWASP
V7 Logging reorg
Collection of logging related issues for overview.
Related issues:
- https://github.com/OWASP/ASVS/issues/892
- https://github.com/OWASP/ASVS/issues/997
- https://github.com/OWASP/ASVS/issues/1272
- https://github.com/OWASP/ASVS/issues/1396
- https://github.com/OWASP/ASVS/issues/1419
- https://github.com/OWASP/ASVS/issues/1466
A bit related:
- https://github.com/OWASP/ASVS/issues/1231
- https://github.com/OWASP/ASVS/issues/1063
After reorg:
- https://github.com/OWASP/ASVS/issues/1132
Add links to V7 references section:
- https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
Proposal for categories:
- V7.1- what event you need to log - security events, one requirement per topic (authentication, session, authorization, anti-automation etc...)
- V7.2 - how to log / what (meta) information you (can not) log per/with event
- V7.3 - log protection
Minimum list of security events what must be logged
(here I collect minimum list of security events what we need to cover with requirements)
- from current 7.1.3
- successful and failed authentication events
- access control failures
- deserialization failures
- input validation failures
- incorrect HTTP requests (including requests with an unexpected HTTP verb)
- current 11.1.7 (https://github.com/OWASP/ASVS/issues/1272)
- 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.
- current 11.1.8 (https://github.com/OWASP/ASVS/issues/1272)
- anti-automation / automated attacks or unusual activity is detected
- current 9.2.5 V9.2.5 Verify that backend TLS connection failures are logged.
- new - from https://github.com/OWASP/ASVS/issues/1416#issuecomment-1356784913 - account modifications
- new? csp errors? https://github.com/OWASP/ASVS/issues/1445
"Leaders decision" label, as it waits decision - how much we cover security events in ASVS or we leave it more abstract and only "document what you need and do what you documented" without declaring (example) list into ASVS itself.
I would suggest
V7.1 - What to log and what not to log V7.2 - How to log V7.3 - How to protect logs
8.3.5 Also talks about logging so should probably be included in this...
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 8.3.5 | Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. | ✓ | ✓ | 532 |
One more note: in case we will have some (sub)category from program code (architecture), then "Error logging" part should be moved away from Logging.
I try to kick this one on the move.
I proposed: https://github.com/OWASP/ASVS/issues/1444#issue-1493569786
V7.1 - what event you need to log - security events, one requirement per topic (authentication, session, authorization, anti-automation etc...) V7.2 - how to log / what (meta) information you (can not) log per/with event V7.3 - log protection
Josh proposed: https://github.com/OWASP/ASVS/issues/1444#issuecomment-1366685773
V7.1 - What to log and what not to log V7.2 - How to log V7.3 - How to protect logs
Not clear for me - what is the difference?
Anyway, I try to explain logic and put maybe a bit different proposal for discussion.
All category names are topic for discussion, I just try to explain general idea or clarification how to group requirements (and for me it's more clarification between 7.1 and 7.2, no big changes).
V7.1 General Logging
To not start with list of specific events, maybe it makes sense to cover more general requirements. Probably previously (https://github.com/OWASP/ASVS/issues/1444#issue-1493569786, https://github.com/OWASP/ASVS/issues/1444#issuecomment-1366685773) we called id "how to log".
What data elements every log line must contain (just elements, not event data itself!) and what it should not contain (like sensitive information).
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.1.4 | Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. (C9) | ✓ | ✓ | 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. (C9) | ✓ | ✓ | ||
| 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. (C9, C10) | ✓ | ✓ | ✓ | 532 |
| 7.1.2 | Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. (C9) | ✓ | ✓ | ✓ | 532 |
Here also goes: https://github.com/OWASP/ASVS/issues/1759 (if it gets agreed as a requirement)
V7.2 Security events
All actual security events here.
Requirement 7.1.3 here is just an example and this one need to be split up.
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.1.3 | [MODIFIED] Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures, input validation failures and incorrect HTTP requests (including requests with an unexpected HTTP verb). (C5, C7) | ✓ | ✓ | 778 | |
| 7.2.1 | Verify that all authentication decisions are logged. | ✓ | ✓ | 778 | |
| 7.2.2 | Verify that all access control decisions can be logged and all failed decisions are logged. | ✓ | ✓ | 285 |
Othere events here:
- https://github.com/OWASP/ASVS/issues/1444#issuecomment-1357306856
- https://github.com/OWASP/ASVS/issues/1622
- https://github.com/OWASP/ASVS/issues/1445
The problem here is - should we really list all possible security events, or we can use some abstraction? (but let's get categories settled first)
V7.3 Log Protection
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.3.1 | Verify that all logging components appropriately encode data to prevent log injection. (C9) | ✓ | ✓ | 117 | |
| 7.3.3 | [MODIFIED] Verify that logs are protected from unauthorized access and cannot be modified. (C9) | ✓ | ✓ | 200 | |
| 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. (C9) | ✓ | ✓ |
What is the "rework stage" and when it comes? At the moment it seems unreasonable to postpone things that we can actually develop further.
The rework stage is when we deal with all the individual issues and start trying to rework entire chapters at a time
With some there are dependencies, where one issue depends on other. Instead of waiting and pushing them to the future, for me it makes sense to move them further. This is only way to collect feedback for them.
The current reality is - all those "rework" issues are "muted" or to be ignored. I clearly don't like it. And instead of discussing the issue, which was quite simple question, we discuss how long time more we should ignore the issue...
@tghosth - please find time to take a look to https://github.com/OWASP/ASVS/issues/1444#issuecomment-1779770076 . Discussion over PR's does not seem to work as well.
2 opened questions:
- Should we also have reference to "Logging Vocabulary Cheat Sheet"?
- https://github.com/OWASP/ASVS/issues/1444#issue-1493569786
- https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html
- Should we move 8.3.5 into V7?
- https://github.com/OWASP/ASVS/issues/1444#issuecomment-1481459673
Should we also have reference to "Logging Vocabulary Cheat Sheet"?
There is a reference at the bottom of V7 (FYI @jmanico ) https://github.com/OWASP/ASVS/blob/master/5.0/en/0x15-V7-Error-Logging.md#references
Should we move 8.3.5 into V7?
Yes I think we should, do you want to open a separate issue @elarlang ?
Yes I think we should, do you want to open a separate issue @elarlang ?
No need for issue adding the link, everything is agreed and confirmed here already.
Separate issue can be opened for the 8.3.5 topic.
edit 1: now I can see, that we actually have the link there already... so the question was for 8.3.5?
edit 2: discussion over 8.3.5 is also done here, so it's trackable without opening the issue.
Just point to https://github.com/OWASP/ASVS/issues/1444#issuecomment-1481459673
So you want to open a PR @elarlang or should I?
Ended up with separate issue https://github.com/OWASP/ASVS/issues/1960
Everything is done here, so I close this one.