© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit To get CAcert Root into Browsers => Audit is required => which requires: management policies + practices review of business & systems (against policies and practices).

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit ➢ CAcert has two major business areas: ➔ Assurance ➔ Systems

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit a. Assurance Assurance Policy now is in full POLICY status ➔ It is binding on all Assurers The process of Assurance can be reviewed.

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit a.i Auditor on (ATE) Tour Assurers shall assure the Auditor == Evidence of Assurance to policy. verifies quality of assurance (Increased quality of assurance?)

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit a.ii In the absence of the Auditor A Senior and Experienced Assurer should stand in his stead and be assured by each Assurer. (If already assured, then she should instead oversite the assurance of another person) Make a statement that: „assurances were conducted to Assurance Policy” "Secondary evidence" in the audit process

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit a.iii The review of assurances the gathering of evidence is planned to be completed 16 th May Munich.

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit b. Systems Review of the systems was delayed by lack of a secure hosting service. The systems were moved 1 st October, 2008 from Vienna to the secure data center at BIT, a company in Ede, NL.

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit b. Systems (cont.) A new team of systems administrators Approval of the Security Policy to DRAFT mode => Binding on the systems administrators and the Access Engineers => now possible to review the systems against the policy.

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit b.i On-Site Inspection 1 st visit on 4, 5, 6 th May, 2009 warm-up: personnel, Roots, Access, inventory probably 1 st of 3 visits. Next scheduled mid-June

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit b.ii We still lack the CPS (which is nearly ready)

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 CAcert and the Audit b.iii Review of the software Innsbruck software camp Week 20 th April Serious difficulties in maintenance, improvement and securing Cannot form a conclusion over software New software development team, new design, new build

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background The audit criteria: DRC for "David Ross Criteria". David is a retired quality engineer He started Cacert's Audit He was called to Grand Jury duty

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background DRC has a strong feature: requires the ➔ Risks, ➔ Liabilities, and ➔ Obligations to be clearly stated to everyone!

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background This raised several huge barriers for the CA: what exactly are the R/L/O? who do they apply to? are they reasonable? and, how do we deal with them?

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background These barriers are subtle: ➔ DRC doesn't ask them to be fair, but ➔ disclosure of R/L/O makes us consider them but CAcert people want them to be fair. which means we have to deal with them!

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background One big result of this thinking process we required: ➔ a CAcert Community Agreement ● and it had to do following things:

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background a. make Members a mutually binding Community. b. to state the R/L/O c. to limit the liabilities ➔ 1000 Euros ➔ to *allocate the liabilities* back to the Members

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background How do we allocate the liabilities? ➔ By making our own „forum of dispute resolution“, ➔ agreeing to be bound to that resolution, ➔ writing a Policy to control that process: ==> Arbitration.

© CAcert, 2009 Ulrich Schroeter, Assurer Training Events, April 2009 Audit Background Summary: The original “Why” of Arbitration: ➔ Audit (DRC) forced disclosure of Liabilities ➔ simple fix: limiting ➔ complex fix: allocation ➔ the safe and cheap way to allocate is: ➔ to use our own Arbitration (Last section discusses „How“.)