= Arbitrated Background Checks =

Recently some questions have arisen about the purpose and effectiveness of ABCs. At the same time there seem to be some
fundamental misunderstandings about what the intent behind arbitrated background check is.  Having been part of designing this system, I feel it is high time to clarify these issues and let the community know what an ABC is good for and what not. 

Right off the bat I want to dispel a myth: an ABC does not prevent the infiltration by an agent of a security service. We do not catch out spies. I think this is an important realization to have. Not just does an ABC not catch spies, it is also not intended to. As a matter of fact, if an employee of a security service were to come along and disclose his employment situation, it would not mean that he would not "pass" his ABC.

Which is where I need to dispel the second big myth. An ABC is not something you can pass or fail. The only people that can fail an ABC are the clinically insane.

But rather than go through all the myths about ABCs point by point and dispel them, I think it better to actually explain what an ABC is supposed to accomplish and how it works.

To begin with we have to make clear statements about some of the needs of CAcert.
1.  We have more stringent security needs than your average Open Source project, simply because we deal with our members personal data. As such we need to make every effort we can to ensure this data is kept safe. 

2. Most leaks and abuse of personal data, in fact most security breaches, happen not because of maliciousness on the part of staff, but rather because they either over estimate their own competence or are simply negligent because they do not understand the security needs an procedures and environment of the tasks they undertake. 

On the base of these fundamental assumptions, we have decided to start doing ABCs on all personnel that has access to sensitive data. Specifically these areas are "Critical Systems Administration", "Support Personnel" and "Software Assessors". Each of these roles has different security relevance and different security needs in their role.

A "Critical System Administrator" for example is charged with running our servers. As we all know, any little kid can run a little Linux server. And just in terms of running and maintaining our systems there is very little that just about anyone in our community could not do. But then there is our security. We do have a four eyes principle in place and our administrators need to understand why. They need to understand the nature of the data they are working with and the implications that follow from that. They need to, for example, understand that we cant just let our backups lay around for anyone to grab.

Most people, and this is also true for our members, have expended very little thought about what security means and what the consequences are that flow from that. 

But let's take the next role, the "Support Person". A support person has direct access to other members accounts and can make modifications to them. That's great, let's just mess around with member's data! Well there are security implications here. When may a support person take what action? Ever heard of social engineering? Have you ever done a job with sensitive data like this in the past? What were your experiences there? What would be a good thing to do if you are threatened to force you to hand over another user's account? What support can CAcert give you in such a circumstance? These are some of the questions that may be discussed with a potential "Support Person".

And last but not least the "Software Assessor". Is there anything in the person's background to uniquely qualify them to examine code for security problems? Do they have any background in secure programming or are they more of a general programmer without any security background. What software should the person look at? What you have had experience in crypto programming for the NSA? Well great, maybe you would be a good person to examine the code of our signing server and report on any issues you find!

As you may already be able to tell, Arbitrated Background Checks are not about the background of a person in terms of criminal history as much as about background in terms of capability. It's more about experience, and where training is needed. It's more about does this person seem mentally stable or not. Are there things in the persons past that put them at risk if they were to work on sensitive data. And last but not least it's about conflicts of interest.

It is clear by the simple fact that the ABC is started, that one of the persons interests is CAcert. Are there other competing interests, that would make the assignments of some tasks risky? Are there other allegiances that would put the person on the spot in certain circumstances?

Let us assume a "Software Assessor" that is also a critical systems programmer for VeriSign (for any value of VeriSign). If that person found a flaw in our systems they would have to decide whether their interest is really in securing CAcert Systems or whether disclosing the flaw to their employer would be more in their interest. We do not want to put people into positions where they are forced to make such a choice. There is a plethora of things that person could still do for CAcert, being a "Software Assessor" is still one of them, but maybe not in certain areas.

Let us assume a "Support Person". Are there things that predestine them to be blackmailed into tampering with accounts? Are they aware of their own risk factors? These are people that may come under pressure, and we do not want them to be unsupported when that happens. We want our people to know what options are open to them when they come under pressure and what we expect of them. We want to help our people to assess risks and act accordingly.

The Arbitrated Background Check is intended to facilitate this by asking an experienced person to have a discussion with a potential staff member. Have a discussion and enable the potential staff member to discuss their life, skill-level and circumstances in an open way. It is intended to establish the strengths and weaknesses of a potential staff member and discuss how to mitigate their weaknesses. This is something most people are loathe to do in a public forum, but it is a necessity if we are to grant a person access to sensitive material.

I have yet to meet the person that "passes" his ABC with flying colours. The person where the report will say, this is a perfect candidate and has no weaknesses whatsoever. Every single interview I have done to date has come up with something the person should look into. The only person I am truly opposed to doing an ABC with is the person that goes into the process saying "I should not be working with sensitive data". Most often they are right.

The last thing that an arbitrated background check is supposed to accomplish is to establish a record to protect the potential staff member from the community. Any community I have ever seen has its weak moments. Assume a security breach where a staff member is involved. There will be inevitably be questions raised by the community. And there will be accusations thrown about. As long as we are human beings this will happen. One of the most damaging accusations is "why did you not tell us relevant fact XYZ" before hand. It is damaging, because it is most often both irrelevant to the cause of the breach and second is most often simply an ad hominem attack. We want to give our staff members the opportunity to establish the record beforehand. This way such attacks fall onto barren ground, because they did in fact disclose XYZ beforehand. This affords our staff a measure of security and certainty that is invaluable for the tasks they have to perform.

As I described in the beginning, there have been qualms about the ABC process, both in terms of purpose and in terms of effectiveness. I would like to invite the community at large to review the process. If anyone knows of a better way to accomplish our goals, I am more than willing to listen and work with them. I can be contacted through my CAcert E-Mail Address at any time.

Regards,
PhilippDunkel

'''P.S.: This page describes my personal view and does not represent an official view held by CAcert.'''