The April 2009 report to the Community on Audit progress. See also: [[AuditPresentations|all others]]. [[Audit/CommunityReport20090119|Previous]]. [[Audit/CommunityReport20090623|Next and final]]. == 1. Systems == ||Critical Systems are now being reviewed by Audit.|| === 1.1 Review of Critical Systems === 1. At the meeting of [[Advisory/SysadmMinutes20090306|20090306]] we agreed that a. Security Policy was in good enough shape to push forward to DRAFT a. SP was a suitable document to control the critical systems a. critical systems team was now in good enough shape to consider review 1. We have agreed on a 1st audit visit in period 20090504-06. 1. Additional tasks that I will try and achieve are these: a. Check the escrow and protection of the top-level root. a. Talk to the Access Engineers: Rudi, Rudi and Hans. 1. My guess is that the review over systems will take around 3 visits. === 1.2. New Roots === 1. The new root and subroots are still awaiting some internal testing? 1. As discussed [[Audit/CommunityReport20090119|last report]] '''there should be a separate subroot for organisations'''. 1. It has also been pointed out that it would be nice to have a subroot for Assurers. Although not a necessary thing from Audit perspective, it would certainly improve many of the business issues. Whether it is a cost-effective way to proceed is open to discussion, but it might be created at the same time as the Organisation subroot. 1. The opportunity to create the new subroot(s) might come up around [[events/HAR2009|HAR2009]] if can collect enough people there. According to procedure, we need at least one Board director, one sysadm and one other. === 1.3. Team Participation === 1. Background Checking is now in place. a. The SP in DRAFT authorises the procedure. a. The procedure places the process before the Arbitrator, which gives a good measure of oversite (four eyes minimum) and is also a good use of the Arbitration concept. a. At least one Background Check is now in the pipeline. a. Once the background check is done, it is provided to the Board as advice. 1. Join the cacert-sysadm list and hang around there if you can help. 1. All critical positions are covered: a. (critical) System Administrators a. Access Engineers -- the Oophaga guys a. Support Engineers a. Software Assessors. == 1. Software == 1. In mid-April (last week), we brought together several developers for a week at a remote location in order to review the software. Cost for this was Euros 1400 (provisional). 1. Our intent was that out of this one week stint, we would have sufficient information: a. a review over the software, and b. a good plan to recommend the way forward. 1. The view of the team -- Mario Lipinski, Philipp Dunkel and Alejandro Mery -- was mostly negative. Although this does not say the software is insecure, it does say that it is too difficult to maintain, review and improve. 1. The team recommended a complete rewrite from scratch. To that end, [[https://dev.cacert.cl/wiki/birdshack/Work_History|the team did]]: a. a design exercise, actors, RESTful accesses, block structure, etc. a. three major blocks are identified: frontend website, business logic server, backend serial signer. a. for reasons best known to them, the project is codenamed '''BirdShack'''. a. much infrastructure was set up on a development machine [[http://dev.cacert.cl/wiki/birdshack/|BirdShack]]. 1. Coding has already started. Look out for how to help on the cacert-devel list. 1. Next big opportunity for software meeting after that is [[events/HAR2009|HAR2009]]. a. We are looking to make this event a bugfest: code up as much as possible. a. Sign up quickly for HAR2009 because the price goes up. a. but, given the intensity of coding needs, maybe we should do something else before that? Thoughts welcome... == 2. Policies == ||''Notification of the CCA to our Members is remains a '''critical''' hole.''|| === 2.1 The CAcert Community Agreement === || One Important step remains with the [[https://www.cacert.org/policy/CAcertCommunityAgreement.php|CAcert Community Agreement]]: || || ''' Members need to be notified. ''' || || [[RolloutCommunityAgreement|More on the wiki...]] || 1. Checkboxes have been added to most places on the online system. a. These are a stop-gap measure as they do not record the event. 1. A recent Arbitration [[Arbitrations/a20090303.1]] decision ruled that CAP forms can be done by writing out all the elements on a blank sheet of paper. This means that we do not need to necessarily enforce the CAP forms to be put on the main website. Hence, this goes off the list of things that need to be done for Audit, although each Assurer will still need to figure it out. 1. '''What remains is to notify the Members of the agreement.''' a. Some way of dealing with the big change needs to be done. a. The same pressure is felt with ATEs and with other issues: CAcert has no way to easily talk to its people. a. There was an old view that you could trust CAcert because it would never mail you. This view is dead; many things require us to mail out the people, the policies say this, and the time of fear-of-spam is over. Now we are in the world of social networking, and talking to your community is the new thing. === 2.2 The CPS === 1. The CPS has now been reviewed by a few more people. 1. It is still needy of attention. 1. Policy group can probably have a go at it any time. === 2.2 Security Policy === 1. After discussions in the Netherlands, we agreed to split the Security Manual into a fully controlled Security Policy, and a team leader controlled Security Manual. 1. Security Policy: a. It was sliced from the SM over a month of slicing and referencing by Philipp D, Wytze and self. a. We all reviewed the SP in great depth. a. It was presented to the board and policy group. a. The recent DPA issue raised the SP to the forefront. a. '''Policy group voted the Security Policy to DRAFT status''' [[PolicyDecisions|p20090327]]. a. This was the most popular vote ever, with 11 AYES. a. '''Security Policy is now binding on the Community'''. 1. A couple of new issues arose. a. Access Engineers (Oophaga people) are now covered by the SP. This was because the only way for it all to make sense was to treat Oophaga as totally transparent: to security, governance, HR, audit, etc. a. The SP and SM are written with DPA in mind. One of the provisions of DPA is that there has to be a contract between the "owner" of the data and the system security people who can get access to the data. SP and SM was written to fill this need, in that it includes the elements of the "standard" contract. a. the old NDA.txt that was used in the past was struck down by the Board in meeting 200903xx.y and replaced by the SP. 1. As SP is now in DRAFT, we can audit against it. a. Changes can still be done through the normal Policy method. a. Probably the best thing is for the audit process to kick in some changes, in the act of trying it out. a. That is planned for 04-06 May. === 2.3 Assurance === 1. The Assurance Policy has been put on the website at http://www.cacert.org/policy/AssurancePolicy.php which is its final long-term home. 1. Any exceptions to standard Assurance are now ruled by the full policy, so if there is anything you want to do in the future, get cracking on those subsidiary policies: a. The Exceptions: TTP, Super-Assurer, Junior, etc. Coming soon to a Policy debate near you. a. Code-signing: there is nothing here for this, so this may be a worry. The question here is whether the code-signing policy is to require any additional Assurance measures. If the CPS simply issues code-signing certs without any impact on Assurance, no need for a new policy. OTOH, until it is written down, there can be no code-signing in the new roots, so '''something needs to be written''' regardless. a. TTP: there is the Remote Assurance Policy as a ''work-in-progress''. a. Junior-Assurer and Junion-Member -- Sebastian and Philipp D have been looking at that. a. TVerify -- no policy seen so far, and the moment to shut it down is around 3rd May, if no subsidiary policy is written. a. Super-Assurer -- probably, the old Super-Assurer programme is dead. However, the AP leaves the way forward for the Board to approve additional experience points on a temporary basis. If giving more than 10 Assurance Points is the objective, this may be the way forward: a slightly less super-assurer can be approved by the Board, giving a temporary capability of 35 Assurance Points. If more is required, a subsidiary policy could get it up to 50 (which is now the maximum under all programmes). 1. '''We are now reviewing Assurance in operation.''' a. This involves going to [[comma/RegularCampaigns/AssurerEvents/UpcomingEvents|as many Assurance Events as I can find]]. a. At each, I observe the assurances. Each Assurer is checked for understanding of Assurance Policy. a. With enough checks over the breadth of events, we can rely on the statistical evidence to draw a conclusion over all Assurance. a. For those where I cannot go, we can rely on the report of the Event Organisor. There needs to be checks that the Assurance is done according to AP, and a statement to that effect in the report to the Events coordinator. a. You can help! Run an event, check the Assurance Policy, and let us know... [[comma/RegularCampaigns/AssurerEvents/UpcomingEvents|UpcomingEvents]] 1. Calendar is this: a. Before this current Spring Tour, Assurance events were observed in Vienna, San Diego, Hannover. a. Now done recently: Vienna and Innsbruck. a. Next on the list: Prague, Budapest, Paris, Ede (NLUUG), London and Munich. 1. At the last date in Munich, 16th May, we will conduct a '''mini-TOP on Assurance.''' More details later. === 2.4 Other Policy Areas === 1. For OAP. a. it is deferred for the moment a. If it all gets fixed with a new OAP and manual, Audit won't be the one to hold it back. a. there is a list of things to fix in OAP in [[PolicyDrafts/OrganisationAssurance|wip Policy Changes page]]. a. There is now a wip new form of Policy circulating. a. It is a lot of work to write the policies needed, get them approved, get them rolled out to the OAs, and then get them reviewed by Audit. || '''Organisation Assurance''' is deferred under current cycle. || == 3. Audit Thinking == === 3.1 The Current Cycle === 1. Audit is concentrating is now reviewing the Assurance practice over individuals. 1. The target is to check 6 countries. 1. When done, we may be able to do one of two things: a. deliver an Audit opinion over Assurance of Individuals, which would potentially mean that Assurance could be combined with other CAs. a. pending the review over systems, deliver an opinion that permits the subroot for Assured (Individual) Members to be used. 1. Once subroots go into operation, they would have to be carefully controlled by all participants, as well as by the code. a. This means that the addition of new sorts of certificates, or the weakening of the overall service in any way, will have ramifications beyond CAcert. == 4. Admin == 1. Costs. a. The cost of the software development meeting is around 1400 euros, from "work". a. The cost of the Assurance Spring Tour is also around 1400 euros, from "expenses". a. Expenses budget is pretty much exhausted. a. Current situation is summarised at [[AuditBudget]]. 1. The next 2-monthly [[AuditPresentations|report]] should be around July. ---- [[Audit/CommunityReport20090119|Previous]]. [[AuditPresentations|all]]. [[Audit/CommunityReport20090623|Next and final]]. ---- CategoryAudit