Before: Arbitrator UlrichSchroeter (A), Respondent: Jochim Selzer (R), Claimant: MarioLipinski (C), Case: a20130125.1

History Log

Original Dispute, Discovery (Private Part) (optional)

EOT Private Part

Discovery

Deliberations

  1. regarding open questions
    1. can the ABC passed over a non-critical-infrastructure admin?
      • no policy found that prevents an ABC process over any CAcert member
      • SP 1.1.2. Out of Scope ... defines 
        Non-critical systems are not covered by this manual, but may be guided by it, and impacted where they are found within the security context. Architecture is out of scope, see CPS#6.2.
        • "but may be guided by it" leaves room and doesn't prevent, to pass an ABC over whatever personal initiated
        • Once an ABC did pass over a person, the candidate may later move from one team to another without having to pass an ABC again. There are 2 known cases, where teammembers have been nominated to become teammembers of another team then the original that was requested for the ABC in the first time, to pass an ABC and later, after another team asks Board to approve a still ABC'd member to becoming member of another critical team. This means, an ABC will be passed only once per candidate. The nomination to a critical team is another scope, that has to be discussed and decided within the teams. If an ABC finishes with 'not applicable for the moment', this doesn't mean one cannot ask for a 2nd ABC. A current CoI may prevent passing an ABC today, but will succeed one day in the future where the CoI has gone.
    2. are there any other jobs that have non-implicit requirements passing an ABC?

      • from current state of SP, probably we have a flaw within the policy definitions, that misses the team that is needed for whatever New Roots & Escrow method selected.

      • From the old definitions of Roots escrow, originaly Board has been selected as the team having this task assigned. With the vetoed SP under motion m20100327.2 that identifies a clash with the CAcert Association rules, I'm trying to identify the team members of the Escrow process that is still not approved. As long there is still no Escrow method defined, that CAcert will use for the new roots under SP, as long we have the list of potential different Escrow methods defined in the New Roots & Escrow project in the wiki available. This includes as an example the multi-member-escrow method, that requires a couple of CAcert members, to hold parts of the keys.

      • From principle SP definition, such Escrow team members requires an ABC, despite the fact this isn't yet explicitely defined under SP.
      • From the old days development of SP, Board was selected and defined as this Escrow team. Nowadays, with the vetoed SP and removal of board, we have the requirements of such a team still undefined.
      • Maybe the simple solution would be to replace the definition under old SP 9.1.4.2. Coverage (later this section moved under SP 1.1.1.) from Board to Escrow team to prevent the clash of definition Board with the CAcert Inc rules, but this is speculative, as this is a Policy Group task.

      • Fact is, an Escrow team is still undefined under SP, only reference is SP 9.2.2. Backup and escrow -> The top-level root must be escrowed under Board control.

      • Under "Board control" doesn't mean, that each board member helds a part of the root key, but the escrow process is under control by the Board.
      • This means: if someone holds the root key or parts of it for escrow, SP defines in general personal to be under critical role, that requires an ABC. So an ABC needs to be passed over a personal that may become teammember of the not yet existing Escrow team.

      • Ok, maybe one day this New Roots & Escrow project will be picked up again and the project moves forward, probably Arbitration may becomes flooded with ABC requests over new Escrow team members if eg the multi-member-escrow method will be approved as the CAcert's applicable escrow method for their new roots. This multi-member-escrow method requires far more CAcert members ABC passed then we currently have yet passed. Each passed ABC personal will become a potential new roots escrow team member.

      • Passing more CAcert members through an ABC therefor is a recommendation in relation to the future escrow project.
  2. in the ABC interview, one question pops up, how a non-critical sysadmin can follow the SP requirement of the 4 eyes principle, as the sysadmin receives a request to create a new mailbox and executes this task as a single sysadmin.
    • The question is quite simple to answer:
    • Once the sysadmin receives a request - another party has still initiated the request. The sysadmin doesn't act on its own.
    • By executing the request that is confirmed by a team leader and reporting the actions taken, the case is documented. Two parties from 2 "teams" are involved in this process (the requestor, the teamleader and the sysadmin). So probably we have also the 6 eyes principle.
    • This is similar to procedures that critical sysadmins will perform, receiving a request from an arbitrator, executing the task and replying the request with an exec report.

  3. Another discrepance regarding previous topic araises out of question 14 of current ABC interview questionaire. This discovery is not specific to this running case. Many ABCs did pass, where the respondents had asked about the Security Policy. Some know where it is located, some know how to search for, but only a few still have read it before an ABC interview. Its a teamleaders obligation, to prepare a candidate for their role under critical aspects. But teamleaders probably aren't aware about this obligation. So one comes in mind, that teamleaders should start with some training in their area with the new candidates (-> training, one of CAcert's principles), especialy to ask the applicant to read the Security Policy before a candidate will be proposed as a candidate for the team to undergo an ABC. Ok, then question 14 probably makes no more sense, but this is only a refresh about the candidates knowledge ... The more is the principle understanding of the philosphy behind SP. Starting with some training in the ABC interview should be the fallback option, but not the default. This I've also discussed with (C) in an irc session, after the interview finished. To encourage the teamleaders, to start with some training and also remind this topic in the init mailing of ABC cases under topic 5. Instead of a request for the candidates PoV, request the CV, reference list and contacts infos and also propose to read SP before the interview starts. So we have 3 levels, the candidates will be spotted on, to occupy oneself with the Security Policy.

    1. by the teamleaders and their teams, starting with some training before asking for an ABC
    2. by the disputes init mailing - ABC specific point 5
    3. in the ABC interview
  4. Before I come to the question in detail "Should email sysadmins do undergo an ABC or not?" I have to discover potential other CAcert areas and teams, that relates to the same question.
    • We have at least two business areas, that didn't fall under SP, but has to deal with sensitive data - personal identifiable information (PII). This is:
      1. Non-Critical Infrastructure
        1. email (user mailboxes, mail exchanger)
        2. issue (Ticket system for Support, OA program, TTP program)
      2. Arbitration
      3. Supports Triage team is a bit special, read comments later
    • All these 4 teams have sometimes to deal with Privacy data. Data that relates to content under the critical system. Eg. for the ABC case, I have to request the Assurances received over the respondent from (Support). So this information is now disclosed to me, the Arbitrator and to the Casemanager of current running case.
    • From communitys perspective, its interesting to them, to know a bit more about the people that are working in these areas and probably comes in contact with sensitive data. So it makes me wonder, that Software-Assessors that have to deal with source code for the critical system have to undergo an ABC, where the code is freely available and reviewable, but the Email sysadmin and the Arbitrator, that comes in contact with email addresses of the users, the full usernames and their DoB and maybe other informations (in an ABC case, the Arbitrator receives a full CV and contact details of an applicant) have not to undergo an ABC.
    • Triage: Triage is the first step to bring in new team members into the Support team, that falls under SP. Triage is the pre-processing of all incoming tickets to Support under the ticket system. Before a new Triage team member gets access to any ticket, the new proposed candidate do undergo a training by a Support-Engineer including advises regarding Security Policy. This is a well defined and documented part of the training course for new proposed members to the Support team, before they will be passed to an ABC process, they'll have to undergo some time the Triage work, to receive advise about CAcert's structure, about Security Policy related areas and the Security Policy concept. The Triage concept has been implemented back in end 2009, beginning 2010 after Support did crash. A Triage team member, never gets access to the support console before the ABC process will pass. Also a Triage member has no access to the Support queue in the ticket system. The only view a Triage member gets is the individual ticket that receives Support, before its been processed to another queue. So here the Triage member has the same view to individual emails/tickets as an email sysadmin may probably have. The difference: the Triage team member is probably on the way to an ABC process, the email sysadmin is still part of the non-critical infrastructure team, that currently doesn't require any ABC. The Triage member status is a temporarely one, the Email sysadmin is a fixed state in relation to a pre ABC processing. The Triage member is under supervising by a Support-Engineer, the Email sysadmin is not under supervising by any experienced teammember or teamleader.

    • ABC requirements From the public relations view, ABC'd people in the critical and core teams of a CA brings some advantage that people can trust. The difference between the critical teams that falls under Security Policy with an ABC requirement and teams that don't fall under SP is the starting process. For the critical teams, the team makes a suggestion for a new teammember and the teamleader proposes the new candidate to pass through ABC before board for nomination. The team members of other core teams have the option to initiate an ABC by theirselves or ask their teamleader to initiate an ABC dispute. Members of the non-critical core teams can volunteer for an ABC. This can be before they become teammembers of a core team or it can be later, once they are still team members. Its in each members decision to volunteer for an ABC or not.

  5. Another aspect is, if we open ABC processing also for non-critical teams we potentialy increase the workload to Arbitration. Arbitration is still running under a huge backlog. With more ABC cases, the chance to decrease the backlog becomes more and more back in distant.
    • So one question araises: what is the advantage or disadvantage of the opening for ABC'd people in core, non-critical teams in relation to the increase of workload for Arbitration?
    • From the perspective I've discovered above, that every ABC'd candidate can easily switch from one team to another without a new ABC process, with opening of ABC cases for core and non-critical teams, we increase the members base of resources, that are able to easily step in into each other role, including critical teams. To become a member in a critical team still requires one more step: nomination by the teamleader and appointment by board. But with an increased resources base, its easier to fill in vacant roles that requires attention. From this PoV moving forward with an opening for ABC processing for core and non-critical teams is an advantage to CAcert in the whole. Currently the Escrow project didn't got that high attention, but one day it may become and then, dependent on the Escrow method decided, Arbitration may become flooded with a heavy load of ABC requests. So from current perspective its easier to handle some ABC cases along with other cases over a longer time then to stress Arbitration with a big count of ABC cases at once. So passing ABC's also for core and non-critical teams has more an advantage then a disadvantage.
  6. Now coming to the detailed view: Does Email sysadmins requieres an ABC?

    • To answer this question, we probably have to turn around the question to find an answer by constructing theoreticly cases. What is the most possible damage in a case of an incident? once a critical sysadmin goes wild or an email admin goes wild? (-> concept from risk analysis)

      1. An Email admin can potentialy read the content of the emails passing through the system. This may be personaly identifyable data, this can be logs. If an Email sysadmin tries to manipulate data, eg. delete an email, delete a logfile, this has no impact to the critical database as the critical database is on another system and is still under control of critical teams. If the Email sysadmin discloses data from email contents, this is subject to an Arbitration case against the Email sysadmin. The impact is a reputational one regarding non-critical systems. But the (critical) CA system is still on the save side.
      2. If a critical sysadmin goes wild, the manipulation of data has a direct impact to the critical database. We have to do with data of identities. Manipulation of records in the critical database set is another quality then manipulating emails. Also to disclosure of parts or in a whole of the critical database or selling data impacts the CA in the whole. So the impact is the most heaviest one a CA may have and results in a broke of the CA.

    • So critical and critical can be quite different in quality to an impact. Its not on discussion, that the email systems are critical systems under business view, but this depends on the business. From CAcert's business view, the most critical system is the critical database that contains data related to identities and this is not located within the email system. For an example: a company that business is research the email communication is far more critical, as patents may be disclosed via email that may result in a heavy loss of money. Same for all companies, where transfer of informations by email is part of their business and directly relates to the companies income (-> financial transactions). For CAcert's business, running a CA, the "critical" system is the Webdb system. The email system is a communication channel that may transport sensitive data, but isn't the core system that helds the critical database.

  7. The Status of Webdb and other systems

    1. Security Policy defines under 1.1. Motivation and Scope

      • "This Security Policy sets out the policy for the secure operation of the CAcert critical computer systems. These systems include:
        1. Physical hardware mounting the logical services,
        2. Webserver + database (core server(s)),
        3. Signing service (signing server),
        4. Source code (changes and patches).
      • The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual."

    2. Security Manual: 1.1 - no addtl. systems defined

    3. CAcert's Management Assertion defines: "CAcert Inc. operates Certificate Authority services for and on behalf of registered members (Members) within CAcert’s community at large (Community)". So CAcert's business is to run a CA but isn't to run an Email system.

    4. Regarding Intellectual Property Rights CPS defines under 9.5.5. Certificates and Roots: "CAcert asserts its intellectual property rights over certificates issued to Members and over roots." and under CCA 4.4 Not Covered in this Agreement: "Intellectual Property. This Licence does not transfer any intellectual property rights ("IPR") to you. CAcert asserts and maintains its IPR over its roots, issued certificates, brands, logos and other assets. ...". The Roots and certificates are part of the critical system, but aren't part of the email system. CAcert's Email system is a community droven system at a lower critical level then the Webdb system, that is under control of SP.

    5. From the business PoV: For CAcert is running their own Email system a nice to have feature, but is not a requirement to run the CA.
    6. Despite the fact that SP 1.1.2. Out of Scope says "Non-critical systems are not covered by this manual" .. its revealed in the next sentence: "... but may be guided by it, and impacted where they are found within the security context". So following SP for Email system is not explicitly forbidden, it is to read as "optional". If SP will not be followed by Email sysadmins (eg reporting of incidents), there is no reason to file a dispute and seek for Arbitrators review on any sysadmins action. But doing so is no reason, to be rejected by Arbitration as not responsible for if once filed as a dispute.
  8. The Status of Email System according to CAcert Policies

    • CCA defines for members under 2. R/L/O, especialy under 2.3 

      •     2.3 Obligations
      You are obliged
      [...]
      3. to submit all your disputes to Arbitration (DRP => COD7).

    • and under CCA 2.5 Security 

      •     2.5 Security

