CAcert System Admins discussion list

[Ian G <iang AT cacert.org>]

On 27/02/2010 16:05, 
ulrich AT cacert.org
 wrote:

> > ......  But is OTRS covered
> > by SP at all?
>
> Ok, rethink this question from another PoV:
>
> the webadmin console to edit/delete accounts
> is the main purpose why SE's are under SP/SM
> They have direct access to the "critical" data
> thru the webadmin console interface



Yes.  SP covers the access to the online system.

email from support people was not considered in SP, although it was a 
consideration, because people send sensitive stuff.


> > > * should the OTRS be a critical system?
> > Maybe. But then we should think about mail first. Maybe we even need to
> > do some more seperation then just betweens critical/infrastructure.


Right, if we put OTRS in "critical" under SP then a lot of other stuff 
goes as well.


> > > * should Triage people be fully under Security Policy?
> > Imho yes.
>
> Triage people has no access to the Webadmin console interface ...
> and therefor no direct access to the "critical" data


Right.

> so we have to define, if the support mails are covered
> by the "critical data" definition or not ...
> if no, Triage need not to be under SP/SM
> if yes, Triage needs to be under SP/SM


Right.

Triage people see stuff that is sent to them by users and others, and in 
that act, one can assume that the people give permission for additional 
sight of that data.  So no additional permission is needed, we can 
simply imply it to cover Triage.

Hence, I analogise that Triage is not much more than say an Assurance, 
where an Assuree puts lots of info before the Assurer, and asks for the 
Assurance.  In that act occurs the implied permission for the privacy 
opening, also now stated in the "I give permission / request an Assurance."

Here is my logic for having the Triage team only mildy covered by SP:

https://lists.cacert.org/wws/arc/cacert-policy/2009-12/msg00041.html

I saw no objection on the policy list.


My thoughts ...

iang

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