Tag Archives: milestone

Software-Assessment-Project reached next milestone

Todays systemlog message marks the quantum leap in our about 10 months project work, to become the Software-Assessment area auditable.

As many Software-Updates are in the queue from the software developers, that needs testing and reviews by Software Assessors, the team started by end of last year with this project,

  • to build up a new ”controlled” testserver with authority by Software-Assessors
  • built up by the critical team as a Disaster Recovery testcase
  • a new central repository for all the upcoming software projects (including the New Software project BirdShack)
  • building a new test team running the software tests
  • and finalyze the process by a review of the patches by 2 Software-Assessors
  • document the patches, the testing, the review and the check by two Software-Assessors
  • to bundle the new Software-revision for transfer to the Critical team

The systemlog message signals, that the first tested and reviewed patches has received by the critical system webdb and is incorporated into production. A new tarball has been generated to build the next basis for applying the next patches.

So here my thanks goes to all the involved teams,

  • Software-Assessment-Project team
  • the new Software Testteam
  • the Critical Sysadmins team
  • and last but not least to the Software-Assessors from the Software-Assessment team

With all these people assistance, this project hadn’t be pushed to this milestone. Thank you Andreas, to build the project plan and the technical background, and also hosting the current testserver, Thank you Wytze for all your work to build the new testserver from scratch as identical as possible to the production server, to Michael, who assist us in deploying the new git repository and also assistance in deploying the Testserver-Mgmt-System, so everybody can start testing w/o the need of console access, Thank you Markus, for all your time and effort to deploy the repository and testserver environment and also your work together with Philipp as Software-Assessor, to finalyze the Software-Update-Cycle. Thank you Dirk for all your suggestions to move on with this project.

Some more work is todo:

  • adding a test-signer, so also cert related patches can be tested in the future (Andreas and Markus are working on this)
  • deploying a C(ontinous)I(ntegration) system for automated testing (Andreas is working on this).

Now the teams have to walk thru the list of open bugs, that needs to be pushed thru … First of all is the “Thawte” bug … to signal all users who’ve got their Thawte points transfered by the old Tverify program if they are effected by the points removal or if they are safe. The CCA-Rollout with a couple of patches, a list of new Policies and Subpolicies related patches (eg. PoJAM, TTP program), a list of Arbitration pushed patches, and so on …

So guys, lets have a party tonight, we’ve wiped out one of the biggest audit blockers!

SP to DRAFT — marks the milestone in Policy!

This weekend, the Security Policy goes into DRAFT. We’ve battled and we’ve won: consensus has erupted in policy group. Not only do we get our Security Policy, but SP going to DRAFT marks a major milestone for CAcert:

We now have a complete set of policies for audit !

We’ve been close before, but never the cigar. In early 2009, some audit work was done, but with gaps: the CPS and the “index” were missing. The CPS came into DRAFT in June 2009, it was close enough at the time. The “index” is called the Configuration-Control Specification (CCS), which is a rather clumsy name for such a simple thing. CCS is a list to all the assets that have to be audited, so it’s worth a little attention. The structure more or less looks like this:

Audit => Criteria (we call them DRC) => CCS (the index)

Then, with CCS in hand, the Auditor can find the parts needed:

                     --> Policies
       CCS ==----> critical systems
                     --> roles in control, etc

CCS was the missing link. Luckily the index CCS is relatively easy to write, if all the other policies and systems are clear, and this also means it was doomed to always be last, once the other policies were clear. A month back policy group pushed it through, we brought the CCS finally into its place as a (DRAFT) binding policy.