CAcert exists to help you to secure yourself. You are primarily responsible for your own security. Your security obligations include
     [...]
     2. to keep your email account in good working order,

    • further definition under CCA 3.5 Communication 

      •     3.5 Communication

Notifications to CAcert are to be sent by email to the address support at CAcert.org. You should attach a digital signature, but need not do so in the event of security or similar urgency.

Notifications to you are sent by CAcert to the primary email address registered with your account. You are responsible for keeping your email account in good working order and able to receive emails from CAcert.

Arbitration is generally conducted by email.
    • So what we want from our members to be obliged to, we also have this same obligation, to keep our email system in good working order
    • This PoV reopens the question, if the Email system is a critical system or not.
    • CAcert's internal Arbitration is a key concept in the whole Policy framework. It works for administrative issues, it is a fallback option for all undefined issues and also a fallback option for policies in question
    • That the email system is a business critical system is NOD, but also a running Arbitration system is business critical.
    • Thinking deeper, all arbitration team tools (email, wiki for arbitration files, OTRS ticketing system) are also business critical systems for Arbitration.
    • So probably we have to set many of our non-critical systems to critical state?

    • Ok, separate critical from non-critical systems was an audit project, so also definition of critical and non-critical systems was an audit task, that results in current state as shown under System Administration: Systems Overview

      • Where can we found a definition, what qualifies for critical and what qualifies for non-critical in above list?
      • Was it decided by a board motion?
      • Is it a game of dice?
    • The answer on the question what systems are defined critical and which systems are defined non-critical has been answered by former auditor in an email reply

      • A summary can be found under: System Administration: Systems - Definitions

      • and references to Security Policy (see deliberations 7.1 and 7.2)

        • Security Policy defines under 1.1. Motivation and Scope

          • "This Security Policy sets out the policy for the secure operation of the CAcert critical computer systems. These systems include:
            1. Physical hardware mounting the logical services,
            2. Webserver + database (core server(s)),
            3. Signing service (signing server),
            4. Source code (changes and patches).
          • The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual."

        • Security Manual: 1.1 - no addtl. systems defined

    • From Audit perspective and Community PoV - redefining non-critical systems to critical systems means: increase of audit task and checklist. This relates to an increase of audit costs.
      1. From Communities PoV, an increase of audit costs will not be helpful to the Community (currently its still an open question) to get an audit passed.
      2. What is the gain, moving CAcert's email system from non-critical to critical?
        • Moving CAcert's email system from non-critical to critical places procedures and handling of the Email system under the SP regime. This means, Email sysadmins must have to undergo the ABC process
      3. What does this mean for Audit?
        • Moving CAcert's email system from non-critical to critical means, that an addtl. system needs to be audited by the systems audit (Audit over CA) process (review all systems that falls under SP regime)
      4. What is the difference if the Webdb or Signer goes offline vs. if the Email system goes offline?
        • An Email system outage may happen (one day). To recover the CAcert email system but is less a problem in relation to recovery of the Webdb/Signer system.
        • An outage of the Email system for eg. 2 or 3 days is less a problem then an outage of the signer.
        • CAcert Inc's main business, running a CA is not affected by an outage of the Email system.
        • Ok, notifications to members cannot be sent, but renewal notifications will be sent 45 days ahead of expiering certificates.
        • Urgent responses to notifications sent to CAcert still have an approximately response period of ~14 days left
        • Moving CAcert's email system from non-critical to critical doesn't help in the event the system requires a recovery

