Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

I wanted to split my answers into multiple separate emails, to make it easier 
to respond to a single item, but the answers are too much interlinked.

> > If so, my first responses are:
> > 1) full responsibility for both approval and implementation of 
> > changes
> > (HW/SW) are combined in one person ==> not really "industry best
> practice",
> > I would suggest have this split into two persons
> 
> Yes. You are fully right, it would be best practice to have that split 
> into two persons. The problem is just that we don´t have two persons 
> available locally.

I don't think you'd need to have them both available locally. 
When someone (or maybe a group) else would define/approve the change, and 
then forward a "change implementation request" to the local admin, you would 
have implemented dual control. 
It would also make auditing easier: 
- Every change without request is suspect and needs reviewing
- every change request that has not been implemented correctly needs reviewing
- every change request that has been correctly implemented has been reviewed 
by at least two individuals

I see multiple phases in the change process:
1) an event/incident, requiring a change
2) a request for a change (probably requested by the system admin, or by a 
selected group)
3) a change implementation request (the request created by the change 
manager), that is the "work order" for the system admin
4) a implementation log, that is the description of the implementation, 
created by the sysadmin, and sent to the change manager and other selected 
individuals

The whole process can be monitored by a select group of individuals. It can 
also be monitored by a bigger group, by sending them signed hashes of the 
events, the change request, the implementation request, and the log entry. 
This group would then be able to monitor the whole change management process, 
without knowing in detail what changes are implemented.

This might look like a complex process, but adds governance because it makes 
the process transparent and auditable, and removes the dependency on a single 
person.
Also, this is a way to protect the current sysadmin: he/she will know that 
any unauthorized change will be noticed, and can use that in case he/she is 
bribed or blackmailed in any way shape or form.


> > 2) hardware changes are
> > not document ==> not acceptable, you will need a approval process 
> > and
> full
> > logging.
> 
> I am planning to change that policy as soon as we have enough 
> capacities to fulfill it.

I'm sorry, I do not understand why a change log is not mandatory. Documenting 
changes is vital, especially to be able to rollback changes that lead to 
errors. Cannot go into detail, but I've seen multiple companies with core 
systems down because the sysadmin made a change a few weeks earlier, and no 
one knew about it because it was not logged. It is even more important if 
there is only one sysadmin.

This brings up another question: if there is only one sysadmin, then what is 
the DR policy for CAcert?

> > 3) root certificates are the responsibility of the administrator ==> 
> > not acceptable, you'd need a certificate change ceremony for all 
> > changes, with at least two separate key administrators who need to 
> > be present, and key components (for backup) under control of at 
> > least two other key custodians.
> 
> Yes. All three changes demand more ressources than we currently have.
> Keep in mind that CAcert is geographically spread around the whole world.
> Our trusted core team are currently 4 people, one in Australia, one in 
> Brazil, one in France and one in Austria. That´s quite contrary to a 
> normal company, having all people in the same place.

As I described in my answer for software changes, being geographically 
distributed adds some hassle, but does not make it impossible. SW and HW 
changes can be done via an auditable process as described.
However, key changes is another thing.  I do not know how many persons are 
available at the location of the core system, but with enough procedures this 
can be done in a safe way. It is relatively common to use trusted employees 
as the custodians for key components. This would require their attendance at 
all changes to important keys, thereby creating a de facto dual-control 
system.
These key custodians should not be able to have physical or logical access to 
the core systems, and would need to be escorted to these systems during key 
ceremonies.

> 
> > You'd need more detail, and more procedures.
> 
> Can you go into detail?
>
Yes, I've seen a number of these type of procedures, but they are always 
location specific. How complex do you want them?
Another issue here: key management procedures are normally "internal use 
only" and even "need to know only".  Describing high level policies seems OK 
to me, but do you also plan on describing roles and responsibilities on a 
work instruction level here?


Regards, Lambert Hofstra