Which should have been the completion of our policy set for audit, but as CCS was finishing, the Board of CAcert Inc decided to veto the Security Policy, as they can under the rules (PoP 4.6). Now, much has been written about this drama in the maillists, and the debate did raise some serious questions at the time, but they can be left for another day. This week, then we in policy group are taking Security Policy back to DRAFT. Has anything changed? Here are the major points of change:

  1. The part about the Board Members having a background check has been removed. This was reasonable, as, on the whole, the ABC process is too clumsy for the Board, and the Board now has its own requirements to deal with conflicts of interest, courtesy of the new Associations Act 2009.
  2. Application Engineer is removed, and that capability is returned to the Systems Adminstration team leader. T/L can bring in a Software Assessor any time he needs one, and take on that risk, etc.
  3. One non-difference is that SP was still binding on the critical roles, because they accept the SP as their binding document when they are appointed. This is part of the process, as documented in Security Manual. The reason for this is that, under the principles of data protection, anyone who can access the data needs a special agreement, and in CAcert, the SP is that agreement.
  4. Meanwhile, SP goes back to being binding on the Community. Why would the Community need to be bound to Security Policy, when they can’t do anything wrong anyway? Well, because there are always errors, holes, bugs, omissions and short cuts. In any process! So, while we should fix these omissions, it helps to have the big stick of policy to wield as well. Just because you find a software bug doesn’t mean you can exploit it, and just because you have a title like “auditor” doesn’t mean you can stare at the private root key. We all have wider obligations, and SP is one of them.

Other than tighter wording, etc, that’s it. Welcome to our complete Policy set!

Which final comment brings us to the success of CAcert’s Policy project. It was 5 calendar years in the making, starting off with Christian’s original CPS, and it cost many Member-Years of effort. Some examples: The SP was probably a Member-Year of effort. The CPS is likely equal, the agreements and foundations (CCA, DRP, PoP, etc) another huge lump. I said CCS was an easy one to write, but “easy” still runs to around a Member-Month of effort. PoJAM, similar.

If we think how much a commercial company pays for a Member-Year of effort (100k, plus or minus), that’s a serious investment.

Thank your policy group, and help out with reading and voting!

35 decisions, 13 policies to DRAFT and beyond, 55 contributors. Here’s the top ten, a Hall of Fame, collected a wiki-scraping script I wrote last night:

Name # Decisions
Tomáš 10 p20100510,p20100426,p20100401,p20100119,p20100113,p20091108,p20091106,p20090706,p20090327,p20081016
Faramir 10 p20100510,p20100426,p20100401,p20100326,p20100120,p20100119,p20100113,p20091106,p20090706,p20090327
Lambert 10 p20100426,p20100401,p20100326,p20100113,p20091108,p20091106,p20090706,p20090327,p20090105.1,p20081016
Philipp D 9 p20100510,p20100426,p20100401,p20100113,p20091106,p20090706,p20090327,p20090105.1,p20081016
Pieter 8 p20100510,p20100426,p20100401,p20100306,p20100120,p20100113,p20091106,p20090327
Iang 8 p20100510,p20100426,p20100306,p20100120,p20100119,p20100113,p20091106,p20090706
Ulrich 7 p20100510,p20100426,p20100401,p20100326,p20100306,p20100120,p20100119
Ted 7 p20100510,p20100120,p20100119,p20100113,p20091106,p20090706,p20081016
Brian 7 p20100510,p20100426,p20100401,p20100119,p20091108,p20091106,p20090706
Morten 6 p20100510,p20100426,p20100306,p20100120,p20100119,p20100113

(That’s not a formal result, and it only counts voters from the last 2 years, many others did other things that are harder to measure.)

We now have a set of policies that not only deals with the criteria of the Audit (DRC), not only removes that critical path blockage of documentation for audit, but also presents the only honest, fair, presentable and sustainable policy set in the entire business. In my humble opinion.

This is a set of documents everyone can be proud of. On this foundation we can build. We can, for our Members, create business of real value, not just issue certificates that defy valuation to people who don’t understand their need.

Now, on to implementation and audit. Questions about the audit are questions about implementation, so don’t forget:

Do not ask when your audit is done, rather, ask how you, yourself, are doing your audit!

And now, you’ve got the full policy set, so you know what the Auditor is going to be looking for 😉