OWASP
Section and requirement relevance questions
Something which comes up constantly is how do we know which requirement/sections of ASVS are relevant to an application.
(Most recently in discussions with the ADA.)
I think it would be good to have a set of questions at the start of each chapter/section to guide someone in whether they need to consider the requirements in that chapter/section.
What do people think?
From my (organizing requirements to sections) point of view we need to clearly define, what kind of requirements should belong to which sections. It could help to solve this as well.
Something like: You need this section when the application uses X functionality / Y technology / Z solution
@ryarmst this is part of what I meant when I spoke about the 3 things that should go into section text
What would be nice is to have a simple web-based form with some questions about your application which would automatically filter out the requirements for you. This would require associating some metadata to the requirements.
An example, would be to be able to remove 9.4.5. if you don't check "Using mTLS" (https://github.com/OWASP/ASVS/issues/2698#issuecomment-2725754937)
I agree it would be nice, but it is a question of the presentation layer and mapping. It smells like a separate project.
In short, in ASVS we try keep only must-have requirement content in releasable content, or in other words, to push everything out of releasable content to have the possibility to update metadata, mapping, etc, without a need to make a new release.
Yes, I agree that, it would probably be a separate project / extension to the main project.
I think this is a good idea, but I think it would be best as a new project or tool separate from the ASVS core. Just to clean up issues, @randomstuff are you ok if we close this out for now? If not, I understand. Just askin'. :)
This issue is not ready to be closed, because the initial proposal is not satisfied and it is not exactly what Gabriel proposed.
Understood, if you want I can delete the comments I made above and your reply to remove the noise.
To be clear @jmanico, we mark things as non-blocker when we want to keep them but we don't want them preventing us getting to 5.0 :)
@tghosth is there a vision or template/structure for consistent section text? I would be happy to make a proposal, but my personal preference is for more verbosity and I know there was some interest previously in minimizing content.
I think we don't have such a template or example.
For me, the point of the issue must be proven first. It means the idea is nice, but can we implement it without causing confusion or misleading the reader? Some sections are clear and easy choices, e.g., cookies, if you don't use cookies, then you don't need to test or implement those requirements.
The first direction or choice can be the message: "You need to use this section if... " or "You can skip this section, if ...".
Might be good to have some clear guidelines on section text.
I am thinking something like:
- Risks that the requirements in this section address
- When do you NOT need to do these requirements?
- Any other crucial contextual information for the requirements.
How about something like this (adapting V13.5):
Purpose
This section provides key security requirements to prevent attacks related to communication security and session management targeting WebSocket communication channels.
Applicability
This section applies only to applications utilizing WebSocket communciation.
Context
WebSocket is a communications protocol, providing a simultaneous two-way communication channel over a single TCP connection. It was standardized by the IETF as RFC 6455 in 2011 and is distinct from HTTP, even though it is designed to work over HTTP ports 443 and 80. The WebSocket protocol uses the ws and wss schemes.
Or as a table (I am learning only now that Markdown does not support tables without headers...):
| Purpose | This section provides key security requirements to prevent attacks related to communication security and session management targeting WebSocket communication channels. |
| Applicability | This section applies only to applications utilizing WebSocket communciation. |
| Context | WebSocket is a communications protocol, providing a simultaneous two-way communication channel over a single TCP connection. It was standardized by the IETF as RFC 6455 in 2011 and is distinct from HTTP, even though it is designed to work over HTTP ports 443 and 80. The WebSocket protocol uses the ws and wss schemes. |
I like the direction and I think this is something we can work on through RC1 as well. I don't love the table but the heading based option seems to take up a lot of space so I am not sure.
I would rename "Context " to be something like "Other notes". I think it should not be general information and not stuff you can look up on the internet but rather ASVS specific info that you absolutely need to understand the requirements but could not fit into the requirement.
A few examples:
- 5.3 (BE) has a note at the end which kinda explains when you would not be able to use parameterization which I think is useful context for understanding when a requirement may not be possible.
- 2.6 (BE) and 2.7 (BE) provide information to confirm what we mean when we talk about "Lookup Secrets", "Time based One-time Passwords (TOTPs)" and "Out-of-Band mechanisms". In principle, that is not ASVS specific info as such but we are using the terms in a specific way so we want it to be clear.
- 7.2 (BE) has an explanation of why alerting is not in scope.
The direction is nice, but I share some concerns about it.
If you are looking for test-cases for proof-of-concepts, I prefer to use something that is not one-technology specific, for example, v5.0.be V5.2, V10.4, V50.8
The task itself is not trivial; experience says it may take a lot more time than people in the beginning estimate, so I have quite a strong concern about that.
I though we wanted to keep section descriptions brief since few people seem to look at it. This proposal seems to go in the opposite direction. I'm flexible but I'm curious at the suggested change in philosophy.
I though we wanted to keep section descriptions brief since few people seem to look at it. This proposal seems to go in the opposite direction. I'm flexible but I'm curious at the suggested change in philosophy.
I removed pretty much the same line from my previous comment before posting.
If few people look at the text, I don't see a need to target any specific length, long or short. It is easy enough to skip. IMO the necessary information to understand and make use of each section should be included regardless of length.
I will write up some further PoCs when I have a moment.
I though we wanted to keep section descriptions brief since few people seem to look at it. This proposal seems to go in the opposite direction. I'm flexible but I'm curious at the suggested change in philosophy.
You and @elarlang are correct and I think this is still important. On the other hand I think we do need some guidelines and in certain cases we explicitly included information in section text that we didn't want to include in requirements.
Having discussed with Elar, I wanted to clarify a few things.
Size
If we can combine purpose and applicability into a one-liner which explains the section together with when it is or is not applicable, that would be ideal. If not, we still want to keep it short.
"Context" or "Other notes"
The intention of this part is information which is in our heads but is not written in the requirements. Generally it should either be rationale for why the requirements are they way that they are, or extra ASVS-specific contextual information that would not fit in the requirements. I think my examples in my comment above fit this definition.
I think Elar's v5.0.be V5.2 example (now V1.3) fits this definition will as it is specific to how we use terms in our requirements.
I think Elar's v5.0.be V10.4 example (now V15.3) partially fits as some of it is a general summary whereas other parts of my specific/explanatory.
I think Elar's v5.0.be V50.8 example (now V3.7) is not a great fit for this definition as it is more like a summary than an explanation.
Plan to progress
I think realistically we need to approach this task on a "best efforts" basis and try and make gradual improvements. Section text is not a breaking change and can be updated in point releases. Trying to comprehensively and exhaustively update section text will probably take longer than we have before we need to release v5.0.0.
Since v5.0 is already released, I just want to pick up where this thread left off as it got me curious... So does that mean we need to clarify the "scope of ASVS" to clarify that ASVS is primarily to be used for web applications and web services, but can be used in general on other types of applications that do not necessarily fit the traditional examples? And then update/include section text of Purpose, Adaptability and Context of each chapter? I can take a stab at those, but just wondering what direction does everyone want to go for?
I think the original intention was to make it clearer under which circumstances a particular section could be skipped.