* Case Number: a20130125.1 * Status: closed * Claimants: MarioLipinski * Respondents: Jochim Selzer * Initial Case Manager: AlexRobertson * Case Manager: MartinGummi * Arbitrator: UlrichSchroeter * Date of arbitration start: 2013-02-02 * Date of ruling: 2013-05-01 * Case closed: 2013-11-27 * Complaint: ABC on Jochim Selzer * Relief: TBD Before: Arbitrator UlrichSchroeter (A), Respondent: Jochim Selzer (R), Claimant: MarioLipinski (C), Case: a20130125.1 == History Log == . 2013-01-26 (issue.c.o) case [[https://issue.cacert.org/otrs/index.pl?Action=AgentZoom&TicketID=211505 | s20130125.78]] . 2013-01-26 (iCM): added to wiki, request for CM / A . 2013-02-02 (A): I'll take care about this case as (A) and MartinGummi as (CM) . 2013-02-02 (A): sending opening email to (C), (R), (iCM), (CM), (Arb mailing list) . 2013-02-02 (A): sending init mail to (C), (R), w/ request for CV/reference list from (R) . 2013-02-02 (R): accepts CCA/DRP under this arbitration . 2013-02-02 (R): sends in CV/reference list . 2013-02-02 (A): request for contact information from (R) . 2013-02-02 (R): sends in requested contact information + CV + reference list . 2013-02-03 (A): ABC interview did happen @ [[events/FOSDEM2013|FOSDEM 2013]] with (R), Dirk as interviewer/observer, MartinGummi (CM) as trainee for ABC interviews and (A) . 2013-02-04 (A): minutes made by Dirk reviewed. Made minor corrections (participients, location), structural correction, sending rev2 to (Dirk), (CM) for review and confirmation . 2013-02-04 (CM): typo in minutes reported . 2013-02-04 (A): request to (Support): ABC procedure 2.1 Assurances, Assurances rcvd by (R) . 2013-02-04 (A): irc talk with (C) . 2013-02-05 (Support): [s20130204.77] sends the requested infos over (R) . 2013-02-09 (A): sending discovery and first deliberations to (C), (R), (Arbitration mailing list) for review and comments == Original Dispute, Discovery (Private Part) (optional) == * '''Link to Arbitration case [[Arbitrations/priv/a20130125.1|a20130125.1 (Private Part)]], Access for (CM) + (A) only)''' <> ==== EOT Private Part ==== == Discovery == * Status of (R) (according to [s20130204.77]) * (R) received over 50 assurances (fully assured), gave over 50 assurances (experienced assurer); stopped counting as there are far more assurances received/given * passed the co-auditor requirements check (senior assurer, co-auditor) * [[Assurance/Co-Auditor|List of Co-auditors]] * open questions * can the ABC passed over a non-critical-infrastructure admin? * are there any other jobs that have non-implicit requirements passing an ABC? * [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|Security Policy (SP)]] {{{ 1.1.1. Covered Personnel Critical roles are covered. These roles are defined as: o Access Engineer o Systems Administrator o Support Engineer o Software Assessor 1.1.2. Out of Scope 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. 1.2. Principles Important principles of this Security Policy are: o dual control -- at least two individuals must control a task o four eyes -- at least two individuals must participate in a task, one to execute and one to observe. o redundancy -- no single individual is the only one authorized to perform a task. o escrow -- where critical information (backups, passphrases) is kept with other parties o logging -- where events are recorded in a file o separation of concerns -- when a core task is split between two people from different areas o Audit -- where external reviewers do checks on practices and policies o Authority -- every action is authorised by either a policy or by the Arbitrator. Each task or asset is covered by a variety of protections deriving from the above principles. }}} * New Roots & Escrow project * project has started, but its still not finished, especialy the Escrow method to use is not yet approved by either policy group, nor CAcert Inc board * [[Roots/NewRootsTaskForce|New Roots Task Force]] * [[Roots/EscrowAndRecovery|Overview of the Escrow project and methods]] * Escrow methods that requires far more CAcert staff * [[Roots/EscrowAndRecovery/MultiMemberEscrow|Escrow method: Multi Member Escrow]] * [[Roots/EscrowAndRecovery/ActorPassword|Escrow method: Actor Password]] * Different audit criterias (-> [[http://rossde.com/CA_review/|DRC]]) that effects human resources (-> CAcert staff) * C.3.d - The root certificate private key is stored by the CA and not by any outside party. * C.3.f - The root certificate private key pass-phrase (or parts thereof) is known only to CA personnel. * C.3.h - Provision is made to prevent loss of use of the root certificate resulting from the loss of one key person. * C.3.i - Use of the root certificate private key requires cooperative action by at least two CA personnel. * A pre-revision of SP includes under 1.1.1. Covered Personnel -> Board * This has been vetoed by Board in 2010 ([[https://community.cacert.org/board/motions.php?motion=m20100327.2|m20100327.2]] (veto over Security Policy board background checks)), so Board has been removed from the list of personal who requires an ABC * lastest revision of SP: [[PolicyDecisions#p20100510|p20100510 Security Policy to DRAFT]] rev 1918 * further related policy decisions * [[PolicyDecisions#p20100401|p20100401]] VETO takes a policy to WIP Document * 20100327 Remove Board background checks from DRAFT Security Policy -- VACATED {{{ Daniel Black: Identified that board background checks conflict with Association Rules This purported decision does not reach the standards of Policy on Policy and and is vacated 20100330. If any further deliberations are required they should be done by a proper vote before policy group. Board should abstain. Elsewise, refer to dispute resolution procedures in PoP. }}} * Board motion [[https://community.cacert.org/board/motions.php?motion=m20100327.2|m20100327.2]] {{{ veto over Security Policy board background checks Resolved that the board, in accordance with Policy on Policy 4.6, exercises its veto authority over the DRAFT Security Policy and requires the removal of a background check of board members. The board objects as this policy component as it is a control over board membership qualifications, that is fully within the domain of the rules of the CAcert Incorporated association and not the policy group. }}} * [[PolicyDecisions#p20100326|p20100326]] Security Policy to remain in DRAFT * Keep SP in DRAFT for another period, and re-work those BLUE sections. * Security Policy remains in DRAFT * rev 1855 - from [[https://community.cacert.org/board/motions.php?motion=m20100327.2|m20100327.2]] (veto over Security Policy board background checks), this policy is vetoed and reverts to WIP. * [[PolicyDecisions#p20090327|p20090327]] Security Policy to DRAFT * rev 1237 - many changes suggested by policy group now incorporated, ready for DRAFT, should take out some sections. * Main differences in SP revisions rev 1237 vs. rev 1918 concerning ABC, Board, Escrow * 3.4.2. Special Authorisation * Old: 3.4.2. Special Authorisation || List Name || Who || Purpose of access || Relationship || Manager || || Physical Control List || Access Engineers || control of access by personnel to hardware || exclusive of all other roles || Board of CAcert (or designee) || || Physical Access List || Systems Administrators || hardware-level for installation and recovery || exclusive with Access Engineers and Software Assessors || Board of CAcert (or designee) || * New: 3.4.2. Special Authorisation || List Name || Who || Purpose of access || Relationship || Manager || || Physical Control List || Access Engineers || control of access by personnel to hardware || exclusive of all other roles || Access team leader || || Physical Access List || Systems Administrators || hardware-level for installation and recovery || exclusive with Access Engineers and Software Assessors || Systems Administration team leader || * 9.1.1. Roles and responsibilities * Old: 9.1.1. Roles and responsibilities * New: 9.1.1. Roles and responsibilities * Arbitrator: conducts ABCs. Authorises exceptions to policy. (added) * 9.1.3. Process of new Team Members * Old: 9.1.3. Process of new Team Members {{{ New team members need: * Recommendation by team leader * Independent background check * Authorisation by Board }}} * New: 9.1.3. Process of new Team Members {{{ New team members need: * Recommendation by team leader * Arbitrated Background Check ("ABC") * Authorisation by Board }}} * 9.1.4. Background Check Procedures * Old: 9.1.4. Background Check Procedures {{{ Background checks are carried out with full seriousness. Background checks must be conducted under the direction of the Arbitrator, with a separate Case Manager to provide four eyes. }}} * New: 9.1.4. Background Check Procedures {{{ The Arbitrated Background Check ("ABC") must be conducted under the direction of the Arbitrator, with a separate Case Manager to provide four eyes. ABCs are carried out with full seriousness. }}} * 9.1.4.1. Scope * Old: 9.1.4.1. Scope {{{ An investigation should include examination of: * realm-specific knowledge * realm-specific understanding of good security practice * history of activity within Community * reputation and standing within Community * provided references * conflicts of interest }}} * New: 9.1.4.1. Scope {{{ An investigation within ABC should include examination of: * realm-specific knowledge * realm-specific understanding of good security practice * history of activity within Community * reputation and standing within Community * provided references * conflicts of interest }}} * 9.1.4.2. Coverage * Old: 9.1.4.2. Coverage {{{ A background check is to be done for all critical roles. The background check should be done on all of: * Systems Administrator * Access Engineers * Software Assessor * Support Engineer * Board }}} * New: 9.1.4.2. Coverage {{{ ABC is to be done on every individual in a critical role. See §1.1.1. }}} * 9.2.2. Backup and escrow * Old & New: 9.2.2. Backup and escrow {{{ Root keys must be kept on reliable removable media used for that purpose only. Private Keys must be encrypted and should be dual-encrypted. Passphrase must be strong and must be separately escrowed from media. Dual control must be maintained. The top-level root must be escrowed under Board control. Subroots may be escrowed by either Board or Systems Administration Team. }}} == Deliberations == 1. regarding open questions a. 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. a. 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 [[https://community.cacert.org/board/motions.php?motion=m20100327.2|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. 1. 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. 1. 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 1. by the disputes init mailing - ABC specific point 5 1. in the ABC interview 1. 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 a. email (user mailboxes, mail exchanger) a. issue (Ticket system for Support, OA program, TTP program) 1. Arbitration 1. 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. . {{attachment:abc-requirements-pic1c.jpg|ABC requirements|width=400,align="right"}} 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. 1. 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. 1. 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) a. 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. a. 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. 1. The Status of Webdb and other systems 1. [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|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, 1. Webserver + database (core server(s)), 1. Signing service (signing server), 1. Source code (changes and patches). . The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual." 1. [[SecurityManual|Security Manual]]: 1.1 - no addtl. systems defined 1. [[https://svn.cacert.org/CAcert/CAcert_Inc/Agreements/ManagementAssertion.html|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. 1. Regarding Intellectual Property Rights [[https://www.cacert.org/policy/CertificationPracticeStatement.php|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 [[https://www.cacert.org/policy/CAcertCommunityAgreement.php|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. 1. 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. 1. 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. 1. The Status of Email System according to CAcert Policies * [[https://www.cacert.org/policy/CAcertCommunityAgreement.php|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 [[https://www.cacert.org/policy/CAcertCommunityAgreement.php|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 [[https://www.cacert.org/policy/CAcertCommunityAgreement.php|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 [[SystemAdministration/Systems|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: [[SystemAdministration/Systems#definitions|System Administration: Systems - Definitions]] . and references to [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|Security Policy]] (see deliberations 7.1 and 7.2) * [[https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html|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, 1. Webserver + database (core server(s)), 1. Signing service (signing server), 1. Source code (changes and patches). . The Committee of CAcert, Inc. (hereafter, "Board") may add additional components into the Security Manual." * [[SecurityManual|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. 1. 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 1. 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) 1. 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 1. Ruling to ABC request over Jochim Selzer 1. 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 [[https://wiki.cacert.org/SystemAdministration/Systems|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 [[https://wiki.cacert.org/SystemAdministration/Systems|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. * The background check has not revealed any material issues in conflict with a role under Security Policy (SP) * During the interview, no potential CoI was discovered. * Investigation of potential weaknesses in social engineering revealed that (R) has familiarity with this topic. * (R)'s background related to anticipated subject matter (Sysadmin) has been shown by experience in running some time as email admin and by further job references. * My recommendation to (C) is: should do some training to (R) regarding SP [13]/SM [14] knowledge. (R) still received an advise to read SP [13]/SM [14]. * (R) built-up a history and good reputation of activity within the Community * Observer shall wipe all handwritten ABC interview transcript files and emails (if not yet done). === 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. I. 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. I. 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]] . Security Policy to remain in DRAFT<
> [2] [[https://community.cacert.org/board/motions.php?motion=m20100327.2]] . veto over Security Policy board background checks<
> [3] [[https://wiki.cacert.org/PolicyDecisions#p20100327]] . Remove Board background checks from DRAFT Security Policy -- VACATED<
> [4] [[https://community.cacert.org/board/motions.php?motion=m20110501.2]] . New critical systems<
> [5] [[https://wiki.cacert.org/AGM/TeamReports/2010/Audit]] . "The Board picked up two priorities related directly to audit, being, . (1) work to move the infrastructure servers out of the domain of the . critical systems, ..."<
> [6] [[https://svn.cacert.org/CAcert/CAcert_Inc/General_Meetings/AGM-20100130/CAcert_Annual_Report_2009.pdf]] . with references to critical systems (p.16), SP and ABC process (p.17)<
> [7] [[https://blog.cacert.org/2010/10/489.html]] . ".. system migrations for the big Infrastructure project to separate . Non-Critical from the Critical systems (The big Infrastructure Task). . This project is running about 2 years, . but currently without progress."<
> [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 == * 2013-05-01 (A): sent ruling to: a. (R), (C) a. teamleaders of teams falling under SP 1. Critical, 2. Support, 3. Software-Assessment, 4. Board as fallback for Access Engineers team (AE t/l vacant) a. (Dirk) - observer in ABC interview a. Arbitration team a. (CM) * 2013-05-01 (A): confirmation request to (Dirk) (observer in ABC interview), to have all files and emails with ABC transcript content and references destroyed. * 2013-07-21 (A): confirmation request to (Dirk) (reminder #1) * 2013-05-24 (A): confirmation request to (Dirk) (reminder #2) * 2013-11-21 (A): confirmation request to (Dirk) (reminder #3) * 2013-11-27 (Observer): destroyed all files/emails regarding the ABC interview, (interview transcript and updates to this transcript), notification by signed email * 2013-11-27 (A): notification to all arbitration participients, case closed. == Similiar Cases == || [[Arbitrations/a20091209.1|a20091209.1]] || [[Arbitrations/a20091209.1|Arbitrated Background Check over Wolfgang Kasulke]] || || [[Arbitrations/a20091215.1|a20091215.1]] || [[Arbitrations/a20091215.1|Arbitrated Background Check over Martin Schulze]] || || [[Arbitrations/a20120211.1|a20120211.1]] || [[Arbitrations/a20120211.1|Arbitrated Background Check over Marek Michal Mazur]] || || [[Arbitrations/a20091202.1|a20091202.1]] || [[Arbitrations/a20091202.1|background check for support crew Michael Tänzer]] || || [[Arbitrations/a20100116.1|a20100116.1]] || [[Arbitrations/a20100116.1|Arbitrated Background Check over Markus Warg]] || || [[Arbitrations/a20100908.1|a20100908.1]] || [[Arbitrations/a20100908.1|Arbitrated Background Check over Bernhard Fröhlich]] || || [[Arbitrations/a20120418.1|a20120418.1]] || [[Arbitrations/a20120418.1|ABC Request over Martin Simons]] || || [[Arbitrations/a20120703.1|a20120703.1]] || [[Arbitrations/a20120703.1|Arbitrated Background Check over Benny Baumann]] || ---- . CategoryArbitration . [[CategoryArbCaseSystemABC]]