ASVS v5.0 - mappings to other standards

[elarlang]

I opened issue based on wish/requirement/proposal from Rob van der Veer.

A lot of different standards or documentation have their own numeration and as an end user it would be nice to have mapping between them.

Some mapping related hanging issues:

• https://github.com/OWASP/ASVS/issues/810
• https://github.com/OWASP/ASVS/issues/1025

The question is - how much ASVS should reference and map to other standards.

Hard work for mapping is done in https://www.opencre.org/ and it does not seem to make sense to duplicate this work or duplicate this storage in ASVS - potentially it just run out of sync really fast and then there are a lot of conflicts and confusion between CRE and ASVS.

In my opinion - we need web output. Related issue: https://github.com/OWASP/ASVS/issues/895

For the web output, we can do this mapping with some script - take mapping based on ASVS requirement number and display link(s) to mappings or show mapped requirements to web directly. We don't have any need to duplicate mapping to ASVS markdown content, we just need to create web output and use existing mapping information from CRE.

CRE covers: WSTG, CWE, Pro-active controls, cheat sheets, NIST 65, NIST 53B, Top 10 (2017, 2021 is underway).

Mapping to ASVS content makes sense only when we need to point to the source of the requirement - like quite many authentication related requirements come from NIST.

[BillReyor]

I don't know if CRE yet covers the OWASP DevSecOps maturity model (https://owasp.org/www-project-devsecops-maturity-model/), and can certainly see ASVS referencing aspects of it directly especially as deployments and infrastructure provisioning as code continue to align. ie section 14.1.1

[gcrow]

I think investing in a mapping dilutes the 'levels' of ASVS. I already see policies that say "all applications must meet sections ASVS 4, 6 and 13", blissfully ignorant of how ASVS works. Mapping ASVS directly to more binary standards will encourage more of that thinking.

[mario-platt]

