search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.72k stars 665 forks source link

7.2 covering "Security Events" #1795

Closed elarlang closed 5 months ago

elarlang commented 11 months ago

Intro

The first steps of V7 re-org are in progress. There have been discussions on covering security events in different issues, main ones are:

There are also opened some issues related to security events logging:

Problem to solve

I think it does not make sense to list all the possible security events in ASVS. Every application has its own needs and for every application, the required list of security events must be analyzed and documented.

Related comments from other issues:

On the other hand - it would be nice to define the minimum list of events every application must log. It opens again discussion for every event - should it be in the "minimum list"?

So the challenge here is to find suitable abstractation.

jmanico commented 11 months ago

Minimum list is hard, but perhaps all AuthN, AuthZ and input validation events?

jmanico commented 6 months ago

I think an expanded logging security section that includes events from the application security vocabulary cheatsheet is a good idea. If you agree team, I'l take this on.

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html

elarlang commented 6 months ago

We have had this discussion (https://github.com/OWASP/ASVS/issues/997#issuecomment-1103924784). We should not create too detailed requirements for logging, otherwise it is like a separate project inside ASVS and does not make sense.

In ASVS - all the security events must be analyzed and documented (documentation requirement as a precondition for implementation and testing).

At the moment, the idea is to not have more than 1 requirement "per type", e. g. one requirement for authentication, and one for authorization.

We need to finetune requirements to send the idea, not the long list of events as separate requirements.

Waiting for wordsmithing:

elarlang commented 6 months ago

One extreme end is to have one requirement per event, but this is like a separate standard for logging and we don't do this. We have an agreement on this.

Another extreme end is to have abstract requirements. The danger here is to be too abstract, that it is not intuitive, understandable in testable - so it is "fix the logging" and it is losing its point to exist.

I would like to have something in the middle - one requirement per topic (authentication, authorization, input validation, connections...).

We need to have agreement on this as a precondition to develop other logging-related requirements.

jmanico commented 6 months ago

Elar, I'd rather see more detailed logging requirements. But in the interest in getting 5.0 done - something needs to drop - and I think it's fair see security logging as a lower priority.

tghosth commented 5 months ago

Following a lot of discussion, our approach is to create less and more abstract requirements with references to other resources such as the cheatsheets.