CAcert System Admins discussion list

[Lambert Hofstra <lamberthofstra AT gmail.com>]

Hi Ian,

my short short summary of your proposal is:
- add a group that filters incoming email and forwards to the correct
group. Since the people in this group have no access to critical systems
we don't need ABC, even though t the people in this group might come in
contact with private info

My short answer is:
- I agree, go ahead

Explanation:
our SP covers specific security issues (systems, people) that have a
significant impact on CAcert. Support is one of the groups that is
covered, because they potentially have direct access to all data.
The Triage (??) group only receives info, but cannot initiate access to
private info. Therefore the impact of a security breach is way smaller
(what can happen? Forward an individual email?)
Since we request these people to be full assurers, they are bound by the
CCA. Because of their role they also have to adhere to specific
procedures (privacy and all).

So in my opinion the remaining risk is very small: who from the triage
would want to risk a full fine by forwarding an accidental email? No
individual gain but a lot too loose...

So in my opinion: go ahead!

Btw. also include Ted's comments, I also agree with those!

Lambert



Ian G wrote, On 19/11/2009 12:17:
> To (people who think about policies),
>
> *background* as per last weekend, the board decided to make me
> temporary support officer.  (This was in a wider discussion including
> the vetoing the Security Policy, which remains an option on the table.)
>
> As Support Officer, I don't think I've yet breached SP, but I'm coming
> close.  See the relevant snippets at bottom.
>
> *plan*  Here's what I plan to do:
>
>
>
>                /----> SE   ... support engineers ("fix")
>               /
>              /
>              |   /--> help ... help team (maillist cacert-support)
>              |  /
>              | /
>   triage team ------> disputes ...  case managers  -->  arbitrators
>              |\
>              | \
>              |  \---> meta ... stuff related to support, but not
>              \
>               \
>                \----> buckets ... visible/searchable by SEs
>
>
>
> a.  create a new group primarily staffed by Assurers with no
> background check to manage the "mailbox" that is filled with support@
> email.  I call this new (as yet unformed) group "triage".  Its job is
> to read the email, and forward it to one of about 4-8 "channels",
> depending on how we count.  "All" they can do is read mail and forward
> it.  The danger is that they see privacy details, and they can
> potentially fiddle by injecting/blocking stuff.
>
> b.  Software Engineers will be one of the channels.  These people will
> be checked out under ABC (Arbitrated Background Check).  3 - 4
> Assurers are in the process now.  These people will receive the emails
> from triage, and they will have the special online system powers.
>
> See more, evolving story at
> https://wiki.cacert.org/comma/Support/Triage
>
>
>
> *analysis*  Now, here's what I think:
>
> i.  Email, the mailbox, the support@ address and the reading of the
> incoming mail are *NOT COVERED* by Security Policy.
>
> Therefore I can construct the triage team, and put people onto the
> emailbox reading and forwarding with no clash with Security Policy.
>
> ii.  In contrast, the online www.c.o. system special access methods
> are somewhat more clearly controlled as they are specifically mentioned.
>
> Therefore, we need to follow those controls, or file dispute to get an
> override access, or get access then file dispute to confirm emergency
> access.
>
>
>
> Now, you might disagree.  Also, you might think that SP should be
> changed to "correct" the interpretation, close the loophole.
>
> But, in the absence of feedback and help to change SP, etc, my guess
> is that right now I should just charge on and do it.
>
> Comments?
>
>
>
> iang, writing as temp-SO
>
>
>
>
>
> *Security Policy snippets*
> https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html
>
> ===========================
> 3.4. Access control
> All access to critical data and services shall be controlled and logged.
> 3.4.2. Special Authorisation
> ...
> Support Access List - Support Engineer - support features in the web
> application
>
> 8.1.  Authority
> The software interface gives features to Support Engineer. Access to
> the special features is under tight control. Additions to the team are
> approved by Board, and the software features are under CCS. See §3.4.2.
> 8.3.  Channels
> Support may always be contacted by email at support at cacert dot org.
> Other channels may be made available and documented in Security Manual.
>
> 9.1.1.  Roles and responsibilities
> ...
>     * Support Engineer: human interface with users.
> 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:
> ...
>     * Support Engineer
> ==========================End.