From having been working on ASVS User Stories for a while (https://github.com/OpenSecuritySummit/project-ASVS-User-Stories), my recommendation would be to lower expectations on the usefulness of mapping between standards. I think a reference table on general relationships of areas would be useful, and act as a way to validate and confirm moving forward if what ASVS is defining keeps a level of coherence with how other standards are evolving.

What it shouldn't do, is make those mappings in a way that suggests that being compliant to the ASVS requirement automatically makes you compliant to any other mapped standards, because that won't always be the case and may lead to false senses of compliance.

For a practical example, https://github.com/OpenSecuritySummit/project-ASVS-User-Stories/blob/main/Authentication/2_2_4-Authentication_Authenticator-impersonation-resistance.md

The first scenario meets (MFA) meets ASVS and CWE guidance, but not NIST, which suggests other ways to meet the requirement. There will be other examples where a timeout is suggested, and standard A says 30 min and standard B 6h, for instance.

I think the route to map against opencre makes sense, and maybe leaving it at that would be sufficient. Doing more than that, iMO, would imply a need to extend to cover acceptance criteria of the standards (which I don't think the ASVS project would be aiming for) or big disclaimers with lots of caveats on what that mapping actually means or how compliant one can expect to be, and the fact that ASVS has levels of assurance makes that mapping even more challenging and prone to misinterpretation

[tghosth]

To me, the main value of mapping is to make it easier to move from requirement to testing guide to detailed guidance on how to fix in a particular case.

[tghosth]

We have discussed this internally within the project leadership team.

Whilst we appreciate mappings, we want to focus on the core content of the standard. Our current plan for 5.0 is to continue to support CWE and NIST mappings but move them together with any other mappings to a separate folder in the repo rather than being within the main document itself.

[northdpole]

Hey everyone, I'm part of the opencre.org team. A few thoughts after we had some calls with several of you.

I don't know if CRE yet covers the OWASP DevSecOps maturity model (https://owasp.org/www-project-devsecops-maturity-model/),

This can easily be done, do you have any parseable output? We are moving into a model where we allow-list friendly repos and automatically import mappings from them. Would be happy to write a parser for your project e.g. check what I did here for cheatsheets.

Whilst we appreciate mappings, we want to focus on the core content of the standard. Our current plan for 5.0 is to continue to support CWE and NIST mappings but move them together with any other mappings to a separate folder in the repo rather than being within the main document itself.

I can export ASVS to CRE mappings in a table format for 4.0 and provide you with the script that did it so you can use it as a future base for any opencre automation.

However, for 5.0 I think it's important that ASVS gets added to the automatically parsed standards. In order to do that we need you to add a link to specific CREs in ASVS controls. I'd rather this isn't in a separate folder as it would make creating Hyperlinks for specific ASVS controls harder than it should be.

Also, for 5.0 I would be open to help you automatically generate any type of mappings you want from opencre. But to do this I need to have ASVS 5.0 auto-parsed so it can remain up to date.

[tghosth]

Hi @northdpole

For DevSecOps Maturity Model, you will need to speak to @wurstbrot.

For 4.0, I think we already discussed. For 5.0 let's discuss nearer the release at the end of this year.

[tghosth]

hey @northdpole,

Thanks for the PR.

A few questions:

1. Does it make sense to include the mapping in the en folder or can it go in the folder above since it is not language specific?
2. Is there any expectation that this mapping would be included when generating one of the ASVS output formats or is it sufficient that it just exists in the repository (happy to create a link from README or wherever to highlight it.
3. Aside from including this file, is there anything else we need to do within the ASVS repo?
4. Please can you confirm that this mapping was done against the 4.0.3 version?
5. Did you skip the mapping where a requirement was tagged as [DELETED]?
6. If so, other than that, are all other requirements mapped?

Thanks :)

[elarlang]

I still have question - why this mapping need to be in ASVS repository?

We can use for output generation generation as well (but I think it makes sense to use extra parameters for that).

For example - if you keep this mapping on CRE side and maintain there - why it is not enough or better then keeping one separate mapping file in ASVS repository and then need to sync it between repos?

[tghosth]

I discussed out of band with @elarlang and that point is now clear.

@northdpole, just need your comment on my other questions above https://github.com/OWASP/ASVS/issues/1167#issuecomment-1126969629

[northdpole]

Hey everyone, thanks a ton for your comments.

Does it make sense to include the mapping in the en folder or can it go in the folder above since it is not language specific?

It can go anywhere you want it, I placed it in /en only because the CRE titles are in English. Happy to move it if you'd like us to.

Is there any expectation that this mapping would be included when generating one of the ASVS output formats or is it sufficient that it just exists in the repository (happy to create a link from README or wherever to highlight it.

It would be preferable if it was included when generating the ASVS output formats same as you currently link to CWE. Open to discussion of course.

Need to doublecheck and confirm your other questions.

[tghosth]

Getting it integrated into the output like that would be a little tricky because of the way we generate the docs.

7. I will thank about where to put it but are there any plans or expectation that CRE titles will get translated into multiple languages?

[northdpole]

Getting it integrated into the output like that would be a little tricky because of the way we generate the docs.

7. I will thank about where to put it but are there any plans or expectation that CRE titles will get translated into multiple languages?

yes but not in the near future (next year or so)

[lfservin]

Getting it integrated into the output like that would be a little tricky because of the way we generate the docs.

I respectfully disagree. Exactly because of how we generate the docs, we can add other links. So far there is an intermediate step in the 5.0 branch in which HTML links are added to the PDF in the CWE corresponding columns. If there were other columns with "easy" hints as to the URL, it would be easy to implement.

Right now something like 444 gets translated to https://cwe.mitre.org/data/definitions/444.html. The CWE number is trivially set into the URL. As to other mappings, it would be necessary to see what the destination URL would be like.

[tghosth]

@lfservin where is this done?

[lfservin]

@tghosth it's done in the makefile as the pre-step to processing the markdown files into pdf, wordx

[tghosth]

@northdpole I opened a PR on your PR and then I can merge your original PR :)

[northdpole]

~Seems good will approve asap,~

Approved, shall we close the other PR?

[tghosth]

Ok, I just had a closer look at this. I apologise that I did not do so before. I now have some additional questions:

8. I changed the name of the ASVS requirement to comply with the project's reference standard. Do you have any conceptual objections to that?
9. I realised that you are linking to v4.0.2. Please can you confirm that mapping was done based on v4.0.3 and that it is valid for v4.0.3?
10. Do you have any objection to me updating the links so that they link to the correct section and not just the correct chapter? If you have no objections I will fix this myself as it will be an annoying/fiddly job :)

@northdpole

[northdpole]

Ok, I just had a closer look at this. I apologise that I did not do so before. I now have some additional questions:

8. I changed the name of the ASVS requirement to comply with the project's [reference standard](https://github.com/OWASP/ASVS#how-to-reference-asvs-requirements). Do you have any conceptual objections to that?

Not at all, thank you for doing this!

9. I realised that you are linking to v4.0.2. Please can you confirm that mapping was done based on v4.0.3 and that it is valid for v4.0.3?

I would have sworn it was 4.0.3, but seems I'm mistaken, sorry for this one I'll update the table then. How can I validate it's for v4.0.3?

10. Do you have any objection to me updating the links so that they link to the [correct section](https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V4-Access-Control.md#v41-general-access-control-design) and not just the [correct chapter](https://github.com/OWASP/ASVS/blob/master/4.0/en/0x12-V4-Access-Control.md)? If you have no objections I will fix this myself as it will be an annoying/fiddly job :)

Thank you! No problems at all, i'd love it if you could do this! (also, beers on me next we meet for this fiddly job :) )

@northdpole

[elarlang]

10. Do you have any objection to me updating the links so that they link to the correct section and not just the correct chapter? If you have no objections I will fix this myself as it will be an annoying/fiddly job :)

@tghosth , In this case, please use links to v4.0.3 release/tag, not to master branch.

I would have sworn it was 4.0.3, but seems I'm mistaken, sorry for this one I'll update the table then. How can I validate it's for v4.0.3?

@northdpole , The main difference in this context is that some requirement got removed from v4.0.3. Otherwise meanings for requirements in v4.0.2 stayed the same in v4.0.3. For example, see (removed) requirements 1.4.2 and 1.4.3.

Full diff between v4.0.2 and v4.0.3 is available here: https://github.com/OWASP/ASVS/pull/1104/files?file-filters%5B%5D=.md&file-filters%5B%5D=.py&file-filters%5B%5D=.sh&file-filters%5B%5D=No+extension&show-deleted-files=true&show-viewed-files=true

[tghosth]

@elarlang 👍😀

@northdpole If you want to make sure you are seeing v4.0.3, you are best off using this branch: https://github.com/OWASP/ASVS/tree/v4.0.3

@northdpole Please let me know when your work is complete on item 9). I can then do item 10).

[tghosth]

Ok so I think I now just need to do item 10) here...

[tghosth]

@set-reminder 1 week work on this

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 14, 2022 12:00 AM (GMT+01:00)

work on this

[octo-reminder[bot]]

🔔 @tghosth

work on this

[tghosth]

#1454 opened for this