Hello Andi, It's been a few days since I last wrote, but we've been experimenting with the quickstart and demo apps to get familiarized with them and also defining some procedures to be followed for the assessment. So far the applications have been quite accessible and we haven't found roadblocks to the work we're carrying out.
I wanted to share with you the details of how we want to propose to proceed for the assessment and you'll tell us if it sounds reasonable to you and if there are changes to it you'd want to request. As mentioned in my earlier email, the assessment will be based on OWASP's Application Security Verification Standard[1] (v4.0.1, specifically). For now, we won't try to cover anything beyond Level 1, and in fact, for the purposes of our initial report, we'd limit to certain portions of it to make the work more manageable for everyone. The standard is basically a set of checklists covering several different security requirements. For each of the checklists selected, we'll be performing test procedures to make a preliminary determination of whether the items in the checklist are deemed as PASSED or FAILED. Then we'd submit to you those results for your corroboration; for the FAILED items, in particular, we'll include notes indicating how we carried out the check and why we think the app failed it, as well as a tentative severity level. We'd like to ask you to provide the following feedback to those: a) whether or not you agree that the app indeed fails the stated checks and the severity we're suggesting for them, b) whether the failure can be attributed to the Isis framework or if the checked requirement falls outside of the scope of what the framework is intended to provide (in which case it would fall under the framework user's responsibility to address the requirement in their application), and c) for failures that are considered in the scope of the framework, whether or not a bug or ticket can be filed for addressing them (no need to define a priority nor delivery timeframes, only to make sure the discovered issues would be tracked with the usual mechanisms you already employ for the project). We think most of the exchanges could be done publicly in this list or the Slack channel you pointed me to already, but it's possible that in some cases we'd need to ask a question or report an issue that could be sensitive because it would hint about a vulnerability that may affect existing users of the framework, so we'd like to have a way to discuss them (initially) in private. Should we be writing directly to you in those cases? Please, let us know if the above sounds reasonable and feel free to ask for clarifications you may need or suggest changes to the procedures. Once again, thank you very much for your time and attention. Best regards, Paulo [1] https://owasp.org/www-project-application-security-verification-standard/
