cacert-sysadm AT lists.cacert.org
Subject: CAcert System Admins discussion list
List archive
- From: Daniel Black <daniel AT cacert.org>
- To: cacert-sysadm AT lists.cacert.org
- Subject: Re: [Cacert-sysadm] Security Manual comments
- Date: Fri, 20 Jun 2008 07:22:51 +1000
- List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
- List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>
- Organization: CACert
On Fri, 20 Jun 2008 05:06:16 am IanG wrote:
> Hi Pat,
>
> as we don't have a security list, I'll post some comments
> here, below.
Good idea.
> From 1.2 --> 2.2 inclusive.
>
>
>
> For others, the evolving SecurityManual is here:
>
> http://wiki.cacert.org/wiki/SecurityManual
>
> under editorial direction by Pat. She would probably
> appreciate any suggestions.
>
> ==========
> 1.2 Physical assets.
>
> Where is the inventory to be located? Currently, future?
I started https://wiki.cacert.org/wiki/SystemAdministration/Systems/Email as
an example. Is a system by system location sufficient?
> Who can inspect this?
> Is it likely to be a
> controlled-distro document? Or can we open it up for the
> world to see what kit we have?
For those that know the facilites is this being public going to incur
additional risks.
> (If we agree that it is a controlled-distribution document,
> then we could possibly create an access mechanism via the wiki?)
I agree.
> ==========
> 1.2.3.2 Destruction
> I'm less concerned by the method of destruction than by who
> is doing it and who witnesses the results. Can we add
> something like:
>
> Record of secure erasure should describe: who carried out
> the procedure, who witnessed, method of final disposal. It
> should be signed by the person concerned.
>
good.
note - probably should add a section about maintaince by vendors/contractors
as far as sanitisation/supervision.
> ==========
> 2.1.1 Infrastructure
> Diagrams of physical / logical. Again, I'm concerned that
> they be *available for scrutiny* because if not then they
> will be lost, if not in reality, in effect.
>
> Can we decide where the diagrams are held, and in what form?
> I'm assuming digital, which of course then leads to a
> discussion of what tools...
i've got some in svg which is ok. I just use inkscape currently.
> ==========
> 2.1.2.1/2 Ingress and Outgress
> I see this blocks idle ports. OK.
>
> What it does not say is whether access is blocked by IP#s.
true. probably should - I've incuded this in the Email system wiki page.
I need to do outgress usages too.
> Currently, Philipp has it set up to block SSH access unless
> in a white-list.
it lowered our risk profile with the debian ssh thing went public.
> This was a serious issue;
I'm happy if this is limited provided the admins have access via a static IP.
My relaying off a box Philipp controls isn't ideal but it works.
> if there is a
> decision that this is policy, then we should also add that
> part to that section.
>
> My understanding is at this stage Teus has accepted it as
> policy, so it should go in.
Something like: "if possible tcp/ip services services should be limited to a
location where they are used."
>
> Or is this an issue for 2.4 Access Control?
for ssh i'd say it is. thats 1/2 why i did that rough statement in tcp/ip
services terms.
> ==========
> 2.1.3. Intrusion detection
> Who is the appropriate person? It could be "systems
> administrator designated for that role" or "systems
> administraion team leader"
i'm more in favour of these two.
> I'm not so fussed who it is, I would just make my life
> easier if I can see a name or role, then I can ask that
> person some audit questions.
>
>
>
> ==========
> 2.2.2 Patching
>
> You have kicked the central discussion over to the CCS
> there, which is fine. There are some changes there, which
> now says:
>
>
> http://wiki.cacert.org/wiki/PolicyDrafts/ConfigurationControlSpecification
> -------------
> The Systems Administration Officer (SAO) is responsible for
> implementing changes to any kind of software.
notice this has some good scoping that the SM doesn't.
> The SAO maintains a log to record all changes and reports to
> software. All software installations and updates are logged.
>
> Software changes should be checked and approved by a second
> system administrator. If another administrator is not
> available, the check is generally deferred.
>
> Patches. The SAO watches and tracks the newsfeed of patches
> from distributors of software. CAcert uses the stable branch
> of any distribution,
approval process for non-stable packages defining business case and the risks
incurred?
> and applies patches when deemed
> necessary. The SAO authorises the patch and notifies M-SC of
> the intention.
intention or result?
>
> New Software. New software, configurations or ports that are
> not encapsulated in vendor patches are to be authorised by
> M-SC on request by SAO.
>
> List. Changes to the above list of controlled software are
> authorised by M-SC on submission from SAO.
--
Daniel Black
(daniel AT cacert.org)
Email Adminstrator
Attachment:
signature.asc
Description: This is a digitally signed message part.
- [Cacert-sysadm] Security Manual comments, IanG, 06/19/2008
- Re: [Cacert-sysadm] Security Manual comments, Daniel Black, 06/19/2008
Archive powered by MHonArc 2.6.16.