Ruling

The ruling I've split in 3 parts to answer the different questions, that come out of this ABC request

  1. Ruling over ABC requests in general, not only covered by SP specific roles
  2. Ruling to ABC request over Jochim Selzer
  3. Recommendations to teamleaders and Arbitration team for future ABC requests

Part 1

The original request "ABC over Jochim Selzer" is not intended to be requireded as per SP definition, so therefor the ruling has to cover first the question, if ABC requests that aren't intended for a critical role falling under SP can be handled by Arbitration.

As found in the long deliberations, we have issues, there it makes sense, to have ABC'd members at hand, to be nominated to a new team (eg. Roots Escrow team) without prior explicit nominitations. The nomination procedures can by simply turned around. First pass as many ABC's, then forward request for nomination of ABC'd members to a team falling under SP to Board to receive their final nomination to a team. This procedure follows common practice in Assurance area, where bonafide Assurers gets their first educated assurance in a F2F meeting and later fullfils the requirements for a specific job (-> become a CAcert Assurer). We also had a precedent case, where an ABC'd member moved from one team to another team by simply one board motion.

SP 1.1.2. Out of Scope defines: "Non-critical systems are not covered by this manual, but may be guided by it" This doesn't prohibit ABC processes over members, so passing an ABC process over a member is identified to be optional (to non-critical roles). So if a member agrees to the ABC process or requests an ABC process over his own (similar to the request for assurance), CAcert is on the save side. After the ABC process has been passed, the candidate can be nominated by whatever team bound to SP, by passing step 2 of the two step nomination procedure for critical roles by Board nomination (SP 3.4.2. Special Authorisation and SP 9.1.1. Roles and responsibilities)

