CAcert System Admins discussion list

[Ian G <iang AT cacert.org>]

Hi Mario and Wytze

Just on this question of audit and future.

On 9/08/10 1:35 AM, Wytze van der Raay wrote:
> On 08/07/2010 04:06 PM, Mario Lipinski wrote:

> > Once there is an audit we can show that the systems are designed
> > independent and they can be moved out. And not having done so is just a
> > reason of the resources available by then.
>
> Well, we can show that also now. It depends very much on the auditor
> and his/her procedures whether that is considered sufficient or not.


Right, it's a bit of both.  The difficulty I saw as once-auditor was 
that there was sufficient intermingling to make it hard to form a 
conclusion, without quite stringent testing of the controls.

Things came somewhat to a head for me personally when one access 
engineer was granted sysadm access to an infrastructure server. 
Although this is doable, and an Arbitrator OK'd it, it raises questions. 
 It means for example that an access engineer has an ability to SSH 
into the hop machine, and thence into the internal network.  It also 
means that the person concerned has a reason to be poking around in the 
rack and reading console messages:  to reboot the infrastructure server. 
 By himself.

This puts stress on all the other controls;  they have to work, which 
means they all have to be tested fully.  More work for the auditor, but 
also more stress and bureaucracy for the critical team and the access 
engineers.

Before hand, we had controls, *plus* no stress, in that the access 
engineers had no reason to access software, or access hardware without 
coordination with critical system team.  So any access was _a priori_ 
wrong.  These two things worked together well, and made audit "easy".



So we decided the ideal position as having the infrastructure machines 
outside the SP / BIT / critical team domain completely.  Then, the whole 
above question disappears, *and* we can use our sysadm resources more 
economically.

Separation is the objective.

Then there is the implementation.  We decided we wanted multiple sites, 
for several reasons:

  * the ideal HR situation seems to be a small tightly-knit local team, 
close to the server.
  * with 2-3 sites, each can do redundancy and backup on a remote site.
  * any hosting situation is a big and risky project, so we felt that 
going for 2-3 would give us more chance of success, with 1-2.  This was 
based on our experiences with the AT-NL transition, that took around 2 
years.
  * we want more sysadms, partly so as to feed the critical team.



On the one hand, this was a lot or mostly or entirely my analysis.  A 
future auditor would likely make up his or her own mind.  And the board 
might decide to adjust this.

On the other hand, I don't see the analysis as being fundamentally 
challenged.  The implementation has hit some roadblocks, but that's 
distinct from the analysis and strategy.

So, options.  If you think putting the infrastructure machine outside 
the firewall, and on the open net .. is a good idea, then I'd agree. 
That gets rid of all the "software/internet" access issues.  It doesn't 
get rid of the hardware/access temptations though, so I'd also see it as 
an intermediate step.  But an intermediate step is often better than no 
step.

Also, there are other options:  moving the VMs off one at a time to 
perhaps the Sonance site;  talking to HCC;  reducing the number of VMs; 
 exploring a TLS/SNI multi-hosting arrangement.



iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature