Skip to Content.
Sympa Menu

cacert-sysadm - Re: questions from the board on OTRS

cacert-sysadm AT lists.cacert.org

Subject: CAcert System Admins discussion list

List archive

Re: questions from the board on OTRS


Chronological Thread 
  • From: Ian G <iang AT cacert.org>
  • To: cacert-sysadm AT lists.cacert.org, Cacert List SE <cacert-se AT lists.cacert.org>
  • Cc: Ian G <iang AT cacert.org>
  • Subject: Re: questions from the board on OTRS
  • Date: Tue, 23 Feb 2010 15:15:47 +0100
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none

On 22/02/2010 23:24, Ian G wrote:
Board has asked us to comment on the following questions concerning
OTRS, the issue tracking system used by Support:

* Is it compliant with SP / SM?


SP primarily covers the online website. See SP1.1. The special features in the website made available to SEs are under control of SP.

SP1.1 also says "Board may add additional components into the Security Manual." (The Board has not done so for OTRS, and did not do so for the prior system, mailbox.)

SP also states that channels must be documented in SM. This exists in SM 8.3. I've updated that to provide more reference to the OTRS, although the current way we talk about channels is that the channels are inside OTRS and other places, not that OTRS is a channel.

Also channels should be logged. This probably applies to the use of OTRS, and we should figure out how OTRS logs.

Overall, I conclude that OTRS is not included in SP's meaning of a critical system, and to the extent that SP/SM talk about it, it is documented adequately.


* where is the workflow?
* should the OTRS be a critical system?


That leaves this big question above: do people feel that the support tools such as OTRS should be "critical systems?" And in the past, the mailbox.

Now, if the answer is YES, we should probably also look at Mail, and other associated tools like blog & wiki.

If the answer is NO, is the incoming private information covered adequately by the "infrastructure" security level? One way of addressing this is that the incoming emailed privacy information can be compared to that seen by the average Assurer.

comments?


iang



* should Triage people be fully under Security Policy?
* where is the description of the system and its security?
* who are the people who control access to the system?

That's a work in progress. We probably should have a post to board by
mid next week. Let us know your thoughts :)

iang



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




Archive powered by MHonArc 2.6.16.

Top of Page