So here I come to the following ruling: Arbitration cannot reject a request for ABC over a member 'cause the members current role within CAcert doesn't require it and Arbitration has to pickup whatever ABC over XYZ request. There is no reason given (SP 1.1 doesn't qualify for this, as its put into perspective by SP 1.1.2), to reject such a request.

In the deliberations process, while reviewing events and jobs that have non-implicit requirements passing an ABC, I've stumbled over a missing definition for an Escrow team for the roots in the Security Policy, especialy since Board has been removed from the "required to undergo an ABC" list of Covered Personnel (SP 1.1.1) from SP in the SP vetoed process [1], [2], [3]. This topic is not subject to this Arbitration, but I recommend, that Policy Group reviews SP and rethinks about a new definition of an Roots Escrow team.

At least the New Roots & Escrow project probably requires as many ABC'd members. This gives the reason, to continue with this arbitration process.

So the main question: are there any other jobs that have non-implicit requirements passing an ABC? is to answer with YES.

The question, if this also covers Email admins, I come to the conclusion, that its nice to have Email admins ABC'd, nice for CAcert's reputation, nice to the Community, nice to the world, but from current deliberations, there is no implicit reason given, to move over the Email systems to status Critical, and therefor there is no implied requirement to have Email admin's ABC'd.

SP has no explicit section, who is responsible to define systems and services that falls under SP regime except section SP 9.4. Outsourcing "Outsourcing of critical components must be approved by the Board" - so in reverse, Board's responsibility is also to define systems and services as business critical. This is covered by the https://svn.cacert.org/CAcert/CAcert_Inc/Agreements/ManagementAssertion.html "CAcert Inc. operates Certificate Authority services for and on behalf of registered members (Members) within CAcert’s community at large (Community)." There exist one precedent board motion, to define addtl. services / systems to be critical and to fall under the SP regime [4].

Board didn't yet defined the email systems as business critical. Under running audit back in 2008/2009 thoughts was to seperate criticial from non-critical systems, so that audit only has to cover the essential critical systems as listed under Systems Overview that are required to undergo an audit process (see also further references [5] - [10]). In AGM report 2008 [11] only 2 systems are named to be "critical" -> "This process has been delayed for the CAcert critical servers (user database and signing server)". In board motion m20110501.2 new critical systems had been defined so that current state is documented under Systems Overview

One may argue, what is with privacy and security of the email system? The Privacy and Security topic is covered via CCA. In case of a privacy issue or security issue, it requires to be referenced to Arbitration -> file a dispute (Arbitration is our global weapon / fallback option for any unforseen issue). It can be assumed, that all non-critical sysadmins are fully assured, have passed the CATS test, and gave some assurances. So they've agreed to the CCA and therefor bound into Arbitration.

So I hereby come to the following ruling: There is no explicit and no implicit reason given, that requires an ABC process over Email admins. All potential issues are covered by either SP guidance or Arbitration. But I leave it open to each email admin's choice, to accept or request an ABC process according to SP 1.1.2.

Part 2

Part 2 of the ruling covers the ABC over Jochim Selzer.

According to Part 1 ruling, I conclude, that Jochim Selzer accepted the ABC dispute and accepted to undergo the ABC process.

The interview did happen at Fosdem 2013, Bruessels, 2013-02-03 in a face-2-face meeting.

Part 3

Not only current case shows, that proposed new team members to critical roles falling under the SP regime, did not undergo any training by the team leaders before the ABC process has been started.

This is an issue in the ABC interview as it stretches the time required to pass an ABC interview. It also obsoletes some questions in the interview, as the knowledge transfer has to be done in the interview.

  1. I recommend to the teamleaders of critical teams falling under SP starts with some training, before t/l's proposes a new teammember and initiates an ABC request. At least advises the new proposed teammember to read the Security Policy and the Security Manual before they'll start with a dispute filing.
  2. I also recommend to the Arbitration team, to enhance the init mailing in ABC cases with a sidenote, to start reading SP/SM before the ABC interview starts so the respondent becomes familiar with the CAcert specific Security policies and handbooks (still added to the Arbitration training lesson [12])

Frankfurt/Main, 2013-05-01

[1] https://wiki.cacert.org/PolicyDecisions#p20100326

[2] https://community.cacert.org/board/motions.php?motion=m20100327.2

[3] https://wiki.cacert.org/PolicyDecisions#p20100327

[4] https://community.cacert.org/board/motions.php?motion=m20110501.2

[5] https://wiki.cacert.org/AGM/TeamReports/2010/Audit

[6] https://svn.cacert.org/CAcert/CAcert_Inc/General_Meetings/AGM-20100130/CAcert_Annual_Report_2009.pdf

[7] https://blog.cacert.org/2010/10/489.html

[8] https://wiki.cacert.org/EmailBoardDecisions2008-09#m20090422.1
[9] https://lists.cacert.org/wws/arc/cacert-sysadm/2009-03/msg00114.html
[10] https://wiki.cacert.org/EmailBoardDecisions2008-09#m20090422.1
[11] http://svn.cacert.org/CAcert/CAcert_Inc/General_Meetings/AGM-Nov2008/CAcertInc_Yr2008BoardReport.html
[12] https://wiki.cacert.org/Arbitrations/Training/Lesson08
[13] https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html
[14] http://wiki.cacert.org/SecurityManual

Execution

Similiar Cases

a20091209.1

Arbitrated Background Check over Wolfgang Kasulke

a20091215.1

Arbitrated Background Check over Martin Schulze

a20120211.1

Arbitrated Background Check over Marek Michal Mazur

a20091202.1

background check for support crew Michael Tänzer

a20100116.1

Arbitrated Background Check over Markus Warg

a20100908.1

Arbitrated Background Check over Bernhard Fröhlich

a20120418.1

ABC Request over Martin Simons

a20120703.1

Arbitrated Background Check over Benny Baumann

Arbitrations/a20130125.1 (last edited 2013-11-27 00:02:32 by UlrichSchroeter)