Thank you for responding on behalf of ETSI ESI and ACABc! I believe that this is an important topic and I hope that ETSI ESI and ACABc members will continue to participate in the discussion.
On Thu, Aug 16, 2018 at 11:11 AM clemens.wanko--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear all, > this is a joint response from ETSI ESI and ACABc: > > ETSI have published a supplement to its audit requirements specifically to > address specific requirements of Mozilla, and other CA/Browser Forum > members, for auditing Trust Service Providers that issue Publicly-Trusted > Certificates TS 119 403-2. This is available for download at: > https://www.etsi.org/standards-search#search=TS119403-2 > This is extremely helpful in normalizing ETSI Audit Attestations and ensuring that they contain the basic information that Mozilla requires, but it provides no guidance on documenting non-conformities. > > > With regard to the treatment of non-conformities it says in PTA-4.3-08: > The Audit Attestation shall be issued only if no critical non-conformities > are identified. > > > Yes, as I mentioned in my original email, this is the fundamental concern I have with ETSI audits: qualified Audit Attestation reports cannot be issued. I do not even understand how it is possible for ETSI auditors to provide an unbroken sequence of period-of-time Audit Attestations if a "critical non-conformity" occurs. Apparently once the non-conformity is remediated it is no longer "critical"? This process gives relying parties no visibility into the problems identified by ETSI audits. > > ETSI audits do cover the CA incident management. That includes the whole > process including the timely treatment of incidents as well how to > guarantee proper and comprehensive responses to incidents. In ETSI EN 310 > 401 corresponding requirements are not only provided directly by section > 7.9 Incident Management but also through the requirement for a ISMS as > stated in section 5. Assessing that, the ETSI auditor will look at the CA > incident treatment during the Stage 1 as well as during the Stage 2 onsite > part of the audit. This includes the treatment of Bugzilla and cert.sh > listed issues. Incidents closed by the CA may have resulted in a change in > the CA operations. In such cases the auditor checks that the changes are > functioning correctly as defined by the CA. In that way the auditor is > assessing the incident management as such including possible measures taken > to avoid such incidents in the future and at the implemented measures > itself. > > > Good. But if, for example, a CA were to repeatedly and systematically fail to respond to incident reports within 24 hours. Would that non-conformity appear on the Audit Attestation? This has appeared as a qualification on a number of recently completed WebTrust audit statements. > > Another matter is the question of how to handle security related incidents > and the counter measures taken by a CA in audit reports. In order to keep > the security issue confidential as well as the details of the measures > taken by the CA, the accredited CABS (ETSI auditors) decided to document > such findings in their detailed audit reports. These detailed reports list > all relevant non conformities and the counter measures taken by the CA. It > is handed over to the CA in addition to the audit attestation. Based upon > that detailed report, the ETSI auditor will compile the Audit Attestation > as the browsers have it in their hand. The contents of the Audit > Attestation as summary document was agreed upon between ACAB’c and the CA/B > Browser Forum. If you regard it helpful to add information about the audit > results gained in the area of the CA incident treatment, we can certainly > discuss that. We then should reach a common agreement on what exactly we > add. > > Yes, this would be helpful information, and I agree that there should be a discussion resulting in auditor guidance on what to report to ensure that we get consistent information from all auditors. > > > We certainly believe however, that it is not advisable to publish detected > weak points. E.g. there might be findings in the way that the CA has NOT > correctly treated an incident. In that case the ETSI auditor will document > such findings and will not issue a positive report as well as no Audit > Attestation. The CA is then obliged to immediately install appropriate > counter measures which again will be judged by the auditor. Only if the > counter measures are rated sufficient in coverage and suitability by the > auditor, he will issue a positive report and an Audit Attestation. > > > Any sufficiently serious vulnerability should of course be fixed immediately. Once it has been fixed, there is value in disclosing the problem. It provides relying parties with information on the risks they are taking in trusting the CA and can result in the development of better practices across the industry. This is consistent with Mozilla's incident response guidance [1]. > > Regards > Clemens > > - Wayne [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
