Dear Ben, Dear Kahtleen,
we suppose, there are no other changes intendent then apart from what you say below? If the rest of section 3.2 remains as it is, the specific matter of the ETSI auditor qualification would be addressed through the referrer back to BRG section 8.2. It would then read like this, which is okay for us: "3.2 Auditors In normal circumstances, Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2. A Qualified Auditor MUST have relevant IT Security experience, or have audited a number of CAs, and be independent. Each Audit Report MUST be accompanied by documentation provided to Mozilla of the audit team qualifications sufficient for Mozilla to determine the competence, experience, and independence of the auditor." Otherwise a link to the Wiki would be necessary for clear definition of the details for the auditor qualification. Apart from that: is it also intended to change section 3.1.4? All the best Clemens -----Ursprüngliche Nachricht----- Von: mozilla.dev.security.pol...@googlegroups.com <mozilla.dev.security.pol...@googlegroups.com> Im Auftrag von Ben Wilson Gesendet: Dienstag, 9. März 2021 00:31 An: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Betreff: EXT: Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report All, Kathleen and I discussed the language of this proposal and have modified it for MRSP section 3.2 as follows: "A Qualified Auditor MUST have relevant IT Security experience, or have audited a number of CAs, and be independent. Each Audit Report MUST be accompanied by documentation provided to Mozilla of the audit team qualifications sufficient for Mozilla to determine the competence, experience, and independence of the auditor." Ben On Thu, Feb 18, 2021 at 11:27 AM Ben Wilson < <mailto:bwil...@mozilla.com> bwil...@mozilla.com> wrote: > All, > > I have edited the proposed resolution of Issue #192 > <https://github.com/BenWilson-Mozilla/pkipolicy/commit/70db4d97f674807 > 5fa760555c1eabb81bd7914ee> > as follows: > > Subsection 3 of MRSP Section 3.1.4. would read: > > "The publicly-available documentation relating to each audit MUST > contain at least the following clearly-labelled information: ... > > 3. name of the lead auditor and qualifications of the team performing > the audit, as required by section 3.2; ..." > > Section 3.2 would read: > > "A Qualified Auditor MUST have relevant IT Security experience, or > have audited a number of CAs, and be independent and not conflicted. > People have competence, partnerships and corporations do not. Each > Audit Report MUST be accompanied by documentation provided to Mozilla > of the audit team qualifications > < <https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications> > https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications> > sufficient for Mozilla to determine the competence, experience, and > independence of the Qualified Auditor." > > The wiki page linked above will provide further details on how to > submit documentation of the audit team's qualifications (which may be > separate from the audit letter itself). > > Ben > > > <https://github.com/BenWilson-Mozilla/pkipolicy/commit/70db4d97f674807 > 5fa760555c1eabb81bd7914ee> > > > > On Mon, Feb 15, 2021 at 6:01 PM Watson Ladd via dev-security-policy < > <mailto:dev-security-policy@lists.mozilla.org> > dev-security-policy@lists.mozilla.org> wrote: > >> On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote: >> > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote: >> > > Apologies for belaboring the point, but I think we might be >> > > talking >> past >> > > eachother. >> > > >> > > You originally stated “The only place I am aware that lists the >> > > audit partner in a comparable world is the signing audit partner >> > > on public company audits in the US, which is available on the SEC >> > > website.” I >> gave >> > > two separate examples of such, and you responded to one (FPKI) by >> saying >> > > the report was not public (even when it is made available >> > > publicly), >> and >> > > the other I didn’t see a response to. >> > > >> > > This might feel like nit-picking, but I think this is a rather >> serious >> > > point to work through, because I don’t think you’re fully >> communicating >> > > what you judge to be a “comparable world”, as it appears you are >> dismissing >> > > these examples. >> > > >> > > I can think of several possible dimensions you might be thinking >> > > are relevant, but rather than assume, I’m hoping you can expand >> > > with a >> few >> > > simple questions. Some admittedly seem basic, but I don’t want to >> take >> > > anything for granted here. >> > > >> > > 1) Are you/the WTTF familiar with these audit schemes? >> > > >> > > 2) Are you aware of schemes that require disclosing the relevant >> skills and >> > > experience of the audit team to the client? (E.g. as done by BSI >> > > C5 >> audits >> > > under ISAE 3000) >> > > >> > > 3) Are you aware of such reports naming multiple parties for the >> > > use >> of the >> > > report (e.g. as done by FPKI audits) >> > > >> > > 4) Are you aware of schemes in which a supplier requires a vendor >> > > to >> be >> > > audited, and ensures that the customer of supplier are able to >> > > access >> such >> > > audits as part of their reliance upon supplier? (Note, this >> > > doesn’t >> have to >> > > be limited to ISMS systems) >> > > >> > > I’m trying to understand what, given the prevalence of these >> practices, >> > > makes these instances *not* a comparable world, since it seems >> > > that >> helps >> > > move closer to solutions. >> > Ryan, I hope you are not suggesting I am dodging you points. That >> > would >> be absurd. Let me use different words as comparable world seems to be >> tripping you up. You are not providing a general/public distribution >> example to make your point so it is baseless. You are using a >> restricted opinion from EY and neither Ryan Sleevi nor Google are >> listed as the two intended users. The closest I have seen to support >> your desire to name individual auditors is in public company audit >> reports, which are housed on the SEC website. To be clear, of your >> two examples, one is an opinion, which is restricted, and the other >> represents the guidelines. Perhaps you have seen a public/general >> distribution report from your second opinion as I do not see it in >> this thread. I am aware, as mentioned previously, of the Federal PKI >> program desiring to know more about team members, but that is not >> listed in a non-restricted report, in a public/general distribution format. >> >> I can click on the URL and read it. This seems to be the very >> definition of public, even if the audit report says it is not for >> reliance upon by the general public. I fully appreciate that this may >> be a technicality in the world of auditing, but it is very confusing >> to those of us who are less familiar. >> >> > Jeff >> _______________________________________________ >> dev-security-policy mailing list >> <mailto:dev-security-policy@lists.mozilla.org> >> dev-security-policy@lists.mozilla.org >> <https://lists.mozilla.org/listinfo/dev-security-policy> >> https://lists.mozilla.org/listinfo/dev-security-policy >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
