OWASP
Use a story tree to make the requirements more accessible to non-techies.
Ok, so while driving home tonight I listened to an earlier Application Security Weekly episode and learned about the thoughts for the new version from the interview with Josh Grossman. It got me thinking of how to make the asvs more accessible to orgs in general, and more people in general. One idea I had was to have a tree of day-to-day user stories that all lead to different asvs requirements. I couldn't find that this suggestion had already been made, but if so my apologies.
Anyway, with a little help from ChatGPT I made a quick example, and I think it turned out pretty good. This one is based on 2.2.1, which is pretty dense and ridden with sec lingo. The point here isn't that it is the most technical requirement, but it reads kind of "esoteric", if you're not into security and/or authentication in the first place.
--- 8< --- Protecting Against Unauthorized Access Attempts (Making Sure Only You Can Access Your Account) ├── Story: Jane Notices Suspicious Activity on Her Account │ ├── Mini-Story: Jane Receives Multiple "Incorrect Password" Notifications │ │ └── Why It Matters: These Alerts Mean Someone Is Trying to Break into Her Account. The Service Should Limit How Many Wrong Tries Are Allowed (Part of ASVS 2.2.1: Rate Limiting) │ ├── Mini-Story: After Several Failed Attempts, the Service Asks for a CAPTCHA │ │ └── Why It Matters: This Extra Step Makes It Harder for Automated Programs to Guess Her Password (Part of ASVS 2.2.1: CAPTCHA) │ ├── Mini-Story: Jane Can't Log In and Realizes Her Account Is Temporarily Locked │ │ └── Why It Matters: Temporarily Locking the Account After Wrong Tries Keeps Her Account Safe (Part of ASVS 2.2.1: Soft Lockouts) │ └── Mini-Story: Jane Finally Unlocks Her Account but Sees Restrictions on Her Login Attempts │ └── Why It Matters: These Restrictions Prevent Too Many Attempts in a Short Period, Keeping Her Account Secure (Part of ASVS 2.2.1: No More Than 100 Failed Attempts Per Hour) --- >8 ---
It was just a thought I think it was worth mentioning. I would love to help. So let me know if this tickles anyones fancy.
Thank you for feedback, we had similar discussion some time (2 years) ago, https://github.com/OWASP/ASVS/issues/813#issuecomment-801437897
My opinion is - techies need language for techies. Non-techies can not do the tasks which requires deep-techies knowledge. So I am failing to understand, what problem it solves from ASVS side?
To be clear: extra explanation in general is never bad, the question is - where it should be located (and who maintains and synchronizes it).
Where it may give extra value is to "translate" ASVS requirement to abstract business logical functional requirements, but this is out of ASVS scope.
In general - if some requirement text is not understandable, we need to fix the requirement. And there should be difference, is it not understandable because of bad text or because lack of knowledge on the topic. ASVS is not for education and requirement texts can not educate. Often they need to be abstract enough to be valid for different technologies.
Does it give you more ideas and questions? :)
Ok, I obviously read the plans for the asvs wrong. My bad. It was just meant as an idea, not criticism. Personally I love the work you have done, but I also have the problem of "selling it" to project and product management without me or team members having to be hands on. So that's what problem it was meant as a suggestion on how to solve. No matter, keep ut the good work! :)
This suggestion seems like another project/cheatsheet, maybe? Since this is out of ASVS scope.
I also have the problem of "selling it" to project and product management without me or team members having to be hands on
Is it more security awareness issue for the leaders rather than ASVS is not "human" readable?
The point is - let's say ASVS is more human readable, would it solve the mentioned problem or the problem is somewhere else?
Just to be clear, I didn't mean that the ASVS should change its basic wording or language, only that the suggested construct could represent one possible way of making more people understand why there's a need for the different requirements. IMHO it could potentially help make the case for using ASVS for a lot more people, not only management. It's not a question of being human readable or not, it's a question of making what is read more comprehensible to more people.
In my experience devs usually both understand and want to implement the ASVS requirements. It's the people around them that don't necessarily see the need nor the value in giving time and resources to fulfill them. So maybe it's an awareness issue, but that was quite frankly what I got out of what I heard Grossman talked about regarding the plans for version 5, on the mentioned podcast.
From my point of view it's awareness issue. Non-tech leaders just need to hire good tech persons for giving them good advice.
As it all related to @tghosth , then I leave it to him :)
Hi @gobrtg,
Thanks for taking the time to suggest this.
A few thoughts:
- Specifically on 2.2.1 I think that the requirement needs some TLC as it is a little wordy and I have opened #1763 to deal with that separately. Overall for 5.0 we need to be clarifying requirements better.
- The ideal is that ASVS requirements should be understandable to developers and I think we need to get better at that for 5.0. On the other hand, we do try and keep the requirements themselves as short as possible.
- Currently, we have two mechanisms to provide extra context for ASVS requirements:
- The text surrounding the requirements although it isn't clear how often people are reading that.
- The CWE reference to explain which weakness it is aiming to address but again CWEs are not always super clear and sometimes the mapping is not exact.
- For 5.0, we are hoping to map to OpenCRE which is a far more varied and specific software security taxonomy. We also have a lot more input and control with OpenCRE.
- As a general point, I think the use of user stories to explain security controls would be really valuable and not necessarily limited to the ASVS but to explain controls/vulnerabilities in general. Mapping them to
- However, as was suggested in #813, this would probably be best pitched as a separate project. Having the user stories mapped using OpenCRE would be incredibly powerful as well (I don't think OpenCRE existed when the original issue was discussed).
In summary,
- I think your ideas would be super valuable combined with the resources here and here to further develop the OWASP User Security Stories project. If you want to help getting that OWASP project moving again and getting more involved with it, email me at firstname [dot] lastname [at] owasp [dot] org and I can try and help connect you to the relevant people :)
- If you are aware of other ASVS items that are not very understandable (as at the "bleeding edge version", please check if an issue has already been opened about them and if not, open an issue with your thoughts/suggestions.
Thanks again :)
Are we expecting some action based on this issue? If not, maybe we can close this.
I think this was an interesting idea but probably more suitable for a separate project so I think we can close for now.