Thanks. My current thinking is that we can leave the MRSP "as is" and that we write up what we want in https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications, which is, as you note, information about members of the audit team and how individual members meet #2, #3, and #6.
On Thu, Jan 28, 2021 at 12:44 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Thu, Jan 28, 2021 at 1:43 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On second thought, I think that Mozilla can accomplish what we want >> without >> modifying the MRSP >> < >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors >> > >> (which says audits MUST be performed by a Qualified Auditor, as defined in >> the Baseline Requirements section 8.2), and instead adding language to >> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications that >> explains what additional information we need submitted to determine that >> an >> auditor is "qualified" under Section 8.2 of the Baseline Requirements. >> >> In other words (paraphrasing from BR 8.2), we would need evidence that the >> persons or entities: >> 1. Are independent from the subject of the audit; >> 2. Have the ability to conduct an audit that addresses the criteria; >> 3. Have proficiency in examining Public Key Infrastructure technology, >> information security tools and techniques, information technology and >> security auditing, and the third-party attestation function; >> 4. Are accredited in accordance with ISO 17065 applying the requirements >> specified in ETSI EN 319 403 *OR* 5. Are licensed by WebTrust; >> 6. Are bound by law, government regulation, or professional code of ethics >> (to render an honest and objective opinion); and >> 7. Maintain Professional Liability/Errors & Omissions insurance with >> policy >> limits of at least one million US dollars in coverage. >> >> We do some of this already when we check on an auditor's status to bring >> an >> auditor's record current in the CCADB. The edits that we'll make will >> just >> make it easier for us to go through the list above. >> >> Thoughts? >> > > I'm not sure this approach is very clear about the edits you're making, > and whether pull requests or commits might be clearer, as Wayne did in the > past. If there is a commit, happy to look at it and apologies if I missed > it. > > I'm not sure this addresses the issue as raised, or at least, "or > entities" seems to create the same issues that are trying to be addressed, > by thinking in terms of "legal entities" rather than qualified persons. > > Your discussion about "auditor's" and "auditor's status" might be misread > as "Audit firm", when I think the issue raised was thinking about "person > performing the audit". The individual persons aren't necessarily licensed > or accredited (e.g. #4/ #5), and may not be the ones that retain PL/E&O > insurance (#7). Further, the individuals might be independent, but the firm > not (#1) > > So I think you're really just left with wanting to have a demonstration as > to the members of the audit team and how individual members meet (#2, #3, > #6). Is that right? I think Kathleen's proposal from November got close to > that, and then the remainder is clarifying the language that you've > proposed for 2.7.1, namely "Individuals have competence, partnerships and > corporations do not". > > I think the expectation goal is that "Individually, and as an audit team, > they are independent (#1)" (e.g. you can't have a non-independent party > running the audit with a bunch of independent parties reporting to them, > since they're no longer independent), while that collectively the audit > team meets #2/#3, with the burden being to demonstrate how the individuals > on the team meet that. > > Is that what you were thinking? Or is my explanation a jumbled mess :) > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
